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

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

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

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

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

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

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

לארגון2, כמו לאלגוריתמי Password Hashing מקבילים יש שתי מטרות:

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

2. להפוך את החיים קשים לאותו תוקף גם אחרי שקיבל את בסיס הנתונים, באמצעות מנגנון שמכריח את התוקף להשתמש במשאבים רבים כדי לחשב את ה Hash של כל מילה וכך מאט מאוד מתקפות מסוג Brute Force ו Dictionary Attacks.

נלך לראות איך להשתמש ב Argon2 כדי לשמור סיסמאות בבסיס הנתונים בשפת Python. דרך טובה לגשת ל Argon2 מתוך פייתון היא הספריה passlib. נתקין את הספריה:

pip install passlib argon2_cffi

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

נראה איך זה עובד בתוכנית קטנה:

from passlib.hash import argon2
h = argon2.hash("ninja")
print(h)

# prints: $argon2i$v=19$m=102400,t=2,p=8$SkkpRci5tzZGaG0thbB2bg$OzPDd59KfGJbfqg4SsJLYw

# prints True
print(argon2.verify('ninja', h))

# prints False
argon2.verify('demo', h)

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

>>> argon2.hash("ninja")
'$argon2i$v=19$m=102400,t=2,p=8$6F3rHeN8790b4/yfMyYEwA$4aFNx5iWvsAt0u8U2Mdm6g'
>>> argon2.hash("ninja")
'$argon2i$v=19$m=102400,t=2,p=8$nhMCQMiZ0/ofA2BM6Z1TKg$WincHSs3Afkgqp+qn0Emdw'
>>> argon2.hash("ninja")
'$argon2i$v=19$m=102400,t=2,p=8$8D6nVArh/B9DaI3x/r83Jg$jZSKc5iwdFAVF8RN8G8xtg'

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

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

ראיתי השבוע חבר מקליד את הפקודה הבאה בגיט כדי לצאת ממצב מביך:

$ git reset --hard origin/master

בואו נראה מה היא עושה כדי להבין אם היא יכולה לעזור גם לכם.

מתחילים בתיעוד של גיט. יש לגיט ריסט שלושה מצבי פעולה:

       git reset [-q] [<tree-ish>] [--] <paths>...
       git reset (--patch | -p) [<tree-ish>] [--] [<paths>...]
       git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] [<comm
it>]

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

In the third form, set the current branch head (HEAD) to
<commit>, optionally modifying index and working tree to match.

לכן הדבר הראשון שריסט יעשה הוא לשנות את HEAD כך שיצביע על הקומיט שעובר בפרמטר האחרון. הקומיט הזה במקרה שלנו הוא origin/master שזה אומר הקומיט שאנחנו חושבים שהשרת קורא לו master. זה אומר שאם עשינו כבר קומיטים אצלנו ב master אנחנו הולכים לחזור לנקודה לפני הקומיטים שלנו. מצד שני פקודת reset לא פונה לשרת לכן אם מישהו אחר עשה push לשרת אנחנו לא נדע מזה. אנחנו נלך למקום ש origin/master היה בו בפעם האחרונה שפנינו לשרת.

אפשר לראות את הנקודה הזאת עם:

$ git log -1 origin/master

או אם מה שמעניין אתכם זה רק ה Commit Hash תוכלו להפעיל:

$ git rev-parse origin/master
a08935913801409ef7437ba9038d4a0580f1f6c5

ועם פקודה דומה נוכל לגלות אם ה master שלנו כבר התקדם מהקומיט הזה או שהוא עדיין שם:

$ git rev-parse master
a08935913801409ef7437ba9038d4a0580f1f6c5

דרך אחרת היא פשוט להפעיל status. אם ה master שלכם לא תואם ל origin/master תקבלו על זה הודעה בשורה השניה של הפלט. במקרה שלי הם תואמים אז יש לנו:

$ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

בחזרה ל reset - אז הדבר הראשון שיקרה זה ש HEAD יעבור להצביע על הקומיט שנקרא origin/master. הדבר השני ש reset עושה זה לעדכן את הקבצים בתיקיית העבודה. המתג --hard אומר:

Resets the index and working tree. Any changes to tracked files in the working tree
since <commit> are discarded.

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

