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

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

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

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

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

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

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

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

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

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

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

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

ואז היה יום עמוס בעבודה. ואחריו שבת. ואחריו עוד חופש של עוד רגע חג.

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

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

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

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

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

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

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

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

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

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

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

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

הביטוי Ajax הוא בכלל קיצור של Asynchronous JavaScript and XML. עכשיו אפשר לשאול, מה קשור XML? אנחנו ב 2024, אבל אני כותב את זה בשביל להזכיר איך דברים משתנים כל הזמן. ה Ajax קשור ל XML כי כשדפדפנים רק התחילו לפנות לשרתים אחרי שעמוד HTML נטען הם השתמשו בממשק שנקרא XMLHttpRequest, שבכלל היה חלק מחבילה של XML (אפילו שדרך הממשק הזה הם קיבלו את התשובה ב JSON). לימים כולם עברו להשתמש בממשק fetch שבכלל לא כולל את המילה XML בשביל לבנות את אותם מנגנונים.

עם גירסה 14 של next.js הקונספט של Ajax שוב משתנה. הפעם מספיק להפעיל await מתוך קוד טיפול באירוע כדי לשלוח הודעה לשרת, לקבל תשובה ולפענח אותה. שימו לב לקוד הבא בצד הלקוח:

async function handleInput(ev: FormEvent<HTMLInputElement>) {
  if (ev.target) {
    const input = ev.target as HTMLInputElement;
    const text = input.value;
    const options = await search(text);
    setOptions(options);
  }
} 

ולקוד שמתאים לו בצד השרת:

export async function search(what: string) {
  if (what.length < 3) {
    return []
  } else {
    return sentences.filter(s => s.toLowerCase().includes(what))
  }
}

יש פה כמה דברים מדהימים:

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

2. אין צורך לכתוב את הקריאה ל fetch. לא צריך לבנות RTK Query או React Query או שום דבר. הפרמטרים עוברים כמו העברת פרמטרים רגילה ב JavaScript.

האם זה העתיד? לאפליקציות מסוימות בהחלט כן. הבעיה היחידה שעדיין נשארה היא שאין ל next מנגנון טוב לעדכן React Server Components אחרי שינויים בשרת, מה שאומר שאנחנו עדיין צריכים לשמור Client Side State בהרבה אפליקציות. אני מקווה בעתיד הקרוב לראות גם את זה נפתר עם מנגנון Subscriptions אוטומטי ואז נוכל רשמית להיפרד מ Redux וחבריו.

נ.ב. רוצים לראות את הקוד הזה בפעולה? זה הלינק:

https://next-search-demo.vercel.app/

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

https://github.com/ynonp/next-search-demo

הפונקציה Object.keys מחזירה את כל המפתחות באובייקט נכון? לא בדיוק. זאת ההגדרה שלה ב MDN:

The Object.keys() static method returns an array of a given object's own enumerable string-keyed property names.

מילת המפתח כאן היא enumerable. היא גורמת ל Keys להחזיר רק את המפתחות שיחזרו מ for ... in, או ליתר דיוק רק את אלה מתוך for ... in שלא הגיעו מהפרוטוטייפ.

הפעלה רגילה עשויה לתת את ההרגשה שזה כל המפתחות:

const object1 = {
  a: 'somestring',
  b: 42,
  c: false,
};

console.log(Object.keys(object1));
// Expected output: Array ["a", "b", "c"]

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

const object1 = {
  a: 'somestring',
  b: 42,
  c: false,
};

Object.defineProperty(object1, 'secret', {
  value: 'secret',
  enumerable: false
})

console.log(Object.keys(object1));
console.log(object1.secret)

הפעם אנחנו עדיין מקבלים רק את המפתחות a, b ו c, למרות שההדפסה השנייה מצליחה ומדפיסה את המילה secret.

ואיך בכל זאת נקבל את כל רשימת המפתחות כולל אלה שאינם enumerable? ב JavaScript חשבו על הכל ויש פונקציה אחרת בשם getOwnPropertyNames שמחזירה את כל המפתחות. הקריאה הזו:

console.log(Object.getOwnPropertyNames(object1))

מדפיסה את:

