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

הנה חידה קטנה לסיים את השבוע - הקוד הבא אמור לעזור לנו לממש 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.

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

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

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

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

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

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

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

כי על פניו אם אתה מתכנת Front End שכותב CSS ב-5 שנים האחרונות ואתה מגיע לחלק המקצועי בו שואלים אותך איך לשים אלמנט באמצע העמוד אתה כנראה יודע לדקלם את זה הפוך מתוך שינה. עכשיו שתי שאלות: קודם כל למה אנחנו שואלים שאלות מקצועיות בראיון עבודה? ולמה אנשים עם הידע המקצועי המתאים לא עוברים?

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

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

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

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

במשחקים עם דוקר ראיתי את השורה הבאה בתיעוד שלהם:

$ printf "This is a secret" | docker secret create my_secret_data -

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

זה עובד גם מחוץ לדוקר, למשל התוכנית wc יודעת די טוב לספור תווים בשורה שהיא קוראת מתוך STDIN או מקובץ, אבל אם יש לכם ביד טקסט קבוע תוכלו להשתמש ב printf כדי לשלוח אותו ישירות אליה:

$ printf "hello world" | wc -c
11

אז למה printf ולא echo? כי מסתבר ש echo מוסיף תו ירידת שורה לטקסט אותו הוא מדפיס. כך בספירת התווים אנחנו מקבלים:

$ echo "hello world" | wc -c

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

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

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

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

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