-->

יום שבת, 22 בדצמבר 2012

סמינר על פיתוח למובייל בכנס MOBI WEB של ג'ון ברייס

אודה לכם אם תפיצו למי שעשוי להיות רלוונטי ו/או מעוניין.

עדכון: גיל גבעתי, מנכ"ל Efficens Software, יצטרף אלי וידבר על ניתוח התנהגות משתמשים בתוך אפליקציית המובייל.


כנס MOBI WEB כולל מגוון מרצים ונושאים סביב לנושא המובייל - יש עוד הרבה נושאים מעניינים (חלקם גם בחינם).

תודה מראש,
ליאור


יום שישי, 21 בדצמבר 2012

במה שונה פיתוח למובייל?

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

שפה חדשה

האם אתם שולטים ב Objective-C? ב JavaScript? ב HTML5 וב CSS3? ב ++C/C?
אם אתם הולכים לפתח למובייל - ייתכן ותאלצו ללמוד שפת תכנות חדשה: זו כבר לא כל-כך בחירה שלכם מה אתם מעדיפים - זו דרישה של הפלטפורמה.

סביבת עבודה חדשה

כמה מכם מכירים Linux או Unix? כמה רגילים לעבוד ב Mac OS או חלונות 8 (שבה חוויית השימוש שונה לחלוטין)?
האם אתם רגילים ל Visual Studio, Eclipse וגם Xcode?
ייתכן ותאלצו להתרגל לסביבה חדשה וכלים חדשים.

ספריות חדשות

הביטו במפה הבאה שיצרתי. עם כמה מהספריות הללו עבדתם כבר? האם אתם מזהים לאיזה תחום כל ספרייה שייכת?
אתם בוודאי יודעים שלהשתמש בצורה יעילה בספריה - לוקח זמן. ייתכן ויש לא-מעט ללמוד על מנת לפתח אפליקציות מובייל בצורה יעילה.
(נכון: חלק מהספריות ה javaScript נכונות גם לפתרונות Desktop)

חזרה לפיתוח של אפליקציות מקומיות / Rich Client  / אפליקציות שולחניות

מאז שנת 2000 בערך, היה מעבר משמעותי של פיתוח אפליקציות ווב על חשבון האפליקציות השולחניות. במובייל יש חזרה במידה רבה לפיתוח אפליקציות מקומיות למערכת ההפעלה (מה שנקרא גם native).

משתמשים חדשים

כמה מהמשתמשים שלכם כיום:
  • נמצאים במרחק-נגיעה מהמחשב 90% מהזמן?
  • אומרים: "אל תתן לי להקליד במקלדת"?
  • מסירים תוכנה אם היא לא הגיבה תוך 2-3 שניות?
  • עובדים בתנאי רעש ותאורה לקויה?
אנו נוהגים לומר שאותם האנשים, עם אותם צרכים והעדפות, ברגע שהם נוגעים במכשיר מובייל - הופכים למשתמשים מזן חדש.

מומחיות חדשה

האם אתם מומחים למגע (Touch) ומחוות (Gestures)? יודעים להבדיל בין "התנהגות חלקה", "קצת מקרטע" ו "ממש flickering!"? ואם ההתנהגות לא-טובה, מה עושים בכדי לשפר אותה?
האם אתם מכירים את רוב הדגמים של המחשבים של הלקוחות שלכם ואיזו חומרה יש להם? חומרת Desktop היא סטנדרטית למדי - לא כך במובייל.
האם אתם יודעים למה אין (כמעט) סמארטפונים עם חלת-דבש? (גרסת אנדרואיד)
כיצד אתם בוחרים מה ייכנס ל Notification Area, ל Action Bar או כ Charm?

שינוי בסדרי-גודל

מעבר מפיתוח אפליקציות (Application) יחידה עם הרבה פונקציות --> לפיתוח אפליקציות (Apps) רבות בעלות פונקציה יחידה כל אחת. סביר להניח שאם לתוכנה שלכם יש כיום תפריט ראשי עם 6 פריטים, נכון יהיה בעולם המובייל להפוך 4 מהם ל-Apps* ו 2 אחרים "להעלים" (כלומר לומר למשתמש: עבור פעולה זו - לך לממשק ה Desktop).

* בלתי-תלויים!

חוקי עיצוב UI חדשים

נכון - מעולם לא הייתם מעצבי ה UI באופן רשמי, אבל תמיד הייתה לכם השפעה.
בעולם המובייל יש רף חדש של חוויית משתמש של אפליקציות פשוטות ו"זורמות". אפליקציות שלא מתנהגת בהתאם - בולטות לרעה.
יש אתגרים חדשים כאשר עובדים על מסך של "3 עד "5 (לסמארטפון) או "7 עד "10 (טאבלט) כאשר אמצעי ההצבעה הוא אצבע ולא עכבר / עט.
יש כמובן גם כמה קונבנציות חדשות, לכל מערכת הפעלה - וגם בכלל בין מערכות ההפעלה השונות.

חזרה לתכנות מוגבל-משאבים

למכשיר סמארטפון ממוצע יש 512MB זכרון סה"כ - לפעמים פחות. 
המעבד חלש משמעותית יותר, ה Storage קטן יותר והרשת אטית יותר.
מתי בפעם האחרונה לא היה לכם 1MB של זיכרון כשרציתם אותו??

חוקי ביצועים חדשים

