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

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

You can turn Fraudulent Website Warning off (in Settings > Safari) as long as you're willing to accept less vigilance against sketchy pages. The issue is really that Apple activates the feature by default without alerting users, and that it doesn't specify just where Tencent operates

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

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

נ.ב. לינק לאחד המקורות בנושא (מאמר של מאת'יו גרין): https://blog.cryptographyengineering.com/2019/10/13/dear-apple-safe-browsing-might-not-be-that-safe/.

״שנה שלמה למדתי בשביל העבודה הזאת. היה ממש קשה אבל אני שמחה שהתמדתי - יש לי היום עבודה טובה ששווה את המאמץ״.

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

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

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

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

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

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

4. אתרי שאלות כמו Stack Overflow ו Quora הם מקור ידע מעולה אבל שימו לב שאתם קוראים תשובה עדכנית ואת כל ההערות הרלוונטיות.

לשאלות המעניינות שנרצה לשאול את האינטרנט התשובה ממילא מורכבת ואנחנו לא רוצים המלצה כמו "תמיד תבחרו X" או "תמיד תבחרו Y". המטרה בחיפוש היא לקבל כיווני מחשבה וקריטריונים להשוואה כדי שתוכלו לבדוק בעצמכם בצורה יסודית ולבחור את הדבר שמתאים למערכת ול Use Case שלכם.

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

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

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

What is a closure, and how/why would you use one?

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

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

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

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

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

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

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

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

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

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

x = 0b10
print(x) # prints 2

x = 011
print(x) # prints 9

x = 0x10
print(x) # prints 16

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

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

if (( $(date +%"H") < 20 ))

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

-bash: ((: 08: value too great for base (error token is "08")

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

if (( $(date +%"_H") < 20 ))

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

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

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

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

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

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

הפקודה הראשונה שחשוב להכיר היא locale. מפעילים אותה עם -a כדי לקבל רשימה של כל השפות שהמערכת שלכם מכירה:

$ locale -a
C
C.UTF-8
en_US.utf8
POSIX

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

fr_FR.UTF-8 UTF-8

אחרי זה מפעילים את הפקודה locale-gen כדי להתקין את קבצי השפה החדשים:

$ locale-gen
Generating locales (this might take a while)...
  fr_FR.UTF-8... done
  en_US.UTF-8... done
Generation complete.

ונשמח לגלות שהשפה הותקנה באמצעות קריאה נוספת ל locale:

$ locale -a
C
C.UTF-8
en_US.utf8
fr_FR.utf8
POSIX

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

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

$ locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

בשביל לשנות שפה כל מה שצריך הוא להגדיר משתני סביבה בשם LANG ו LC_CTYPE. אני רוצה שהשינוי יהיה קבוע לכן אכניס את שתי השורות הבאות לקובץ ה ~/.profile שלי:

export LANG=fr_FR.utf-8
export LC_CTYPE=fr_FR.utf-8

ו... voilà המחשב מתחיל לדבר צרפתית:

$ date
lundi 7 octobre 2019, 14:38:29 (UTC+0000)

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

״עזוב אותך זה לא יצליח״

״דבר איתי עוד חודשיים כשתתייאש״

״זה הרבה יותר קשה ממה שנדמה לך״

״כל הכבוד על האומץ״

״לא חבל לוותר על מה שכבר יש לך?״

״אולי תתחיל עם משהו יותר קטן?״

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

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

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

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

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

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

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

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