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

מישהו שיתף השבוע ברדיט פרויקט שולה מוקשים שכתב ביום. הסטאק הטכנולוגי? 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 לסיים את הקלט.

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

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

הפלט של שתי הפקודות האלה על השרת הפתיע אותי -

ynon@schooler-prod-2:~$ touch a
touch: cannot touch 'a': No space left on device

ynon@schooler-prod-2:~$ df -h
Filesystem                                               Size  Used Avail Use% Mounted on
udev                                                     7.9G     0  7.9G   0% /dev
tmpfs                                                    1.6G  8.5M  1.6G   1% /run
/dev/sda                                                 315G  103G  197G  35% /
tmpfs

איך יכול להיות ש touch לא יכול ליצור קובץ חדש ומתלונן שאין מספיק מקום על הדיסק, כש df מראה שיש דווקא המון מקום? האם df משקר? האם יש corruption במערכת הקבצים? מה קורה פה?

ייתכן. אבל לפני שרצים להפעיל fsck שווה לנסות גם את df -i. מערכות קבצים בלינוקס צריכות לשמור בנוסף לקבצים עצמם גם אינדקס שמקשר בין שם הקובץ לתוכן שלו על הדיסק. האינדקס הזה גם תופס מקום והמבנה שלו יוצר מגבלה על מספר הקבצים שאפשר לשמור בתיקייה. הפקודה df -i מציגה כמה קבצים אפשר לשמור על כל כונן וכמה יש לכם, בלי קשר לגודל שלהם.

כשיש מקום על הדיסק אבל אין מספיק inodes פנויים, הפקודה touch (ויצירת קבצים באופן כללי) יציגו את אותה הודעת שגיאה מבלבלת No space left on device, למרות שהם היו צריכים להגיד Not enough free inodes on device.

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