ToCode

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

import { memo } from 'react';

const NewMessage = memo(() => {
  return <p>demo</p>;
})

NewMessage.displayName = "foo";

export default NewMessage;

והקומפוננטה בכלי הפיתוח הופיעה עם השם foo. וכן ברוב המקרים כדאי לבחור שם את שם הקומפוננטה המקורי כדי שהיא תיקרא בשם האמיתי שלה ולא באיזה _c עם תוספת Memo. כשהעברתי את אותו קוד ל next זה לא עבד ושם הקומפוננטה שהופיע בכלי הפיתוח היה _c. הפיתרון היה להגדיר את ה displayName על הקומפוננטה לפני שמפעילים memo באופן הבא:

'use client';

import { memo } from 'react';

const NewMessage = () => {
  return <p>demo</p>;
}
NewMessage.displayName = 'foo';

export default memo(NewMessage);

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

אז כבר לא צריך State Management Library בריאקט? ביקשתי מ lovable לשכפל את טטריס. הוא הכניס את ריאקט ראוטר, את ריאקט קוורי, את טיילווינד כמובן וגם את Shadnc. הוא גם חילק את המשחק לקומפוננטות בצורה מסודרת והפריד את הלוגיקה לקובץ hook נפרד. אני לא ביקשתי שום דבר מזה. על ספריית ניהול סטייט הוא וויתר. גם v0 לא חשב שזה חשוב, וגם base44 וויתר על זה. אז נכון אני לא בטוח שצריך ללמוד מ AI באיזה ספריות להשתמש אבל יש להם נקודה. אלה התבניות שאנחנו רואים היום: 1. סטייט גלובאלי מנוהל דרך קונטקסט (לדוגמה React Query) בצורה שקופה. אפשר להגיד שבמקום לחלק את האפליקציה ל slices בסגנון רידאקס אנחנו מחלקים אותו ל"תחומי אחריות גלובאליים" כשכל תחום אחריות מנוהל על ידי ספריה נפרדת. 2. מבנה שטוח של קומפוננטה ראשית שמנהלת סטייט ומעבירה אותו בתור prop לילדים, במקום עץ עמוק של קומפוננטות. 3. הסתמכות גדולה יותר על קוד צד שרת ועדכון הסטייט ישירות לקומפוננטות באמצעות Web Sockets או SSE. 4. התבנית הקלאסית של נקסט - קריאת מידע מ DB מקומפוננטת צד שרת והעברה בתור prop לקומפוננטת צד לקוח, שמירה חזרה לשרת עם Server Action ועדכון סטייט מקומי בקומפוננטות. ומה אתכם? עדיין משתמשים ברידאקס או ספריות דומות? אם כן אשמח לשמוע בתגובות לאיזה צרכים ואם ניסיתם פתרונות אחרים?

סיכום וובינר GenAI ותוכניות להמשך אתמול העברתי כאן וובינר ראשון אחרי תקופה ארוכה של הפסקה במסגרת קבוצת לימוד GenAI. קצת הופתעתי מכמות האנשים ובמיוחד מכמות האנשים שכבר משתמשים בכלי AI לפיתוח. דיברנו על איך לשלב AI בתהליך כתיבת הקוד וראינו מספר אסטרטגיות- 1. הראיתי שהקוד בפרויקט שלנו הוא חלק מהפרומפט, ולכן דרך אחת לקבל תוצאות טובות יותר מה AI היא לשפר את איכות הקוד או לבנות מסגרת כללית לפיתוח פיצ'רים. 2. חלק מהמשתתפים הזכירו שגם מסמכים יכולים להיות פרומפט, ושהם מצליחים להגיע לתוצאות טובות בעזרת כתיבת איפיון מסודר לפרויקט ולפיצ'ר, היעזרות ב AI כדי לשפר את האיפיון ובסוף כשאותו איפיון מגיע לרמת פירוט ודיוק מספיק טובה אז נותנים ל AI לממש. 3. הראיתי את Ask Mode של כלי הפיתוח והמלצתי להשתמש בו כדי ללמוד יותר על הפרויקט מתוך ה Cursor או ה VS Code. הלימוד הזה משרת שתי מטרות, גם נותן לנו נקודת מבט נוספת על הפרויקט וגם ולא פחות חשוב עוזר לנו להבין איך ה AI קורא את הפרויקט שלנו. הרבה פעמים שווה לסכם שיחות כאלה ב Ask Mode לקובץ Markdown (כלומר לבקש מה AI לסכם בשבילנו) ואז אפשר לצרף את הקובץ הזה לבקשות עתידיות. היתה גם הסכמה שהמקצוע שלנו עובר מהפכה ושאנחנו לא בטוחים איך יראה תהליך כתיבת קוד בעתיד. עכשיו לגבי ההמשך: 1. היתה הענות טובה והיה נראה שאתם רוצים לראות עוד דוגמאות לכן בינתיים אני ממשיך את הוובינר בתור פגישה שבועית. 2. שבוע הבא אציג טיפים לעבודה עם AI על פרויקט קיים דרך הוספת פיצ'ר לאתר טוקוד: נתחיל להוסיף דף נחיתה לקבוצת לימוד ה AI של ימי חמישי בבוקר. אני מקווה שעד סוף השעה הדף אפילו יהיה באוויר. המפגש יהיה בזום באותו לינק. 3. ולסיום בקשה מכם - אני מאוד אשמח לראות איך אתם עובדים עם AI בתוך Cursor או VS Code. אם הייתם אתמול (וגם אם לא) ואתם מוכנים שבוע הבא להציג 5-10 דקות איך אתם עובדים עם AI דרך פיצ'ר קטן כתבו לי ונתאם. אפשר דרך דף צור קשר פה באתר.

