להשתמש ב-TextMate בשביל הודעות Commit של Git


אני עובד עם Textmate ועם Git מאז שיש לי מק ומאז שהתחלתי לעבוד עם Ruby On Rails.

אחד החסרונות הכי גדולים של Git לעומת מערכות Source Control אחרות, היא שאין GUI למק (או לפחות אחד כזה נורמלי) ולכן, הודעות הקומיט שלי תמיד היו מתבלגנות ב-Command Line ומצאתי את עצמי מפרט פחות ממה שאני רגיל ואוהב.

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

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

ראשית, צריך להורות ל-Git להשתמש ב-TextMate בשביל זה, עושים את זה על ידי ה-Command Line – כך:

git config --global core.editor "mate -w"

לאחר מכן, את הודעות הקומיט מבצעים כך:

git commit -a --amend

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

זה הכול, הקומיט בוצע! שימו לב שכבונוס, git כוללת בפנים גם את שמות הקבצים, אם תוציאו אותם מהערה תוכלו לכלות בקומיט גם את שמות הקבצים או לעשות הודעות מסודרות כמו שם הקובץ ומתחתיו לכתוב את כול מה ששיניתם בקובץ (זו הדרך החביבה עלי)

תאוריית החלון השבור – איך זה קשור לפיתוח תוכנה?

חלון שבור

פיתוח תוכנה מכירים? אני בטוח, אני גם בטוח שאחרי הפוסט הזה תגשו לפיתוח תוכנה בצורה קצת אחרת (אני לפחות מקווה).

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

הקדמה – תאוריית החלון השבור

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

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

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

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

בעקבות הניסוי החוקרים פיתחו את תאוריית החלון השבור, בואו ונבהיר אותה או לפחות ננסה.

בניין מגורים – חלון שבור

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

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

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

אני יודע מה אתם חושבים עכשיו (אני גם קורא מחשבות בזמני הפנוי)…

מה זה קשור לפיתוח תוכנה ואיך זה נוגע לי כמפתח בחיי היומיום?

כן, הכותרת שברה שיאי אורך :-)

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

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

קוד מקור לדוגמא

קוד מקור לדוגמא

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

אילוצים או תירוצים?

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

אבל אם נסתכל אחד לשני (ולעצמנו) בעיניים אנחנו בעצם יודעים שאלה תירוצים ולא סיבות.

מה אפשר לעשות?

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

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

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

לסיום, אני רוצה לצטט את Uncle Bob Martin (ברשותכם כמובן)

No matter who. No matter what. No matter when. Short term.Long term. Any term. Writing good code is ALWAYS faster than writing bad code.

Refactoring should never appear as a task on a schedule, Keeping code clean is just something you do all the time

כרגיל, אשמח לתגובות.

הטעויות הכי נפוצות (וגדולות) בפיתוח אפליקציות פלקס

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

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

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

1. שימוש בflex כדי לבנות אתרי אינטרנט או אפליקציות מדור ישן

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

אני זוכר, בתור ילד צעיר למדתי קראטה, with great power comes great responsibility, אמצו את זה כאשר אתם ניגשים לפתח אפליקציה. אם אין לכם אפליקציה שדורשת ויזואליות מסוימת, אנימציות, עבודה עם datasets גדולים וכו', עדיף שתשתמשו בטכנולוגיות אחרות כמו html, css ואפילו פלאש.

Flash this not that

Flash this not that

אפשר לראות פוסט באנגלית על זה כאן

מקור התמונה The Flash Blog

2. האטת האפליקציה עד כדי זחילה על ידי שימוש ביותר מדי containers

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

השקף הזה מדבר על ריבוי containers. הרבה אנשים שמגיעים מhtml לתוך עולם הפלקס (וזה קורה המון) לא מבינים שcontainer  בפלקס הוא component בפני עצמו שיש מאחוריו עשרות (לעיתים מאות) חישובים של גודל, מיקום, מיקום ילדים, גודל ילדים. ועוד יותר גרוע מזה, ולידציות וinvalidations.

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

