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

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

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

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

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

נ.ב. למי שרוצה לקרוא עוד על חלומות אני ממליץ על הספרון הזה שנקרא "תפסיקו לגנוב חלומות" ומתיחס לבתי ספר וליכולות המופלאות שלהם: https://medium.com/@thisissethsblog/stop-stealing-dreams-4116c7dbff7b

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

הספריה Express של Node.js היא הדרך האהובה על מתכנתי Front End רבים לכתוב קוד צד שרת, וזה לא סתם. בהיותה ספריית Node אקספרס מאפשרת לשתף המון קוד בין צד השרת לצד הלקוח, כולל שילוב מאוד קל של Server Side Rendering בפריימוורקס שתומכות בזה.

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

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

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

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

2. איך לפתח נכון קוד אסינכרוני באמצעות Promises.

3. מהם Express Middlewares, למה צריך אותם ואיך הם עוזרים לנו לכתוב קוד נקי יותר בפרויקטים שלנו.

השתתפות בחינם אבל דורשת רישום מראש בקישור: https://www.tocode.co.il/workshops/56

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

נתראה בחמישי, ינון

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

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

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

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

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

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

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

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

ויש עוד בעיה עם שידרוגים שצריך להזכיר אותה והיא הבאגים בגירסאות גדולות חדשות. קחו את ריאקט לדוגמא - גירסא 16 הביאה שכתוב מלא של כל המנוע. זה מדהים, אבל זה גם אומר ש 16.0 כנראה פספסה כמה דברים שתוקנו ב 16.1. בדוגמא גדולה נוספת ריילס 5.0 יצא לאוויר העולם ביוני 2016, וחודש וחצי אחר כך כבר קיבלנו את 5.0.0.1, בדצמבר כבר יצא 5.0.1 ומרץ 2018, כלומר כמעט שנתיים אחר כך הגיע ריילס 5.0.7. ברור שעדיף לחכות ולשדרג לריילס 5.0.7 במקום להיות הראשון עם 5.0.0. השידרוג לא יותר קשה והחיים יותר קלים כי יש פחות באגים.

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

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

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

"עשית כבר שיעורי בית?" "מה עם העבודה שצריך להגיש למחר?" "את זוכרת שיש לך מבחן בשבוע הבא?" "מי לא הכין עדיין שיעורי בית?" "אין טלויזיה עד שלא תסיימי את כל השיעורים" "אם לא תסיים את השיעורים עד ארבע לא תלך לחוג"

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

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

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

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

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

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

שתי מסקנות מהסיפור הזה:

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

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

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

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

וכל השאר נגזר מזה.

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

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

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

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

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

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

1. האם כותבים טסטים? האם משתמשים במערכת CI/CD כלשהי?

2. האם משתמשים בכלי ניהול גירסאות (רצוי git) ?

3. האם יש תרבות של Code Reviews ? מי מבצע Code Reviews? ולמי? ובאיזו תדירות?

4. מה מדיניות החברה בנוגע להשתלמויות מקצועיות? האם יקנו עבורך קורס אונליין?

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

6. מה היחס לנושא נגישות?

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

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

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

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