בוקר טוב עוד חמש דקות מתחילים וובינר על כלים לקידוד עם AI זה הלינק https://us06web.zoom.us/j/86295492018?pwd=7lGAenxpaXM7oe25PqcDzFkWrhNqpS.1

טיפ npm - תמיד לבדוק מספרי חבילות בגיטהאב כן אני יודע זה לא בדיוק טיפ אם אני רק מוסיף לכם עבודה, אבל תקשיבו רגע כי זה חשוב. צ'ארלי אריקסון פרסם בתחילת החודש את הממצא הזה: https://www.aikido.dev/blog/catching-a-rat-remote-access-trojian-rand-user-agent-supply-chain-compromise בקצרה מישהו מצא חבילת npm בשם rand-user-agent שכבר לא נתמכת אבל טוקן העדכון שלה היה פרוץ, לקח את הטוקן והתחיל לפרסם גירסאות "חדשות" של הספריה שכללו סוס טרויאני. מי שמריץ את אותן גירסאות חדשות לצורך Web Scraping יגרום למחשב שלו עצמו להפוך לזומבי עבור מרכז השליטה החללי של אותו מפרסם גירסאות מסתורי. בין הסימנים החשודים לגבי החבילה: 1. היא מסומנת בתור "Deprecated" 2. לפי התיעוד הגירסה האחרונה אמורה להיות 2.0.82 אבל ב npm היו גירסאות חדשות יותר. 3. הקישור לגיטהאב הוביל לדף ריק. אני יודע שאתם כבר מסתכלים על סימון Deprecated ולא הייתם לוקחים חבילה שכבר לא נתמכת, אבל מסתבר שמספר הגירסה הוא גם סימן אזהרה קל: כנסו לגיטהאב של הפרויקט (תמיד יש לינק מ npm) ותראו מה הגירסה הכי עדכנית ואם זה תואם למה שאתם רואים ב npm. מיטיבי לכת יכולים גם להיכנס לרשימת הקומיטים ולראות אם יש תורם קוד חדש בגירסאות האחרונות, ונינג'ות AI יכולים כבר לכתוב סוכן AI שיעשה את זה בשבילכם לכל החבילות ב package-lock.json.

הבעיה עם default scope ב Rails הסיפור של היום הוא על Rails כי ריילס היא כמו פלסטלינה ומאפשרת לעצב את הפרויקט איך שרוצים, וכי קוד שאילתות בריילס יכול להיות מפוזר בין הרבה קבצים. אבל הסיפור הוא גם על AI ואיך כלי פיתוח מבוססי AI יכולים לעזור גם למפתחים עצלנים לכתוב קוד נכון יותר. וזאת גם הזדמנות טובה להזכיר שמחר בבוקר אני מעביר וובינר על עבודה עם כלי AI בפיתוח שמיועד למתחילים. אשמח לראות גם אתכם שם (הלינק יעלה לקבוצת טלגרם בחמישי בבוקר או שתשלחו לי מייל ואשלח לכם). עכשיו נחזור לריילס. ב Rails בשביל לשלוף מידע מבסיס הנתונים אני משתמש בשכבת ORM שנקראת Active Record. לדוגמה ניקח שתי טבלאות, אחת של מוצרים ואחת של קטגוריות, ובטבלת המוצרים יש עמודת משקל. בדף הקטגוריה עלינו להציג את המוצרים מסודרים לפי משקל מהקטן לגדול. אפשר לכתוב את הגדרת ה ORM בריילס באופן הבא:

