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

גירסא חדשה של רובי יוצאת כל שנה בערך, עם רובי 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. אבל הרבה יותר קשה לגלות מה עושים הלאה.

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

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

שפת Sass, שזה קיצור ל Syntactically awesome style sheets היא שפה שנועדה להוסיף מנגנונים של שימוש חוזר בחלקים מהקוד ל CSS. היא נכתבה על ידי הנרי תורנטון ונמצאת איתנו מ 2006. בזכות תאימות מלאה ל CSS קל מאוד להתחיל להשתמש בה וכך לאט לאט לשפר את קוד ה CSS שלכם. כל העבודה עם Sass מתבצעת בצד השרת לפני שהקבצים מגיעים לדפדפן ולכן מבחינת הדפדפן זה שקוף לגמרי. לגולש אין מושג אם אתם משתמשים ב CSS או ב Scss.

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

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

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

אבל קודם - מה זה בכלל אומר ״מוכנים הרבה יותר ממה שצריך?״

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

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

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

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

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

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

בהצלחה.