📌 היתרונות של ריאקט נשמעים לי הרבה פחות משכנעים היום

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

1. אני חושב על ה State ועל התרגום שלו ל UI פעם אחת במקום בכל פעולה.
2. אני חושב על חלוקה נכונה לקומפוננטות ומשתמש באותן קומפוננטות לאורך היישום.

בואו נפתח את זה.

✏ חשיבה על הסטייט במרוכז ולא עבור כל פעולה

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

document.querySelector("button").addEventListener("click", () => {
  count++;
  document.querySelector("#count").textContent = count;
});

ואז שוב בלחיצה על הכפתור שמאפס:

document.querySelector("button").addEventListener("click", () => {
  count = 0;
  document.querySelector("#count").textContent = count;
});

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

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

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

✏ חשיבה במסכים במקום בקומפוננטות

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

זה לא שיקול יותר.

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

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

שורה תחתונה אני רואה מעט מאוד סיבות היום להעדיף ריאקט במערכת חדשה על פני אפליקציית Vanilla JS או Web Components ואם יש שרת אז htmx.

מה דעתכם? איזה סיבות יש לכם להמשיך לבחור ריאקט או כל Frontend Framework אחר בעידן הסוכנים?

📌 זה יהיה במבחן?

״אני רוצה לכתוב את הקוד נכון אבל המנהל שלי דורש שאעלה גרסה אתמול״.

״אני מנסה להסתכל על הקוד אבל זה משעמם מדי. ממילא הוא עובד והמשתמשים מרוצים (ואם יש להם בעיה אני תמיד יכול להעביר את התלונה לקלוד)״.

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

״זה פשוט לא כלכלי. כל פעם שישבתי 4 שעות להבין איך AI מימש מנגנון מסוים בסוף הרגשתי שהוא עשה עבודה טובה והפסדתי 4 שעות״.

כל המשפטים האלה הם גרסה של אותה שאלה מבית הספר: ״זה יהיה במבחן?״

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

האלטרנטיבה היא סקרנות.

״מעניין איך תיראה מערכת שלא מחברת כמה התנהגויות באותה פונקציה״.

״מעניין איך הקוד מטפל במקרי קצה ומה קורה כשהוא נשבר״.

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

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

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

📌 היום למדתי: git intent to add

בואו נשחק עם גיט. יש לי ריפו ויצרתי בו קובץ חדש בשם demo.py. רואים את זה:

ynonp@ynons-MacBook-Air ~/tmp/blog/git (main?) $ git status
On branch main
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        demo.py

nothing added to commit but untracked files present (use "git add" to track)
ynonp@ynons-MacBook-Air ~/tmp/blog/git (main?) $

עכשיו אני רוצה לראות מה יש בקובץ. קודם כל אני מנסה git diff - אבל הוא לא מדפיס כלום כי אין שינויים בקבצים של הפרויקט (הקובץ demo.py הוא חדש ומבחינת גיט לא חלק מהפרויקט עדיין).

אז אני מנסה להוסיף אותו עם git add . ועכשיו הוא חלק מהפרויקט:

ynonp@ynons-MacBook-Air ~/tmp/blog/git (main?) $ git add .
ynonp@ynons-MacBook-Air ~/tmp/blog/git (main+) $ git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   demo.py

ynonp@ynons-MacBook-Air ~/tmp/blog/git (main+) $ git diff
ynonp@ynons-MacBook-Air ~/tmp/blog/git (main+) $

אבל עדיין git diff לא מדפיס כלום כי אין הבדל בין תוכן הקובץ לתוכן הקובץ ב Staging Area. שוב ברור, git add הוסיף את הקובץ ל staging area.

עד היום השתמשתי ב git diff HEAD או git diff --cached כדי לראות את השינויים אחרי add לדוגמה:

ynonp@ynons-MacBook-Air ~/tmp/blog/git (main+) $ git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   demo.py

ynonp@ynons-MacBook-Air ~/tmp/blog/git (main+) $ git diff
ynonp@ynons-MacBook-Air ~/tmp/blog/git (main+) $ git diff HEAD
diff --git a/demo.py b/demo.py
new file mode 100644
index 0000000..d77c663
--- /dev/null
+++ b/demo.py
@@ -0,0 +1 @@
+print("hello world from python")

מסתבר ש git add מגיע עם מתג מיוחד בדיוק למקרים האלה, המתג -N או --intent-to-add. מתג זה מסמן לגיט שאנחנו מתכוונים להוסיף את הקובץ הזה לפרויקט בלי להוסיף את התוכן שלו ל Staging בדיוק בשביל שנוכל לראות את ה diff. ככה זה נראה:

