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

טיפים קצרים וחדשות למתכנתים

חידת פייתון ו C

09/11/2020

דני תוכניתני חשב שיוכל לחשב מספרי פיבונאצ'י הרבה יותר מהר אם יעביר את פונקציית החישוב מ Python ל C. הפונקציה ב Python נראתה כך:

def fib(n):
    x, y = 0, 1
    for i in range(n):
        x, y = y, x + y

    return y

ודני שכבר יודע דבר או שניים על חיבור פייתון ל C הלך ותירגם את הקוד ל C באופן הבא:

static PyObject *
spam_fib(PyObject *self, PyObject *args)
{
  int n;
  if (!PyArg_ParseTuple(args, "i", &n))
    return NULL;

  unsigned long x = 0, y = 1;
  unsigned long temp;

  for (int i=0; i < n; i++) {
    temp = x;
    x = y;
    y = temp + x;
  }

  return PyLong_FromUnsignedLong(y);
}

אחרי קומפילציה ובדיקה קצרה של הקוד הבא:

import spam

print(spam.fib(5))

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

מה דני שבר?

התנהגות ברירת מחדל

08/11/2020

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

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

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

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

השנה 2020, ואני עדיין כותב עברית הפוך

07/11/2020

הקוד הבא ב pyglet מציג את הטקסט בעברית בכתב מראה:

import pyglet
from pyglet import shapes

window = pyglet.window.Window(960, 540)

label = pyglet.text.Label('שלום עולם',
                          font_name='Times New Roman',
                          font_size=36,
                          x=window.width//2, y=window.height//2,
                          anchor_x='center', anchor_y='center')

@window.event
def on_draw():
    window.clear()
    label.draw()


pyglet.app.run()

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

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

הפונקציה getByRole ב react-testing-library

06/11/2020

אחד הדברים שהכי קשה להכיל במעבר ל react-testing-library הוא החשיבות הגדולה שמפתחי הספריה מעניקים ל Accessibility Roles. בעוד רוב ספריות הבדיקה נותנות לנו להגיע לאלמנטים באיזו צורה שאנחנו רוצים (דרך CSS או אפילו XPath), כשמגיעים ל react-testing-library מגלים ש getByCSS זו לא פונקציה אמיתית שם.

השינוי הטכני הזה נובע משינוי תפיסה לגבי תפקיד הבדיקה ומה אנחנו רוצים לבדוק: בעוד ספריות בדיקה מסורתיות רוצות לבדוק שדברים מגיעים ל DOM בצורה נכונה, ב react-testing-library אנחנו רוצים לבדוק יותר מזה, אנחנו רוצים לבדוק שאנחנו מבינים את העמוד שלנו כמו שמשתמש מבין אותו. המעבר ל getByRole מהווה שינוי בנקודת המבט.

שימו לב לקטע הבא לדוגמה שהצגתי בוובינר אתמול:

export default function SimpleList({ items }) {
  const [filter, setFilter] = useState('');

  return (
    <>
      <input
        type="search"
        value={filter}
        onChange={(e) => setFilter(e.target.value)}
        name="filter-list"
      />
      <ul>
        {items.filter(item => item.text.includes(filter)).map((item, idx) => (
          <li
            key={item.id}
            className={(idx + 1) % 2 === 0 ? "even" : "odd"}
          >
            {item.text}
          </li>
        ))}
      </ul>
    </>
  );
}

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

document.querySelector('input[name="filter-list"]')

אבל במעבר ל react-testing-library ובפרט אם אני מוכן לקבל את השגעונות שלהם ולהשתמש ב getByRole אני אגלה שקשה לי לתפוס את אלמנט ה input הזה. הקוד הבא יעבוד:

const el = screen.getByRole('searchbox');

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