לסיכום הפקודה git reset --hard origin/master עושה את הדברים הבאים:

1. היא בודקת מה מזהה הקומיט של הענף origin/master.

2. היא מזיזה את הענף הנוכחי כך שיצביע גם הוא לאותו קומיט. יחד איתו יזוז גם ה HEAD.

3. היא מאפסת את כל הקבצים ב Staging Area ולוקחת את הגירסא מהריפוזיטורי.

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

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

וקטנה לסיום- אם הפעלתם את git reset --hard origin/master בטעות ופתאום נעלמו לכם הקומיטים שעשיתם, אתם תמיד יכולים לגשת ל git reflog כדי למצוא את הקומיטים האבודים. אחרי שמצאתם את הקומיט ש master הצביע עליו קודם, תוכלו להשתמש ב git reset נוסף כדי לחזור אליו.

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

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

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

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

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

מצאו שתי בעיות במנגנון וספרו איך הייתם מתמודדים אתן.

הקוד:

const cache = {};

const ajaxService = {
    get(url) {
        return new Promise((resolve, reject) => {
            if (typeof cache[url] !== 'undefined') {
                return resolve(cache[url]);
            } else {
                $.get(url).then(function(res) {
                    cache[url] = res;
                    return resolve(cache[url]);
                }).catch(err) {
                    return reject(err);
                };
            }
        });
    },
};

export default ajaxService;

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

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

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

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

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

גירסא חדשה של רובי יוצאת כל שנה בערך, עם רובי 2.5 שיצאה במרץ 2018 ואחריה בדצמבר יצאה 2.6. התוכנית היא לשחרר את 2.7 בדצמבר השנה, מה שנותן לנו כמה חודשים להנות משתי הגירסאות האחרונות של 2018. נעבור לראות כמה יכולות חדשות שלהן כדי שגם לכם יהיה חשק לשדרג.

הספריה ngReact מאפשרת להוסיף פקדי ריאקט יחסית בקלות ליישום Angular.JS (כן אנגולר1, הישן...) שלכם. התבנית הבאה יכולה לתת נקודת התחלה טובה לשימוש בה.

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

אז ניקח לדוגמא את המילה switch ב React Router לעומת JavaScript. ל JavaScript יש פקודת switch מה שאומר שהתוכנית הבאה מדפיסה x == 10:

var x = 10;

switch(x) {
  case 2:
    console.log('x == 2');

  case 5:
    console.log('x == 5');

  case 10:
    console.log('x == 10');
}

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

var x = 10;

switch(x) {
  case 10:
    console.log('x == 10');

  case 2:
    console.log('x == 2');

  case 5:
    console.log('x == 5');
}

כלומר התוצאה:

x == 10
x == 2
x == 5

הסיבה היא מנגנון שנקרא Fallthrough שאומר שמרגע שתנאי אחד ב switch מתאים כל הפקודות הבאות הולכות להתבצע. אפשר לבטל את המנגנון עם שימוש יזום בפקודה break והתוכנית הבאה תדפיס שוב x == 10 בלבד:

var x = 10;

switch(x) {
  case 10:
    console.log('x == 10');
    break;

  case 2:
    console.log('x == 2');
    break;

  case 5:
    console.log('x == 5');
    break;
}

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

import { Switch, Route } from 'react-router'

<Switch>
  <Route exact path="/" component={Home}/>
  <Route path="/about" component={About}/>
  <Route path="/:user" component={User}/>
  <Route component={NoMatch}/>
</Switch>

כשאנחנו בנתיב /about לא יתבצע Fallthrough ובזכות ה Switch רק נתיב About יופיע על המסך ולא שני הנתיבים שמופיעים אחריו.

הרכיב Switch של React Router כמובן מועיל וחשוב, אבל בהתחשב בהתנהגות הרגילה של פקודת switch של JavaScript אני מוצא את השם מבלבל. ובאופן כללי כשאנחנו לוקחים שם שיש לו כבר משמעות בעולם התוכן של האנשים שאנחנו מדברים אליהם (במקרה הזה שפת JavaScript) כדאי לוודא שאנחנו שומרים בדיוק על אותה המשמעות.

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

אבל בתכנות הסיפור קצת אחר.

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

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

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

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

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

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

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

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