ynonp@ynons-MacBook-Air ~/tmp/blog/git (main?) $ git add -N demo.py
ynonp@ynons-MacBook-Air ~/tmp/blog/git (main+*) $ git status
On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        new file:   demo.py

no changes added to commit (use "git add" and/or "git commit -a")
ynonp@ynons-MacBook-Air ~/tmp/blog/git (main+*) $ git diff
diff --git a/demo.py b/demo.py
new file mode 100644
index 0000000..d77c663
--- /dev/null
+++ b/demo.py
@@ -0,0 +1 @@
+print("hello world from python")
ynonp@ynons-MacBook-Air ~/tmp/blog/git (main+*) $

הקובץ מסומן בתור new file אבל התוכן שלו עדיין לא נשמר וכך אנו רואים אותו ב git diff רגיל.

📌 ואיך את יודעת מה המערכת עושה?

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

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

class IssueInvitation
  class Rejected < StandardError; end

  def self.call(email:, admin:)
    raise Rejected, I18n.t("admin.forbidden") unless admin.admin?

    token = SecureRandom.urlsafe_base64(32)
    invitation = nil
    # Serialize issue/resend calls, including invitations without an existing row.
    admin.with_lock do
      invitation = Invitation.find_or_initialize_by(email: email.to_s.strip.downcase)
      raise Rejected, I18n.t("admin.invitations.existing_user") if User.exists?(email: invitation.email)
      if invitation.accepted_at?
        raise Rejected, I18n.t("admin.invitations.already_accepted")
      end
      if invitation.last_sent_at && invitation.last_sent_at > 1.minute.ago
        raise Rejected, I18n.t("admin.invitations.cooldown")
      end
      invitation.assign_attributes(invited_by: admin, token_digest: Invitation.digest(token),
        expires_at: 7.days.from_now, last_sent_at: Time.current)
      invitation.save!
    end
    InvitationDeliveryJob.perform_later(invitation.id, token)
    invitation
  end
end

הסוכן יצר מנגנון קירור כדי לוודא שאני לא שולח יותר מדי הזמנות, אלה השורות:

if invitation.last_sent_at && invitation.last_sent_at > 1.minute.ago
  raise Rejected, I18n.t("admin.invitations.cooldown")
end

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

token = SecureRandom.urlsafe_base64(32)
...
invitation.assign_attributes(invited_by: admin, token_digest: Invitation.digest(token),
        expires_at: 7.days.from_now, last_sent_at: Time.current)

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

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

ואני מחדד את הפוסט מהבוקר עם הפוסט הזה

https://www.parameter.ai/labs/we-found-a-gap-at-openai

ספריית גרפים בשם mathlive מציירת גרפים אבל גם מאפשרת לאייפריימים לצייר מקלדת וירטואלית מ HTML שאנחנו מעבירים

כש ChatGPT השתמשו בספרייה הזו כדי להציג גרפים אף אחד לא אמר להם שהיא גם תאפשר לאייפריימים הפנימיים של כל צד שלישי להריץ JavaScript על האתר שלהם

ושום AI Security Review בצד של ChatGPT לא ראה את זה לפני שהבאג עלה לאוויר
״תמיד היו בעיות אבטחה״ לא אמור לתת לנו להכניס חופשי קוד למערכת בלי לדעת מה נכנס לשם

📌 הגרסה המעניינת

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

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

https://tocode.ravpage.co.il/ai-daily

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

וזו הגרסה השניה אחרי הערות:

https://tocode.ravpage.co.il/ai-daily-devs

הרבה יותר יפה אבל משעמם באותה מידה.
(גם הוא עובד. אפשר להירשם ותקבלו 4-5 מאמרים על AI למייל כל בוקר מלבד שבתות וחגים).

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

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

📌 הפרומפט השביעי

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

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

פעם שניה הוא הלך לאיבוד בחיבור בין next.js ל eve. תיקנתי שוב את הפרומפט.

פעם שלישית הוא ניסה להשתמש בבסיס נתונים מקומי שלא עובד על vercel, שוב שדרגתי את הפרומפט עם הנחיה מפורשת לשמור את בסיס הנתונים על neon.

פעם רביעית הוא השתמש ב BetterAuth המשולב ב neon (או לפחות ניסה). תיקנתי את הפרומפט שישתמש במנגנון התחברות מקומי.

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

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

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

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

