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

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

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

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

1. כשהיא באה מתוך היכרות מעמיקה עם הפרויקט והמגבלות שלו.

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

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

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

[pytest]
markers =
    integration: integration test
    slow: slow test
    version: tests to run before deploying a new version

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

@pytest.mark.integration
def test_website():
    pass

ולהריץ את כל הבדיקות שמסומנות בקטגוריה integration:

$ pytest -m integration

או להריץ את כל הדברים שלא מהקטגוריה עם:

$ pytest -m "not integration"

פייטסט גם כולל המון סימונים מובנים למשל הסימון skip שגורם לפייטסט לדלג על בדיקה, skipif שמקבל תנאי וגורם לדילוג על בדיקה רק אם התנאי מתקיים ו xfail שמסמן שבדיקה צריכה להיכשל (ולכן לא צריך להתרגש מכישלון).

אבל האתגר היותר משמעותי הוא לא איך להשתמש בפיצ'ר אלא מתי להשתמש בו - כלומר על איזה בדיקות כדאי לדלג ואיזה קטגוריות להגדיר, מתי להוסיף xfail ומתי skip ומתי בכלל עדיף למחוק את הבדיקה.

ננסה לענות על זה בכמה כללי אצבע-

1. רוב הפיצ'רים של בדיקות הם יותר טובים כשלא משתמשים בהם. זה נכון לגבי mock-ים, לגבי before ו after וכן גם לגבי דילוגים. אם אתם יכולים בלי זה עדיף.

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

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

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

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

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

1. לא בדקתי, אבל נראה לי שזה מה שהיה לוקח לי.

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

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

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

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

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

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

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

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

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

״למה הקונטיינר שלי לא נדלק?!״

״למה אין עדיין רווחים מהמערכת?!״

״למה הדף נטען כל כך לאט?!״

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

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

2. • או - לשלם למישהו שלמד כבר את עולם התוכן כדי שיעזור לנו לפתור את האתגר.

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

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

  @main
  def parens(): Unit =
    val result = if (Random.nextInt() > 0) {
      Try { throw new Exception("20") }
    } else {
      Try { throw new Exception("30") }
    }.recover { err => 30 }

    println(result)

והשאלה מה הערך של result?

בשביל לענות על זה נתחיל עם דוגמת קוד יותר פשוטה ונוריד את ה recover. עכשיו בלוק ה then ובלוק ה else שקולים:

  @main
  def parens(): Unit =
    val result = if (Random.nextInt() > 0) {
      Try { throw new Exception("20") }
    } else {
      Try { throw new Exception("30") }
    }

ו result יהיה שווה לאוביקט Failure שה Exception שלו תלויה בתוצאה של החישוב האקראי. פקודת recover בסקאלה שמופעלת על אוביקט Try משנה אותו מ Failure ל Success עם הערך שמופיע ב recover. הדוגמה הבאה לכן גם צפויה:

  @main
  def parens(): Unit =
    val result = if (Random.nextInt() > 0) {
      Try { throw new Exception("20") }
    } else {
      Try { throw new Exception("30") }
    }

    println(result.recover { err => 30 })

בגלל שלא משנה מה הוגרל result החזיק בכל מקרה Failure, אז הפעלת recover תשנה את הערך ל Success של 30 וזה מה שיודפס:

