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

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

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

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

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

https://www.tocode.co.il/bundles/pregit

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

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

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

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

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

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

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

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

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

בשביל להתקין את גירסת הפייתון נטולת ה GIL עם pyenv הפעלתי:

CONFIGURE_OPTS=--disable-gil PYENV_VERSION_SUFFIX='-free-threaded' pyenv install -f -v 3.13.0rc3t

וידאתי שאני מריץ את הגירסה הנכונה עם:

$ python --version
Python 3.13.0rc3

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

import sys
import math
import multiprocessing.dummy as mp

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

if __name__ == "__main__":
    print(f"GIL enabled = {sys._is_gil_enabled()}")
    with mp.Pool(4) as p:
        print(sum(p.map(is_prime, range(1_000_000))))

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

ynonp@Ynons-MacBook-Air ~/tmp $ time PYTHON_GIL=0 python gil.py
GIL enabled = False
78500
PYTHON_GIL=0 python gil.py  2.83s user 0.04s system 306% cpu 0.938 total
ynonp@Ynons-MacBook-Air ~/tmp $ time PYTHON_GIL=0 python gil.py
GIL enabled = False
78500
PYTHON_GIL=0 python gil.py  2.85s user 0.04s system 305% cpu 0.944 total
ynonp@Ynons-MacBook-Air ~/tmp $ time PYTHON_GIL=0 python gil.py
GIL enabled = False
78500
PYTHON_GIL=0 python gil.py  2.88s user 0.04s system 317% cpu 0.919 total
ynonp@Ynons-MacBook-Air ~/tmp $ time PYTHON_GIL=1 python gil.py
GIL enabled = True
78500
PYTHON_GIL=1 python gil.py  2.61s user 0.05s system 96% cpu 2.753 total
ynonp@Ynons-MacBook-Air ~/tmp $ time PYTHON_GIL=1 python gil.py
GIL enabled = True
78500
PYTHON_GIL=1 python gil.py  2.62s user 0.05s system 97% cpu 2.741 total
ynonp@Ynons-MacBook-Air ~/tmp $ time PYTHON_GIL=1 python gil.py
GIL enabled = True
78500
PYTHON_GIL=1 python gil.py  2.64s user 0.05s system 93% cpu 2.865 total

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

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

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

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

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

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

1. מורידים ומתקינים Ollama מהקישור https://ollama.com/download. וכן יש גם גירסה ללינוקס אז אפשר להפעיל את זה על שרת לכל מערכת ווב שנכתוב.

2. אחרי ההתקנה על מק התוכנה עלתה לבד והתחילה לענות על בקשות ב API. אם זה לא קורה אפשר להפעיל משורת הפקודה ollama serve.

3. איך יודעים שזה עובד? מפעילים:

curl http://localhost:11434/api/generate -d '{
  "model": "llama3.2",
  "prompt": "Why is the sky blue?",
  "stream": false}'

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

ollama run llama3.2

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

1. אם אתם מעדיפים GUI תוכלו להתקין את ollama-gui מהקישור https://github.com/HelgeSverre/ollama-gui. אחרי שכפול הריפו מפעילים npm install ואז npm run dev ומקבלים מסך צ'ט בדפדפן בדיוק כמו ChatGPT.

ההרצאה של DHH ב Rails World האחרון מעולה ומלאה בתובנות על עולם הפיתוח בכלל ופיתוח ווב בפרט. אחת התובנות שאני רוצה לקחת משם ולשתף היא המשפט Being competent is more fun.

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

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

1. דיפלוימנט הולך להתבצע דרך Dockerfile שיהיה חלק מהפרויקט ועל שרת שלך.

2. העדפה לעבודת Front End בלי שלב בנייה, כך שאפשר תמיד ללחוץ View Source ולראות את הקוד המקורי בדפדפן (בלי טייפסקריפט, בלי ריאקט ובלי מיניפיקציה).

3. שימוש בתבניות ו Generators כדי לאפשר כתיבה מהירה של קוד שיהיה באחריות המפתח.

4. כל הזמן חיפוש איך להשתמש בפחות - ריילס 8 כבר לא דורשת redis בשביל לנהל Cache, Jobs ו Web Sockets - כל אלה עברו לבסיס הנתונים.

אני רואה את המאמץ אבל חייב להודות שיש גם משהו לא מדויק בדברים במיוחד כשנזכרים ב Active Record ואיך כל תשתית ה ORM של ריילס מרחיקה אנשים מלימוד SQL ואיך אינסוף הפונקציות שהם הוסיפו לרובי גורמות למתכנתי ריילס להרגיש אבודים כשמנסים להפעיל פונקציה כמו second על מערך ומגלים שזו עוד המצאה של ריילס.

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