אפשר לראות כאן צילום מסך של תחקיר שעשו חברים בקהילה מאתר Inside RIA

צריכת זכרון כאשר יש יותר מדי Containers

צריכת זכרון כאשר יש יותר מדי Containers

ניקח דוגמה שפורסמה בזמנו בYahoo Developer Network (את המאמר המקורי אפשר למצוא כאן, אבל אני מתמצת את עיקרו שרלוונטי לנושא)

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

יותר מדי container באפליקצית flex

יותר מדי container באפליקצית flex

הדרך הראשונה

והקוד:

 <Application layout="absolute">

     <HBox width="100%">

         <Button label="Left"/>

         <Spacer width="100%"/>

         <Button label="Left"/>

     </HBox>

 </Application>
יותר מדי container באפליקצית flex

יותר מדי container באפליקצית flex

שימו לב שיש לנו כאן מספר containers, רובם מיותרים, סבב התיקונים הראשון ועכשיו האפליקציה שלנו נראית כך

הקוד שלנו נראה כך:

 <Application layout="horizontal">

     <Button label="Left"/>

     <Spacer width="100%"/>

     <Button label="Left"/>

 </Application>

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

מספר container נכון באפליקצית flex

מספר container נכון באפליקצית flex

הטיוב האחרון שלנו נראה כך:

והקוד נראה כך:

 <Application layout="absolute">

     <Button label="Left" left="5"/>

     <Button label="Left" right="5"/>

 </Application>

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

3. שימוש בXML

אחד היתרונות הכי גדולים בפלקס זה היכולת של הפריימוורק להתמודד עם XML אבל עדיין בטכנולוגיות של היום יש שיטות כול כך יותר טובות להעביר Data שכל מעבר כזה בין הClient לServer והפוך לוקח הרבה פחות זמן.

XML לא רק לוקח יותר זמן לפרסר אלא לוקח יותר זמן להעביר על הwire ויכול לעלות המון כסף של BandWidth.

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

את האפליקציה הזו אפשר למצוא כאן

דוגמאות לסוגי העברת מידע בין Client לServer

דוגמאות לסוגי העברת מידע בין Client לServer

4. שבירת מוסכמות והרגלי גלישה באינטרנט

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

עם פלקס אפשר להגיע לניווט רגיל לגמרי, אפשר לעשות Bookmark, אפשר להגיע לדף ספציפי עם כתובת ספציפית בלי ליצור SWF's נפרדים, אפשר הכול. כאשר אתן ניגשים לבנות את האפליקציה שלכם, שימו לב לזה, לעשות Deep Linking שיהיה אפשר להגיע לכול חלק מיידית, ללא ניווטים וקליקים מיותרים.

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

5. שימוש מוגזם באנימציות ומעברי עמודים

אני אהיה הראשון שאעמוד לימין הframework והיכולת שלו להתמודד עם משימות גראפיות כבדות, אבל אני גם אהיה הראשון לומר ש"My Account" לא צריך לעוף ב720 מעלות מתוך הקצה הימני של המסך, הוא לא צריך לשנות את הצבע שלו ולא צריך להזיז את הכפתור ב200 קמ"ש אחרי שלחצתי.

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

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

כנ"ל עם מוזיקה או Audio Effects.

6. לא לפתח סביבת פיתוח תומכת Craftsmanship או Agile או לא לפתח EcoSystem בכלל

זה נכון לכול טכנולוגיה, בין אם זה flex או אפילו Ruby on rails. לגשת ישירות לפיתוח מבלי להתחשב ולא להנהיג שיטות Tdd/Bdd, Unit Testing, Code Coverage וכו' זה פשוט לא אחראי, זה לא אחראי במיוחד באפליקציות פלקס מכיוון שכשלא עושים את זה, צריכים לבדוק את הכול דרך הUI, לחכות לקומפיילר שירנדר את האפליקציה בכול פעם, זה בזבוז זמן ומשאבים אדירים.

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

