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

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

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

ואולי כל מה שאנחנו יודעים על קוד הולך להשתנות ונוכל להמשיך הלאה לכתוב בלי להכיר את הפרטים? אולי נוכל לכתוב רק עם "הבנה"?

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

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

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

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

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

הקוד הבא ב Vue מראה על המסך את הטקסט Hello Vue:

<template>
    <template v-if="true">
        <p>Hello Vue</p>
    </template>
</template>

אבל זה כבר לא מראה כלום:

<template>
    <template>
        <p>Hello Vue</p>
    </template>
</template>

בואו נראה למה.

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

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

רק שני דברים הפריעו לחגיגה:

1. ב Scale גדול שרתי ענן יוצאים מאוד יקרים בהשוואה לעבודה על שרתים פיזיים.

2. פיתוח מערכות מבוזרות הוא יותר מורכב מפיתוח מערכות על שרת יחיד.

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

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

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

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

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

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

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

שאלה ראשונה - האם אתם היום מפתחים טובים יותר ממה שהייתם לפני שנה? בזכות מה?

שאלה שניה - מה אתם עושים היום לענות "כן" על השאלה הראשונה בשנה הבאה.

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

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

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

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

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

1. כשאין משתמשים - הכי קל, אף אחד לא יתגעגע למוצר.

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

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

4. כשיצאה טכנולוגיה חדשה ומהפכנית שמאפשרת לבנות מוצר שפותר את אותה בעיה בצורה טובה בהרבה (היוש Chat GPT).

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

ולסיום שאלה - באיזה מצבים אתם זורקים את כל הקוד ומתחילים מחדש? קרה לכם שהשכתוב הצליח טוב יותר מהמוצר המקורי? גרוע יותר? לא הסתיים מעולם?