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

ספריית jQuery התחילה עם רעיון פשוט וגאוני: לבנות API טוב יותר ואמין יותר עבור ה DOM. בימים שהם התחילו המצב היה הרבה יותר גרוע ממה שהוא היום והצורך ב API אמין לחיבור בין JavaScript לאלמנטים על המסך היה מאוד בולט.

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

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

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