SDK ראשון לSilverlight

אם לשפוט לפי התיאור בעמוד ההורדה - הSDK כולל מדריכים, דוגמאות, תיעוד וכלים לפיתוח בSL 1.0.

מאידך, אם לשפוט לפי תוכן התיקיות שהוא התקין - הSDK נראה מעט עני (קובץ CHM עם התיעוד של המוצר, תוסף הIntelliSense לVS, דוגמאות במסגרת המדריכים ועוד כמה שטויות..)..

http://www.microsoft.com/downloads/details.aspx?FamilyID=fb7900db-4380-4b0f-bb95-0baec714ee17&DisplayLang=en

מה אתם מעדיפים? מסד נתונים או קבצים (על מחלות של מפתחים)

החלטתי ללכת בעקבות ג'אסטין, ולכתוב גם כאן תשובות נבחרות לשאלות בפורומים בהם אני פעיל.

היום נשאלה שאלה בפורום התכנות באתר פרש – "מה אתם מעדיפים - מסד נתונים או עבודה עם קבצים?" כותב ההודעה הכריז שהוא אישית מעדיף עדיין לעבוד עם קבצים, אבל ביקש משאר הגולשים לחוות את דעתם.

התקבלו שם מספר תגובות שבעקבותן המשתמש תאר את הבעיה האמיתית:

"אני מתכנת כתחביב , ותמיד אהבתי להתעסק בכתיבת אלגוריתמים משלי לחיפוש , עדכון וכו' של נתונים ואילו מסדי נתונים נראו לי עבודה קלה מידי ופחות תכנותית.

האמת היא שלאחרונה מתחילות להיוצר בעיות מהירות.... ולכן העלית את העניין."

בעיה ראשונה – השאלה הנכונה

