הבלוג של ינון פרק

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

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

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

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

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

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

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

והעניין שלנו היום בהליכי גיוס הוא היחס לפרילאנסרים.

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

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

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

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

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

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

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

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

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

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

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

0 7 * * 0,1,2,3,4,5 /home/ynon/bin/cron/daily_blog.sh
0 21 * * 6 /home/ynon/bin/cron/daily_blog.sh

למי שעדיין לא לקח את קורס Linux שלנו (איך עדיין לא לקחתם את קורס Linux?! הוא מעולה. קחו את קורס Linux) המשמעות היא שבימים ראשון עד שישי המייל יישלח בשבע בבוקר וביום שבת בתשע בערב אחרי צאת שבת.

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

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

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

את תיקיית הפרויקט עם מאגר הגיט אפשר להוריד מהקישור:

http://www.tocode.co.il/system/uploads/git-ex.zip

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

בהצלחה!

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

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

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

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

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

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

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

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

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

[1]
$ git checkout -b new-router
$ # ... work work work
$ # oh no - production error, must fix something in master

[2]
$ git stash
$ git checkout master
$ # fix and deploy

[3]
$ git checkout new-router
$ git stash pull

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

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

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

הפקודה:

$ git stash save 'started writing CSS for the new router but big production bug stopped me'

תשמור את השינויים בצד יחד עם ההודעה.

הפקודה:

$ git stash list

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

$ git stash list stash^{/big}

תציג את כל השינויים שההודעה שלהם כוללת את המילה big ולסיום הפקודה:

$ git stash apply stash^{/big}

תיקח את השינויים מהסטאש החדש ביותר שההודעה שלו כוללת את המילה big לתוך הקוד בתיקיית העבודה שלכם.

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

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

https://www.tocode.co.il/workshops/43

אנשי QA אוהבים לסווג תקלות תוכנה לפי מידת החומרה של התקלה: יש תקלות ממש איומות שאי אפשר להשיק את המערכת עד שלא יתוקנו ולעומתן תקלות פחות נוראות שמשפיעות על פחות משתמשים או על Use Case ספציפי ואותן לא יקרה כלום אם נתקן במועד מאוחר יותר.

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

אפשר להתחיל מהסולם הבא:

1. אני יכול לתקן את זה אבל זה ימחק לכל המשתמשים את כל המידע שלהם.

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

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

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

5. אני יכול לתקן את זה אבל זה ידרוש Down time של שרת הייצור לכמה שעות.

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

7. אני יכול לתקן את זה ויש לי בדיקות אוטומטיות לוודא שהתיקון לא שובר התנהגות ישנה.

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

נתונה תוכנית פייתון קצרה המקבלת קלט ממשתמש וצריכה לוודא שהקלט הוא מספר. בואו בשביל המשחק נוסיף לו 7 ונדפיס את התוצאה:

x = input('please select a number: ')
print(float(x) + 7)

מה עושים אם המשתמשים שלכם לא כאלה נחמדים ומכניסים ערך שאינו מספר? הרצת התוכנית תיראה כך:

localhost:~ ynonperek$ python3 a.py
please select a number: yo
Traceback (most recent call last):
  File "a.py", line 2, in <module>
    print(float(x) + 7)
ValueError: could not convert string to float: 'yo'

ופייתון מתלונן בצדק שאי אפשר להמיר את yo למספר.

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

use strict;
use Scalar::Util qw/looks_like_number/;

print "please select a number: ";
my $x = <>;

if (looks_like_number($x)) {
  print($x + 7, "\n");
} else {
  print("Not a number\n");
}

לפייתון אין פונקציה looks_like_number וכל מיני ניסיונות למצוא דברים דומים יתנו לכם תוצאות לא נכונות. הנה למשל הפונקציה isnumeric שנראית ממש מתאימה:

>>> '1'.isnumeric()
True
>>> '15'.isnumeric()
True
>>> 'a'.isnumeric()
False

עד שעוברים לבדוק מספרים שליליים או כאלה עם נקודה עשרונית:

>>> '-5'.isnumeric()
False
>>> '1.2'.isnumeric()
False

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

try:
    x = input('please select a number: ')
    print(float(x) + 7)
except ValueError:
    # value is not a number
    print("sorry not a number")

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