הנה כמה:

FlexUnit

FlexMonkey

תפתחו שיטות עבודה איכותיות שמעודדות בדיקות, מעודדות Craftsmanship, מעודדות Clean Code ואחריות מפתחים.

7. לא לעשות שימוש בBuild Machine ובContinuous Integration

היות ואפליקציות Flex עוברות קומפליציה, כלומר מקוד מקור לאפליקציה סגורה, קובץ SWF שיטת הpublish צריכה להיות כזו

תהליך פיתוח ומעבר נכון לProduction

תהליך פיתוח ומעבר נכון לProduction

מה זה אומר בעצם?

זה אומר במפתח עושה Commit לקוד שלו, לתוך מכונה יעודית, במקרה הזה עדיף לעשות שימוש בGIT כי אז הוא יכול לעשות local commits וpush רק כשהוא בטוח שיש אצלו הכול.
המפתח כמובן בודק את הקוד שלו, כך שקוד שנכנס למכונה הוא קוד שעבר בדיקות.
על המכונה הקוד עובד בדיקות נוספות, כדי לבדוק Integration של כול המפתחים, במידה וכול הבדיקות עוברות, הקוד מתקמפל לאפליקציה ועולה לאוויר (אם צריך)

יעיל נכון?

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

אני חושב שאלה הנקודות העיקריות שעולות לי לראש בשלב זה, אם יהיו דברים נוספים אוסיף אותם לפוסט.

כרגיל, אשמח לשמוע את דעתכם.

תכנות מונחה התנהגות ברובי און ריילס – חלק 2 (Screencast)

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

החלק השלישי יצולם ויעלה בימים הקרובים.

כרגיל, אשמח לתגובות שלכם

תוסף ל-Flash Builder 4 שמתכנתי פלקס חייבים לנסות

Screen shot 2010-10-03 at 8.02.59 PMאני מתכנת פלקס כבר 4 שנים בערך, מתוכן חצי שנה או אולי קצת יותר אני עובד עם Flash Builder 4.

לאחרונה, גיליתי תוסף לIDE שנותן המון ערך מוסף, בעיקר אם אתם מתכנתים שמאמינים בקיצורי דרך, קיצורי מקלדת code snippets ועוד.

אני מתכנן לצלם השבוע screencast על התוסף הזה עם כול מיני טיפים והוראות של איך עושים בו שימוש וממקסמים אותו עד הקצה, אבל בינתיים, כתבתי על הנושא פוסט באנגלית. אתם מוזמנים לקרוא אותו – Make your life easier with this Flash Builder 4 plugin

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

תכנות מונחה התנהגות – רובי און ריילס (סקרינקאסט)

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

הסקרינקאסט קצר ונועד להסביר בקצרה את העקרונות ולהציג את שיטת העבודה המיוחדת ברובי און ריילס ובBDD.

הערה: לחוויית צפיה מיטבית, מומלץ לבחור HD ולהגדיל את הוידאו למסך מלא.

ניהול זכרון באפליקציות פלקס או איך לשמור על שפיות

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

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

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

הדבר שתיארתי למעלה מתואר בהמון פוסטים שהכותרת שלהם היא "flex sucks" וכן הלאה, נחסוך תיאורים אחרים.

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

מה גם, שבעולם של היום שהוא עולם של mobile devices, חשוב לנו להבין שהזכרון הוא משאב עוד יותר מוגבל.

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

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

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

דליפות זכרון

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

אפליקציות פלקס מנהלות זכרון על ידי referances. כלומר, אם יש לי instanceA שיש לו referance דרך instanceB הוא לא ישוחרר מהזכרון עד שלא נשחרר את ההפניה.

Event Listeners

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