בכל פרויקט קיימת פונקציה של ארכיטקט פתרון (Solution Architect). אותו אדם (שלרוב יש לו עוד כובעים בפרויקט, פשוט בגלל שבד"כ לא מכירים בחשיבות של הפונקציה הזאת ובטוחים שזו תכונה אזוטרית של תכניתן) אחראי להכיר את עולם הבעיה של הפרויקט ולספק תכן פתרון (או מספר פתרונות אפשריים) בצירוף מעט מלל אישי על יתרונות וחסרונות, שיקולים בבחירת הפתרון ופתרונות דומים שכבר מומשו.

כדי לענות על השאלה, אנחנו צריכים קודם כל לפרוט את עולם הבעיה שלנו- מה אנחנו בעצם צריכים?

הנה כמה כללי אצבע שאנחנו צריכים לשאול את עצמנו בהתחלה של המצאת פתרון:

1. מהו החזון הכולל של המערכת אותה אנחנו הולכים לאפיין? (מערכת ניהול חשבונות למשרד עורכי דין... מערכת שליטה ובקרה לטילי קרקע קרקע.. וכו')
2. מהו הקונספט הכללי של המערכת? (האם מדובר על אפליקציה מבוזרת, אתר אינטרנט, תוכנה למחשב כף יד?)
3. מהו הקונספט הארכיטקטוני הכללי? (בהינתן הקונספט של המערכת, ננסה לזהות מהן החבילות שצריכות לדבר ביניהן)
4. מהי הסביבה בה המערכת צריכה לעבוד? (האם ישנן דרישות רשת כלשהן? דרישות חומרה מיוחדות? דיסקים מהירים במיוחד, כרטיס מסך חזק?)
5. מה עם זרימת המידע בפנים ומחוץ למערכת? (האם ישנם ערוצים מאובטחים? האם צריכים לקיים תקשורת בין כמה תהליכים?)
6. מהן דרישות הביצועים של המערכת? (כמה זמן ייקח ביצוע של Use Case?)
7. מהן דרישות האמינות והשרידות של המערכת? (MTBF? NetApp? NLB?)
8. מהן דרישות ההרחבה העתידיות של המערכת? (האם כמות המשתמשים תעלה? האם כמות המידע תעלה? האם יהיה צורך במודולי תוכנה נוספים בהמשך?)
9. מהן דרישות האבטחה של המערכת? (מערכת בטחונית? מערכת מבוססת DMZ? חתימת קוד מקור? הרשאות למשתמשים?)
10. מהם הסטנדרטים בהם יש לתמוך? (סוגי קבצים, תקשורת, אבטחה, אבטחת איכות?)
11. DFO – (מהי מתודולוגית ההפצה והתפעול של המערכת? כיצד תתבצע התמיכה בעתיד?)

ברגע שנשאל שאלה כמו "מה אתם מעדיפים? מסד נתונים או קבצים", פשוט נעבור על הסעיפים שהוזכרו לעיל ונשאל את עצמנו – מה מבין השניים ייתן לי פתרון כולל יותר לבעיה שלי? מהן ההשלמות הנדרשות עבור כל אחד מהשניים?

בעיה שניה – הגלגל כבר הומצא

COTS. המחלה של כל תכניתן, ארכיטקט או איש מערכת "נטול אינטרסים" היא להמציא את הגלגל מחדש, באצטלה של NIH. מה שלא הומצא כאן – פשוט לא טוב. איך אני יודע את זה? כי אני לא עשיתי את זה.. ואם אני לא עשיתי את זה, זה לא טוב.

תכניתן טוב הוא כזה שהחבר הכי טוב שלו הוא Google.com הוא Live.com. אחד שיודע להוריד פתרון מלא מהאינטרנט, להשוות ביקורות.. להריץ בסביבת מעבדה ולבדוק, ובסוף להטמיע בתוך הפרויקט.

כולנו אוהבים ללכלך ידיים... או לפחות, כשזה מעניין אותנו. בשנים האחרונות נראה כאילו עבודתו של התכניתן בעצם הפכה אותו לאינטגרטור של מודולים קנויים (או חינמיים). זה מעצבן אותנו. בגלל זה, אנחנו מנצלים את מרחב המחייה הקטן שיש לנו בשביל לייצר לעצמנו עבודה. כך לדוגמא, אנחנו נבחר להמציא פתרון EAI משלנו במקום להשתמש בiBolt/Biztalk/WebSphere או כל קקי אחר. אנחנו נבחר לממש DAL בעצמנו במקום להשתמש בADO.NET, LINQ, Nhibernate וכו'. אנחנו נממש בעצמו Logger, כי אנחנו יודעים הכי טוב לטפל בקבצים וLAB וLog4Net לא מבינים מהחיים שלהם – ובקיצור, איפה שרק נוכל ואיפה שנזהה חולשה של ראש צוות הפיתוח, אנחנו ניישם את האינטרפרטציה האישית שלנו.

במקרה שראש הצוות מבין משהו ומכיר פתרונות מבחוץ, אנחנו נסבן אותו במונחים כמו "הפתרון שלהם לא מספיק ג'נרי" או "הפתרון שלהם חסר", כשבפועל הפתרונות האחרים כמעט תמיד עוברים את מבחן ה80:20, ובמרבית הפרויקטים גם את ה90:10. יתרה מזאת, ניתן להוכיח באינדוקציה שה10/20 לא רלוונטיים בכלל. גם בשיקולים כלכליים טהורים כבר נתקלתי. בפרויקט שלאחרונה פסקתי בעניין תשתית הDeployment שלו, ניסו לשכנע אותי שלא Deployment Project של VS ולא InstallShield מסוגלים לתת מענה ל"דרישות ההפצה המורכבות שלנו", וניסיון להתאים אותם "יעלה לנו יותר כסף מלכתוב הכל מחדש". אחרי שישבתי עם ראש צוות התוכנה שהגדיר את דרישות ההפצה בגינן נכשל הIS והVS, גילינו שבעצם... הדרישות, בניסוח מעט שונה, כן ניתנות כולן לביצוע על הכלים הקיימים. בסופו של דבר, אחרי יומיים עבודה בחפיפה של סטודנט – הצלחנו לחסוך חודש עבודה ב"פיתוח תשתית הפצה ג'נרית לטובת פרויקטים בארגון, שתעלה פחות מרישיון לIS" ביננו? יום עבודה שמישהו מהצוות שם היה צריך לבזבז – עולה יותר מרישיון לIS.

בעיה שלישית – נסיון העבר

רובנו בני אדם. יש לנו התכונה המולדת – זכרון. ברגע שאנחנו תוקפים פרויקט, אנחנו תמיד זוכרים מה עשינו בפרויקטים קודמים – לטובה ולרעה. במידה וניסינו להטמיע מערכת כלשהי וכשלנו, לעד נהיה נגד המערכת הזאת. במידה וזו הייתה הצלחה כבירה – הרי שזו צריכה להיות התשתית שלנו לכל פרויקט, גם אם מדובר על מערכת GIS והפרויקט הוא כתבן.

לפעמים (או אולי אפילו ברוב המקרים) זה יעבוד. אם בחרנו תשתית GIS לפרויקט אחד וזה הצליח, ייתכן שכדאי לבחור אותה גם לפרויקט אחר. בעיקר לצורך שמירת תאימות בתוך הארגון, כך שתכניתנים שעוברים בין הפרויקטים לא יצטרכו ללמוד את הגלגל מחדש, ובנוסף – עלות הרשיונות יורדת ככל שמשתמשים יותר באותו מוצר. יש יתרון ברור לשימוש חוזר במוצר. מצד שני, מה אם תשתית הGIS שבחרנו בפרויקט הקודם לא הייתה מתאימה? מה אם נאלצנו לאכול קש? האם אנחנו צריכים להנציח את הטעות הזאת גם בפרויקט החדש?

לדידי, אין תשובה חד משמעית לשאלה הזאת. מחד גיסא, כן. עלות השכתוב של הפרויקט המקורי בד"כ מורידה את הרעיון מהפרק – מה שבהכרח מייצר שני פרויקטים שמבוססים על שתי תשתיות שונות. מכאן, שלעתים נכון להשתמש בתשתית קלוקלת גם לאחר שזה כבר ידוע.
מאידך גיסא, פרויקטים, כמו תינוקות – נוטים לייצר קקי. פרויקט תמים וקטן יכול לעתים להשאיר אחריו ערימה גדולה ומסריחה שאח"כ צריכים להתמודד איתה עם מני "חיתולים" (להלן: Workarounds). חיתול עם קקי עדיין נשאר מסריח, וגורם לבעיות בProduction.

ולכן – כל פרויקט צריך להבחן בנפרד. לכל פרויקט צריכים לבצע את השכלול של עצמו. ולפעמים, אין מנוס אלא להחליף תשתית... אבל בד"כ, זו פעולה שתעלה כסף בטווח המיידי והרחוק.