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

טיפים קצרים וחדשות למתכנתים

איך להגיע למידע הנכון בחמישה צעדים

10/02/2025

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

המשך קריאה

ניסוי localstack: הקמת תור ופונקציה לטיפול בהודעות

09/02/2025

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

המשך קריאה

שתי שאלות קשות

08/02/2025

שאלה ראשונה - האם אתם היום מפתחים טובים יותר ממה שהייתם לפני שנה? בזכות מה?

שאלה שניה - מה אתם עושים היום לענות "כן" על השאלה הראשונה בשנה הבאה.

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

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

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

מתי כדאי לעשות Rewrite

07/02/2025

לזרוק ולכתוב מחדש את כל המערכת?! השתגעת? כן יש לנו בעיות אבל בטח המצב לא כזה חמור... נכון?

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

  1. כשאין משתמשים - הכי קל, אף אחד לא יתגעגע למוצר.

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

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

  4. כשיצאה טכנולוגיה חדשה ומהפכנית שמאפשרת לבנות מוצר שפותר את אותה בעיה בצורה טובה בהרבה (היוש Chat GPT).

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

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

תזרוק עליו נעליים

06/02/2025

כבני אדם אנחנו אוהבים לפתור בעיות, וכמו Chat GPT גם אצלנו כשלא מבינים את הבעיה מתחילים להמציא:

  1. נסה למחוק את ה node_modules ולהתקין מחדש.

  2. תעשה ריסטרט לשרת.

  3. תחזור לגירסה ישנה של הפרויקט.

  4. תשדרג את התלויות.

  5. תוציא מהחשמל, ספור עד 10 ותחזיר חזרה.

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

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

נ.ב. לזרוק נעליים על השרת = לזרוק פרומפטים ל AI

פיתרון Advent Of Code 2024 יום 4 בשפת Ruby

05/02/2025

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

..X...
.SAMX.
.A..A.
XMAS.S
.X....

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

M.S
.A.
M.S

וגם הם יכולים להיות הפוכים.

התרגיל המקורי נמצא בעמוד שלהם כאן: https://adventofcode.com/2024/day/4

המשך קריאה

היום למדתי: הסיפור עם bcrypt ו 72 בתים

04/02/2025

לא ברור איך העברתי חיים שלמים בלי לשים לב למגבלה הזאת, אבל עכשיו שגיליתי אותה אני משתף כאן כדי שאתם לא תיפלו באותו בור. לכוכב בסיפור של היום קוראים bcrypt והוא אלגוריתם Password Hashing ישן שעדיין נמצא בשימוש נרחב בהרבה מערכות. בין השאר ספריית Devise שהיא הספריה הפופולרית לניהול משתמשים ב Rails משתמשת בו.

בגדול bcrypt נחשב עדיין מאובטח למרות גילו המבוגר, אבל יש לו מגבלה מתועדת (ומסתבר שמאוד מפורסמת) - הוא לא יודע לערבל סיסמאות ארוכות יותר מ 72 בתים. מה זה אומר? הנה בקוד ריילס:

> u = User.new(name: 'a', email: 'ynon@gmail.com', password: '0' * 80 + '1')
> u.valid_password?('0' * 80 + '2')
 => true

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

לקחים? אם אפשר השתמשו ב Aragon2 במקום ב bcrypt, ובכל מקרה כשאתם בוחרים סיסמה לאתר שימו לב לא להתחיל את הסיסמה ב 72 תווים שקל לנחש ורק אז לשים את הסיסמה האמיתית. מי יודע אם הם לא משתמשים בטעות ב bcrypt וחותכים את מה שבא אחרי ה 72.

נ.ב. הפוסט הזה בנושא סופר מעניין וסוקר את המימוש של bcrypt בעוד שפות תכנות בדגש על איזה ספריות יסרבו לעבוד עם קלט שאורכו מעל 72 בתים לעומת איזה ספריות פשוט ימחקו את החלק שאחרי 72 כדי שבכל זאת דברים יעבדו: https://n0rdy.foo/posts/20250121/okta-bcrypt-lessons-for-better-apis/

טיפ פייתון: מחיקת שורה ראשונה מטקסט עם StringIO

03/02/2025

הפונקציה הבאה מקבלת מחרוזת טקסט ומחזירה את הטקסט בלי השורה הראשונה:

def remove_first_line(text):
    return '\n'.join(text.splitlines()[1:])

אבל אם בטעות נעביר ל None היא תזרוק Exception. בנוסף חיבור המחרוזות עם \n עלול להיות מבלבל כי מי שיגיע לקרוא את הקוד עלול לתהות מה קורה ב Windows שם תו סוף השורה הוא שונה. לפעמים זה רעיון טוב לעצור את התוכנית אם מקבלים None, אבל לפעמים אנחנו רוצים לבנות משהו יותר גמיש. דרך נוספת למחוק את השורה הראשונה היא הקלאס StringIO מתוך המחלקה io. הנה גירסה שנייה של אותה פונקציה:

def remove_first_line(text: str):
    f = StringIO(text)
    f.readline()
    return f.read()

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

לספר מה בנינו או לדעת מה נבנה?

02/02/2025

מה עדיף, לכתוב את הבדיקות לפני או אחרי הקוד? ואת דף הפרויקט בגיאהב? ואת התיעוד? והמדריך למשתמש?

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

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

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

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

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

צעדים ראשונים עם localstack

01/02/2025

לוקאל סטאק https://github.com/localstack/localstack הוא פרויקט שמטרתו הפעלת גירסה מקומית של AWS אצלכם על המחשב בתוך קונטיינר. הם מכסים עשרות סרביסים של AWS בחשבון החינמי, ויש גם חשבון בתשלום שכולל יותר יכולות לחלק מהסרביסים ויותר סרביסים. מה שאהבתי במיוחד בעבודה עם local stack זה שהקוד לא צריך להשתנות - הממשק שלהם זהה לממשק של AWS מלבד פקודת קונפיגורציה אחת שמגדירה את ה endpoint שלהם במקום של AWS.

בואו נראה איך להתקין ולעבוד עם סרביס S3 של לוקאל סטאק דרך שלושה סקריפטים.

המשך קריאה