ניקח את פיסת הקוד הזו למשל

//objectX
objectY.addEventListener(some_event, some_function)

יש לנו כאן בעצם שני אובייקטים, יש לנו את אובייקט Y ויש את אובייקט X.

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

כן כן, תנו לזה לשקוע :-)

ניתן בevent Listeners לומר שהlistener  הוא weak, כלומר הוא לא נחשב כreference מאחורי הקלעים, יש ויכוח מאוד גדול כול פעם שהנושא הזה עולה ב StackOverflow או כול פורום אחר, הרבה אומרים שאדובי היו צריכים לעשות שevent listeners יהיו weak כברירת מחדל, אני חייב לומר שאני לא מסכים עם הקביעה הזו, אני חושב שאנחנו כמתכנתים צריכים לדעת לזרוק את ה listeners לפח בסיום השימוש

משתנים סטטיים

משתנים סטטיים לעולם לא מתאפסים, לאורך כול חיי האפליקציה ערך שהצבתם בהם צורך זכרון, דמיינו עכשיו שנתתם למשתנה static ערך מסוג class שמחזיק event listener והנה יש לכם כאן מסננת של זיכרון שתדלוף ותדלוף.

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

// static variable
public static var _foo:Foo;
//setting the value
_foo = new Foo();
//clean
_foo = null;

Dictionaries

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

אני אנסה להסביר את זה בצורה הטובה ביותר שניתן אבל אנא אמצו את עינכם, זה ממש קסמי Adobe ניהול הזכרון באובייקטים האלה :-)

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

אפשר לקבוע weak key כלומר במידה ואין הפניות (references) לאובייקט X, הוא יאסף על ידי הCollector אבל עכשיו יש לנו מצב מוזר, אפילו שיש לנו ערך בלי מפתח, הערך עדיין שם.

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

אשמח עם מישהו מצוות פיתוח פלקס יבהיר את המצב הזה…

נמשיך.

איך מנקים את המצב הזה?
יש האק, אם עושים לולאת For על הDictionary, כול הערכים שאין להם מפתחות ינוקו גם הם, כמובן בכול מגבלות הreferance הקיימות.

סיכום

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

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

לפני כחודש היה לי לקוח שטיפלתי לו בדליפת זכרון של 1G מתוך פלייר וידאו, כול מה שעשיתי היה לדאוג לניקוי של Event Listeners והאפליקציה היום צורך 23מגה בשיא העבודה והעומס שלה.

שמירה על קבצי mxml מסודרים על ידי שימוש ב-ViewHelpers

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

היות ואפליקציות פלקס מכילות לוגיקה שקשורה ל-view, לוגיקה שקשורה ל-services וכן הלאה, אני תמיד בעד לשמור דברים מסודרים ונקיים, כחלק מהעקרונות של clean code. לכן, אני מאוד אוהב שקבצי ה-mxml שלי מכילים אך ורק קוד mxml ללא קוד actionscript כלל וכלל.

איך אני עושה את זה?

אני עושה שימוש במשהו שאני קורא לו ViewHelper. אין להתבלבל אגב עם המימוש של Cairngorm ל-ViewHelper מכיוון שזה לא אותו הדבר, אני עושה שימוש ב-custom class רק כדי לשמור על קוד מאורגן ונקי.

את השיטה הזו אפשר לממש ללא קשר לפריימוורק mvc שאתם עושים בו שימוש (אני אגב משתמש ב-RobotLegs).

מה השימוש לViewHelper?

השימוש הוא בעצם לשמור את כול קוד הActionScript מחוץ לקבצי הmxml שלנו. כמו כן, ליצור משהו גנרי שאנחנו יכולים להשתמש בו דרך כול האפליקציה ושתהיה שפה משותפת. כך למשל, אפשר שהViewHelper יכיל אוסף של ולידציות שאפשר להוסיף לView, כמו כן הוא יכיל Event Listeners שקשורים לאותו View וכו'.