המעבר ל getByRole מכריח אותי לחשוב כמו המשתמש - איך המשתמש יודע על איזו תיבה מדובר? איך המשתמש יודע איפה להכניס את הקלט? משתמש לא רואה את המאפיין name או את הקלאסים של התיבה. הוא יכול לראות את הטקסט שרשום בה אבל בדרך כלל הוא יראה את ה Label שמשויך לתיבת הקלט. וכבר אנחנו רואים את הבעיה בקומפוננטה: ל input אין label שמסביר מה היא עושה.

תיקון של הקוד והוספת label נראה כך:

export default function SimpleList({ items }) {
  const [filter, setFilter] = useState('');

  return (
    <>
      <label>Filter List

        <input
          type="search"
          value={filter}
          onChange={(e) => setFilter(e.target.value)}
        />
      </label>

      <ul>
        {items.filter(item => item.text.includes(filter)).map((item, idx) => (
          <li
            key={item.id}
            className={(idx + 1) % 2 === 0 ? "even" : "odd"}
          >
            {item.text}
          </li>
        ))}
      </ul>
    </>
  );
}

ושימו לב לקסם - עכשיו אפשר להשתמש בטקסט ב label כדי לזהות את ה input שהסתכלנו עליו:

screen.getByRole('searchbox', { name: 'Filter List' } );

אלבום בכל שנה

05/11/2020

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

וזה נכון. ייקח לנו עוד שנתיים עד שנוכל לשמוע את Thriller.

אבל אז אתה נזכר גם ש Help ו Rubber Soul יצאו באותה שנה ושנה אחריהם הביטלס הוציאו את Revolver, עוד שנה קדימה אנחנו עם Sgt. Perpper ועם Magical Mystery Tour, שנה אחריו ב 1968 מגיע האלבום הלבן ו 1969 הביאה את Abbey Road.

איך הם עשו את זה? מה הביטלס ראו שמייקל ג'קסון לא ראה? ומה הם יכולים להראות לנו?

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

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

דבר אחד טוב

04/11/2020

בן אדם מחפש עבודה ורואה מודעה שאומרת:

דרוש/ה מתכנת/ת:

  1. שלוש שנות ניסיון בפיתוח NodeJS

  2. ניסיון משמעותי עם Angular/React/Vue

  3. ניסיון מעמיק עם Rest API

  4. ניסיון מעמיק עם AWS

  5. יתרון לניסיון עם Docker ו Kubernetes

ואז הבן אדם אומר לעצמו - טוב, אני יודע לכתוב Full Stack, כתבתי קצת Node ו React בתפקיד הקודם, נראה משרה בשבילי, אבל עדיין אני לא 100% עומד בדרישות, וגם בעבודה הקודמת שלי עבדתי רק שנתיים בפיתוח נוד. אני יודע! אני יכול לכתוב פרויקט שישתמש בכל הטכנולוגיות ברשימה ואז הם יראו כמה אני מוכשר ומיד יגייסו אותי.

ומכאן המצב רק מתדרדר.

כי אי אפשר לפתח לבד מערכת עם קוד צד-שרת ב Node.JS, צד לקוח ב React, תקשורת ב REST API (בעצם אם כבר אני בונה עכשיו משהו בשביל לעשות רושם אז מה פתאום REST עדיף GraphQL) ואז להעלות את כל זה ל AWS בתוך קונטיינרים. אפילו אם הייתם מכירים את הטכנולוגיות ברמה טובה. הדברים האלה לוקחים זמן ולוקחים צוות. בלי זה העבודה תצא חובבנית.

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

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

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

גאווה מקצועית, כישלון ותחושת כישלון

03/11/2020

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

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

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

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

קדימה ואחורה עם cal

02/11/2020

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

$ cal

   November 2020      
Su Mo Tu We Th Fr Sa  
 1  2  3  4  5  6  7  
 8  9 10 11 12 13 14  
15 16 17 18 19 20 21  
22 23 24 25 26 27 28  
29 30                 

יש גם אנשים מוזרים שאוהבים לראות את היומן שלהם מלמעלה למטה אז הם המציאו את ncal:

$ ncal

    November 2020     