ביצועים של אפליקציית מובייל מודדים במילי-שניות (זמן תגובה), צריכת זיכרון (ב MB) וכו' - כל אלה כנראה לא חדשים.
מדד חשוב חדש הוא (O(watt - מדד הסוללה. סוללה היא תמיד משאב בחסר כשמדובר במכשירים ניידים - וחשוב מאוד לתכנן את המערכת שלכם על מנת לנצל אותה בצורה נכונה. לדוגמה: להביא מידע קצת פחות עדכני ובאצוות גדולות, כי העלות של "יצירת connection", מבחינת הסוללה - היא אדירה.

ערוצי הפצה חדשים

כלומר אפ סטורס, כפי שכבר כתבתי עליהם בפוסט הזה

אינטגרציה הדוקה יותר עם מערכת ההפעלה

בפיתוח אפליקציה למערכת ההפעלה "חלונות" יש כמה אפשרויות אינטגרציה - אולם מלבד הוספה של Tray Icon, מעטות האפליקציות שאכן התממשקו למערכת ההפעלה מעבר ל"ריצה בחלון שהוקצה להן".
במובייל - אנו רואים הרבה יותר אפשרויות מצד מערכת ההפעלה והרבה יותר הענות מהמפתחים להתממשק למערכת ההפעלה. הסיבות העיקריות לכך הן שטח המסך המוגבל ורף חוויית המשתמש הגבוה יותר המקובל. בניגוד לחלונות, בה לרוב האפליקציות המגיעות עם מערכת ההפעלה (Notepad, Calculator) לא הייתה אינטגרציה משמעותית עם מערכת ההפעלה, מלבד ההפעלה הבסיסית, אפל דווקא הדגימה באפליקציות שהגיעו עם האייפון אינטגרציה גבוהה - והמפתחים הלכו בעקבותיה.

חלונות 8 מנחה את המפתחים לא לספק חיפוש-בתוך-האפליקציה מתוך ה UI של האפליקציה, אלא מתוך מקום מרכזי במערכת ההפעלה. כך היא נהגה גם עבור האפליקציות שלה.

ב iOS מנחים את האפליקציות לנהל את ההגדרות (Settings) שלהם מתוך מסך מרכזי של מערכת ולא מתוך האפליקציה. רוב המפתחים אכן הולכים בעקבות הנחייה זו.




שיהיה לכם בהצלחה!



יום חמישי, 13 בדצמבר 2012

האם כתיבת אפליקציות (Apps) היא דרך קלה להתעשר?

שאל אותי מישהו, לא מזמן, למה אני לא כותב אפליקציה או שתיים "סתם כדי לעשות כמה אלפי שקלים מהצד". לא חשבתי על זה בכלל. הוא אמר: "אם הייתי יודע לתכנת - הייתי עושה קצת כסף מהסיפור הזה, לפני שייגמר". התחלתי לתהות: האם באמת מספיק לדעת לתכנת ו"לזרוק" אפליקציה לאפ-סטור על מנת לקבל כמה אלפיות? הרי אפליקציות מגוחכות כגון "I am Rich" (אפליקציה של מסך בודד עם תמונת יהלום, שנמכרה ב 1000$ ליח') הצליחו להעניק לבעליהם "כסף קל" (לכאורה).


זה פשוט מכרה זהב!

איי שם ב 2008, כחודש לאחר השקת ה App Store של אפל, היו כבר כשישים מליון הורדות (!!) ל ~3000 האפליקציות שבחנות.

סכום מדהים של כ 9 מיליון דולר בחודש אחד (מתוך 30 מיליון דולר הכנסות סה"כ) התחלק בין 10 המפתחים המובילים[א]. הבהלה לזהב החלה.
תוך שנה אחת היו באפ סטור כ 55,000 אפליקציות מאושרות. אם לוקחים את זמן הלמידה של פיתוח על פלטפורמה חדשה + זמן הפיתוח עצמו - ברור שזה מספר מדהים.

למה כולם רצים, כל-כך מהר, לכתוב אפליקציות באפ-סטור?
זה לא ברור?? בואו ניקח סתם לדוגמה אפליקציה שהאחיינים שלי אוהבים, Temple Run:

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

האמת היא שהאפליקציה פותחה ע"י זוג נשוי, עם עוד גרפיקאי שעזר להם:


קית', נטלי וקיריל (מימין לשמאל). מקור: gamespot.com
...והאפליקציה מחולקת היום בחינם. מה יותר נחמד מזה?

רוצים עוד סתם דוגמה? ידידה שלי הכירה לי לפני שנה וחצי משחק קטן שנקרא "ציפורים כעוסות". כמה סדרת המשחקים הזו הרוויחה? - אין לי מספרים מדויקים, אבל הנה כמה נתונים: משחקים בסדרה הורדו לפחות 200 מיליון פעם, לפחות 12 מיליון פעמים בתשלום (יש גם גרסת חינם). בשנת 2011 רוביו (החברה שכתבה את המשחק) הכניסה 106 מיליון דולר, כאשר 67 מיליון מהם הם רווחים (אחוז רווח גבוה מאוד). ההכנסות כוללות גם מכירה של האפליקציה, אבל גם תמלוגים על צעצועים, בובות, סרטים, פריטי לבוש, כלי מטבח ועוד הממותגים עם "ציפורים כעוסות", המהווים כ30% מהכנסות החברה וצפויים לגדול. נראה שהחברה הזו מיצתה את הרווחים עד תום.

"מלחמת הכוכבים של הציפורים הכעוסות" - מותג בתוך מותג. מתי אמרתם שיהיה שת"פ עם ג'אסטין ביבר וליידי גאגא?!

זה קפיטליזם אכזרי!

מעניין להכיר גם את הצד השני של הסיפור הנוצץ. שימו לב לזה:
25 חברות / מפתחים - אחראים לכ 50% מההכנסות באפ-סטור (מקור), כל השאר (כ 199,975 חברות / מפתחים) - אחראים ל 50% השני. (מזכיר לכם במשהו את מבנה ההון במשק הישראלי?!)

יש ייתרון ברור מאוד לאפליקציות שנמצאות ברשימת ה "100 המובילות": היכולת, ממעמדן הגבוה, "להמליץ" על אפליקציות אחרות של אותו מפתח וכך לסייע מאוד למכירות. כשיש באפ-סטור כ 700,000 אפליקציות, קשה מאוד להתבלט. כשמייקרוסופט ניסתה למשוך מפתחים לפתח עבור Windows Phone 8, היא קראה: "בואו לפתח עבור חנות אפליקציות כמעט ריקה" - וזכתה להיענות רבה ביותר.

הכנסה ממוצעת לאפליקציה היא מעט יותר מדולר-וחצי לאפליקציה (שאינה משחק) או כ 90 סנט למשחק. משחקים נמכרים בפחות. ע"פ Vision Mobile (בדו"ח המלא), אחד מכל 3 מפתחי אפליקציות "חי מתחת לקו העוני" - כלומר, מפסיד על האפליקציה שכתב. כשביעית נוספים מרוויחים מהאפליקציות 500$ עד 1000$ לחודש - שזה סכום נמוך למדי, אם אתה מתכנת במדינה מערבית. סה״כ כמעט חצי לא מרוויחים ״כסף טוב״, לפחות ברמת התשלומים הישירים על האפליקציה.

בואו נחזור ל 2 ה Block Busters שלנו ש"הצליחו בגדול":
Temple Run - אמנם מכרה כ 40,000 יחידות ב 99 סנט, אבל אז המכירות החלו לצנוח. בראשית היא השתחלה ל "50 האפליקציות הנמכרות" - אך היא לא החזיקה שם מעמד זמן רב. המפתחים היו זריזים מספיק בכדי לשנות מודל כלכלי לפני שהיא תצא מרשימת ה Top 100 (אליה מגיעים באפ-סטור בדפדוף, אל השאר מגיעים בחיפוש) והחלו לחלק אותה בחינם.
כנראה שהמודל החינמי התאים יותר לקהל היעד - שהוריד הפעם 46 מיליון עותקים.
המפתחים הוסיפו למשחק אופציה לרכוש בכסף אמיתי, מטבעות שמסייעים להתקדם במשחק (מה שנקרא "in-game purchase"). כ 2% מהשחקנים שהורידו את האפליקציה בחינם, אכן קנו כאלו מטבעות - מודל שהוביל את האפליקציה לרווחים האדירים שהיא מרוויחה כיום. כדרך אגב, אפל גובה 30% גם על ה in-game purchases, והיא דורשת את הסכום גם כאשר לא נעשה דרך המנגנונים שלה - מה שהיה הרקע למריבה האחרונה עם מייקרוסופט.

ציפורים כעוסות - היא האפליקציה ה 52 (!!) של חברת Rovio. החברה כתבה 51 אפליקציות שלא הגיעו להיות Block Busters, ואולי אפילו הפסידו. לא יודע מה אתכם, אבל אני קצת הפסקתי לכעוס על זה שיש "ציפורים כעוסות" בכל פינה - אחרי ששמעתי את הסיפור הזה. אני מניח שגם אני הייתי "סוחט כל מה שאפשר מההצלחה", לו הייתי מגיע אליה לאחר כ"כ הרבה ניסיונות.



כלכלת אפליקציות

הנה כמה מספרים:


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



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

כלומר - אפליקציה יקרה יותר = סיכון גבוה יותר.




משחקים הם לרוב פחות רווחיים, לפחות ברווחים ישירים, מה שנרחיב לגביו בהמשך.




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

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



השפעת האפ-סטור

עם ההצלחה של האפ-סטור, נוצרו בעיות חדשות למפתחי האפליקציות: שברגע שיש 700K אפליקציות שונות, קשה מאוד להתבלט. ישנו כבר תחום שלם של SEO באפ-סטור (לינק לדוגמה) וסדנאות / יועצים (כובעים לבנים וכובעים אפורים) שיסייעו לכם לקדם את האפליקציה שלכם בתוך החנות. למפתחים עצמיים, זה לא כ"כ שונה מקידום אתרים אצל גוגל - כך שהמגמה מתקבלת בהבנה.

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

לשימוש באפ-סטור יש בעיות נוספות:
  • "מתג המוות" של אפל - אפל יכולה להסיר מיידית אפליקציה, מבלי לתת הסבר מנומק. זה לא קורה הרבה - אך כשזה קורה, זה יכול לכאוב מאוד למפתח האפליקציה שזו פרנסתו. כנ"ל לגבי אי-אישור של אפליקציה מסיבה כזו או אחרת.
  • העמלה שאפל גובה על כל אפליקציה או רכישה בתוך האפליקציה, כ 30%, יכולה להיות מחיר גבוה מדי לחלק מהעסקים, בעיקר לגדולים. העיתון הכלכלי המצליח Financial Times הבין שעבורו 30% זה ההבדל בין "רווחי" ל"לא-רווחי". אפל לא נותנת הנחות.
    FT הסירו את האפליקציה שלהם מהאפ-סטור ועברו ל Mobile Web, שם אין עמלות.
  • לאפ-סטור יש מערכת דירוג / Review יחידה - עובדה זו מסייעת לצרכן לערוך השוואות, אך מצד שני אפליקציה שמסיבה כלשהי לא ״עוברת מסך״ במערכת הדירוג של החנות - עלולה להיפגע מאוד. בעולם שלפני האפ-סטור, אפליקציה הייתה יכולה למצוא סוג דירוג / ביקורת שמחמיא לה.
  • מחסור באנליטיקס - כשנקודת המכירה / פרסום היא בידי המפתח, הוא יכול לאסוף מידע דיי מדויק על התנהגות הצרכנים - מידע חשוב מאוד מבחינה שיווקית / הגדרת מוצר. אפל מספקת מידע בסיסי ביותר, גוגל מספקת יותר. כל מיני פתרונות 3rd Party מנסים בדרכים שונות ומשנות להשיג אנליטיקס על האפליקציות שלכם. קצת מידע: לינק1, לינק2.
  • עדכונים דחופים - אם יש לי בעיית אבטחה קריטית באפליקציה עסקית, הייתי רוצה להגיש תיקון ברגע שהוא מוכן. אם אני משתמש באפ-סטור של אפל - זה אישור של אפליקציה לכל דבר, ויכול לקחת גם שבוע. רק הלקוחות הגדולים ביותר של אפל מצליחים "לזרז" ולו במעט את התהליך. כנ"ל אם אני רוצה לעבוד ע"פ ה Lean Startup ולשחרר גרסאות באופן תדיר מאוד.
  • תמיכה - דוחות על תקלות גם הם מוגבלים למה שפלטפורמת האפ-סטור מספקת, וזה לרוב לא הרבה.

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


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



מודלים לרווחים מאפליקציה

  • מכירת אפליקציות - הלקוח משלם בזמן הקנייה על האפליקציה.
  • Freemium - יש 2 גרסאות לאפליקציה: גרסה "Lite" עם מגבלות / פרסומות המחולקת בחינם + אפליקציה עם יכולות מלאות בתשלום. Freemium היא דרך להתמודד עם החשש של הלקוחות מתשלום על אפליקציה שהם עוד לא ניסו.
  • פרסום - פרסומות בתוך האפליקציה. פרסומות יכולות לבוא עד כמה-שאפשר כשירות (כמו למשל ב Waze) ולא דווקא "לתפוס חצי מסך". מודל זה נפוץ במיוחד באנדרואיד.
  • In-App purchases - האפליקציה בחינם/תשלום נמוך כאשר לקוחות שרוצים יותר - משלמים על השירות. התשלום יכול לעשות עבור "כסף משחק" (לרוב במשחקים), תוכן נוסף (כתבות, מפות) או שירות חד-פעמי שהאפליקציה מספקת. ניתן לראות היום מודל זה גם באפליקציות עסקיות: סוג של גבייה ע"פ שימוש.
  • Mobile-Payments או M-Payments - לקיחת עמלה על עסקה שהאפליקציה סייעה לקיימה: ארוחה במשלוח, מוסיקה, הזמנת שירות וכו'. טכנולוגיית NFC מרחיבה את האפשרויות עבור תחום זה.
  • מינויים (subscription) - ניתן להוריד את האפליקציה בחינם, אך יש לשלם דמי-שימוש.
  • קידום לעסק חיצוני - האפליקציה לא מניבה רווח ישיר כלל, אך היא מגבה את העסק שעומד מאחוריה. דוגמה: אפליקציה עם פרטים על רכבי מאזדה (לא ניתן לרכוש רכב באפליקציה). זה מודל נפוץ בקרב עסקים.
נתון חשוב ומעניין הוא שאפליקציות לאייפד נמכרות בממוצע בכמעט פי-5 מאפליקציות לאייפון - למרות שההשקעה איננה גדולה יותר בכמו מידה. העניין הוא שמשתמשי Smartphone משווים את המחיר ל״1$״ - מספר שאפל השליטה, בעוד באייפד נוטים במידה חלקית להשוות את המחירים לאלו של תוכנה על מחשב נייד (Laptop) - הכל עניין של תפיסה.



נתונים רבים נוספים על כלכלת אפליקציות תוכלו למצוא כאן: http://www.visualisations.visionmobile.com


שיהיה בהצלחה!




----

[א] ככל הנראה היו ל 10 המפתחים האלו יותר מ10 אפליקציות.



יום שלישי, 11 בדצמבר 2012

על חנויות אפליקציה (App Stores)

דמיינו שאתם עובדים לבד על פיתוח אפליקציה לאייפון. מחיר סביר שאתם יכולים לדרוש, בלי לקבל הרמת גבה, הוא דולר או שניים ליחידה. אתם מאוד מעוניינים להתחיל ולמכור, הדבקתם כבר מודעות של האפליקציה על האוטו שלכם ועל האוטו של אמא (ואתם עושים כל יום כמה סיבובים ברוטשילד, היכן שיש הרבה לקוחות פוטנציאליים) - אבל איך ממשיכים הלאה?
  • האגדה על מכירה ויראלית ("כל קונה יספר ל 3-4 חברים ותגיעו למיליון מכירות בחודש") - לא ממש עובדת.
  • איש מכירות ייקח מכם בערך 50$ למכירה, מה שישאיר אתכם עם 48$- לעסקה, במקרה הטוב.
  • פרסומות (שלטי חוצות, עיתונים, רדיו) יעלו עשרות אלפי דולרים, אולי יותר. ספק אם תוכלו לכסות את ההוצאות
  • נניח שכבר הייתה לכם שיחה אקראית ב"סנטר" ועניינתם מישהו באפליקציה, אבל הוא מפחד להתקין על המכשיר מן קובץ ipa[א] ממישהו שהוא לא ממש מכיר!
אם אפל הייתה מספקת רק SDK, ואומרת למפתחים: "אתם יכולים להפיץ את האפליקציה איך שאתם רוצים! אנחנו לא מגבילים אתכם בכלל" - ספק אם מישהו היום היה מתרגש מ"דגם חדש של הטלפון ההוא שנקרא אייפון".


העסקה (נוסח אפל)

נניח שהיה בא מישהו ומציע לכם את העסקה הבאה:
  • אני אמכור עבורכם את האפליקציה. אם היא טובה, היא יכולה להימכר בעשרות אלפי, מאות אלפי או אולי מליוני עותקים.
  • אני אגבה מחיר צנוע: 30% מסכום המכירה. כלומר: 30 סנט לעסקה (לאפליקציה של דולר) - לא תמצאו עסקה טובה יותר!
  • הסיכון שלכם - מזערי. תשלום של 99$ לשנה בכדי להיכנס לעסקה.
  • אני אבצע את הפעולה הכספית מול הלקוח, בצורה מאובטחת, במדינות שונות, מול חברות אשראי שונות - אתם תקבלי ממני העברה בנקאית של 70% מסך המכירות (החלק שלכם) בסוף החודש.
  • אני מתווך מהימן ביותר - לקוחות מרגישים טוב מאוד לרכוש ממני אפליקציות.
  • אני מתווך מאוד ממוקד: מי שיראה פרסומת לאפליקציה שלכם, הוא רק לקוח פוטנציאלי רלוונטי (עם חומרה מתאימה). לא עוד "פרסומת לטמפונים שמשודרת לגבר בן 60".
  • אם אתם רוצים לשווק את האפליקציה שלכם בחינם - אדרבא, אני אפילו לא אקח עמלת מכירה.

איך אפשר לסרב לכזו הצעה? 700,000 אפליקציות אמנם לא סירבו, יצרו +35 מיליארד הורדות ומפתחיהם גרפו לכיסם סכום של כ6.5 מיליארד דולר בארבע השנים האחרונות.

הצמיחה במכירות אפליקציות למובייל. מקור: http://kpcb.com/insights/2012-internet-trends-update
CAGR היא גדילה שנתית ממוצעת (במקרה זה אכן נראית כמו טיל).
האפ סטור, אגב, הופיע רק עם ה iPhone 3G - הדגם השני של האייפון, באמצע 2008. למשתמשי הדגם הראשון לא היה אפ-סטור. אם אתם תוהים "כיצד זה ייתכן?" - קראו את הפוסט הזה.

בעקבות ההצלחה המטאורית של האפ-סטור של אפל החל לצוץ חנויות מקבילות אצל המתחרים הישירים: Android Market (שאח"כ הפך ל Google Play), חנות של נוקיה בשם Nokia Store (לשעבר Ovi), מייקרוסופט עם Windows Phone Store.



איך זה עובד?

אפ סטור היא לא רק "חנות": זהו ערוץ שלם של הפצה, תשלומים ותמיכה.
על מנת להוסיף אפליקציה לאפ סטור של אפל, יש לעבור תהליך אישור לאפליקציה.
המפתח יכול לשחרר גרסה מוקדמת של האפליקציה בהפצת "ad-hoc" לצורך בדיקות תקינות / שימושיות / בדיקות-ביטא למספר מצומצם של מכשירים שהוא יודע את ה Unique Id שלהם. משתמשים של מכשירים אלו בלבד יכולים למצוא את האפליקציה ולהוריד אותה. על מנת לצאת ל"תפוצה מלאה" - על האפליקציה לקבל את האישור של אפל.

כשמפתח מגיש את האפליקציה שלו לבדיקה - עליו להגיש את ה source code עצמו. תיקון: רק ה binaries נארזים ועל פהם יש static analysis. מסמך NDA דו-כיווני מבטיח שאפל לא תחשוף את הקוד ומצד שני אסור על המפתח לחשוף את ההערות שהוא קיבל מאפל על הקוד שלו, או לפרסם את הסיבה בגינה אפל פסלה את האפליקציה. מסך ברזל קטן, אם תשאלו אותי.
תהליך האישור כולל כנראה כלי Static Analysis אוטומטיים ומרכיב מסוים של בדיקה אנושית. בעבר, התהליך ארך מספר שבועות - אולם מאז הוא התייעל וכיום הוא לוקח לרוב פחות משבוע. בסוף התהליך האפליקציה מאושרת ומשוחררת לאפ-סטור או נדחית עם פירוט הדחייה והצעות לתיקונים - למפתח האפליקציה.

על מה פוסלים אפליקציות? לאף אחד אסור לומר! בכל זאת התגנבו ידיעות על הסיבות הבאות:
  • אפליקציה שאינה עומדת בסטנדרטי איכות מסוימים (לא גמורה או בעלת באגים חמורים וברורים).
  • אפליקציה שמכילה רכיבים זדוניים, או כאלו שיכולים לשמש כעזר לתוקף פוטנציאלי בפריצה למכשיר.
  • שימוש ב APIs של iOS שאינם מתועדים (כלומר, לא מיועדים לשימוש).
  • חריגה בוטה מהנחויות עיצוב ה UI של אפל לאפליקציות.
  • אפליקציות שדומות מדיי לאפליקציות של אפל, במראה או בסט היכולות (פתח למניעת תחרות, אם כי אפל טוענת שזו דרך להגן על הלקוחות בפני "הטעייה").
  • יש אפליקציות שנפסלו על עירום עדין ("עמוד 3" במגזין בריטי) בעוד אפליקציה של פלייבוי זכתה לאישור.
  • כמה משחקים נפסלו על אלימות יתר או מסרים גזעניים.
  • לסיכום: אפליקציות נפסלות על חריגה מהמדיניות של אפל, הן לגבי תוכן והן לגבי כללים לכתיבת קוד. פרטי המדיניות מתעדכנים מעת לעת.

האפ סטור של אפל בגרסתו הראשונה. מקור: techCrunch


שינוי פרדיגמה

מעבר להצלחה המיידית - נוצר כאן שינוי פרדיגמה משמעותי. רבים מייחסים את ה"חדשנות" של אפל לשימושיות הטובה של המכשירים שלה, למוצר הבסיס. אולי דווקא המוצר המקיף ("Whole Product") שהוא המכשיר + האפ-סטור או חנות התוכן iTunes הם אלו שבהם טמונה ה"חדשנות" המשמעותית-יותר של חברת אפל.

מצד הלקוח: האפ-סטור מאפשר חווית קנייה פשוטה, מהירה ומהנה - ישר מהמכשיר. חוויה שגורמת למשתמש iDevice לקנות יותר.
מצד הספק: האפ-סטור הוביל לכך שאפשר להרוויח מאפליקציות קטנות מאוד שמפותחות ע"י מפתחים בודדים (איך בדיוק מרוויחים - אולי בפוסט המשך). המתווכים הקלאסיים - נעלמו, ואיתם הוצאות רבות הקשורות להפצה. אפליקציות קטנות => פשטות שימוש => חוויות שימוש טובה יותר של ה Whole Product. אפל טיפלה בכל שרשרת הערך של המוצרים שלה, בלי להשאיר אף חלק ל"יד המקרה". הכל הרמוני, seamless, ומוכן לשימוש. דוגמאות נוספות:
  • אפל איננה ספקית תוכן, אך על מנת שהמוצר שהיא מוכרת (חומרה/תוכנה) יצליח: היא נכנסה לביזנס, יצרה את iTunes, ועשתה את הבלתי-יאמן כשהחתימה חברות מוסיקה גדולות על הסכמים למכירת שירים ב 1$ (עוד בימי ה iPod). חברה אחרת יכלה בקלות "לחתום על כמה הסכמים עם שותפים" ולקוות לטוב.
  • iCloud שירות האכסון / סנכרון בין מכשירים. למי שיש יותר ממכשיר אחד קל מאוד להבין מדוע זה "נדרש".

הרעיון של ה App Store גלש מעבר למכשירי המובייל לעולמות אחרים והופך, אט אט, לסטנדרט חדש להפצת תוכנה:
  • Chrome Store - עבור Plugins לדפדפן הפופולרי.
  • Mac App Store ו Windows 8 Store - אפ סטור למחשבים שולחניים. אם הקונספט עובד היטב למכשירי מובייל, למה שלא יעבוד גם למחשבים שולחניים?
  • App Stores אלטרנטיביים. בעולם האנדרואיד, היכן שיש חופש ופחות שליטה מרכזית, צצו כ +20 AppStores שונים כמו ה Amazon App Store למכשירי קינדל (תוכן הוא הביזנס העיקרי של אמאזון), אפאיה, LG World או Samsung Apps. יש גם אלטרנטיבות "מחתרתיות" לעולם ה iOS, "מחתרתיות" כי בסוף הם מפנות לאפ סטור של אפל להורדה.
  • App Store ל HTML5 apps, כמו זו של מוזילה או OpenAppMarket.
  • ספקיות הסלולר, בפעם המי-יודע כמה, ובאיחור שגרתי מנסות לחזור למרכז הבמה עם אפ-סטור משלהן: Vodafone, Horizon ואחרים.
  • App Store קהילתי מסביב לתחום עיסוק מסויים כמו ה SAP Store, לאפליקציות עסקיות (בעיקר סביב מערכות סאפ).
  • App Store ארגוני המשמש לתוך הארגון.
המעניין מכולם, עבורי, הוא ה Enterprise App Stores, בהם מנסים ארגונים להפיץ תוכנות שהארגון קנה בין העובדים. לארגונים יש כמה נקודות כאב (pain points) ייחודיות:
  1. הארגון קנה "רשיון רוחבי לכל העובדים" בסכום גבוה - אבל עובדים רבים לא מודעים לכך ולא משתמשים בתוכנה.
  2. תהליך הרכש בארגון, אפילו לסכומים קטנים, הוא מייגע. מה שהייתי יכול לקנות online בחמש דקות עם כרטיס אשראי עלול לקחת חודש או יותר, כשהוא עובר במערכת הרכש של ארגון גדול.
  3. ניהול רשיונות (מבחינה חוקית + כספית) הוא אתגר לארגון, ש App Store הוא נקודת כניסה נוחה שיכולה לסייע מאוד.
ספקי תוכנה ארגונית כבר מספקים בימים אלו "App Store ארגוני" ואפילו גוגל הכריזה על הפצה של Play גם כחנות ארגונית סגורה (SaaS).


אין כמובן מניעה מאפליקציה להפיץ עצמה במספר רב של App Stores, כל פעם תחת חוזה קצת אחר. גם אם אפליקציה תופץ ב 20 App Stores שונים - זה עדיין שבריר ממספר המפיצים / מפרסמים שחברות היו צריכות לנהל עימן קשר עד לא מזמן, בכדי להפיץ תוכנה.



סיכום

קונספט האפ-סטור משפיע לא רק על הדרך בה תוכנה מופצת ונמכרת, אבל באופן עקיף גם על הדרך בה תוכנה נכתבת:
  • ישנם חסמי כניסה נמוכים יותר כך שמפתחים בודדים / חברות קטנות יכולים להתחרות בחברות גדולות יותר. אי אפשר קשה יותר "לשלוט" בערוצי ההפצה, כפי שחברות גדולות נהגו לעשות, כדי לפגוע בתחרות.
  • קל יותר, למשל, למכור באמריקה תוכנה שנכתבה בסין - הגבולות הגיאוגרפים מטשטשים אפילו יותר.
  • התוכנה צריכה לעשות רושם ראשוני חיובי ומייד - אחרת המשתמש יחזיר אותה (החזרה תוך רבע שעה ב Google Play) או בכלל לא יקנה אותה (אם ה screenshots לא נראים לו).


שיהיה בהצלחה!



---

[א] IPhone Application = ipa



יום שלישי, 4 בדצמבר 2012

סדרה: MVC בצד-הלקוח ובכלל

תבנית העיצוב (Design Pattern) המורכבת Model-View-Controller (בקיצור: MVC) היא בסיס היסטורי לכתיבת אפליקציות UI ב"צורה נכונה", אבן יסוד של ארכיטקטורות UI.
אך אליה וקוץ בה:  כששני אנשים מדברים על MVC בסבירות גבוהה הם לא מדברים בדיוק על אותו הדבר. ישנן וריאציות שונות ופרשנויות שונות לתבנית-עיצוב זו, הנובעות בעיקר מצרכים של טכנולוגיות UI שונות: Command Line או Desktop application, טרמינל או אפליקציות ווב.

בסדרה זו נדון ב MVC אך לא מהצד התאורטי-הכללתי, כי אם מהצד המעשי ובעזרת דוגמאות. בגלל הפריחה של ספריות MVC ל javaScript (בערך 15 שאני מודע אליהן) וההתעסקות השוטפת שלי לאחרונה עם פיתוח ב javaScript - החלטתי להקדיש את הסדרה ל MVC צד-לקוח בג'אווהסקריפט. זו זווית אחת שלא תכסה את הנושא התאורטי בשלמותו - אך לעתים עדיפה דוגמה אחת או שתיים שמבינים מאשר הכללה שאין אנו "חשים".


ספרייה: Backbone.js



הצצה מהירה על Backbone.js (ספריית MVC לצד-הלקוח)
סקירה כללית על ספריות Client-Side MVC, וריאציות שונות (MVP, MVVM), וכיצד שימוש בספרייה לדוגמה, Backbone.js, נראה.







אוספים (Collections) ב Backbone.js
לאחר הצצה מאוד בסיסית על קוד Backbone הגיע הזמן לתת תמונה קצת יותר מציאותית. זאת נעשה בעזרת סקירה של אחד המרכיבים המרכזיים ב Backbone: אוספים.







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





AMD ו Require.js



AMD ו Require.js
תבנית העיצוב AMD איננה קשורה ישירות ל MVC - אך היא משרתת אותה מטרה ומסתדרת איתה מצויין.
פוסט זה סוקר את AMD ומספק מבוא ל Require.js - המימוש הנפוץ ביותר של תבנית-עיצוב זו.



Backbone.js - ספגטי או רביולי?

״קוד ספגטי״ הוא תיאור של קוד סבוך, מלא תלויות - ועל כן קשה לתחזוקה. בכל פעם שעושים שינוי באזור אחד בקוד, קיים סיכוי גבוה ״לשבור״ אזורים אחרים בקוד. ״קוד רביולי״ הוא המושג ההפוך המתאר קוד מודולרי וקל לתחזוקה: רביולי הם נפרדים אחד מהשני ויש להם הכמסה טובה - רביולי אחד לא יכול לגעת ב״מילוי״ של השני.

ג׳אווהסקריפט מעלה את נושא ״קוד הספגטי״ מחדש למרכז הבמה: מתכנתים רבים נכנסים עכשיו לעולם הג׳אווהסקריפט, עולם עם מעט הגנות והרבה אפשרויות ליצור "קוד ספגטי". ג'אווהסקריפט לא תוכננה בכדי לתמוך במערכות גדולות, והאופי "מונחה-האירועים" מעודד פיזור אחריויות ויצירת תלויות רבות. מי שחושב ששפה איננה אחראית לאיכות הקוד - שייזכר בפקודת ה GOTO בשפת בייסיק.

ספריות JavaScript MVC באו לנסות ולעזור למתכנתי ג'אווהסקריפט לעשות סדר - אך האם הן מספיקות?

בפוסט זה אני רוצה לעזוב את מסלול הTutorial שהתחלנו בו לגבי Backbone.js (בקיצור: BB): מסלול שמציג את יכולות הספרייה בצורה אופטימיסטית בה הכל מסתדר יפה. אתם בוודאי מכירים את המצב הבא: אתם לומדים טכנולוגיה, עושים כמה tutorials ומרגישים שהכל ברור ואז אתם מנסים את הטכנולוגיה בעבודה היומיומית שלכם ו..."הופ" - נתקעים אחרי שעות בודדות רק כדי לגלות איזו בעיה עקרונית, מוכרת, שהרבה פורומים דנים בה - אך יש לה מעט פתרונות יפים. מכירים?!

ספריות JavaScript MVC הן לא שונות, ועל כן אני רוצה להציג גם את הצדדים הללו. 


שייך לסדרה: MVC בצד הלקוח, ובכלל.

קוד "ספגטי"?

בחרתי להתמקד בדוגמה "קטנונית" לכאורה. הדוגמה מבוססת על מודל ה Person וה View בשם PersonView מהפוסטים הקודמים. בחלק זה הוספתי לה את היכולת לעשות expand/collapse לפרטים של האדם (במקרה שלנו: האימייל) + אייקון יפה שמציג את המצב, "פתוח" או "סגור".

הנה הקוד:
הקוד אמור להיות ברובו מוכר.

1- העשרתי מעט את ה template. הוספתי תמונה המתארת את מצב הפריט ברשימה (סגור/פתוח) והוספתי class בשם hidden שבעזרתו אני מסתיר חלקים ב markup. תיאור ה class יהיה משהו כמו:
.hidden {
display : none
}
טכניקה זו מאפשרת לי להסתיר / להציג את ה markup ע"י הוספה / הסרה של CSS class - פעולה קלה בjQuery.


2 - שימוש במנגנון האירועים של BB. הפורמט הוא key: value, כאשר:
Key = מחרוזת: <שם אירוע jQuery><רווח><שאילתת Selection ב jQuery>".
Value = מחרוזת עם שם הפונקציה באובייקט ה View שתופעל כתגובה לאירוע.

BB בעצם מפעילה כאן את jQuery: היא רושמת את הפונקציה שהוגדרה ב value, לשם האירוע (למשל "click" או "keypress"), על האלמנט(ים) שחוזרים מהשאילתה.

את השאילתה היא מבצעת על אלמנט ה el, ואם לא הוגדרה שאילתה - היא מפעילה jQuery.delegate על el, כך שהאירוע יופעל עבור כל אלמנט-בן של el.

בנוסף, BB גם עושה עבורנו Function Context Binding (לטיפול ב this) - כך שאין צורך לבצע bind/bindAll לפונקציית הטיפול באירוע.

את האובייקט הנכון של ה View היא מזהה בעזרת ה cid שעל ה el - מה שחוסך לנו הרבה עבודה.

3 - זו הפונקציה שתקרא לאחר שהמשתמש לחץ על ה person-frame שלנו. היא מזהה את המצב הנוכחי ומבצעת את השינויים הדרושים ב DOM. קריאת toggleClass של jQuery מסירה / מוסיפה CSS class בדיוק עבור שימושים כאלו.


הנה ההרצה של הקוד:



1 - אנו מוודאים שה default הוא הנכון.

2 - אנו מדמים לחיצה של משתמש על ה person frame ומוודאים שהמצב השתנה.
טיפ קטן: אני משתמש ב ('trigger('click, הקצת פחות קריאה, ולא ב ()click הקצת פחות אמינה. כמה דפדפנים מונעים שימוש ב click ישירות.

3 - אני בודק גם את המצב ההופכי, עבור שלמות הבדיקה.


הקוד נראה בסה"כ קריא, ולא כ"כ מסובך. מדוע אם כן אני קורא לו "קוד ספגטי"?
  1. אנו שומרים state של האפליקציה (isExpanded) על ה DOM.
    נכון, זו טכניקה מקובלת בג'אווהסקריפט - אבל זה "ספגטי": כל פעם שאנו רוצים לעשות שינויים ויזואליים אנו צריכים "לבחון" את ה DOM ולהסיק מה המצב שלו. כשהקוד גדל ונהיה מסובך - זה יכול להיות פשוט סיוט של קוד.
  2. אנו מציבים לעצמנו מגבלה שה View לא יתרנדר מחדש. אם מרנדרים אותו - אנו מאבדים את ה state שלנו.
  3. ה markup שלנו נובע בעצם מ 2 מקורות שונים: מה template וממנהלי האירועים. כדי להבין מה / כיצד נוצר - יש לבחון את שניהם, מה שיגרום לנו לשאול את עצמנו: "מאיפה 'זה' הגיע...?"
אפילו בקוד הבדיקות, "נגררתי" (עלק) לבדוק את מצב ב DOM: האם יש css class מסוים או לא. מבנה ה DOM הפך לציבורי.


מודל רזה או שמן?

ב JavaScript MVC יש בגדול 2 אפשרויות כיצד לחלק את האחריויות בין ה View וה Model:
  • "מודל רזה" (נקרא גם anemic model) - המודל הוא בעיקרו DataStructure / DTO שמחזיק בצד הלקוח עותק קונסיסטנטי של מצב האובייקט בצד-השרת / בבסיס-הנתונים. כל הלוגיקה ה"עסקית" מתרחשת ב View.
  • "מודל שמן" (נקרא גם rich model) - המודל הוא המקום בו מתרחשת הלוגיקה העסקית, בעוד ה View הוא רק שיקוף של UI למצב המודל.
BB, באופן רשמי, לא נוקטת עמדה לגבי הגישה המועדפת. "אפשר גם וגם".

אם אתם משתמשים ב"מודל רזה", BB מספקת מנגנון בשם Backbone.sync שעוזר לשמור / לטעון את המודל משרת בעל RESTful APIs: אם תגדירו על מודל / אוסף (collection) את ה url של השרת / REST servuce ותקראו לפעולת ()fetch, ספריית BB תקרא לאותו ה URL ב get (קונבנציות REST) ותטען מחדש את המודלים מהשרת. פעולת create על האוסף תיצור בשרת (ולאחר תשובת HTTP 201 - גם באוסף שלכם) את המודל. כנ"ל יש גם update ו delete וכו'.

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

הקושי נובע מהמצב בו אתם רוצים לשמור על המודל client-side state או ui state - כלומר properties שישמשו אתכם בצד הלקוח אך לא תרצו לשמור בשרת.
כיצד תוכלו לומר ל BB אילו תכונות של המודל נשמרות בשרת ואילו לא? BB לא מספקת יכולת מובנה לדילמה זו.
ההורשה ב BB, כלומר extend._ איננה הורשה אמיתית, היא בעצם ממזגת עותק של אובייקט האבא (כלומר Prototype Design Pattern) עם אובייקט חדש שאתם מגדירים.
BB גם לא תומכת בארגון מודלים בהיררכיה - רק ברשימות (כמו טבלאות ב DB רלציוני). כלומר: איננו יכולים להשתמש בהיררכיה על מנת להפריד בין ה״מודל לשמירה בשרת" ל״ערכי המודל של צד-הלקוח״.
  1. לפלטר את ה ui state בצד השרת? אאוץ.
  2. אפשר להשתמש בplug-in ל BB שמאפשר ניהול היררכי של מודל (במקום הורשה), משהו כמו BB deep model. קצת מסורבל.
  3. אפשר לוותר על שימוש ב Backbone.sync ולפלטר לבד את ה ui state.
בואו נבחר בדרך מס' 3.

בלי קשר לבעיה זו - אינני אוהב את הדרך בה עובד מנגנון הסנכרון לשרת של BB :
  • הוא בעיקר עושה דלגציה ל ajax.$ ומוסיף עליה מעט מאוד. אני מרגיש שבנקודה זו BB לא השקיעה בי מספיק.
  • נקודת הגישה לשרת נעשית דרך המודל ולא ישירות - דבר שלא מרגיש לי נכון. טיפול בשגיאות והתנהגויות חריגות הוא מסורבל, הקשר ההדוק הזה מקשה על היכולת לבצע בדיקות-יחידה, ואי אפשר להשתמש ב Backbone.sync עבור צורות תקשורת אחרות (למשל Push/WebSockets).


"מודל שמן" ב Backbone.js

הנה המודל שלנו ב"גרסה השמנה" (Rich Model):

  • הוספתי למודל תכונה בשם isCollapsed שהיא חלק מה UI State שלו - שלא אמור להישמר בבסיס הנתונים.
  • יצרתי מתודה בשם getJSONToPersist שתחזיר לי את ה JSON של מה שצריך להישמר בשרת. ניתן ליצור superclass חדש של BB.Model על מנת למחזר קוד זה.
  • את השינוי במצב (גלוי/חבוי) שייכתי לפונקציה במודל בשם toggle. כרגע היא מזערית, אך זה הרגל טוב לכתוב גם פונקציות לוגיות מזעריות - במקום הנכון. הן נוטות להתרחב.
  • הוספתי עוד דוגמה לפונקציה "לוגית" קצת יותר עשירה בשם isVIP. היא איננה בשימוש בדוגמה זו (ולכן מסומנת באפור).
הנה ה View:



אפשר לראות שיש 2 templates עבור כל מצב: Collapsed או Expanded - גישה זו טובה כאשר יש 2-3 מצבים. אם יש יותר - אז כדאי להחזיק template בסיסי ולבצע ב ()render שינויים ב markup.

המחזור של תגובה-לאירוע שונה משמעותית מזה של הדוגמה הקודמת:
אם קודם המחזור היה: רינדור View ל DOM, לחיצה של משתמש, אירוע -> שינוי ה DOM,
עכשיו המחזור הוא: רינדור View ל DOM, לחיצה של משתמש, אירוע -> שינוי המודל -> אירוע שינוי המודל -> רינדור ה View ל DOM.

השינוי מתרחש במודל - וה View משקף אותו. ב View אין חוכמה לוגית / עסקית - הוא מטפל ב UI נטו.
שימו לב שעל מנת לשנות את המחזור, הוספתי binding לאירוע ה change של המודל בבנאי - כלי נוח ש BB מספק לי.
קוד ה render הוא לא קצר הרבה יותר מהדוגמה הקודמת - אך הוא פשוט יותר ו"שביר" פחות. הוא בוחן את המודל (קוד js פרטי ולא DOM - שיכול להיות מושפע מהרבה מקורות) ורק על פיו הוא מחליט מה לצייר.
אין לי צורך "לבצע delta" (במקרה זה: הסרה של ה CSS Class בשם hidden) כי בכל מחזור אני מתחיל על בסיס ה template מחדש - דבר שמפשט את הקוד משמעותית.


שיקולי ביצועים

אחד הדברים שהכי בולטים בקוד ה"רביולי", מלבד שהוא קצת ארוך יותר, הוא שהוא עושה יותר עבודה.
במקום לשנות ב DOM משהו קטן - רינדרנו חתיכת markup מחדש והחלפנו את כולה. "שיטת המוסכים המורשים" - אני קורא לה: "שריטה בדלת? - נחליף דלת", "רשרוש במנוע? - לא מתעסקים. נחליף את המנוע".

זה עשוי להראות דיי מרתיע - אך לרוב אין פה בעיית ביצועים אמיתית: רוב הפעמים ההחלפה תהיה של "מודל בודד" שלא יכלול הרבה markup - ולכן החלפתו לא תהיה יקרה.

אם שמתם לב, הוצאתי את "קימפול" של ה templates (פקודת template._) מחוץ ל instance הבודד של ה view - זה דבר משמעותי הרבה יותר מבחינת ביצועים!

אם בכל זאת אתם רוצים לבצע החלפה דינמית, כי ה markup שלכם גדול או הביצועים הם ממש קריטיים - BB מספק מספר כלים שיכולים לעזור.
  • אתם יכולים לעשות binding לשינוי של שדה ספציפי במודל, בפורמט '<change:<field name' על מנת להיות מסוגלים להגיב לשינויים נקודתיים מאוד.
  • אתם יכולים לבקש מ BB להשתמש ב el קיים ב markup ולא לייצר אותו, כך שתוכלו להשתמש בספריית templating סלקטיבית (לדוגמה pure.js או handlebars) - אשר עושה שינויים ב markup מבלי לרנדר אותו כל פעם מחדש.
  • אתם יכולים לא להשתמש בספריית templating ולבצע רינדור סלקטיבי בעצמכם. עשו סדרה של שינויים ב DOM - אך שאבו את המידע מהמודל ולא מה DOM.

אני בטוח שיש עוד כמה דרכים אפשריות...

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


סיכום

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

באידאל - יש להתאים את המודל לצרכים הקונרטים: ספגטי לארוחת צהריים מהירה שבקרוב תשכח, רביולי לארוחת ערב מפנקת ומשמעותית. "קוד ספגטי" למערכות פשוטה שאנו רוצים לסיים מהר, "קוד רביולי" - למערכת שאנו צופים עליה עוד עבודה רבה ושינויים רבים.

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

אני מניח שאם הגעתם להתעסק ב Backbone / JavaScript MVC - כנראה שעלה צורך ל"קוד רביולי".
אני, הייתי הולך עם זה עוד צעד קדימה - ועובד עם "מודלים שמנים, Views רזים".


שיהיה בהצלחה!






יום שני, 26 בנובמבר 2012

Backbone.js (ספריית MVC) - אוספים

בפוסט הקודם, הצצה ל Backbone.js (בקיצור BB, ובלי לדבר על פוליטיקה) ראינו את שני הטיפוסים המרכזיים ביותר של ספריית BB. בפוסט זה ארצה להרחיב מעט את היריעה לטיפוס מרכזי נוסף שנקרא Collection שמסייע לארגן את המודלים במערכת.
להזכיר: מודל (model) מייצג אובייקט המתאר "יישות בעולם בו עוסקת המערכת", קרי Domain Object. לעתים קרובות נרצה להציג / לטפל בסדרה של מודלים. BB מאפשר ותומך בצורך זה בעזרת Collection שהוא אוסף של מודלים, המספק יכולות מתקדמות יותר מרשימה פשוטה.

שייך לסדרה: MVC בצד הלקוח, ובכלל.


דוגמה בסיסית

בואו נפתח בדוגמה פשוטה:

אתם יכולים לזהות מודל מינימלי בשם Person ואת האוסף (Collection) בשם People - אוסף של Person.

1 - ההגדרה של model בבנאי של האוסף אינה נדרשת בשלב זה. היא משמשת רק כאשר משתמשים ביכולות ה REST המובנות ב Backbone.Model ו Backbone.Collection על מנת לסנכרן שינויים לשרת. איננו עוסקים ביכולת זו עדיין, אך אני מעדיף להגדיר את המודל לצורך הקריאות. הקונבנציה המקובלת ב BB היא לקרוא לאוסף בשם הרבים (s בסוף) של המודל, למשל Invoice ו Invoices.

2 - אנו יוצרים מודל (בצורה נאיבית, אציג דרכים יעילות יותר בהמשך) של מג'יק ג'ונסון ומוסיפים אותו לאוסף.

3 - לכל מודל (בעצם לכל אובייקט של BB) שנוצר ניתן מזהה גלובלי ייחודי, בפורמט "<מספר רץ>c". במקרה זה אני יודע שאובייקט של מג'יק ג'ונסון הוא השלישי שנוצר במערכת ועל כן אני יכול לאמת את ה cid שלו. זו הנחה שלא הייתי רוצה להסתמך עליה בקוד אמיתי.
cid הוא קיצור של Client Identifier, שנועד לסייע לזהות מופע של מודל בצורה ייחודית. ב BB מניחים שצד-השרת, בעקבות השימוש בבסיס נתונים כלשהו, יהיה לכל אובייקט זיהוי ייחודי. בטווח הזמן בו האובייקט נוצר בצד-הלקוח ועדיין לא נשמר בבסיס הנתונים וקיבל Id ייחודי מבסיס הנתונים, ה cid אמור להיות כלי העזר על מנת לזהות ייחודית את המודלים.

4 - הוספנו עוד מודל אחד לאוסף.

5 - אוסף של BB, באופן מובנה, יכול להשתמש utilities של underscore.js - שהם דיי שימושיים. הנה דוגמה של פונקציה בשם plunk שעוברת על כל אחד מהמודלים באוסף, ומכניסה לתוך מערך התשובה ערך של שדה שהוגדר, במקרה זה - כל שמות המשפחה. כמה נוח.
כן, underscore.js "מתעסק לנו" באובייקטים בסיסיים של השפה כמו "Object" או "Array"', במקרה זה הוא הוסיף את plunk ומתודות אחרות למערך. נכון, זה משהו שממליצים לא לעשות. לא לעשות באפליקציה - אך זה "מותר" לספרייה. תתרגלו.


Collection ו Views

הנה דוגמה מורכבת מעט יותר המציגה חיבור של Collection ל View:
View אחד עבור כל Person, ועוד View עוטף של האוסף People.

התוצאה, עבור אוסף מינימלי של 2 אנשים, תראה משהו כזה:
הכותרת "שני אנשים" שייכת לPeopleView, והשאר נוצר ע"י שני מופעים של PersonView. בלי שום Styling כמובן - בכדי לצמצם את גודל הדוגמה.

כמיטב המסורת, נפתח בדוגמת ההרצה, ורק לאחר מכן נעבור לקוד עצמו:

ב1 - אנו יוצרים אוסף בשם people ומזינים אותו בערכים. המשמעות של reset היא "החלף את כל הערכים הנוכחיים ברשימת הערכים הבאה" והיא האופן בו נרצה להזין ערכים כאשר אנו טוענים מצד-השרת רשימה מלאה של ערכים. אנו מזינים את people במערך של אובייקטים שכל אחד מתאר את המודל של הרשימה - Person.

ב2 - אנו יוצרים את ה PeopleView, ה View שיודע להציג את הרשימה וליצור את ה HTML הנ"ל. נראה את הקוד שלו מייד.

ב3 - כך מבצעים בדיקת-יחידה יציבה (לא-שבירה) עבור תוצאת HTML. טעות נפוצה היא להשוות את כל תוצאת ה HTML כ String לערך שהיה נכון בסוף רגע הפיתוח ובחנו שהוא תקין. הבעיה: כל שינוי ב markup - אפילו ריווח או תוספת תג לא משמעותית (למשל label) תשבור את הבדיקה - גם כאשר התוצאה עדיין תקינה. הדרך הנכונה לבדוק היא לאתר "עוגנים חשובים" ב HTML ולבדוק רק אותם. האומנות היא למצוא את רמת הפירוט האופטימלית.
אנו מאמתים את טקסט הכותרת
אנו מאמתים את מס' האלמנטים מסוג h2
אנו מאמתים שהטקסט של הראשון הוא "ג'ונסון, מגיק" - כלומר את הפורמט. eq היא המקבילה של jQuery ל index.
אנו מאמתים שאחרי ("~" ב css selector) הכותרת h2 הראשונה ישנו אלמנט p שמכיל את כתובת האימייל של זיגי. איננו רוצים "להפיל" את הבדיקה אם מחליפים את התחילית "email" באייקון קטן, למשל. אנו מתמקדים בנתונים ההכרחיים.

ב4 - אנו מבצעים reset לנתונים - עם רשימה באורך 3, רק כדי לוודא שהכותרת הראשית (h1) אכן תלויה באורך הרשימה.

הנה הקוד עצמו:
ההתחלה אמורה להיות מוכרת. פרקטיקה טובה היא להוסיף ערכי defaults למודל עבור כל שדה שאנו הולכים להשתמש בו ב View - אחרת אנו עשויים להיתקל ב Runtime Errors ללא fallback (למשל כשיש מודל עם age בלבד).

1 - לא התאפקתי והשתמשתי הפעם ב template engine - שהיא הדרך המומלצת ב BB כדי לייצר את ה markup עצמו. השתמשתי בצורה בסיסית ביותר בספרייה המובנה בתוך underscore.js (אתם יכולים לזהות ע"פ תחביר ה ERB/JSP), אבל אין שום מניעה לעבוד עם ספרייה אחרת כמו handlebars.js, mustache.js או dust.js.
אתם יכולים לשים לב שב template.people יש קו על התגית <u>. הסיבה: התגית <u> היא deprecated ב HTML5. הדרך ה"נכונה" ע"פ HTML5 לייצר קו תחתון הוא לעטוף ב span עם class שלי ואז להחיל עליו קו-תחתון בעזרת CSS. לצורך דוגמה זו אתעלם מזוטות שכאלה.
עוד נקודה מעניינת היא השימוש ב class (נקודה) ולא id (סולמית) על מנת לזהות את החלק שבו "יוזרקו" חתיכות ה markup של ה Person הבודד. על Id ב HTML להיות ייחודי בכל הדף ואיני יודע בוודאות אם ה PeopleView יוצג יותר מפעם אחת על הדף או לא. סיכוי אחר: אולי מישהו אחר ישתמש בid בשם people-list במקום אחר. על מנת להישאר סטנדרטיים יש להימנע משימוש ב id אלא אם אפשר לוודא שהוא אכן ייחודי - מה שלרוב קשה לדעת. הפתרון: שימוש ב  css class לזיהוי.
בכל מקרה, אחפש את ה css class בצורה יחסית - כך שלא אשפיע על אזורים אחרים ב markup, גם אם הם השתמשו באותו css class בדיוק.

גישה פופולרית היום היא להקליד את ה templates עצמם בתוך ה HTML עצמו עטופים בתג <'script type='text/template> ועם id ידוע מראש ואז להשתמש ב jQuery על מנת לטעון את ה template בזמן ריצה. ה template כמובן אינו משפיע על ה HTML - הוא רק "יושב שם מבלי להפריע". מדוע לעשות זאת?
  • כדי ליהנות בעת כתיבת ה template מה HTML Editor עם Syntax Highlighting ובדיקת שגיאות.
  • הצמדות לכלל שאומר: makrup נמצא בקובץ ה HTML - לוגיקה ב javaScript. כל ספריות ה template engine שציינתי למעלה הן "logic-less" ואינן מאפשרות כתיבת javaScript בתוך ה template, אלא רק לוגיקה רק בשפה הפנימית שלהן. היה נכון יותר לקרוא להן "javaScript-less", בעצם.

מדוע, אם כן, אני מעדיף בכל זאת לשמור את ה templates בתוך ה javaScript code?
  1. אני משתמש בIDE בשם WebStorm שמספק לי את היתרונות של HTML Editor בתוך קובצי הג'אווהסקריפט. החיסרון היחיד: חוסר החופש לייצר שורה חדשה ללא +.
  2. כתיבת ה templates בתוך ה javaScript מאפשרים לי להריץ את בדיקות-היחידה ללא קובצי HTML - מה שמאפשר להם לרוץ הרבה יותר מהר. התוצאה: אני מריץ בדיקות בצורה תכופה הרבה יותר - כי כולן רצות בשתי שניות בתוך ה IDE.

2 - ביצירה של ה PersonView אני מייצר את ה"אוטומט" של ה template. על מנת להשיג יעילות מרבית, ה template engine נוהגים לפרק את ה string של ה template לצורה מהירה יותר לשימוש. לרוב מקובל לקרוא למשתנה שמחזיק את התבנית פשוט "template", השתמשתי ב myTemplate על מנת לנסות ולהקל על ההבנה במקרה זה.

3 - כאן מבצועת ההפעלה של ה"אוטומט" של ה template engine על נתונים מתאימים, במקרה זה - המודל המדובר. ה"אוטומט" myTemplate הוא בעצם פונקציה שמרנדרת html markup ברגע שמזינים לה נתונים. אנו טוענים את התוצאה לתוך this.el שהוא, כאמור, העטיפה ב DOM ל View שלנו.

בואו נעבור עכשיו ל PeopleView המייצג את התמונה הכוללת:
4 - לאחר שרינדרתי את החלק של People ב HTML, הרי היא ה"מסגרת" (במקרה שלנו - רק כותרת), אני רוצה להזין את הנתונים של המודלים הבודדים. אני קורא ל $.this על מנת לבצע חיפוש בתוך ה markup של this.el בלבד, אחר המקום בו "אזריק" את ה Views של המודלים הבודדים. זוהי גרסה מקוצרת (ומומלצת) לכתיבת "(this.el).find('.people-list')$" (אני מניח שאתם מכירים jQuery).

5 - each של collection מאפשרת לי להריץ פונקציה עבור כל מודל באוסף - משהו כמו foreach.

6 - או יוצרים מופע של PersonView עם המודל ה person הנוכחי. אולי זה מרגיש קצת "כבד" לייצר View כל פעם ולא לייצר אחד ולעשות בו שימוש חוזר - אך זה בסדר.

7 - אנו משתמשים ב view על מנת לרנדר את ה markup ומוסיפים את ה "glueing markup", שבמקרה זה הוא רק תגית br. אנו רוצים לשמור את ה template של Person "נקייה" כך שנוכל להשתמש בה גם ללא ה PeopleView.


סיכום

בפוסט זה צללנו לדוגמה ריאלית קצת-יותר (מהפוסט הקודם) של קוד ב backbone - על מנת להבין כיצד קוד ב BB "מרגיש". אני מקווה שהצלחתי להעביר את התחושה, אם כי היא עדיין מינימלית למדי. כפי שראינו, BB לא עושה "קסמים" (כמו Ember או Angular) - אנו עדיין כותבים את כל הקוד, אך BB נותן לנו מסגרת, guidance ו utilities על מנת להגיע לשם.
על הדרך השלמנו את הפער אודות השימוש ב template engine, שהוא היבט מרכזי בספריות "javaScript MVC", והדגמתי כיצד לבצע בדיקות-יחידה ל View וראינו Views מקוננים. כל זה דחוס בפוסט לא כל-כך ארוך. אני מקווה ששמרתי על איזון נכון של "לא משמעמם" ו "ניתן להבנה".

הערות יתקבלו בשמחה!


שיהיה בהצלחה!



יום שבת, 17 בנובמבר 2012

הצצה מהירה על Backbone.js (ספריית MVC)

שפת ג׳אווהסקריפט התפתחה בעשור האחרון מ״שפת צעצוע״, המשמשת ליצירת אינטראקציה מקומית בדף אינטרנט, לשפה משמעותית שמשמשת לבניית מערכות שלמות. ממה נבע השינוי הזה?

האם השפה עצמה התפתחה הרבה בעשור האחרון? - לא. אמנם הגרסה הבאה שלה[א] אמורה להיות עליית מדרגה משמעותית - אך היא עדיין לא שם. אם כן ניתן לחפש את השינוי במקום אחר.

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

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

שייך לסדרה: MVC בצד הלקוח, ובכלל.


סמל, שאם תכתבו ב Backbone.js - תיתקלו בו עוד הרבה...

רקע

לא ניתן להתעלם מתרומתה הרבה של ספריית jQuery ודומותיה[ב] בעיצוב מקומה החדש של שפת ג׳אווהסקריפט. במעגל השני של ההשפעה (לפחות בצד-הלקוח) נמצאות ספריות שעוזרות בכתיבת אפליקציות צד-לקוח גדולות. ספריות אלו נקראות ״MVC Frameworks" או ״ספריות ארכיטקטוניות״. השם MVC עשוי לבלבל את מי שכבר מכיר ועבד עם ספריות MVC צד-שרת כגון Struts או ASP.NET MVC.

בעוד ספריות "MVC קלאסיות" מטפלות באפליקציות רבות דפים והניווט בניהם, ספריות ה "JavaScript MVC" לרוב מטפלות באפליקציות דף-יחיד (כגון GMail) בהן יש מסך עקרי אחד שחלקים בו מתחלפים / משתנים - אך אין ניווט משמעותי. בכלל, עצם הפעולה בצד-הלקוח, ב Ajax, בו אין refresh לדף בעת פעולה - משנה את כללי המשחק: מציב בעיות חדשות ופתרונות אחרים. עוד הבדל בולט הוא שברוב ספריות ה "JavaScript MVC" אין Controller. השם MVC בא לבטא את הרזולוציה ואת הבעיה שהן באות לפתור: ארגון קוד באפליקציית UI גדולה ומורכבת.

קיימות כיום מספר רב של ספריות "JavaScript MVC" וצפוי בהן עוד תהליך של קונסולידציה. שלושת הגדולות הן:
  • Backbone.js כנראה הנפוצה והבוגרת מכולן. מספקת מסגרת כללית בלבד ומשאירה חופש / חללים למפתח להחליט ולמלא בעצמו.
  • Knockout.js ששמה במרכז את ה Data Binding ומאפשרת לכתוב בקלות אפליקציות "מונחות-נתונים" (מערכות מידע וכיוצ"ב) נפוצה במיוחד בעולם ה NET.
  • Ember.js (לשעבר Amber.js), ספרייה מקיפה שכוללת גם Class System[ג] ושואבת רעיונות רבים מ Rails ״כתוב מעט קוד, אך עשה זאת בדרך שלנו" צעירה יחסית - אך זוכה למומנטום משמעותי. נפוצה במיוחד בקרב מתכנתי רובי.
ספריות משמעותיות אחרות הן Spine.js, JavaScriptMVC, Batman.js ו AngularJS (מבית גוגל). האתר המצוין todoMVC מציע השוואה מעמיקה בין האפשרויות בכך שמימש אפליקציית דוגמה בכל אחת מספריות הנ"ל (ועוד כמה ספריות נוספות).


רגע של התפלספות

כפי שציינתי, ספריות "JavaScript MVC" הן לא בדיוק MVC קלאסי. בעצם, גם ל"MVC קלאסי״ יש כמה פרשנויות שונות (לדוגמה, האם ה Controller מתמקד בעיקר בטיפול ב input או אחריות על ניהול הflow והתלויות?[ד]).

המדקדקים מגדירים את Knockout.js כ MVVM) Model, View, View-Model) - תבנית עיצוב שמייקרוסופט מקדמת בעולם הNET. זה דיי נכון.
את Backbone.js ו Ember.js נוהגים להגדיר כ Model, View, Presenter) MVP). האמת, ספריות כמו ASP.NET או GWT מתאימות יותר להגדרה זו. הגדרה כגון Model, View-Controller, Router (בקיצור MVCR) תהיה יותר מדויקת.

ההגדרה המועדפת עלי כרגע היא !Model, View, Whatever (בקיצור MVW או *MV).
התחלתי את הפוסט הזה בניסיון לעקוב אחר ההיסטוריה של תבנית העיצוב MVC, הוריאציות והשינויים שהיא עברה במשך השנים, בעיקר MVP ו MVVM, והניסיון להסביר כיצד ספריות ה "JavaScript MVC" מתאימות לתבניות אלו.

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

בסופו של דבר - MVC הוא ניסיון לארגן אפליקציית UI מורכבת בצורה שתהיה קלה לתחזוקה ושינויים. כל דור של UI (Web, Fat Client, Fully Client Side, Command Line) - והאתגרים שלו.
כפי שמרטין פאולר ציין פעם: "אנשים נוטים להסתבך עם MVC. החלק הכי חשוב הוא לבצע הפרדה אמיתית בין Business Logic ל UI. כל השאר - משני". אני מסכים ב 100%.

לכל ספרייה יש את הדרך שלה לארגן את הקוד - ואולי יותר מעשי ומעניין פשוט להתבונן בישומים קונקרטיים.
בפוסט זה אתן הצצה בסיסית ביותר ל MVW בג׳אווהסקריפט בדמות Backbone.js - הספרייה הנפוצה והמינימליסטית שיכולה להיות בסיס לימודי מצוין להבנת MVC בג׳אווהסקריפט.


אז מה יש ב Backbone.js?

אקצר מעתה ואקרא ל Backbone.js פשוט BB.
  • BB היא קטנה למדי. 700 שורות קוד בערך. 1400 שורות עם הערות.
  • BB משתמשת ב underscore.js (ספרייה טובה ל javaScript Utils מאותו היוצר) ו jQuery. אם אתם עובדים עם BB - יהיה לכם מאוד נוח להשתמש גם כן בספריות אלו, וקצת פחות נוח (אך אפשרי לחלוטין) להשתמש בספריות אחרות. BB מעודדת שימוש בספריית Templating - ואתם יכולים לבחור את זו של underscore (תחביר JSP-like, שלי אישית, עושה צמרמורת) או כל אחת אחרת.
  • ל BB יש תיעוד טוב (reference) ו Tutorials סבירים. יש קהילה גדולה ופעילה.
  • בגלל ש BB פשוטה - מייחסים אותה כמתאימה למערכות פשוטות יחסית - אך בפועל יש גם מערכות גדולות מאוד ומורכבות שנכתבו בעזרתה.
  • מאוד קל לעבוד עם BB מול שרת שמספק REST APIs - במיוחד אם תבנית-הנתונים היא JSON.
  • ל BB יש ארכיטקטורת Plug-Ins וניתן למצוא Plug-Ins רבים שמרחיבים את יכולות-הבסיס שלה.
  • BB מספקת מסגרת לא-מחייבת. אם אתם רוצים לפעול קצת אחרת, יש לכם את החופש לעשות זאת. כאשר מדובר במבנה של האפליקציה שלי - אני אוהב את זה.
  • כמו ספריות "JS MVC" אחרות, BB מספקת:
    1. מערכת-מחלקות (Class System) עבור Model ו Views (וגם Routers ו Collections - שהם רכיבים מרכזיים אחרים בBB)
    2. ניהול של המודלים (ה instances), כולל הקשרים בניהם.
    3. כלים לאימות ערכים (Validation Logic) במודל.

הנה דוגמה למודל מינימלי שניתן לייצר ב BB:
הערה: משפטי ה expect...toBe הן בדיקות-יחידה המציגות את התנהגות הקוד. כל הבדיקות עוברות בהצלחה.

המודל שלנו, Person בדוגמה זו, הוא פשוט למדי. הייתי יכול ליצור אותו גם ללא defaults - רק עלי ידי הורשה ריקה מהמחלקה Backbone.Model. תכונות המודל (כמו שם פרטי/משפחה) הן דינמיות ומוגדרות בזמן יצירת האובייקט הספציפי. ה default היא היכולת לחייב שתכונות מסוימות יהיו בכל מקרה.

ב1 - אנו יוצרים מודל של אדם בשם אוזי כהן.
ב2 - בכדי להדגיש את השוני בינו ובין אמן אחר בשם ״ליאונרד״ ובעל שם משפחה זהה, אוזי משנה את שם המשפחה שלו.
ב3 - אנו מקבלים את המודל המלא בפורמט JSON.

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

השתמשתי במודל הכי פשוט שאפשר - כי ברצוני להתמקד ב View.

PersonView היא המחלקה שאחראית לצייר מודל של Person. יכולים להיות, כמובן, כמה Views שונים לאותו המודל. את ה markup שה View יוצר, ארצה לשלב היכנשהו ב DOM. בדוגמה זו - זה יהיה container$, שמשתמש ב span בכדי לא לבלבל עם ה div ש Backbone יוצר באופן אוטומטי לכל מופע של המודל.

el הוא בעצם אלמנט ה DOM שיצר לי BB כחלק מה View. הוא עושה זאת על מנת לאפשר ל markup בפנים להשתנות, בלי שאצטרך לחבר את ה markup שוב ל container. הבחירה ב div היא כמובן רק default, ואם אני זקוק ל list element (תג <li>) - אפשר לקבוע זאת.

ב1- אני בודק מה יש בתוך ה container - ניתן לראות את ה markup שנוצר בתוך הפונקציה render. זו דוגמה דיי מכוערת - לרוב נשתמש בספריית templating על מנת שהקוד שיוצר את ה html snippet יהיה אלגנטי. לא רציתי להעמיס על דוגמה זו ולכן הקוד ה"פרימיטיבי".

ב2- אנחנו בוחנים את ה markup כולל ה container. רק לוודא שהתמונה הכללית ברורה.

ב3- אנחנו מבצעים שינוי למודל ורואים שה markup ב container השתנה באופן פלאי. "פלאי" - כמובן שלא. אנחנו כותבים את הקוד שעושה זאת - backbone רק מכווין אותנו למבנה מסוים ועוזר לנו.

בואו נבחן את הפונקציה initialize שהיא לצורך העניין הבנאי (constructor) של מחלקת ה PersonView שלנו, וכוללת 2 משפטים מוזרים:
ב5- אנחנו מבצעים פעולת JavaScripts's bind לכל המתודות במחלקה שאנו הולכים ל"ייצא" כ callbacks לאובייקטים אחרים. במקרה זה - יש רק את ״render״, אך יכולתי באותה מידה לשרשר גם שמות של מתודות נוספות. למה צריך לעשות JavaScript bind? - כדי ש this ימשיך להצביע לאובייקט שלנו. מבולבלים? קראו את הפוסט להבין את JavaScript this.
הסימן "_" (קו תחתון) הוא הקיצור לגשת לספרייה underscore.js, ממש כמו שניגשים עם $ ל jQuery. אלו המקומות ש underscore מסייעת מאוד לכתוב קוד ב BB. אתם לא חייבים - אבל כדאי.

ב6- אנחנו "מחייטים" את ה View שלנו לבצע פעולת render כל פעם שהמודל משתנה (change' event'). מאוד דומה לאירועים ב jQuery.
הבהרה קלה: אם אתם מכירים את תבנית העיצוב MVC אתם יכולים להבחין שה View ב Backbone מבצע פעולות ("חיוט") של Controller. זה נכון: אפשר לומר שה View ב BB הוא בעצם View-Controller: הוא עושה הרבה פעולות שבמקור יוחסו ל Controller.
אם אתם מכירים את תבנית העיצוב MVP נראה שה View הוא בעצם יותר Presenter. הוא אחראי ל Presentation Logic. זה נכון: בעצם מה שנקרא "View" ב BB הוא דומה ל MVP's Presenter בעוד ספריית ה Templating (בעצם ה Template עצמו) - דומה מאוד ל MVP's View.


סיכום

הצצנו ל Backbone וטעמנו כיצד נראה קוד שמשתמש ב Backbone.js. טעימה קטנה.
דיברנו גם על החשיבות של ספריות "JavaScript MVC" - כאשר קוד הג'אווסקריפט שלכם מתחיל לגדול ולהסתבך. וגם על החשיבות לא לחפור בתבנית-העיצוב MVC וההיסטוריה שלה יותר מדי :)

ייתכן ואמשיך לכתוב קצת על Backbone על מנת להתעמק בו קצת יותר, בניסיון לבחון JavaScript MVC "מהשטח".

בהצלחה!


------

[א] נקראת Harmony, ג׳אווהסקריפט 2.0 או ECMAScript 6.0. כוללות, ככל הנראה, מחלקות, מודולים (חבילות של מחלקות עם ניהול תלויות), תיקונים לכמה כשלים של שפת ג׳אווהסקריפט ועוד. ממש מהפיכה!

[ב] Prototype ו MooTools היו גם הן מועמדות ראויות, אך קהל המפתחים בחר לבסוף בjQuery. ניתן לקרוא על העיקרון מאחורי jQuery בפוסט מבוא מואץ ל jQuery.

[ג] כלים / Framework להגדרת מחלקות וכל מה שקשור בהן. בג'אווהסקריפט, כפי מתואר בפוסט מחלקות בג'אווהסקריפט. בשפת ג'אווהסקריפט לא קיימות מחלקות - ועל המתכנת לייצר אותן לבד. בעוד ספריות "JavaScript MVC" רבות מספקות סביבה אחידה / מוגנת ליצירת מחלקות עבור האלמנטים הבסיסיים בספריה (כמו Model או View).- ספריית Ember מספקת כלים שתוכלו להשתמש בהם עבור כל המחלקות בפרויקט שלכם.

[ד] המקור של MVC הוא בשפת Smalltalk בשנות ה-70. כשהגיעו ה Fat Clients (ב ++C), ולאחר מכן הווב - נוצרו פרשנויות ווריאציות שונות ל MVC על מנת להתמודד עם האתגרים החדשים שהציבו טכנולוגיות אלו.



יום שני, 12 בנובמבר 2012

על תפקיד ה Product Owner והשפעתו על הארכיטקטורה

בסקראם, ה Product Owner (בקיצור PO) נדרש למלא 2 תפקידים שונים בתכלית:
  • מצד אחד: לחבוש את "מגבעת המרחבים" ולחלום על חזון רחוק, שכרגע אולי ואינו ברור או אפשרי.
  • מצד שני: לחבוש את "קסדת בוב הבנאי" ולהוביל בנייה הגיונית של מוצר מעשי.
בעוד מגבעת המרחבים נמצאת עם איש המוצר עוד מימי "מפל המים", קסדת בוב הבנאי היא חדשה למדי.
הכישרונות הנדרשים עבור כל כובע, גם הם, שונים לחלוטין:
  • כשהוא לובש את מגבעת המרחבים, עליו לעבוד עם לקוחות ולקלוט כל רמז או רעיון אפשרי, לעשות סדר בהר של דרישות, לעמוד בלחצים כבדים והתערבויות מההנהלה ואנשי השיווק (מי לא רוצה להשפיע על המוצר?), ולקנות לו מקום בלבם של אנשי המכירות ואנשי השטח.
  • הכובע של בוב-הבנאי דורש מיקוד רב והתעלמות מרעשים (מה שהיה עד אותו הרגע "חזון"), כתיבת דרישות תכליתיות ומפורטות, חשיבה לוגית על סדר הבניית המוצר ועבודה עם מתכנתים - להיות זמין ולענות תשובות קונקרטיות בזמן-אמת.
ממש פיצול אישיות!

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


שייך לסדרה: אג'ייל - מתודולוגיות פיתוח רזות


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

בעוד ה PO חובש את מגבעת המרחבים, התמונה הראשונה המתגלה לעיניו על המוצר היא משהו כזה:

אקסל כ"מוצר עוצמתי ורב יכולות עבור המשתמש המקצועי". מקור: http://nizagreen.blogspot.co.il/2012/01/partes-de-excel.html

או אולי משהו כזה... (עבור ה PO בעל הנטיות השיווקיות):
"אקסל מוכן להשקה". מקור: מייקרוסופט
"Begin with the end in mind" היא אחת העצות שנותנים למנהלי מוצר בכדי שיהיו יעילים.


תחת הכובע של בוב הבנאי, התמונה הראשונה שעל ה PO לראות צריכה להיות משהו כזה:
היכולות הבסיסיות ביותר באקסל, מפורטות ומדויקות. מקור: וויקיפדיה.

האם זה אפשרי? האם אדם אחד יכול לעשות כזה "סוויץ'" בנקודות המבט? בואו נניח שכן.


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

מה יקרה אם יהיה לנו ״איש חזון ושיווק״ טוב, שלא יחבוש את ״קסדת בוב-הבנאי״?

בואו ניקח לדוגמה סיפור בו אנו רוצים להוסיף למוצר שלנו יכולת חדשה: בדיקת איות.
ה PBIs[ב] של היכולת, כפי שהוגדרו על ידי ה׳ PO, נראים כך:
  1. כמשתמש, אני רצה שבדיקת האיות תהיה מהירה, תוך כדי הקלדה (= שיפורי ביצועים)
  2. כמשתמש, אני רוצה שיוצגו לי כתיקון לשגיאת הכתיב, קודם מילים נפוצות יותר בשפה
  3. כמשתמש, אני רוצה שיוצגו לי הצעות לתיקון ע"פ מילים שמופיעות במסמך
  4. כמשתמש שמגדיר את העדפותיו - אני רוצה לקבוע אם בדיקת האיות תהיה תוך כדי הקלדה וכמה משאבים יוקצו לה
  5. כמשתמש שמגדיר את העדפותיו - אני רוצה לקבוע אילו מילונים יהיו בשימוש
  6. כמשתמש שמגדיר את העדפותיו - אני רוצה לקבוע חוקים ספציפיים לבדיקת האיות בשפה נתונה
  7. כמשתמש בגיליון - אני רוצה לראות סימון אדום כאשר יש לי שגיאת כתיב
  8. כמשתמש בגיליון - אני רוצה לקבל המלצות לתיקון
  9. כמשתמש בגיליון - אני רוצה להיות מסוגל להחליט שמילה שנתפסה כשגיאה היא תקינה - ולהוסיף אותה למילון
תפקיד ה PO לקבוע priority חד-משמעי לכל PBI: באיזה סדר על צוות הפיתוח לעבוד. זו הדרך של סקראם לוודא שלא עובדים על פיצ'רים לא-חשובים ושומרים על יעילות גבוהה. כפי שנראה בהמשך, מנגנון זה דורש רגישות רבה לאופן בו מפתחים מוצרים.

שאלה: בהנחה שיש לצוות יכולת לבצע את כל 9 ה PBIs בוודאות, האם יש משמעות לסדר של ה PBI שהוא מגיש?

תשובה: בהחלט כן! לסדר בו יגיש ה PO את ה PBIs לצוות יש השפעה ניכרת על התוצאה הסופית מבחינת ארכיטקטורה ואיכות הקוד.

אנו נוגעים כעת במרכז העצבים של מתודולוגיות ה Lean / Agile.


על קביעת העדיפויות
ייתכן ול PO הדבר שלחוץ ביותר, כשהוא חובש על ראשו את מגבעת המרחבים, הוא בדיקת איות מהירה תוך-כדי כתיבה. המתחרים מתהדרים בזה, אנשי המכירות רוצים סופסופ לומר "גם לנו יש!" או שזו ההזדמנות להקדים את המתחרים ולהכות את השוק.
אלו הם שיקולים עסקיים חשובים! מחויבותו של ה PO הוא להבין אותם ולתת להם דגש.

מצד שני, אם ה PBI הראשון ב backlog יהיה: "כמשתמש, אני רצה שבדיקת האיות תהיה מהירה, תוך כדי הקלדה" (= שיפורי ביצועים) - איך יוכל צוות הפיתוח לגשת למשימה? יהיה עליו לעשות שיפורי-ביצועים, אבל למה? למשהו שעוד לא קיים? למשהו שעוד לא ברור כיצד הוא יעבוד ומה הוא יעשה?!

זכרו את הקונטקסט: בסקראם, כולם נמצאים בריצה מספרינט לספרינט. ברוב הפעמים, לא יהיו הגדרות מדויקות של PBIs, ולא יהיו UI Mockups מוכנים אלא אם זה PBI שצפוי להתממש בספרינט הקרוב. כולם עובדים "Just-In-Time".

הנה תוצאה אפשרית וסבירה למצב הנ"ל:
  • המפתחים יפתחו מנגנון Cache. כי cache = ביצועים.
  • כיוון שהם לא יודעים מה תהיה התנהגות הריצה של מנוע בדיקת האיות, ואלו תבניות התנהגות הוא יכתיב ל Cache - הם יוכלו לכתוב רק Cache "גנרי". כזה שעושה הכל "בסדר", אך לא מצטיין באף תסריט ספציפי.
  • סביר אפילו, שעבור הרגשת הביטחון שה Cache בסדר ("!Done means Done") יפתחו אותו קצת אקסטרה - רק כדי "להרגיש בטוחים", וללא קשר לידע קונקרטי.
  • אם נקביל תהליך זה להתאמת מבנה-נתונים לבעיה, אזי על צוות הפיתוח לבחור מבנה נתונים לבעיה שלא הוגדרה. כיצד בוחרים מבנה נתונים כזה? מחפשים כנראה הרבה (O(1 - אולי HashTable שמאונדקס כפול ברשימה-משורשרת. ברור שזה מבנה נתונים שאינו "גרוע" למקרים רבים - אך כנראה שגם לא אופטימלי לכמעט אף מקרה.
מה לא היה בסדר? ה PO שם במקום הראשון את הדבר שמרקטיאלית הוא החשוב ביותר - זה נשמע הדבר נכון לעשות.
ה PO גם לא יכול היה לספק Functional Spec מפורט להכל מראש - זה לא Waterfall.
כלומר: ה PO יכול "לעשות הכל ע``פ הספר" - ועדיין להגיע לתוצאה לא-טובה.


"Amplify Learning / Amplify Feedback"
אם נחזור לעקרונות ה Lean, ניזכר שאחד מעקרונות היסוד הוא "הגבר את הלמידה" - זהו עקרון מרכזי בעולם האג'ייל[ג].

בעת בניית וסידור ה Backlog, על ה PO לחבוש את "קסדת בוב-הבנאי" ולקחת בחשבון גם שיקולים של בניית מוצר: מה הגיוני לבנות לפני מה? היכן ישנן שאלות מהותיות (טכנולוגיות) פתוחות - שאם נתקוף אותן קודם לכן נוכל לייצב טוב יותר את ארכיטקטורת המערכת.
תזכורת: ב"מפל המים", החופש המלא לקבוע את סדר הפיתוח היה בידי צוות הפיתוח. מנהל המוצר העביר "מסמך דרישות" והוא נפגש עם הצוות לאחר שנה לראות את התוצאות. צוות הפיתוח היה מודע לאספקטים הטכנולוגיים ויכול היה לקבוע סדר הגיוני של פיתוח.
לרוע המזל, שיטת מפל המיים, דווקא בנקודה זו, לא עבדה כ"כ יפה: כמעט תמיד גוף הפיתוח לא סיים לממש את כל הדרישות ולעתים נוצר מצב בו פ'יצר משני פותח במלואו, בעוד פ'יצר מרכזי וחשוב - נשאר בחוץ.

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

להלן 2 כללים שיכולים לעזור ולהנחות כיצד לבנות Backlog שמאפשר גדילה בריאה (טכנולוגית) של מוצר. כמובן שה PO יכול להעזר למשימה זו בפיגורה טכנולוגית.

חתרו למשהו מינימלי ועובד, ורק לאחר שהוא עובד - חזרו ועבו (מלשון עיבוי) את הפ'יצר.
מי שבא מרקע של מדעי המחשב בוודאי זוכר את האלגוריתמים לסריקת גרף: BFS ו DFS. בכדי "לגדל מערכת" באג'ייל אנו נרצה בבירור לעשות DFS (להגיע ל"משהו עובד" מהר ככל האפשר) ולא BFS (לעבוד שכבה שכבה ולסיים עם כולן בו-זמנית).

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

כיצד נראה Flow מינימלי ועובד? - הכי פשוט שאפשר.
בדוגמת האיות, אפשר להגדיר מילון סתמי שאומר:"Ncok ו Rokk הן שגיאות כתיב, כל השאר - בסדר". במקום להתעסק בהגדרת מילונים ובנייתם - אנו יכולים להתקדם לשלב הבא. בניית מילון היא משימה צפויה / ברורה. עלינו לזהות משימות צפויות או ברורות ולדחות אותן לשלב מאוחר יותר.
בשלב הבא: לדאוג שהמוצר שלנו ("אקסל") מאתר את שגיאות הכתיב תוך כדי הקלדה ומציג אותן למשתמש בצורה שאנו מוצאים כטובה. ה UI יכול להיות מאוד בסיסי.
ברגע שיש לנו את הסיפור השלם והבסיסי ביותר עובד (עם כמה הנחות מקלות בדרך - שנחזור ונתקן) - השגנו משהו חשוב מאוד:
שיתפנו את כולם בצורה מאוד ברורה בחזון שלנו. מצגות ומסמכי-מלל הם דבר נחמד, אבל רק כאשר מתחילים לחבר את הפרטים - התמונה באמת מתבהרת. מתכנתים זקוקים לפרטים על מנת לבנות את המערכת בצורה נכונה. גם מנהל המוצר עצמו יוכל לוודא יותר טוב שהוא בכיוון הנכון על בסיס משהו מוחשי וברור - פנימית וחיצונית לארגון.
בשלב מאוחר קצת יותר, כשהמפתחים יגיעו לממש את הסיפור "בדיקת איות תוך כדי הקלדה" - תהיה להם הבנה מספיק טובה של התסריט - על מנת לבנות את המנגנון הנכון להאיץ אותו.

הנה, כך אנו רוצים שבדיקת האיות תראה. אופס - וצריך גם "ignore". האם אתם רוצים לגלות זאת לפני, או אחרי שכתבתם את כל הקוד?

הגדירו Maximum Learning PBIs - ויישמו אותם ראשונים
ה PBIs מהם נלמד הכי הרבה הם לרוב כאלו שכוללים UI.
מדוע? "תמונה אחת שווה אלף מילים". כבני אדם, אנו יכולים להפיק מהגדרות ה UI הבנה טובה יותר של הדרישה מאשר מהתיאור המילולי שלה. אפילו ה PO בעצמו יתגבש טוב יותר - אם הוא יעבוד עם איש ה UX בשלב מוקדם להגדיר את ה User Interaction. בעיות רבות עלולות לצוף באופן זה בשלב מוקדם.
במערכות ללא UI, כגון שרתים - יהיו אלו הנתונים. "נתונים לפני" ו "נתונים אחרי" או "מה נכנס" מול "מה יצא". התבוננות בנתונים ראליים, בעלי משמעות - שווה יותר מעשרות מצגות ופגישות הדנות ב"כוונות" וב"המוצר - לאן?". פשוט אספו נתונים ראליים שאתם רוצים שהמערכת שלכם תעבד והציגו אותם.

ב"מפל המים" לימדו אותנו שאי אפשר לכתוב UI לפני שהשירותים שמאחוריו כבר כתובים ועובדים. בואו נתקן אמירה זו: לא ניתן לסיים לכתוב את ה UI לפני שסיימנו לכתוב את השירותים שמאחוריו, אבל אפשר להתחיל.
UI שבו רוב הכפתורים הם disabled - הוא התחלה סבירה על מנת להגביר את הלמידה. כיתבו קוד שמציג התנהגויות מרכזיות שהוגדרו מראש, אפילו בצורה hardcoded, ועליתם מדרגה ברמת הלמידה שניתן להשיג בשלב מוקדם זה.
  • UI יוצר דיון וגורם לאנשים להביע דעה / להבין / להעלות בעיות.
  • ה UI ישתנה בכל מקרה - עדיף להתחיל את סבב השינויים עוד לפני שסיימנו לכתוב את כל המערכת שתומכת בו.
  • UI הוא "הקשר עם הלקוח/משתמש". קשר שממנו כל ההתנהגויות האחרות נובעות. שינינו את החוזה מול המשתמש? סביר להניח שכל המערכת תושפע מכך.
הערה: כל אלה נכונים, באין UI, גם לנתונים איכותיים.

כמובן שיהיו אנשים שיתנגדו לגישה זו: "למה לעשות UI בכאילו? למה לכתוב סימולציה hard-coded רק כדי למחוק אותה בספרינט הבא?".

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


תרגיל מחשבתי: גישה כנגד גישה
בתרגיל המחשבתי שמוצג בתמונות הבאות, ניתן לראות התפתחות אפשרית של מוצר בשני מקרים:
  1. אנו עובדים תחת הנחות מסורתיות של "מפל המים" / BFS: קודם נסיים את התשתיות - ואז נגיע בסוף ל UI.
  2. חתירה, מרבית, ל End 2 End flow - שגם מתחילה מהUI.
התרגיל הוא דמיוני, אך אני מרגיש שהוא מתאר יפה את הדינמיקה המציאותית.
הוא ממחיש כיצד עבודה ממוקדת תוצאה-מוקדמת יכולה למנוע מאיתנו להשקיע בכתיבת קוד שלא יהיה לבסוף בשימוש.
יש גם יתרון מובנה בלסיים "Flow" מוקדם יותר: יש זמן יותר לבחון את ה Flow, לתקן בו בעיות או להציע בו שיפורים.

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

הנחות: הצוות יכול להשלים "יחידה" אחת בספרינט, אך כדי שלא יהיה "צפוף מדי" למפתחים - עובדים תמיד על 2 קוביות שונות במקביל. כלומר: תוך 2 ספרינטים - אפשר לגמור קובייה.

לחצו על התמונות להגדלה.

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

אל מול:

"אנחנו לומדים", "אנחנו מנסים", "נצמצם סיכונים - ונתמקד קודם בחשוב מכל. נמשיך הלאה אחרי שנראה אותו גמור" - יותר טוב.


שיהיה בהצלחה!

הפוסט עודכן ב 17/11/12 עובר רביזיה כללית.

----

[ב] Product Backlog Item - יחידת עבודה לספרינט עבור הצוות או חלקים ממנו.

[ג] תוכלו לקרוא על עקרון זה ואחרים בפוסט "קיצור תולדות הסקראם - חלק 2" בסדרה זו.




יום שני, 5 בנובמבר 2012

סדרה: Agile (מתודולוגיות פיתוח רזות)

ישנם חילוקי דעות לגבי מתודולוגית הפיתוח החדשה יחסית "סקראם" (SCRUM): "שווה" או "לא-שווה"?

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

נתקלתי ברעיונות האג'ייל לראשונה בשנת 2002, עוד בתקופת האוניברסיטה, בעת שמנחה הפרויקט שלנו דרש מאיתנו לעבוד ב Extreme Programming - קיצוני למדי לאותה התקופה, אולי בכלל. רעיונות אלו טלטלו אותי והשפיעו עלי עמוקות.

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

בסדרה זו קיבצתי פוסטים העוסקים בנושא מתודולוגיות הפיתוח הרזות - Agile.
שימו לב שהפוסטים לא מוצגים בסדר שהם פורסמו: פרסמתי קודם "דיוני-עומק" ורק לאחר מכן חזרתי אל הבסיס.


אני מתכוון, עם הזמן, להמשיך ולהעמיק את הסדרה.




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





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





קיצור תולדות הסקראם - חלק ב'
בעוד חלק א' הוא יותר סיפורי - חלק ב' מתמקד בעקרונות עצמם, כפי שהושמו ע"י טויוטה וה TPS.
עקרונות אלו נקראם Lean או Lean Manufacturing - סקראם הוא רק תרגום שלהם, לעולם התוכנה.




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





סקראם - על חודם של שני אנשים
בואו נדבר ת'כלס: סקראם כולל הרבה רעיונות / כללים, אבל מה באמת הכי חשוב?
אם אנו רוצים להתמקד ברעיון אחד או שניים - מה הם צריכים להיות?






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



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