אוקיי, אז איך נראית אפליקציה לדוגמא?

כך נראה מבנה הקבצים שלנו בתוך Flash Builder 4

Screen shot 2010-08-19 at 5.26.08 PM

ניתן לראות שיש לנו את האקליקציה המרכזית, יש לנו View component יש לנו את ה helper של ה view component הזה ויש לנו את הקלאס BaseViewHelper שמכיל את כול השדות והפקודות שכול ViewHelper יורש מהן.

אז בואו נראה איך נראה הקוד של BaseViewHelper

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

package com.kensodev.core
{
	import mx.core.UIComponent;

	public class BaseViewHelper
	{
		private var _view:UIComponent;

		public function BaseViewHelper()
		{

		}

		public function init():void
		{

		}

		public function set view(v:UIComponent):void
		{
			_view = v;
		}

		public function get view():UIComponent
		{
			return _view;
		}
	}
}

אז כמו שאפשר לראות יש לנו כאן referance לview שיכול להיות כול uiComponent וזה בערך הכול, אפשר להרחיב את הhelper לכול צורך שאתם רואים, למשל להצמיד לכול View מודל מסוים או dataProvider שצריך להיות bindable ועוד.

עכשיו, איך נראה ViewHelper שיורש מה base class שלנו?
כך


package com.kensodev.views.helpers
{
	import com.kensodev.core.BaseViewHelper;
	import com.kensodev.views.MyViewComponent;

	public class MyViewComponentHelper extends BaseViewHelper
	{
		public function MyViewComponentHelper()
		{
			super();
		}

		public function get myView():MyViewComponent
		{
			return MyViewComponent(this.view);
		}

		public override function init():void
		{
			//TODO Auto-generated method stub
			super.init();
		}

		public function myButton_clickHandler(event:MouseEvent):void
		{
			// TODO Auto-generated method stub
		}
	}
}

כמו שאפשר לראות גם כאן אני מבצע override לחלק מהפונקציות שקיימות בBase, הוספתי פונקציה שנקראת myView שמחזירה לי את ה view של הhelper אבל הפעם עם קאסטינג לview האמיתי, כך אני יכול לגשת לכול קומפוננטה על הview מתוך הhelper ישירות, זה מאוד יעיל ומרכז קוד בצורה טובה מאוד.

עכשיו לחלק האחרון, כך נראה הView שלנו

<?xml version="1.0" encoding="utf-8"?>
<mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml"
		   width="400"
		   height="300"
		   creationComplete="helper.init()"
		   xmlns:helper="com.kensodev.views.helpers.*">

	<mx:Script>
		<![CDATA[

		]]>
	</mx:Script>

	<helper:MyViewComponentHelper view="{this}" id="helper" />

	<mx:Button id="myButton" click="helper.myButton_clickHandler(event)"

</mx:Canvas>

כמו שאפשר לראות, אנחנו כוללים את הhelper בתוך הview מה שגורם לו להיות "מופעל", כמו כן ניתן לראות שבקליק על הכפתור אני מפעיל פונקציה בתוך הhelper במקום לכתוב את הפונקציה ישירות על אותו הקובץ

דרך אגב, יש מוסכמה על השמות, כך שבעצם קל מאוד למצוא את הקבצים האלה במערכת
אם יש לכם view שנקרא myViewComponent אז הhelper שלו יקרא myViewComponentHelper והמודל שלו יקרא myViewComponentModel והקומנד יקרא myViewComponentCommand וכן הלאה.

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

Screen shot 2010-08-19 at 5.36.53 PM

קוד המקור של האפליקציה נמצא בgit, תרגישו חופשי להוריד ולראות איך זה בנוי.
http://github.com/KensoDev/view-helper-example

האם כול המתכנתים צריכים להיות חברים פעילים בקהילה?

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

