עבודה או כסף ?

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

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

הסיבה האמיתית שאני משלם לך כסף

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

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

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

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

עבודה בארגון

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

לדוגמא הקוד הזה (שעובד גם בשפות שאינן JavaScript):

1 for (var i = 0; i < items.length; i++) {
2     if (items[i] === 'polyfill') {
3         return items[i];
4         break;
5     }
6 }
7 

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

היזון חוזר

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

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

הנה כמה דרכים לקבל היזון חוזר על העבודה

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

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

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

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

חומרי הדרכה

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

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

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

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

ואם תהיתם מה היה הקורס ... http://ynonperek.com/node/96

למה אני לומד

קיימות סיבות רבות המביאות אותנו ללמוד דבר מה חדש. להלן רשימה חלקית:

לצורך ביצוע משימה נקודתית (php)
לצורך ביצוע מספר משימות או מטלה ארוכת טווח
כי כל הילדים המגניבים מדברים על זה (ruby on rails)
כדי למצוא עבודה (java, .NET, php)
כי נשאר תקציב הכשרות לשנת 2011
כדי לעשות מזה כסף (אייפון)
כדי לפגוש אנשים חדשים עם תחומי עניין דומים לשלי
כדי לתת מענה טוב יותר ללקוחות/עמיתים
כדי להבין באגים מוזרים החוזרים על עצמם (character encoding)
כדי לשפר את ההבנה שלי במרחב הבעיות שבו אני עוסק
כי אי אפשר אחרת

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

מצגות טובות

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

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

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

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

ומה על מאיה ? צייתנות לא מייצרת עתיד. חשיבה יצירתית כן. תעזבו את המצגות ותתחילו לעבוד.

למידה יעילה

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

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

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

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

קצר או קריא ?

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

 אם ניקח את הקוד הבא לדוגמא:

 1 $f2 = shift or die "Missing dictionary file";
 2 
 3 open FH, "<$f2" or die $!;
 4 while(<FH>) {
 5   chomp;
 6   $h{$1} = $2 if /^(\w+) *= *(.*)$/;
 7 }
 8 close FH;
 9 
10 while(<>) {
11   s/\b\w+\b/exists $h{$&} ? $h{$&} : $&/ge;
12   print;
13 }
14 

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

 1 use strict;
 2 use warnings;
 3 
 4 my $USAGE = <<END;
 5 Usage: perl translate_long.pl <dictionary_file>
 6 END
 7 
 8 my $WORD = qr { \b\w+\b }xms;
 9 
10 my $dictionary_filename = shift or die $USAGE;
11 my %dictionary          = init_dictionary($dictionary_filename);
12 
13 while (<>) {
14   s/($WORD)/translated(\%dictionary, $1)/ge;
15   print;
16 }
17 
18 sub init_dictionary {
19   my ($filename) = @_;
20   my %dictionary;
21 
22   open my $dict_file, '<', $filename;
23 
24   while (my $line = <$dict_file>) {
25     chomp $line;
26 
27     my ($term, $value) = split / *= */, $line;
28     $dictionary{$term} = $value;
29   }
30 
31   close $dict_file;
32 
33   return %dictionary;
34 }
35 
36 sub translated {
37   my ($dictionary, $term) = @_;
38 
39   return ( exists $dictionary->{$term} ?
40                   $dictionary->{$term} : $term );
41 }
42 

עלינו מ 13 שורות ל 41 שורות. אז נכון את הקוד הראשוני היה קשה להבין, היה קשה לתקן או לאתר בו באגים ובוודאי שלא היה מה לדבר על שימוש חוזר - אבל האם באמת הרווחנו קריאות ? אני לא בטוח.

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

 1 use strict;
 2 use warnings;
 3 use Config::Std;
 4 
 5 my $USAGE = <<END;
 6 Usage: translate.pl <dictionary_file>
 7 END
 8 
 9 my $dict_filename          = shift or die $USAGE;
10 read_config $dict_filename => my $dictionary;
11 
12 # Use the default section of the file
13 my $section = $dictionary->{''};
14 
15 while (<>) {
16   s{ (\b\w+\b) }
17    { exists $section->{$1} ?
18      $section->{$1} : $1
19    }xge;
20    print;
21 }
22 

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

תמונות שחור-לבן

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

 1 use strict;
 2 use warnings;
 3 use Image::Magick;
 4 use File::Basename;
 5 
 6 my $path = '.' || shift;
 7 foreach my $png (glob("$path/*.png")) {
 8   my $basename = fileparse($png, '.png');
 9   my $bw_name  = "$basename-bw.png";
10   my $image    = Image::Magick->new;
11 
12   $image->Read($png);
13   $image->Quantize(colorspace =>'gray');
14   $image->Write($bw_name);
15 }
16 

כשהפטיש לא מתאים למסמר

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

אחד הכללים הידועים בתכנות הוא לבחור את שפת התכנות או הטכנולוגיה הנכונה למשימה. משחק לפייסבוק עדיף לכתוב בפלאש, אך אתר אינפורמטיבי עדיף לכתוב ב html5/javascript. כשרוצים להגיע לתוצאה מהירה עדיף להתרחק מג'אווה או C++.
כלל זה תקף גם בבחירת הגישה לעבודה כשמתחילים פרויקט. הגישה מורכבת מאוסף ההחלטות שקיבלנו ונקבל לגבי הפרויקט והיא שתביא אותנו לקו הסיום בזמן. להלן שלושה סוגים של פטישים והשימוש הנכון בהם.

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


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

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

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

ציונים

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

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

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


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

תודה לכל מי שהיה בקורס ההוא וקורא. הייתם אחלה. עכשיו חזרו לעבוד.

פרל ? מישהו עדיין עובד בזה ?

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

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

 1 use strict;
 2 use warnings;
 3 use Dancer;
 4 
 5 my $proj_path = '~/src/project';
 6 
 7 post '/commit' => sub {
 8   system("hg pull -R $proj_path /.. >> $proj_path/hg.log");
 9   system("hg update -R $proj_path /.. >> $proj_path/hg.log");
10   return 0;
11 };
12 
13 dance;

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

http://myhostname.com:3000/commit

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

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

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

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

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

גמישות השפה והתאמה לכלל DRY. כלל ידוע בתכנות הוא שלכתוב דבר פעמיים זו טעות (Don't Repeat Yourself). הראציונל הוא פשוט, כשמגיעים לבצע שינוי בקוד צריך להיות ברור איפה משנים, ועדיף שזה יהיה בכמה שפחות מקומות. לדוגמא, העובדה שבג'אווה אנו לא צריכים לכתוב את חתימת המתודות בשני קבצים שונים, הופכת אותה לשפה עדיפה על פני C++.

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

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

חידוש האתר

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

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

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

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

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