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

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

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

git log main@{10.minutes.ago}

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

git show main@{10.minutes.ago}

או בשביל להראות תוכן מלא של קובץ:

git show main@{2.days.ago}:main.py

כל ההרצאות מ React Conf עלו לרשת לפני כמה זמן. אפשר למצוא אותן בקישור כאן: https://conf.react.dev/talks

הנה הבעיה:

1. אי אפשר לשמוע הכל כי אין זמן.

2. רוב המידע בהרצאות האלה לא יהיה שימושי מחר בבוקר.

3. אין דרך טובה לדעת מראש איזה הרצאה תדבר אליי.

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

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

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

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

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

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

הממשלה מפרסמת כל יום רשימה של טיסות שהמריאו, נחתו או התבטלו בקישור: https://data.gov.il/dataset/flydata

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

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

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

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

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

הפונקציה ROW_NUMBER של SQL מוסיפה מספרי שורות לתוצאות שאילתות, כך לפחות לפי שמה. אבל מספיק לנסות להריץ את השאילתה הבאה כדי להבין שיש פה משהו יותר עמוק:

SELECT *, ROW_NUMBER() from employees;

תגובת בסיס הנתונים תהיה משהו כמו:

SQLite3Error: SQLITE_ERROR: sqlite3 result code 1: misuse of window function ROW_NUMBER()

מה זה? למה misuse? ומה זה אומר window function? איזה חלון יש פה?

קל מאוד ללכת ל ChatGPT כדי שיתקן את השאילתה. הוא יחזיר את זה:

SELECT *, ROW_NUMBER() OVER (ORDER BY id) AS row_num FROM employees;

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

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

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

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

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

החלום של DHH עבור ריילס הוא לוותר על ה Build Step ופשוט לשלב בדף ה HTML את הקישורים לסקריפטים באמצעות ES Modules. בזכות התמיכה של דפדפנים ב HTTP2 וב Import maps הסיפור הזה אפילו עובד די טוב בפרויקטי ריילס המסתמכים על JavaScript.

אבל כשאנחנו מוסיפים TypeScript וריאקט לתמונה העסק מסתבך ושלב בניה הופך הכרחי. גירסה 7 של ריילס שילבה ממשק סטנדרטי לבניית קבצי Front End שנקרא JS Bundling. מנגנון זה מאפשר לעבוד עם esbuild, webpack או rollup ולשלב אותם בתוך פרויקט ריילס. אבל מה שמיוחד ב JS Bundling בעולם של ריילס הוא שאין קובץ הגדרות אחד שעובד על כל הכלים ובמקום זה עלינו לבחור את אחד מהכלים ולבנות לו את קובץ ההגדרות בעצמנו. לפני כמה שבועות פרסמתי כאן מדריך שמסביר איך לשלב React ו TypeScript בפרויקט ריילס ושם הצעתי על הספריה vite-ruby. היום אני רוצה להראות מבנה פרויקט דומה אבל הפעם בעזרת esbuild ותוך שימוש ב JSBundling.

אופרטור ?? ב JavaScript, או בשמו הרשמי Nullish Coalescing operator, הוא גירסה הגיונית יותר של ||. טוב לפחות הגיונית יותר לחלק משמעותי מהמצבים. עבור || הערך 0 נחשב ל"שקר" ועבור ?? הוא נחשב ל"אמת". זה אומר שעם || יש לנו:

> const items = [10, 20, 30, 40]
undefined
> const firstIndexOfTenOrFifty = items.indexOf(10) || items.indexOf(50)
undefined
> firstIndexOfTenOrFifty
-1

לעומתו עם ?? אנחנו מקבלים את האינדקס הנכון של המספר 10:

> const items = [10, 20, 30, 40]
undefined
> const firstIndexOfTenOrFifty = items.indexOf(10) ?? items.indexOf(50)
undefined
> firstIndexOfTenOrFifty
0

אז למה בכל זאת אנחנו כמעט לא רואים אותו בקוד? כמה רעיונות:

1. אנחנו פחות מכירים ופחות רגילים להשתמש בתחביר חדש.

2. אנחנו חוששים שאלה שיקראו את הקוד לא מכירים.

3. אנחנו לא בטוחים באיזה דפדפנים הוא יעבוד (עובד בכל מקום).

4. ממילא רוב הזמן אנחנו בודקים "או" בין ערכים בוליאנים, אז זה לא כזה משנה.

מה דעתכם? באיזו מידה אתם משתמשים בשני סימני השאלה? ולמה אתם לא משתמשים בו יותר?

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

אלה הדברים שסיבכו אותנו עד עכשיו:

1. כל מנגנון בניית ה JavaScript/CSS השתנה מאוד בריילס בשנים האחרונות. כשהפרויקט נכתב במקור לא היתה דרך סטנדרטית לשלב FrontEnd App עם קוד ריאקט ולכן כל פרויקט נראה אחרת.

2. שימוש ב Composite Primary Keys בעבר לא נתמך בריילס. היום הוא כבר נתמך ולכן יש לעדכן את הקוד שיעשה שימוש במנגנון החדש (כי הפיתרון הישן נשבר).

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

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