class Category < ApplicationRecord
  has_many :products
end

class Product < ApplicationRecord
  belongs_to :category

  # Default scope to always order products by weight
  default_scope { order(:weight) }
end

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

category = Category.first
category.products

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

category.products.order(weight: :desc)

אלא צריך לבטל את ה order של הסקופ הדיפולטי קודם עם:

category.products.unscope(:order).order(weight: :desc)

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

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

איך יראה חיפוש עבודה בהייטק ב 2026? כמה מגמות שקורות כבר היום ודורשות תשומת לב: 1. סוכני AI מתאימים את קורות החיים שלנו אישית לכל משרה ושולחים את קורות החיים בצירוף Cover Letter אישי למנהלי הגיוס. 2. תוכנות AI שרצות על המחשב שלנו מאפשרות לענות "נכון" על כל שאלה בראיון הטכני שמתבצע בזום. 3. מראיינים משתמשים ב AI כדי לסנן קורות חיים ובוטים מבוססי AI מבצעים ראיונות בפועל (לאותם מועמדים שנעזרים ב AI כדי לענות על השאלות). 4. פרויקטי Take Home למועמדים מבוצעים על ידי AI או בצורת Vibe Coding מלא או עם הנחיה של המועמד. מאחר וממילא הפרויקטים האלה לא גדולים אין שום דרך להעריך את המועמד על בסיסם. בנקודה הזאת אפשר לעצור ולשאול - "אולי זה בסדר?", אולי זה הגיוני לתת למועמד הזדמנות להראות את היכולות שלו תוך שימוש בכל ארגז הכלים המקצועי שהוא או היא מביאים לשולחן. אם אני מגייס למשרת פיתוח, וממילא בעבודה עצמה יהיה שימוש בכלי AI, אז למה לא לאפשר אותם בראיון? והתשובה כאן היא שהראיון הוא לא באמת סביבת "עבודה". אף אחד לא פותר שאלות LeetCode אחרי הקפה של הבוקר ביום עבודה רגיל, אנחנו משתמשים בהן בתור מייצג מתוך מחשבה שאנשים שיודעים לפתור שאלות כאלה יוכלו להתמודד גם עם האתגרים הגדולים יותר איתם צריך להתמודד בעבודה האמיתית. שימוש בכלי AI במסגרת קבלה לעבודה מרסק את הקשר הזה (וממילא רבים יטענו שהיה מקרי). היום כשאני מסתכל על פרויקט Take Home של מועמד אין לי דרך להסיק מהקוד הזה שום דבר לגבי התאמה או אי התאמה של המועמד. אותו דבר לגבי ראיון בזום או קריאה של קורות חיים. אז מה כן עובד? אני לא יודע. אבל אלה כמה רעיונות שהייתי מנסה: 1. אם יש פרויקט קוד משמעותי שהבן אדם כתב או היה שותף בו הייתי שמח להעיף מבט על הקוד, ובמיוחד על היסטוריית הגיט כדי להבין איזה קוד המועמד או המועמדת שלי הכניסו למערכת. 2. אם אפשר לדבר עם הבן אדם פנים אל פנים זה יכול לעזור. וכן ה Bias פה מוכר אבל אני לא רואה איך אפשר לסמוך על כל מדיום אחר. 3. אם אפשר לתת "משימת ניסיון" על הפרויקט האמיתי זה יכול לעזור, כי שם אין בעיה שישתמשו ב AI. ומה אתכם? איך אתם מסתכלים על אתגר הגיוס בשנים הקרובות? באיזה שיטות תשתמשו כדי להבין רמה מקצועית של הבן אדם שמולכם ולהחליט את מי לגייס?

