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

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

זאת היתה השאילתה שלוקחת מילים ויוצרת כרטיסיה או מחזירה את הכרטיסיה הקיימת:

g
  .V()
  .has(VertexLabels.Card, Properties.IndexedLabel, VertexLabels.Card)
  .where(__.and(
    __.out(EdgeLabels.Front).hasId(front.entityId),
    __.out(EdgeLabels.Back).hasId(back.entityId)))
  .fold()
  .coalesce(
    __.unfold(),
    __.addV(VertexLabels.Card)
      .as("card")
      .addTimestampsProperties()
      .property(Properties.IndexedLabel, VertexLabels.Card)
      .asCard()
      .addE(EdgeLabels.Front).to(__.V(front.entityId))
      .select("card")
      .addE(EdgeLabels.Back).to(__.V(back.entityId))
      .select("card"))
  .id()
  .next()

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

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

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

    val id = g
      .V(front.entityId)
      .coalesce(
        __.in(EdgeLabels.Front).where(__.out(EdgeLabels.Back).hasId(back.entityId)),
        __.addV(VertexLabels.Card)
          .as("card")
          .addTimestampsProperties()
          .property(Properties.IndexedLabel, VertexLabels.Card)
          .asCard()
          .addE(EdgeLabels.Front).to(__.V(front.entityId))
          .select("card")
          .addE(EdgeLabels.Back).to(__.V(back.entityId))
          .select("card")
      ).id()
      .next()

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

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

import { readLines } from "https://deno.land/std@0.221.0/io/read_lines.ts";
import * as path from "https://deno.land/std@0.221.0/path/mod.ts";

const filename = path.join(Deno.cwd(), "std/io/README.md");
let fileReader = await Deno.open(filename);

for await (let line of readLines(fileReader)) {
  console.log(line);
}

מה שחשוב זה הלולאה בסוף שקוראת קובץ שורה אחר שורה ומאפשרת לטפל בכל שורה בנפרד.

המודול מגיע היום עם אזהרת Deprecation. בשביל תאימות לתקן של Web Streams API החברים בדינו החליטו לוותר עליו ולהמליץ לעבוד עם Web Streams, שכרגע לא כולל את הפונקציונאליות הזאת.

ועכשיו השאלה - האם לשתף פעולה עם הקידמה ולכתוב לבד מנגנון שובר שורות, להישאר עם המנגנון ה Deprecated או בכלל להשתמש במודול readline של node, שגם נטען בקלות מתוכנית דינו?

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

נ.ב. ככה זה נראה כשקוראים קובץ שורה אחרי שורה עם ה Web Streams API:

const file = await Deno.open("a.js", { read: true });
const readableStream = file.readable.pipeThrough(new TextDecoderStream()).pipeThrough(new TransformStream({
  transform: (chunk, controller) => {
    const lines = chunk.split("\n");
    for (const line of lines) {
      if (line) {
        controller.enqueue(line);
      }
    }
  },
}));

for await (const line of readableStream) {
  console.log(`> ${line}`);
}

וזאת הגירסה עם readline של node:

import readline from 'node:readline';
import fs from 'node:fs';

const myName = "a.js";

const rl = readline.createInterface({
  input: fs.createReadStream(myName),
})

let index = 0;
rl.on('line', (line) => {
  index += 1;
  console.log(`${String(index).padStart(2, '0')} ${line}`);
});

מה דעתכם? איזה גירסה הייתם בוחרים? ולמה?

נו-של הוא סוג חדש של Shell, הוא כתוב ב rust ומביא את הגישה של Powershell - לפיה כל דבר הוא data - גם ליוניקס. בואו נכתוב שלושה סקריפטים ראשונים ב nushell כדי ללמוד איך זה עובד ולחשוב אם הוא מתאים.

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

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

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

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

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

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

def random_weighted_item(items):
    items = sorted(items, key=lambda x: x.weight)
    min_weight = min(i.weight for i in items)
    max_weight = max(i.weight for i in items)
    normalized_weights = [(i.weight - min_weight) / (max_weight - min_weight) for i in items]
    cumulative_sum = list(accumulate(normalized_weights))
    randomized_weight = random.random() * cumulative_sum[-1]
    index = next(i for i, e in enumerate(cumulative_sum) if e > randomized_weight)
    return items[index]

אפשר להוסיף לזה בקלות Type Hints בעזרת Type Var וזה יראה כך:

class HasWeight(Protocol):
    weight: int

T = TypeVar("T", bound=HasWeight)

def random_weighted_item(items: list[T]) -> T:
    ...

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

def random_weighted_item(items: list[T], weight: Callable[[T], int]) -> T:
    ...

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

def random_weighted_item(items: list[T], weight: Callable[[T], int] = lambda i: i.weight) -> T:

הודעת השגיאה היא:

weighted_random_demo.py:44: error: "T" has no attribute "weight"  [attr-defined]
Found 1 error in 1 file (checked 1 source file)

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

1. לבחור חתימה שעובדת יותר טוב עם ה Type Hints (למשל כמו choices שמקבלת רשימה של פריטים ורשימה של משקלים)

2. לוותר על ה Type Hints ולהתעקש על החתימה שבחרנו.

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

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

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

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

מה ש scope עושה זה נותן לנו להגדיר כללי CSS שמשפיעים רק על אזור מסוים. כלומר אם יש לנו את ה HTML הזה (מתוך הדוגמה ב MDN):

<div class="light-scheme">
  <p>
    MDN contains lots of information about
    <a href="/en-US/docs/Web/HTML">HTML</a>,
    <a href="/en-US/docs/Web/CSS">CSS</a>, and
    <a href="/en-US/docs/Web/JavaScript">JavaScript</a>.
  </p>
</div>

<div class="dark-scheme">
  <p>
    MDN contains lots of information about
    <a href="/en-US/docs/Web/HTML">HTML</a>,
    <a href="/en-US/docs/Web/CSS">CSS</a>, and
    <a href="/en-US/docs/Web/JavaScript">JavaScript</a>.
  </p>
</div>

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

.light-scheme {
  background-color: plum;
}

.light-scheme a {
  color: darkmagenta;
}

.dark-scheme {
    background-color: darkmagenta;
    color: antiquewhite;
}

.dark-scheme a {
  color: plum;
}

די הרבה זמן אני כבר יכול להשתמש ב CSS כזה:

.light-scheme {
  background-color: plum;
  a {
    color: darkmagenta;
  }
}


.dark-scheme {
  background-color: darkmagenta;
  color: antiquewhite;

  a {
    color: plum;
  }
}

ולאחרונה אני יכול להשתמש גם בכתיב הזה כדי להגיע לאותה תוצאה:

@scope (.light-scheme) {
  :scope {
    background-color: plum;
  }

  a {
    color: darkmagenta;
  }
}

@scope (.dark-scheme) {
  :scope {
    background-color: darkmagenta;
    color: antiquewhite;
  }

  a {
    color: plum;
  }
}

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

.light-scheme a {
  color: yellow;
}

@scope (.light-scheme) {
  :scope {
    background-color: plum;
  }

  a {
    color: darkmagenta;
  }
}

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

div {
  padding: 10px;
}

.light-scheme a {
  color: yellow;
}

.light-scheme {
  background-color: plum;

  a {
    color: darkmagenta;
  }
}

ייתן ללינקים שבתוך ה light-scheme את הצבע darkmagenta בגלל שהסלקטור שלו יותר ספציפי.

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

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

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

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