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

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

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

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

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

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

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

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

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

חידת פיזבאז קלאסית היא לכתוב תוכנית שמדפיסה את כל המספרים מ-1 עד 100 ועבור כל מספר שמתחלק ב-3 מדפיסה במקומו את המילה פיז ועבור כל מספר שמתחלק ב-5 מדפיסה במקומו את המילה באז (ואם המספר מתחלק בשניהם מדפיסים פיזבאז).

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

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

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

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

שתי המלצות לסיכום-

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

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

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

ביום חמישי אעביר את החלק השני של וובינר פיתוח יישומי Web עם פיירבייס. אם אתם עדיין מתלבטים אם לבוא (מה מתלבטים?! תבואו) או מתכננים אבל אוהבים לדעת מראש מה הולך להיות - זה הקוד שננסה להספיק לכתוב יחד.

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

אגב2 להרשמה לוובינר של יום חמישי בקרו בקישור:

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

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

1. נתון קטע ה HTML הבא:

<input type='password' required />
<input type='text' />
<input type='email' />

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

1. כתבו כלל CSS שיצייר גבול אדום סביב כל אלמנט img שאין לו מאפיין alt.

2. נתונה הרשימה הבאה ב HTML:

<ul>
  <li data-dir='up'>IRM (+0.59%)</li>
  <li data-dir='down'>BTC-USD (-0.37%)</li>
  <li data-dir='up'>JNJ (+0.60%)</li>
</ul>

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

1. נתון קטע HTML המייצג מספר רשימות:

<ul>
  <li>one</li>
  <li>two</li>
</ul>

<ul>
  <li>red</li>
  <li>blue</li>
  <li>white</li>
</ul>

<ul>
  <li>learn CSS</li>
  <li>write some HTML</li>
  <li>add cool JavaScript</li>
</ul>

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

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