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

איזה מזל, יש HDMI.

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

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

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

מה הצעד הבא? חוזרים למקרן הראשון או נשארים?

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

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

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

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

אני בתיקיה חדשה כותב:

$ git init .
$ echo hello > file1.txt
$ git add .
$ git commit -m 'initial commit'

ועכשיו נשנה לקובץ את השם:

$ git mv file1.txt file2.txt
$ git status

On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        renamed:    file1.txt -> file2.txt

$ git commit -m 'rename'

ואפשר לראות את שינוי השם גם בצפיה בלוג:

$ git log -p --oneline

25ccbd7 (HEAD -> main) rename
diff --git a/file1.txt b/file2.txt
similarity index 100%
rename from file1.txt
rename to file2.txt
0e6c0e3 initial commit
diff --git a/file1.txt b/file1.txt
new file mode 100644
index 0000000..ce01362
--- /dev/null
+++ b/file1.txt
@@ -0,0 +1 @@
+hello

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

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

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

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

$ git log -p --oneline --no-renames
25ccbd7 (HEAD -> main) rename
diff --git a/file1.txt b/file1.txt

deleted file mode 100644
index ce01362..0000000
--- a/file1.txt
+++ /dev/null
@@ -1 +0,0 @@
-hello
diff --git a/file2.txt b/file2.txt

new file mode 100644
index 0000000..ce01362
--- /dev/null
+++ b/file2.txt
@@ -0,0 +1 @@
+hello
0e6c0e3 initial commit
diff --git a/file1.txt b/file1.txt

new file mode 100644
index 0000000..ce01362
--- /dev/null
+++ b/file1.txt
@@ -0,0 +1 @@
+hello

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

גם diff יכול לקבל אותו טיפול והנה שתי האפשרויות:

$ git diff --name-status HEAD~
R100    file1.txt       file2.txt

$ git diff --name-status --no-renames HEAD~
D       file1.txt
A       file2.txt

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

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

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

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

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

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

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

1. אם האוביקט מכיל את המאפיין href אז ל a יהיה href עם הערך המתאים. אחרת לא יהיה לו.

2. אם האוביקט מכיל את האלמנט title אז ל a יהיה title עם הערך המתאים. אחרת לא יהיה לו.

3. אם האוביקט מכיל את האלמנט text אז ל a יהיה טקסט עם הערך שעבר.

זאת הפונקציה שיניב כתב:

function showLink(props) {
  return (
    `<a
      ${props.href ? `href="${props.href}"` : ''}
      ${props.title ? `title="${props.title}"` : ''}
      >${props.text ? props.text : ''}
    </a>`
  );
}

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

function showLinkBetter(props) {
  const { href, title } = attrs(props);
  const { text } = values(props);

  return (
    `<a ${href} ${title}>${text}</a>`
  );
}

"ויותר מזה", התלהבה דנה, "עם פונקציות העזר שלי אתה יכול לתמוך במאפיינים חדשים בצורה קלה בלי לשנות את הפונקציות attrs ו values שכתבתי - רק תוך שינוי הפונקציה showLinkBeter".

איך נראה המימוש של attrs ו values שדנה כתבה?

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

1. בבניית Docker Image אנחנו בונים אימג' ספציפי לארכיטקטורת המעבד ולמערכת ההפעלה עליה אנחנו מריצים את תהליך הבניה.

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

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

4. כל פעם שאתם כותבים docker run או docker pul המנוע של דוקר מחפש אימג' שמתאים לארכיטקטורה ולמערכת הפעלה שהוא רץ בה כרגע. זה אומר שכשאני אכתוב docker run python על מערכת לינוקס ועל מערכת Windows, אני אקבל אימג' שונה בכל מערכת. אפשר לראות את זה אם תפעילו docker image ls בכל אחת משתי המכונות ותראו את ה Digest השונה.

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

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

7. אפשר לבדוק מה הארכיטקטורה שה Docker Engine שלכם כרגע מריץ עם docker version. חפשו את המפתח OS/Arch.

8. משתנה הסביבה DOCKER_DEFAULT_PLATFORM קובע לאיזה ארכיטקטורת יעד אנחנו בונים את האימג'ים כשמריצים docker build. בשביל לבנות למעבדי אינטל כשאני רץ על מכונת ARM אני קובע את הערך ל linux/amd64. בשביל לבנות סכימות יותר מתוחכמות יש מנגנון שנקרא buildx.

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

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

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

והתרגיל-

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

{
    a: [
        { a1: 10, a2: 20 },
        { a3: 40, a4: 50 },
        { a1: 20, a2: 20 },
    ],
    b: {
        b1: 'yay',
        b2: 'jaj',
        b3: [
            { b33: 'yay' },
            { b33: 'jaj' },
            { b44: 'zaz' },
        ]
    },
}

כתבו פונקציה בשם groupByDepth שמקבלת את האוביקט מחזירה את כל המפתחות שלו מסודרים לפי העומק. בחישוב העומק אנחנו בודקים כמה אוביקטים ללא מערכים יש מעל המפתח. באוביקט הדוגמה a הוא בעומק 1 וכך גם b, אבל a1 הוא כבר בעומק 2 ו b33 הוא בעומק 3. סך הכל אם נפעיל את הפונקציה על אוביקט הדוגמה נרצה לקבל:

{
    1: [ 'a', 'b' ],
    2: [ 'a1', 'a2', 'a3', 'a4', 'b1', 'b2', 'b3' ],
    3: ['b33', 'b44'],
}

פיתרונות אפשר לכתוב למגירה או לשתף פה בתגובות. תהנו ובהצלחה.

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

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

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

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

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

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

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

import React from 'react';

function Yo() {
  React.useEffect(function() {
    alert('bye bye');
  }, []);

  return <p>Yo</p>;
}

export default function App() {
  function handleClick() {
  }

  return (
    <div className="App">
      <Yo />
      <button onClick={handleClick} >Say bye bye</button>
    </div>
  );
}

עדכנו את קוד הקומפוננטה App כך שלחיצה על הכפתור תגרום להצגת ה alert שמוגדר ב Yo.

אין צורך לשנות את הקוד של Yo ואין לבצע כל שינוי ויזואלי בממשק.