Su  1  8 15 22 29   
Mo  2  9 16 23 30   
Tu  3 10 17 24      
We  4 11 18 25      
Th  5 12 19 26      
Fr  6 13 20 27      
Sa  7 14 21 28      

אבל בואו, אנחנו לא כאלה.

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

                            2020
      October               November              December        
Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa  
             1  2  3   1  2  3  4  5  6  7         1  2  3  4  5  
 4  5  6  7  8  9 10   8  9 10 11 12 13 14   6  7  8  9 10 11 12  
11 12 13 14 15 16 17  15 16 17 18 19 20 21  13 14 15 16 17 18 19  
18 19 20 21 22 23 24  22 23 24 25 26 27 28  20 21 22 23 24 25 26  
25 26 27 28 29 30 31  29 30                 27 28 29 30 31        

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

פיצ'ר שני שאני אוהב ב cal הוא היכולת להציג לוח שנה של כל חודש היסטורי או עתידי פשוט באמצעות בחירת החודש והשנה. הנה כמה דוגמאות:

$ cal 11 2019

   November 2019      
Su Mo Tu We Th Fr Sa  
                1  2  
 3  4  5  6  7  8  9  
10 11 12 13 14 15 16  
17 18 19 20 21 22 23  
24 25 26 27 28 29 30  

$ cal 11 1918
   November 1918      
Su Mo Tu We Th Fr Sa  
                1  2  
 3  4  5  6  7  8  9  
10 11 12 13 14 15 16  
17 18 19 20 21 22 23  
24 25 26 27 28 29 30  

$ cal 11 2250
   November 2250      
Su Mo Tu We Th Fr Sa  
                1  2  
 3  4  5  6  7  8  9  
10 11 12 13 14 15 16  
17 18 19 20 21 22 23  
24 25 26 27 28 29 30  

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

cal() {
  if [[ ("$1" = -* || "$1" = +*) && "$1" != -3 ]]
  then
    current_month=$(date +%m)
    current_year=$(date +%Y)
    month=$(( ($current_month + $1) % 12 ))
    year=$(( $current_year + $1 / 12 ))
    cal $month $year
  else
    command cal "$@"
  fi
}

ועכשיו אני יכול להעביר מינוס מספר או פלוס מספר כדי לראות את החודש שבא לפני או אחרי X חודשים (חוץ מ -3 אותה השארתי בהתנהגות ברירת המחדל):

$ cal -4

     July 2020        
Su Mo Tu We Th Fr Sa  
          1  2  3  4  
 5  6  7  8  9 10 11  
12 13 14 15 16 17 18  
19 20 21 22 23 24 25  
26 27 28 29 30 31     

$ cal +6

      May 2020        
Su Mo Tu We Th Fr Sa  
                1  2  
 3  4  5  6  7  8  9  
10 11 12 13 14 15 16  
17 18 19 20 21 22 23  
24 25 26 27 28 29 30  
31                    

שלום עולם Lua And LÖVE

01/11/2020

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

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

function love.load()
  x = 100 
  y = 100
  speedX = 5
  speedY = 5
end

function love.draw()
  love.graphics.setColor(255, 0, 0)
  love.graphics.circle("fill", x, y, 40)
end

function love.update()
  width, height = love.graphics.getDimensions( )

  if x + 20 == width or x - 20 == 0 then
    speedX = speedX * -1
  end

  if y + 20 == height or y - 20 == 0 then
    speedY = speedY * -1
  end
  x = x + speedX
  y = y + speedY
end

ב LOVE אנחנו מגדירים כמה פונקציות ו love תקרא להן כשהיא מוצאת לנכון. הפונקציה load נקראת כשהתוכנית מתחילה, הפונקציה update נקראת כל פעם שצריך להבין מה הדבר הבא שצריך לצייר והפונקציה draw נקראת כשצריך לצייר פריים חדש.

יכולים לראות מה הקוד עושה?

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

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

על החשיבות של useEffect בפיתוח ריאקט

31/10/2020

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

המשך קריאה