היום, הפוסט שלי הוא יותר דיון מכול דבר אחר.

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

האפליקציה היא אפליקצית פלקס שמבוססת על שירותים של Java, על Linux ועל vxWorks. כלומר, בתוך החברה הזו יש מתכנתים שיודעים מה הם עושים, עושים את זה כבר הרבה זמן ויש להם נסיון בproduction solutions בכול התחומים והטכנולוגיות שציינתי.

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

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

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

לאן אני חותר? אני חותר לכך שיש שם ידע לתרום ולהוציא החוצה כתרומה לקהילת המפתחים.

עכשיו לשאלה…

שאלתי היא: האם לדעתכם כול המתכנתים צריכים להיות חברים בקהילה הוירטואלית של המתכנתים בארץ?
האם כולם צריכים לכתוב בלוגים?
כולם צריכים להיות חברים פעילים בStackOverflow.com?
האם כולם צריכים להיות חברים בפורומים ולעזור למתכנתים אחרים?

אשמח לתגובות ולדיון…

על אמנות ביצירת תוכנה – Software Craftsmanship

לאחרונה חתמתי על המניפסטו של Software Craftsmanship.

הקדמה

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

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

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

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

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

האומנות ביצירת תוכנה, מה זה?

Software Craftsmanship היא מעבר לכול גישה או פילוסופיה, יש לה המון נקודות משותפות עם xp (extreme programming), אבל כפי שכבר אמרתי, זוהי לא מתודולוגיה, היא לא מגדירה עקרונות low level בפיתוח תוכנה כמו tdd או refactoring.

ישנו ספר שעוסק בנושא, אני מאוד ממליץ על קריאה שלו: הנה לינק אליו

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

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

ממשיכים…

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

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

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

ממשיכים…

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

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

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

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

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

רגע רגע, אני מתכנת .net, זה רלוונטי לי?

הממ, האמת היא שחשבתי הרבה על זה, בכול הפוסטים שמדברים על זה מדברים על זה שאין שום טכנולוגית open source שלא מתאים להחיל עליה softwre craftsmanship.

שימו לב להדגשה של קוד פתוח, ובכן, עם הקביעה הזו אני לא כול כך מסכים, אני חושב שאין קשר בין הפילוסופיה לבין עם אני עושה שימוש ב open source או לא, בהחלט יש כמה קווים שמשיקים בין open source לבין הפילוסופיה, אבל אני לא חושב שאם אתה מתכנת net אתה מוקצה מחמת מיאוס, אני דווקא חושב שזה יכול להיות יעיל מאוד לכול מתכנת באשר הוא, בין אם הוא מתכנת open source או מתכנת דוט נט (וכן, גם אני עושה דוט נט)

יש לי צוות של 20, האם אני יכול להגיד שהם עובדים תחת הכללים של software craftsmanship?

לא

האמת, לא

ושוב, לא

כאן, אני מסכים לגמרי עם מי שכתבו את הmanifesto, מדובר על צוותים קטנים בהם יש 1-2 craftsman ועוד 3-4 מתמחים, העבודה בצוותים קטנים מאפשרת להדגיש את העקרונות הנחים בצורה טובה יותר, אין שום בעיה ש20 איש יעבדו כך, אבל הם צריכים להיות מחולקים לצוותים קטנים יותר עם מספר מומחים קטן ומספר מתמחים גדול יותר בכול צות פיתוח קטן.

מה הקשר לדוד בוב?

uncle bob (חפשו בגוגל, אל תהיו עצלנים) הוא אחד הspeakers הטובים ביותר שיש לנו בתחום, הוא הגדיר את הפילוסופיה כ"חזרה לבסיס" או "לעשות את הבחירות הנכונות". בוב אגב, הוא הכותב של הספר clean code (עוד המלצה).

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

סיכום

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

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

כמובן, שאני כאן לכול שאלה ואשמח לעזור, רק תשאירו תגובה ואני אענה