Array ["a", "b", "c", "secret"]

בתיעוד של אמזון אנחנו מוצאים את הדוגמה הבאה לשימוש ב Polly ב Java:

new SynthesizeSpeechRequest()
    .withText(text)
    .withVoiceId(voice.getId())
    .withOutputFormat(format).withEngine("neural");

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

תבנית דומה לה נקראת Fluent Interface והיא מציעה שימוש בשרשור מתודות כדי לתאר פונקציונאליות או רצף פעולות. לדוגמה הקוד הבא מספריית jQuery:

$('#myButton')
  .click(function() {
    $(this).addClass('active');
  })
  .hover(
    function() {
      $(this).css('background-color', 'lightblue');
    },
    function() {
      $(this).css('background-color', '');
    }
  )
  .fadeOut(1000)
  .fadeIn(1000);

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

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

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

function tap(fn) {
  fn(this);

  return this;
};

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

class Polly
  attr_accessor :text, :engine
  def initialize
    @text = []
  end

  def with_text(text)
    @text.append(text)
    self
  end

  def with_engine(engine)
    @engine = engine
    self
  end

  def print
    puts "Engine: #{@engine}; Text: #{@text}"
  end
end

ועכשיו אני רוצה להפעיל את with_text בלולאה עם המחרוזות a, b ו c. אפשר כמובן להשתמש במשתנה ואז נקבל:

p = Polly.new
p.with_engine("engine")
['a', 'b', 'c'].each {|t| p.with_text(t) }
p.print

אבל אם רוצים לוותר על המשתנה אפשר להשתמש ב tap ואז נקבל:

Polly
    .new
    .with_engine("engine")
    .tap { |p| ['a', 'b', 'c'].reduce(p, &:with_text) }
    .print

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

def bounced
  mp = find_mp('bounced')
  if mp.present?
    mp.update(sent_status: :failed)
    mp.prospect.subscriptions.destroy_all
  end
  head :ok
end

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

אבל לי זה אכפת.

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

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

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

1. מאגר חבילות - דינו תומכים ב JSR, ב NPM ובטעינה של כל קובץ חבילה מ denoland. אבל deno add יודע לעבוד רק עם חבילות npm ו jsr, ואי אפשר לשנות את ברירת המחדל שלו. זה מתיש. אני מבין שהחלום שלהם הוא שכל החבילות יעבדו ב JSR אבל עד שזה יקרה צריכים לראות שאפשר לעבוד עם npm בצורה הרבה יותר חלקה.

2. באגים מוזרים בחבילות מ npm - הוספתם תמיכה ב npm וזה מעולה, אבל צריך גם לוודא שהקוד משם רץ או לפחות ליצור רשימה מסודרת של דברים שידוע שלא עובדים. בניסיון שלי להעביר קוד מאקספרס לדינו גיליתי לגמרי במקרה ש express.static לא עובד וגם cookie-session. איזה עוד? ואיך זה יתנהג על מערכות הפעלה שונות? אלה דברים שכל פרויקט פורטינג יצטרך לגלות לבד ואפילו לא בתחילת הפרויקט.

3. חסרות חבילות במיוחד דרייברים של בסיסי נתונים - הדרייבר של SQLite לא עובד על דינו ויש חבילה אחרת עם דרייבר אחר. על MSSql אין בכלל מה לדבר. קיטור שמצאתי ברדיט ומאוד התחברתי אליו אמר:

I'm spending wayyyy too much time on this. I really wish someone could plug up this one hole in the Deno libraries -- it's the only thing stopping me from getting my company to let me convert everything to Deno (which I desperately want to do).

1. גירסה 0.2 של החבילה הסטנדרטית - אני יודע יש שיגידו שאני נטפל לשטויות ומה זה מספר גירסה אבל אם עדיין לא הצלחתם להגיע לפחות לגירסה 1 של החבילה הסטנדרטית מה זה אומר? הרי דינו עצמו תכף מגיע לגירסה 2.

2. יש אפשרות לטעון מודולים מובנים ב node עם התחילית node:. רובם עובדים אבל גם כאן התאימות לא 100%. לפחות פה הם פירסמו טבלת תאימות.

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