Success(30)

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

    val result = if (Random.nextInt() > 0)
                    Try { throw new Exception("20") }
                 else Try { throw new Exception("30")

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

val result = if (Random.nextInt() > 0)
                Try { throw new Exception("20") }
                else
                Try { throw new Exception("30") }.recover { _ => 30 }

עכשיו זה ברור - ה recover השפיע רק על בלוק ה else ולא על כל ה if. הקוד החזיר Success כשהמספר האקראי היה 0 או שלילי, ובמספרים חיוביים החזיר Failure. כשמבינים איך זה עובד קל גם לתקן:

  @main
  def parens(): Unit =
    val result = (if (Random.nextInt() > 0) {
      Try { throw new Exception("20") }
    } else {
      Try { throw new Exception("30") }
    }).recover { _ => 30 }

    println(result.recover { err => 30 })

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

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

פונקציה שמטפלת בלחיצה על כפתור מקבלת את הפרמטרים הבאים: flags, game, peer, msg_id, data, password, ולכן הדבר שנראה לי הכי הגיוני כשניגשתי לממש את זה פעם ראשונה היה לשים את המידע החשוב בשדה data של הכפתור, ואז לקבל את המידע הזה בטיפול בלחיצה. בדוגמה של הלייק נשים את ה URL של הפוסט בתור data, נקבל אותו בפונקציה שתטפל בלחיצה כל הכפתור והכל טוב.

(ואז גיליתי)

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

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

1. אפשר להישאר עם המבנה של שמירת URL-ים בכפתורים, אבל פשוט לעבור דרך שירות קיצור URL-ים כדי לוודא שכולם קצרים יותר מ 64 תווים.

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

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

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

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

הכותב הוא Oragbakosi Valentine, בשלוש השנים האחרונות הוא עובד כמפתח תוכנה בגיטסטארט ולפני כן עבד בGoSquare.

גיטסטארט היא פלטפורמת Code as a Service שהופכת את מה יש לכם בבקלוג (backlog) לקוד באיכות גבוהה ובו זמנית מטפחת קהילה הולכת וגדלה של מפתחים ברחבי העולם. בתחילת השנה השיקה גיטסטארט את פעילותה בישראל והחלה לתמוך בצוותי פיתוח מקומיים.

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

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

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

הגישה המקבילית השניה היתה הספריה parallel-collections שמציעה מימוש של map מקבילי.

וכן נצטרך לעשות פוסט המשך עם cats-effect.

טוב קוד? יאללה. זאת התוכנית:

import scala.concurrent.{Await, ExecutionContext, Future}
import scala.util.Random
import concurrent.ExecutionContext.Implicits.global
import scala.concurrent.duration.Duration
import java.net.{URI, URL}
import java.util.concurrent.{CompletableFuture, Executors}
import scala.language.implicitConversions
import scala.util.chaining._
import scala.collection.parallel.CollectionConverters._


object futures {

  private def isPrime(n: Int): Boolean =
    2.to(Math.sqrt(n.toDouble).toInt).forall(n % _ != 0)

  @main
  def virtualThreadsDemo(): Unit =
    val s0 = System.nanoTime()
    1.to(10000000)
      .map(n => Future { isPrime(n) })
      .map(Await.result(_, Duration.Inf))
      .count(identity)
      .pipe(println)

    val s1 = System.nanoTime()

    1.to(10000000)
      .map(isPrime)
      .count(identity)
      .pipe(println)

    val s2 = System.nanoTime()

    1.to(10000000)
      .par
      .map(isPrime)
      .count(identity)
      .pipe(println)

    val s3 = System.nanoTime()

    println(s"1 thread = ${s2 - s1}")
    println(s"* thread = ${s1 - s0}")
    println(s"pmap     = ${s3 - s2}")
}

וכן בשביל המשחק כתבתי אותה גם בפייתון כדי שנוכל להשוות זמנים:

import time
import multiprocessing
import math

def isprime(n):
    for i in range(2, int(math.sqrt(n)) + 1):
        if n % i == 0:
            return False
    return True

if __name__ == "__main__":
    pool = multiprocessing.Pool(5)

    s0 = time.time_ns()
    print(sum(pool.map(isprime, range(10_000_000))))
    s1 = time.time_ns()
    print(s1 - s0)

והתוצאות לפחות אצלי על המחשב:

1 thread = 2025199791
* thread = 3463589500
pmap     = 674844834
python   = 14593734000

לא סיפרתי קודם אבל ניסיתי גם להחליף את ה Executor שמריץ את ה Threads לכזה שמשתמש ב Virtual Threads של Java אבל התוצאות לא עשו חשק לדבר על זה אז קברתי את הניסוי.

מה למדתי?

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

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

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

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

רק כשנבין את זה נוכל לראות למה מתכנתים מסיימים משימות מהר יותר עם קופיילוט. כבר התרגלנו להסתכל על קוד קיים בתור נטל, ולחלום על פרויקטי Green Fields, והנה מגיע ה AI ומתחיל תמיד מאפס, ומראה לנו שאין שום בעיה להרים מאפס דף נחיתה בלי לקחת את ה CSS-ים של הפרויקט (כי הוא כבר יעצב ויכתוב CSS), או להוסיף עוד שליפה מבסיס הנתונים בלי להשתמש באבסטרקציות שכבר קיימות בקוד, כי הן לא בדיוק מתאימות ל Use Case הנוכחי.

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

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

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