ToCode

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

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

# עדכוני וובינרים לאוקטובר - החודש של ריאקט אחרי תקופה של הפסקה בוובינרים אני חוזר החודש לשיגרה של וובינרים וקורסים. לקראת קורס ריאקט שאני הולך להעביר אצל לקוח חשבתי להקדיש גם את הוובינרים לכמה פיצ'רים חדשים של הפריימוורק בדגש על React Hooks. השבוע ביום חמישי אעביר וובינר של שעה על useContext ו useReducer. נראה למה פונקציות אלה טובות וכמה תבניות טובות של שימוש בהן. פרטים והרשמה בקישור. שבוע הבא נשארים בסוכה ולכן שבוע אחרי זה יהיה וובינר שני על React Hooks הפעם על הפונקציות useMemo ו useCallback. נראה איך הן עוזרות לשפר ביצועים ואיך לזהות מתי כדאי להשתמש בהן. פרטים והרשמה בקישור. עדכון אחרון הוא שינוי מדיניות שאני לוקח לקראת השנה החדשה והוא פתיחת הצפיה בהקלטות הוובינרים לכל מי שירצה ותרצה בכך. החל מהיום גם אם אתם לא מנויים לאתר אתם יכולים להיכנס בתפריט לפריט "הקלטות מבוובינרים", לבחור כל וובינר שתרצו ולהיכנס לצפות בהקלטה שלו. בנוסף לפתיחת הוובינרים אני מתכנן להציע בעתיד הקרוב מסלולי לימוד בליווי אישי במטרה לעזור לכם להגיע למטרה מקצועית ספציפית - למצוא עבודה, לבנות תיק עבודות או להרים מוצר POC לסטארט-אפ. המטרה להשקיע חודשיים-שלושה של עבודה אינטנסיבית יחד איתי ולהגיע בסוף להגשמת המטרה המקצועית שלכם. אם מעניין אתכם לשמוע יותר פרטים אפשר לשלוח מייל או להשאיר הודעה כאן באתר ונדבר. במהלך החודש אעלה גם דף נחיתה מסודר למסלול עם כל הפרטים.

# איך לחזור לשיגרת לימודים אחרי הפסקה בתור ילד רוב הדברים שלמדתי היו בתוך מסגרת מחייבת ולימודים מתקשרים אצלי (ואני מוכן להמר שגם אצל רבים מכם) לאותה מסגרת מחייבת. בין אם מדובר על בית ספר, אוניברסיטה או קורס מקצועי, החזרה לשיגרה היתה יותר עניין של התגברות על קושי רגשי מאשר משהו פרקטי. לא משנה כמה רצית שהחופש הגדול יימשך, בסוף תמיד הגיע הסוף. אבל היום החיים השתנו והרבה מהלימודים שלנו הם לימודים וולנטריים - אנחנו יוצרים לעצמנו את המסגרות, אנחנו בוחרים את המורים ואת כלי הלימוד ואנחנו קובעים לעצמנו את השעות. השינוי הזה הוא שמאפשר לאתר טוקוד ולאינספור אתרי קורסים נוספים להתקיים. אני ואתם מלמדים ולומדים כי אנחנו בוחרים בזה, ואנחנו צריכים להמשיך ולבחור כל יום בשביל שהעסק הזה ימשיך לעבוד. בהחלטה של רגע אפשר לברוח. בהחלטה של רגע אפשר להמשיך את החופש הגדול חודשיים או חצי שנה או שנתיים. אף מנהל לא יצלצל להורים לשאול למה הילד הפסיק להגיע, וגם אם יצלצל תמיד תוכלו להגיד שיש עומס בעבודה ולא מסתדר עכשיו. תקופות כמו חופש גדול בבית ספר, חגים, או עומס לא צפוי בעבודה יכולות בקלות להוציא אותנו משגרת לימודים שבנינו במאמץ רב. הפסקות כאלה הן חלק בלתי נפרד מהחיים ואני די בטוח שהן קרו או יקרו גם לכם. שלושה מאפיינים מטרידים במיוחד של הפסקות הם: 1. רגרסיה בידע שצברנו לפני ההפסקה - אחרי חודש בלי ספורט אתה כבר לא בכושר. אחרי חודש שלא כתבת קוד את כבר לא בכושר. לוקח זמן לחזור לרמה שהיתה לפני ההפסקה. 2. מחיקה של חלק מהידע - ידע נבנה בשכבות ולהרבה דברים יש "נקודות שמירה". למרות שהרבה שנים לא כתבתי ב perl, אחרי שאוריד את החלודה אצליח להגיע מהר לרמה די טובה בזה. מצד שני בטכנולוגיה שלמדתי רק כמה שבועות לפני שיצאתי להפסקה גם אם אנסה להוריד את החלודה ולחזור לזה, אצטרך ללמוד כמעט את הכל מחדש. 3. הרגלים נמחקים אפילו יותר מהר מידע. מסיבה זו הרבה אנשים מאריכים את ההפסקות הרבה יותר ממה שתכננו. חופשת ראש השנה של שלושה ימים יכולה בקלות להפוך לחודשיים בהם לא כתבת שורת קוד ב Python, אפילו שלפני החג מאוד רצית ללמוד את הטכנולוגיה. החזרה לשיגרה נדחית וגם כשבסוף כן מנסים הקיר נראה פשוט גבוה מדי. אבל לא באנו לפה בשביל לסיים את הפוסט באווירת יאוש, במיוחד כשהכותרת שלו היתה "איך לחזור לשיגרת לימודים אחרי הפסקה". האמת היא שאם קראתם עד פה והבנתם את האתגרים אני חושב שכבר יש לכם כמה רעיונות איך להתאושש מהחופש. הנה שלי: 1. להכיר באתגרים. להבין שאותם הדברים שגרמו לנו לרצות ללמוד בהתחלה עדיין רלוונטים וששווה לעשות את המאמץ. 2. לא לצפות לחזור מיד לאותה רמה שהיתה לפני החג. לא להיבהל כשאתם לא מצליחים לפתור תרגילים שכבר הצלחתם בקלות בעבר, או שאתם אפילו לא מבינים קוד שכבר כתבתם בעבר. זה נורמלי. 3. כן להתאמץ וליצור שיגרה, תוך הדגשת המאמץ והדרך והתעלמות מהתוצאות העגומות. משריינים חצי שעה לכתוב קוד פייתון, ויושבים חצי שעה לפתור מחדש תרגילים שכבר פתרתם או דומים להם. לאט לאט החצי שעה תהפוך לשעה, התוכן יהפוך למעניין יותר וגם תראו התקדמות שוב. אף אחד לא לימד אותנו איך לעשות את זה. החיים שלחו אותנו שנה אחרי שנה לבית הספר שהיה חובה. האתגר שלכם היום הוא חדש, ייחודי ומרתק. הכרה באתגר זה היא הצעד הראשון בדרך להתמודדות טובה איתו.