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

גם אם אתה יודע לדקלם מתוך שינה את כל תרשימי ה UML של תבנית העיצוב Observer זה לא אומר שתדע להשתמש בה.

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

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

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

https://www.quora.com/How-is-JavaScript-used-within-the-Spotify-desktop-application-Is-it-packaged-up-and-run-locally-only-retrieving-the-assets-as-and-when-needed-What-JavaScript-VM-is-used

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

אבל שניה קודם איניגו

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

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

2. וזה לא הגיוני להגיד שככה כולם עושים- אנחנו יודעים את זה. בדיוק בגלל זה שאלנו למה.

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

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

היא לשנות את החיים כך שהדבר החדש הזה הוא משהו שנשתמש בו כל יום.

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

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

האתגר הוא להבין איך לשנות את החיים ולשלב את הדבר החדש בלי שנצטרך להחליף ארץ או עבודה.

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

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

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

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

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

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

עכשיו השאלה: האם אני מוכן להיות שוב גרוע בזה? האם אני מוכן להתחיל מההתחלה? והתשובה חייבת להיות חיובית למי שרוצה להישאר בתחום הזה לאורך זמן.

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

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

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

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

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

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

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

ביום חמישי בעשר בבוקר אני ממשיך את המסורת של וובינרים בחמישי והשבוע נשקיע שעה בללמוד על ביצועים ב React. התוכנית בגדול:

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

https://eslint.org/blog/2018/07/postmortem-for-malicious-package-publishes

אמלק: מתכנת פעיל ב ESLint עם הרשאות Admin על הפרויקט השתמש בסיסמת ה npm שלו לאתרים נוספים.

האקרים כנראה לקחו את הסיסמא מאחד האתרים האחרים והשתמשו בה כדי להעלות גירסא זדונית של ESLint. הגירסא הזדונית גונבת npm access tokens מכל מי שמוריד אותה.

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

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

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

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

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