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

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

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

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

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

שיתוף פעולה הוא אחד הנושאים העדינים שאנחנו מתמודדים איתם.

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

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

והשאלה החשובה כאן- איפה אתם על הסקאלה? איפה הייתם רוצים להיות?

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

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

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

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

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

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

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

1. הספר Learn Python The Hard Way נכתב סביב העיקרון הזה של קודם לכתוב ואחר כך להבין. פרק טיפוסי שם כולל תוכנית שצריך להקליד במחשב ומשימה לעשות שינוי קטן באותה התוכנית ולראות שעדיין עובד. אחרי שעושים מספיק פרקים דברים מתחילים להתחבר. זה הקישור:

https://www.learnpythonthehardway.org

1. אחרי שמסיימים יש כאן רשימה די פשוטה של תרגילים שאפשר להמשיך איתם:

https://adriann.github.io/programming_problems.html

1. וכאן רשימה נוספת עם כמה קשים יותר:

https://www.practicepython.org

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

https://code-maven.com/exercises

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

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

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

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

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

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