📌 מתי לבנות סוכן

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

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

אז בשביל מה צריך לכתוב סוכן? אלה התשובות הכי מעניינות שאספנו:

1. ביצועים - כתיבת סוכן מאפשרת להריץ את כל הפניות ל LLM מאותו תהליך במקום להריץ תהליך נפרד לכל פניה.
2. שליטה בטוקנים - כתיבת סוכן מאפשרת לי לקבוע את ה System Prompt ולבחור בדיוק מה יישלח ל LLM.
3. חיבור לתוכנית שלי באמצעות מימוש כלים - במקום לכתוב MCP אני יכול לכתוב פונקציות פייתון פשוטות שיאפשרו למודל להתממשק עם המערכת הקיימת שלי.
4. פלט מובנה - פניה לסוכן בסקריפט עם claude -p מחזירה תמיד תשובה כמחרוזת. סוכן יכול לדרוש Structured Output כדי לקבל מבנה צפוי של התשובה.

בסוף הגבול בין המוצרים דק ואפשר לפתור כל בעיה במספר דרכים. בעולם של סוכני AI ובמיוחד כשהיכולות של הכלים כל הזמן מתעדכנות עדיף לא לבזבז יותר מדי זמן בחשיבה "איך נכון לפתור X" אלא להתמקד ב "מעניין איך זה יראה עם כל כלי". וכמובן התשתית הטכנולוגית לטובתנו כאן - "הי קלוד תראה לי איך זה היה נראה אם הייתי רוצה להשתמש ב claude -p במקום בסוכן כאן" או להיפך.

📌 סיימתי הכל בהצלחה

כשהסוכן כותב ״סיימתי הכל בהצלחה״ למה הוא מתכוון?

נתתי ל-4 סוכנים להוסיף 4 פיצ׳רים במקביל לאפליקציית דוגמה לקראת הוובינר של יום חמישי.

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

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

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

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

📌 לא רק קוד

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

ומה איתנו?

נניח שאני רוצה לבנות מערכת API בפייתון שתעבוד להרבה לקוחות. אני מתייעץ עם ה AI והוא ממליץ לי על FastAPI כשהשורה הראשונה בהמלצה "מהיר מאוד ותומך ב-async". אני יכול להמשיך עם "תראה לי דוגמה" או לשאול מה זה asyncio ומה היתרונות שלו ואז אני מבין בגדול על מה מדובר ויכול להתקדם לכתוב את השרת.

אבל כל זה זה למידה של אתמול.

יותר מעניין להמשיך את השיחה עם "מעניין ואיך זה בנוי?" ואפילו "מה הייתי צריך בשביל לממש event loop מאפס?". השאלה השניה מלמדת אותי שזה אפשרי ושהבסיס הוא Generators אז אני ממשיך עם פרומפט יותר ארוך:

בנה מודול לימוד אינטרקטיבי בסגנון Khan Academy על ״מבנה asyncio בפייתון״
במודול לומדים איך עובד asyncio ומה זה mainloop ואיך בונים אותו מאפס. נרצה לראות מימוש פשוט לדוגמה של Task Scheduler, Poller, Time queue ו Ready queue.

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

בנה את זה בתור artifact עם HTML/JavaScript/CSS שיהיה יפה מדליק וכיפי לתלמידים

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

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

בנה מודול לימוד אינטרקטיבי בסגנון Khan Academy על ״מבנה asyncio בפייתון״
במודול לומדים איך עובד asyncio ומה זה mainloop ואיך בונים אותו מאפס.

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

בנה את זה בתור artifact עם HTML/JavaScript/CSS שיהיה יפה מדליק וכיפי לתלמידים

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

שים לב:

1. המודול צריך להיות פשוט. לא להשתמש במילים מתוך async/await עצמה אלא להראות קודם איך בונים כל מושג מתוך מושגים בסיסיים יותר. אני רוצה להתמקד בפיתוח אינטואיציה לגבי asyncio יותר מאשר היכרות עם הפרטים הטכניים שלו
2. המודול צריך ללמד צעד צעד איך בונים mainloop ופונקציות אסינכרוניות ואיך החלקים מתחברים. אפשר להישאר רק עם sleep בתור פעולה לא צריך עבודת רשת בינתיים.

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

https://claude.ai/artifact/S9H8oUouBggjmBizAn6cJF

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

https://sshhole.com/

אחד ההזויים של התקופה