טיפ LLM - ואם נריץ 100 פעמים? שון הלן כתב פוסט מדהים על השימוש ב LLM כדי למצוא בעיית אבטחה בקוד. כל מילה שם שווה זהב ואני ממליץ לקרוא: https://sean.heelan.io/2025/05/22/how-i-used-o3-to-find-cve-2025-37899-a-remote-zeroday-vulnerability-in-the-linux-kernels-smb-implementation/ אחד הטריקים המעניינים שלו היה להריץ את השאילתה 100 פעמים. הנה מה שהוא כותב (תרגום ועיבוד שלי): 1. בהרצת השאילתה 100 פעמים עם פרומפט יחסית קצר, כלומר באזור ה 3,000 שורות קוד, o3 מצא את בעיית האבטחה ב 8 מתוך 100 ריצות. ב 66 מהריצות o3 חשב שאין שום בעיה בקוד ובעוד 28 ריצות o3 זיהה בעיות שלא באמת היו בעיות. (הערת המתרגם - שמתי לב שהמספרים לא מסתדרים אבל משאיר אותם כמו בפוסט המקורי). 2. בהרצת השאילתה 100 פעמים עם פרומפט ארוך יותר, באזור ה 12 אלף שורות קוד, o3 מצא את בעיית האבטחה רק בריצה אחת מתוך 100, אבל באחת הריצות האחרות הוא מצא בעיית אבטחה אחרת שהחוקר לא הכיר. שימו לב למספרים האלה אם אתם משתמשים ב AI למחקר או כדי לייצר קוד או בהקשר של מערכת אג'נטית. כן ריצה חוזרת של אותה שאילתה עולה כסף ומכניסה רעש למערכת, ואולי נצטרך לקחת את כל ה 100 תוצאות ולהעביר אותן לעוד LLM שיסכם את הכל, אבל זה סוג הטכניקות שאנחנו עדיין צריכים היום כדי להגיע לתוצאות טובות.

undefined,
  undefined,
  SECRET_TOKEN
);
  
  


async function translateToSpanishWithOpenAI(text: string) {
   const openai = new OpenAI();
  const completion = await openai.chat.completions.create({
    messages: [
      {
        role: 'system',
        content: 'You are a Spanish/English dictionary but you also know all the languages in the world. When you receive a word or phrase in Spanish respond with its English translation. When you receive a word or phrase in another language translate it to Spanish'
      },
      {
        role: "user",
        content: "hola"          
      },
      { role: "assistant", content: \hello\ },
      {
        role: "user",
        content: "יש לי חבר"
      },
      {
        role: "assistant",
        content:
          \tengo un amigo\,
      },
      {
        role: "user",
        content: text          
      },
    ],
    model: "gpt-4",
  });
  return completion.choices[0].message.content || "Translation Error";
}


export default async (req: Request): Promise<Response> => {
  // Set webhook if it is not set yet
  // Do this in the HTTP handler so we get the endpoint url from req.url
  // This is a no-op if nothing's changed
  if (!isEndpointSet) {
    await bot.api.setWebhook(req.url, {
      secret_token: SECRET_TOKEN,
    });
    isEndpointSet = true;
  }
  if (req.method === "POST") {
    return await handleUpdate(req);
  }
  return new Response("TODO GET", { status: 200 });
};

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

