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

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

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

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

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

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

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

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

https://zoom.us/meeting/register/3dea94be140a83cbcde7dc3c8da9331e

ועכשיו לקוד.

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

וזה משפיע על הכל.

אנחנו הולכים לקורס Design Patterns במקום להשקיע את הזמן בללמוד Design. אנחנו מחפשים קורס Angular (או React, או Vue) במקום להשקיע את הזמן וללמוד JavaScript. ומי בכלל יעז לחשוב שהוא מסתבך עם React או Redux כי הוא לא יודע מספיק JavaScript?

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

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

שתי מחשבות בעקבות הסיפור-

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

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

החל מגירסא 3.3 מתכנתי פייתון לא צריכים יותר ליצור קבצי __init__.py כדי להגדיר חבילות של מודולים. מעל חמש שנים שמתכנתי פרל לא צריכים לכתוב use strict בהתחלה של התוכניות שלהם והתוכנית הבאה ב C++ עובדת גם בלי שנציין את טיפוסי המשתנים:

#include <stdio.h>
#include <stdlib.h>
#include <iostream>

using namespace std;

int main(int argc, char **argv)
{
  auto x = atoi(argv[1]);
  auto y = atoi(argv[2]);
  auto z = x + y;
  cout << x << " + " << y << " = " << z << endl;
}

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

הי חברים,

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

ביום חמישי (עוד יומיים) בשעה עשר בבוקר אעביר וובינר חינמי בו אציג פיתוח Web Application מלא מאפס באמצעות HTML/CSS/JavaScript בצד הלקוח שמתממשק עם שרת Firebase.

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

1. מהו המבנה המומלץ לפרויקט Web.

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

3. מהו Firebase ואיך הוא יכול לעזור לנו לבנות יישומים מהר יותר.

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

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

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

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

פרטים והרשמה בקישור: https://www.tocode.co.il/workshops/38

נתראה, ינון