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

המשפט בכותרת הוא תרגום של המשפט הבא מתוך ה Zen של פייתון. זה המקור:

There should be one-- and preferably only one --obvious way to do it.

והוא נכון לכל השפות. נזכרתי בו במקרה כשדפדפתי בקוד הבא, דווקא בשפת רובי:

class ShoppingCart < ActiveRecord::Base
  has_many :products, :class_name => 'CartProduct', :dependent => :delete_all

    def <<(product)
        line = CartProduct.find_or_initialize_by(:product => product, :cart => self)
        # comment out to allow quantity
        # line.increment(:qty) unless line.new_record?
        line.save!
        @finalized = false

        self
    rescue ActiveRecord::RecordNotUnique
        retry
    end

    def add_with_options(product, options)
        line = CartProduct.find_or_initialize_by(:product => product, :cart => self)
        line.price = options[:price]
        line.options = options
        line.save!
        @finalized = false

        self
    rescue ActiveRecord::RecordNotUnique
        retry
    end
end

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

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

  test 'cart price is the sum of all product prices' do
    @cart = create(:cart)
    @cart.products << create(:item, price: 20)
    @cart.products << create(:item, price: 50)

    assert_equal(70, @cart.price)
  end

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

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

תיאורטית פיתרון קל מאוד במקרה כזה יהיה פשוט שהפונקציה הראשונה תקרא לפונקציה השניה, כלומר:

    def <<(product)
        add_with_options(product, {})
    end

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

במקרה שלנו אפשר לחשוב על:

class ShoppingCart < ActiveRecord::Base
    def add_product_sold_by_partner(product, partner_price, partner_options)
    end

    def add_product_from_website(product)
    end
end

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

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

function App() {
  const [text, setText] = React.useState('');

  return (
    <div>
      <input type="number" value={text} onChange={e => setText(e.target.value)} />
      <p>Text: {text}</p>      
    </div>
  );
}

ReactDOM.render(<App />, document.querySelector('main'));

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

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

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

בשביל להבין מה קורה המשכנו לכתוב דוגמא קצת יותר מתוחכמת:

function App() {
  const [numericInputChanges, setNumericInputChanges] = React.useState(0);
  const [textInputChanges, setTextInputChanges] = React.useState(0);
  const [numericInput, setNumericInput] = React.useState('');
  const [textInput, setTextInput] = React.useState('');

  function reset() {
    setTextInput('');
    setNumericInput('');
    setTextInputChanges(0);
    setNumericInputChanges(0);    
  }

  function numericInputChanged(e) {
    setNumericInputChanges(v => v + 1);    
    setNumericInput(e.target.value);
  }

  function textInputChanged(e) {
    setTextInputChanges(v => v + 1);
    setTextInput(e.target.value);
  }

  return (
    <div>
      <p>Numeric Input Changes: {numericInputChanges}</p>
      <p>Text Input Changes: {textInputChanges}</p>      
      <input type="text" value={textInput} onChange={textInputChanged} />
      <input type="number" value={numericInput} onChange={numericInputChanged}  />
      <button type="reset" onClick={reset} >Reset</button>
    </div>
  );
}

ReactDOM.render(<App />, document.querySelector('main'));

וכן, יש גם קודפן:

הפעם אני מציג גם Counter שעולה ב-1 כל פעם שקומפוננטת ה input מפעילה את הפונקציה שכתובה ב onChange. הנה מה שקורה שם:

1. כל פעם שטקסט ב input משתנה, ריאקט מנסה להפוך את הטקסט למספר ואז משווה אותו לערך הקודם שהיה רשום בתיבה.

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

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

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

עריכה - ותודה לגדי על התיקון

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

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

אבל שעה כל יום זה ממש אחלה. בשעה כל יום אפשר ללמוד Data Science או Web Development או אפילו גרמנית. שעה כל יום קונה לכם עולם ומלואו.

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

שעה ביום. אל מול עולם שלם שרק רוצה שתוותרו.

מה אתם מחליטים?

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

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

נו, תודה.

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

עכשיו היית מצפה שאחרי כל זה אנשים היו להוטים ללמוד על ה Box Model. נו, תמשיכו לחלום.

הדבר העיקרי שמביא אנשים לקרוא את התיעוד וללמוד לעומק על CSS Box Model הוא בדיוק התסכול וההפסד במאבק נגד הדפדפן. וזה דווקא סופר הגיוני - לפני שמפסידים במאבקים עם הדפדפן אין תמריץ לבלות שעות מול התיעוד, וגם אם מנסים אז מפספסים את הפינות ומקרי הקצה.

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

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

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

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

ואז זה לא עובד.

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

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

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

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

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

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

https://unoptimal.files.wordpress.com/2019/11/realgraph.png?w=1424

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

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

נתון קובץ docker-compose.yml הבא:

version: '3.8'

services:
  db:
    image: postgres:latest
    environment:
      POSTGRES_PASSWORD: docker
      POSTGRES_DB: wordcount_dev
      POSTGRES_USER: docker
    volumes:
      - database_data:/var/lib/postgresql/data

  webapp:
    image: pydocker1-test:latest
    depends_on:
      - db
    ports:
      - 5000:5000

volumes:
  database_data:
    driver: local

מה עושה הפקודה depends_on? האם היא תוביל לתוצאה הרצויה במקרה הזה (בו האפליקציה תלויה בבסיס הנתונים ולא יכולה להתחיל לעבוד בלעדיו)? ואם לא, מה הייתם עושים במקום?

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

הי כולם,

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

1. אתם יכולים ללמוד כל נושא שבעולם מהמורים הטובים בעולם והרוב בחינם או כמעט בחינם. ויש לכם את כל היום כדי להשקיע בזה. שנה של ניסיון ב Machine Learning? קיבלת! שנה של ניסיון כמפתחת Front End? אין בעיה. ביבי משלם את החשבון.

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

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

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

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

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

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

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

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

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

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

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

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

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