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

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

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

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

אבל מהר מאוד עלתה שאלה יותר קשה- איך מתחילים? איך מתחילים ללמוד ריילס, או אנגולר, או CSS?

אז הלכתי ליודמי כדי לשמוע איך אנשים מלמדים CSS. שלושת הקורסים המובילים נראו כך: קורס אחד כלל 11 שעות במהלכן אתם צופים במישהו כותב דף HTML/CSS. קורס שני הציע 28 שעות וידאו והפעם המדריך כתב שני פרויקטים מלאים. הקורס השלישי נשמע לי הכי מעניין כיוון שלא כלל פרויקטים ובמקום נראה שהסביר מאוד לעומק על כל פיצ'ר מה המשמעות שלו ומתי נשתמש בו. הבעיה שזה לוקח 22 שעות של וידאו שבמהלך לא בונים כמעט שום דבר מעניין.

אבל האמת שאם מישהו ישאל אותי איך ללמוד CSS ההמלצה שלי היא על הקורס הזה של סקרימבה:

https://scrimba.com/g/gintrotocss

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

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

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

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

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

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

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

import React from 'react';

class App extends React.Component {
    render() {
        return
            <div>
                Hello World
            </div>
    }
}

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

import React from 'react';

class App extends React.Component {
    render() {
        return undefined;

            <div>
                Hello World
            </div>
    }
}

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

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

/^#/
{
    gsub(".", "-");
}

{
    print;
}

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

# List of acceptable shells for chpass(1).
# Ftpd will not allow users to connect who are not using
# one of these shells.

/bin/bash
/bin/csh
/bin/ksh
/bin/sh
/bin/tcsh
/bin/zsh
/usr/local/bin/zsh

התוצאה היתה:

# List of acceptable shells for chpass(1).
------------------------------------------
# Ftpd will not allow users to connect who are not using
--------------------------------------------------------
# one of these shells.
----------------------

---------
--------
--------
-------
---------
--------
------------------

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

/^#/ { print; }

{
  gsub(".", "-");
}

{
  print;
}

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

/^#/ {
  gsub(".", "-");
}

{
  print;
}

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

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

יש לכם bash גירסא 4? גם אתם יכולים להשתמש ב globstar שיגרום לתבניות הגלוב שלכם לתפוס יותר קבצים. בואו נראה מה זה ואיך מפעילים.

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

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

או ניזכר ב git: אם המודל המנטאלי שלכם אומר שקומיט מייצג את השינויים בין שתי גירסאות יהיה לכם קשה מאוד להבין איך filter-branch או rebase עובדים. רק כשמחליפים מודל מנטאלי ומתיחסים לקומיט בתור "מצב הפרויקט ברגע מסוים בהיסטוריה" כל השאר מתחבר ונהיה הגיוני.

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

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

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

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

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

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

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