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

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

app.use('/client/*', serveStatic({ root: './'}));

אם ניגשים לנתיב /client/foo.js יוגש הקובץ foo.js מתוך תיקיית client. אם ניגשים ל /client/index.html יוגש הקובץ index.html ואם ניגשים לנתיב /client/ יוגש גם כן הקובץ index.html כצפוי.

אבל מה קורה אם ניגשים ל /client (בלי לוכסן בסוף)? הונו מנסה ללכת לקראתנו ואוטומטית מגיש שוב את תוכן הקובץ index.html. הבעיה היא שה URL נשאר בלי הלוכסן, ולכן אם index.html כולל הפניה לקובץ אחר ההפניה תהיה יחסית ל / ולא יחסית ל /client. לדוגמה נניח שבתוך index.html מופיעה השורה:

<link rel="stylesheet" href="style.css" />

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

פיתרון מהיר הוא להוסיף הפניה מ /client ל /client/ עם הקוד הזה:

app.get('/client', (c) => {
  return c.redirect('/client/', 301); // Permanent redirect
});
app.use('/client/*', serveStatic({ root: './'}));

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

הבעיה עם Chat GPT ו Code Reviews היא שאין ל GPT עדיין מספיק קונטקסט בשביל להבין למה בניתי דברים כמו שבניתי ולכן הוא ימליץ על Best Practices כלליים, גם כשזה לא הכרחי, וגם יכול לטעות ולחשוב שלא השתמשתי ב Best Practice מסוים אפילו שכן. הנה שתי דוגמאות קטנות שעזרו לי לראות מה GPT רואה ומה הוא מפספס.

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

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

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

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

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

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

6. קוד משתנה אבל התיעוד שמלווה אותו נשאר ללא שינוי.

7. אף אחד לא יודע איך או מתי צריך לשדרג תלויות.

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

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

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

כן צריך לשים לב לשתי טעויות שאנשים עושים סביב הצלחות כאלה-

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

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

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

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

הרשת גועשת סביב המעבר של OpenAI מ next ל remix. כולם משתפים חוויות ומסבירים כמה גם להם היה קשה לעבוד עם next ואיך ה App Router החדש מסובך מדי. אנסה לעשות קצת סדר:

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

2. רינדור בצד שרת (SSR) זה אפילו עוד יותר מסובך, כי יש לנו את כל הסיבוך של SPA ובנוסף צריכים להתמודד עם ניהול Cache בצד שרת ולוודא שהקוד של הקומפוננטות לא מפעיל דברים שצריכים את window כשהוא רץ בשרת. אנחנו מרנדרים בצד שרת כי מנועי חיפוש, קוראי מסך ועוד כלים רבים אחרים אוהבים לקבל את ה HTML מוכן גם אם הם לא מריצים JavaScript.

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

הנטיה של יותר מדי מפתחים היא לבחור את שיטת העבודה הכי מסובכת כי אולי נצטרך את זה בעתיד. זה מה שקרה ב OpenAI, שבונים אפליקציית SPA אבל השתמשו ב next.js שמתאים לקומפוננטות צד שרת. בשלב מסוים הם כנראה הבינו שהם משלמים יותר מדי על הבחירה הטכנולוגית שלהם ועברו לאפליקציית SPA רגילה עם רמיקס, שאגב הספיק לאחרונה להתמזג חזרה לתוך React Router.

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

התמיכה של דינו ב Web Standards הביאה לזה שמאוד קל לכתוב קוד הונו שמשתמש ב Streams כדי לקבל הודעות מגולשים ולדווח אותן הלאה לגולשים האחרים באתר, הכל ב SSE. בואו נראה איך לחבר את החוטים בפרויקט דינו ו Hono.

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

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

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

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

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

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

איך ההבדל הזה משפיע על הכלכלה? על התרבות? על המדע? על החיים?

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

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

למה Stack Overflow לא רוצים ש Chat GPT יענה על שאלות? ומה זה אומר על שאר הדברים שאנחנו רוצים או לא רוצים לעשות עם AI?

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

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

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

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

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

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

2. ב Gremlin הפקודה g.V(id) מחזירה צומת מהגרף לפי id. אפשר להעביר מספר מזהים כדי לקבל מספר צמתים למשל g.V(2, 3, 5) יחזיר את הצמתים 2, 3 ו-5. העברה של ערך ריק (בלי כלום בתוך הסוגריים) מחזירה את כל הצמתים בגרף.

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

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