פרידה ולקחים מ Spanish Panda לפני כמה שנים התחלתי לעבוד על פרויקט צד שיעזור לי לזכור מילים בשפות זרות. חשבתי שיהיה נחמד אם יהיה לי מילון זמין שגם יוכל לזכור את המילים שחיפשתי ואחרי כמה ימים להמשיך להזכיר לי את אותן מילים עד שאני כבר אזכור טוב את משמעותן. השבוע הורדתי את השרת שהריץ אותו אחרי שהבנתי טוב יותר מה באמת אני צריך ובניתי פיתרון מדויק בהרבה. זה הסיפור בקצרה וכמה לקחים. הכל התחיל בטכנולוגיה את המוטיבציה לכתוב מילון קיבלתי כשהתחלתי ללמוד על בסיסי נתונים גרפיים. חשבתי שחיבור בין מילים בשפה זה שימוש ממש מושלם לבסיס נתונים גרפי ומאוד אהבתי את הממשק של neo4j וככה חשבתי לפתור שתי בעיות בפרויקט צד אחד: גם אוכל ללמוד neo4j וגם לזכור מילים בשפה זרה. בשביל הזמינות ובשביל לחסוך עבודה על הממשק החלטתי שזה יהיה בוט לטלגרם, וכך נולדה הפנדה הספרדית. באותו זמן ה AI היה עוד בחיתולים ואי אפשר היה להשתמש ב ChatGPT כדי לתרגם. גוגל טרנסלייט גם החזיר תוצאות בינוניות ולכן השקעתי המון עבודה בלמצוא ולטייב תרגומים ולחבר תוצאות מכמה מילונים. זה היה כיף אבל גם מיותר לגמרי כי עד שסיימתי את הפיתוח כבר היה AI וכל בעיות התרגום שלי נפתרו בשיחה עם קלוד, אבל לא בטוח שאפשר היה לדעת איך דברים יתפתחו באותו זמן. מבחינת בסיס הנתונים העבודה עם neo4j נראתה מבטיחה בהתחלה אבל מהר מאוד האבסטרקציה נשברה. הבעיה עם neo4j עבורי היתה שהשאילתות היו כתובות בשפה מיוחדת שלהם והיה קשה לבנות שאילתות בסיסיות ולהשתמש בהן כדי לבנות שאילתות מורכבות יותר. מצאתי שאני משכפל הרבה מקוד השאילתות וכך המערכת הפכה לקשה עד בלתי אפשרית לתחזוקה. בגלל שאחת המטרות של הפרויקט היתה ללמוד טכנולוגיה, המחסום נראה כמו הזדמנות ועברתי לשכתב את המערכת על בסיס נתונים גרפי אחר שנקרא JanusGraph. הוא כתוב ב Java וזו נראתה הזדמנות טובה ללמוד סקאלה וכך נכנסתי להרפתקאה חדשה של לימוד סקאלה, JanusGraph ושפת שאילתות שנקראת גרמלין. המוצר היה רק תירוץ סקאלה היתה בשבילי אהבה ממבט ראשון. שפה זורמת, אבסטרקציות טובות, קלה להרחבה ועם מערכת טיפוסים חזקה. הבעיה עם סקאלה זה האקוסיסטם אבל זה סיפור לפוסט אחר. בגלל שזה היה כיף המשכתי להוסיף פיצ'רים לבוט בעיקר בשביל לשחק עם הכלים: יצרתי חידוני אוצר מילים שהבוט שלח, בניתי תשתית גנרית כדי שאפשר יהיה בקלות לבנות בוטים מקבילים לפלטפורמות אחרות כמו ווטסאפ או סלאק, בניתי מנגנון של Spaced Repetition שעושה מאמץ לשלוח למשתמשים בדיוק את המילים שהם צריכים לתרגל, חיברתי חיפוש תמונה ואפשרות להגדיר אוספים שונים של מילים וגם הסברים ואטימיולוגיה לכל מילה שמחפשים ומערכת לניהול אוצר המילים ששמור בבוט ואפשרות לייצא ולייבא את המילים, כמובן שאפשרות לבחור את השפה של הבוט וקבצי הודעות בכל השפות ועוד המון דברים שאני אפילו לא זוכר. כל פעם כשהיה קצת זמן הוספתי עוד פיצ'ר קטן, סך הכל הפרויקט עמד על קצת מעל 10 אלף שורות. עד שהבנתי שאני בעצם לא משתמש בכל הפיצ'רים האלה השימוש בבוט היה קצת פחות מהנה מהפיתוח שלו. ככל ששמרתי יותר מילים גיליתי שהשיטה של בחני אוצר מילים לא ממש עובדת עבורי. לא משנה כמה פעמים אני מצליח לענות על המילה בבוחן, זה לא עוזר לי להיזכר בה בשיחה אמיתית. לאט לאט הבנתי שאני משתמש בו רק בתור מילון בטלגרם, ואני חייב להודות שבתור מילון בטלגרם הוא כן היה נחמד, אבל בשביל מילון בטלגרם לא צריך 10 אלף שורות קוד, לא צריך בסיס נתונים גרפי וגם לא שרת. אפשר להסתפק ב val.town. וככה נפרדתי מכל הטכנולוגיה המתוחכמת והחלפתי אותה בסקריפט הבא, שרץ בחינם לגמרי על val.town (אפילו לא צריך לשלם על הטוקנים ל OpenAI כי גם זה עליהם):

import { OpenAI } from "https://esm.town/v/std/openai";
import { telegramSendMessage } from "https://esm.town/v/vtdocs/telegramSendMessage?v=5";
import {
  Bot,
  webhookCallback,
} from "https://deno.land/x/grammy@v1.35.0/mod.ts";
const bot = new Bot(Deno.env.get("SPANISH_PANDA_BOT_TOKEN")!);
const SECRET_TOKEN = Deno.env.get("SPANISH_PANDA_BOT_TOKEN")!.split(":")[1];
let isEndpointSet = false;

bot.command("start", (ctx) => ctx.reply("Welcome! Up and running."));

bot.on("message", async (ctx) => {
  const text = await ctx.message.text
  console.log(\received: ${text}\)
  if (text) {
    const response = await translateToSpanishWithOpenAI(text);
    console.log(\translated to: ${response}\);
    ctx.reply(response);
  } 
});


const handleUpdate = webhookCallback(
  bot,
  "std/http",

מה שה Commit Message לא סיפר במהלך תיקון באג אצל לקוח הגענו לקובץ שנראה קשור ומיד עלו השאלות - מי שם את הקובץ הזה שם? למה? מה אנחנו מפספסים? הצעד הבא במצבים כאלה הוא git log על הקובץ:

git log -- file

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