נ.ב. לינק להרצאה, לפחות החצי הראשון מומלץ גם למי שלא חי בעולם של ריילס: https://www.youtube.com/watch?v=-cEn_83zRFw

הג'ם הכי וותיק שאני זוכר בריילס נקרא Devise. לקראת הפוסט בדקתי כדי לוודא תאריכים והוא החל את דרכו ב 2009 ומאז מתקדם עם ריילס ומספק את הדרך הכי סטנדרטית שיש מחוץ לפריימוורק לניהול משתמשים. וכמו הרבה ספריות אחרות שפותרות בעיות גדולות, גם דיבייז יכול להיות מסובך וכולל חלקים נסתרים ולא מעט קסם. דברים פשוטים באמת אפשר לכתוב כמעט בלי קוד, אבל ככל שה Use Case נהיה יותר מורכב כך צריך יותר להתאמץ כדי להיכנס לקרביים ולשנות התנהגויות.

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

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

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

3. קונטרולר ומסכים לטיפול ב"שכחתי סיסמה".

ברירות המחדל שנבחרו מצוינות:

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

class ApplicationController < ActionController::Base
  include Authentication
  # Only allow modern browsers supporting webp images, web push, badges, import maps, CSS nesting, and CSS :has.
  allow_browser versions: :modern
end

השורה include Authentication מכניסה לכל קונטרולר את הבלוק:

included do
  before_action :require_authentication
  helper_method :authenticated?
end

הסיסמאות שמורות בתור bcrypt.

מסך החיבור מוגבל עם Rate Limit עם השורה:

  rate_limit to: 10, within: 3.minutes, only: :create, with: -> { redirect_to new_session_url, alert: "Try again later." }

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

1. אין תמיכה בייצור טוקנים ל API.

2. אין מסכים ליצירת משתמשים, או בכלל התיחסות ל flow של משתמש חדש (אולי אימות של כתובת מייל).

3. אין עריכת פרטי משתמש, שינוי כתובת מייל או שינוי סיסמה.

4. אין התיחסות לחיבור משתמש דרך שירותי צד שלישי.

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

ריאקט התחילה בתור ספרייה לשכבת הממשק בלבד (UI Library). בשנים הראשונות הצוות שעבד על ריאקט חיפש את הדרך הטובה ביותר לבנות ממשק שיאפשר למפתחים לכתוב קומפוננטות לשימוש חוזר. הם עברו שתי מהפכות גדולות - מאובייקטים לקלאסים ומקלאסים לפונקציות. אחרי המעבר לפונקציות החל שינוי כיוון בפיתוח ריאקט והצוות התחיל לחפש "תבניות" שאנשים כותבים בריאקט ולהכניס אותן לתוך הפריימוורק. תקופה ארוכה התעסקנו עם Concurrent Mode ועם היכולת לאפשר לקומפוננטות לעצור באמצע תהליך Rendering, ואחרי שזה בוצע היעד הבא שלהם היא לפתור את ה Data Fetching וזה הסיפור של ריאקט 19.

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

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

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

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

4. פונקציה חדשה בשם use (סוג של הוק) מאפשרת להשתמש ב Suspense לצורך Data Fetching ולבצע קריאה אסינכרונית מתוך קומפוננטה, בעצם סוג של לכתוב קומפוננטה אסינכרונית.

אין ספק שיש הרבה שיפורים מעבר לתמיכה המובנית ב Data Fetching - התמיכה ב Stylesheets מתוך קומפוננטה, התמיכה במאפיינים לכותרות המסמך ותיקוני API שקשורים ל ref ול useDeferredValue, ועדיין אני בטוח שהשינוי הבולט ביותר יהיה הפונקציה use. אז איפה הבעיה? כמו תמיד כשמפתחים API חדש יהיו בעיות, יהיו מקרי קצה מבלבלים, רוב האנשים ישתמשו בזה לא נכון ועוד שנתיים נגלה שחצי מהקוד שכתבנו לא מספיק יעיל או לא מטפל נכון באותם מקרי קצה. וכן זה בסדר לנסות לחדש, אבל הייתי שמח לראות את החידושים שקשורים ל Data Fetching תחומים לתוך ספריות כמו react query ולא גורמים לנו לארגן מחדש את הקוד וליצור "עוד דרך" לכתוב קומפוננטות ריאקט.