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

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

טיפ פייתון: המרה לבוליאנים

09/03/2025

הקוד הזה עובד יפה בפייתון:

import re

if re.search('a', 'hello'):
    print("a found in hello")
else:
    print("a not found in hello")

אבל זה לא כל כך:

if 'hello'.find('a'):
    print("found a")
else:
    print("a not found")

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

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

  2. אם אין __bool__ אבל יש __len__, פייתון יפעיל את __len__ ויבדוק אם התוצאה אינה אפס.

  3. אם אין __bool__ ואין __len__ מחזירים True.

הנה כמה ניסויים:

>>> None.__bool__()
False
>>> (-1).__bool__()
True

מה עם דוגמת הביטוי הרגולארי?

>>> re.search('a', 'hallo')
<re.Match object; span=(1, 2), match='a'>
>>> re.search('a', 'hallo').__bool__()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 're.Match' object has no attribute '__bool__'. Did you mean: '__copy__'?
>>> re.search('a', 'hallo').__len__()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 're.Match' object has no attribute '__len__'. Did you mean: '__le__'?

לביטוי רגולארי אין __bool__ ואין __len__ לכן הוא מחזיר True. והנה ניסוי עם קלאסים שלי:

class Foo:
    def __bool__(self):
        return False

class Bar:
    pass

f = Foo()
if f:
    print("Foo 1")
else:
    print("Foo 2")

b = Bar()
if b:
    print("Bar 1")
else:
    print("Bar 2")

הפלט כצפוי Foo 2 ו Bar 1.

חגורות בטיחות מול כריות אוויר

08/03/2025

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

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

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

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

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

למה אנחנו לא מצליחים ללמוד תוך כדי עבודה

07/03/2025

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

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

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

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

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

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

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

אינפלציה של סוכני AI. או בעצם ...

05/03/2025

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

עם AI לכאורה אין לנו את הבעיה הזאת. בזריקה מהירה מהראש כשיש לי בעיה היום אני יכול להתייעץ עם Claude, grok, gemini, ChatGPT, perplexity, Copilot, DeepSeek וזה לפני שמחפשים סוכני AI מותאמים אישית לבעיות. כל AI מיוצר על ידי חברה אחרת, מאומן בדרך שונה ועל מידע שונה, ולכן אמור לתת תוצאות שונות לשאלות.

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

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

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

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

היכרות עם Drizzle

04/03/2025
SQL

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

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

המשך קריאה

בניתי לבד משהו טוב יותר

03/03/2025

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

האם זה אומר שגם לי כדאי לבנות לבד את התשתית? פה התשובה קצת יותר מורכבת:

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

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

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

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

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

תשובות ל-3 התנגדויות ל next

02/03/2025

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

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

  2. ריאקט = פגיעה בביצועים.

  3. למרות התמיכה ב SSR, הפריימוורקים לא כוללים (או כוללות? פריימוורק זה זכר או נקבה?) את הכלים הבסיסיים לכתיבת קוד צד שרת למערכות אמיתיות.

שלושת ההתנגדויות מבוססות ויש בהן יותר משמץ של אמת, ובכל זאת אני רוצה לחדד ולהוסיף:

  1. נכון, נקסט ו React Router מפותחים על ידי חברות שונות, אבל ריאקט עצמה היא פרויקט קוד פתוח. בעמוד פגוש את הצוות אנחנו פוגשים את מפתחי הליבה של ריאקט. מתוך 21 מפתחי ליבה ברשימה 5 עובדים ב Vercel, עוד 2 עצמאיים ו 14 עובדי פייסבוק. זה אומר שהקשר בין נקסט לריאקט הוא די מבוסס.

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

  3. נקסט הוא בסך הכל node.js. האם היו צריכים להוסיף ORM? ספריה לביצוע משימות ברקע? מערכת לוגים טובה יותר? אולי. אבל Node זה לא רובי ולא אותה אקוסיסטם. בעולם של JavaScript אנשים מעדיפים להרכיב הרבה ספריות קטנות וכל פרויקט הוא שונה, בעוד שבעולם של רובי סינטרה או הנמי לא הצליחו להתרומם ואנשים מעדיפים את הפריימוורק הגדול שפותר את כל הבעיות. זה לא שלא היו ניסיונות אבל איכשהו הם לא היו מספיק מוצלחים או מתוחזקים לאורך זמן. נכון אין לנו פיתרון מובנה מהקופסה לכל הבעיות אבל כל עוד אפשר למצוא שילוב טוב של ספריות או לפתח Serverless על מערכת ענן זה כנראה לא כל כך נורא.

למה בכל זאת צריך לזכור לפני שנכנסים לפרויקט next / react? הבעיה הכי גדולה שלהם היום היא ה Learning Curve, וזה לצערי רק מחמיר. ריאקט נראה פשוט במבט ראשון בגלל שהוא בכל מקום אבל כתיבה נכונה ומסודרת שלו היא עדיין מבלבלת והרבה מפתחי ריאקט מתיחסים לחלקים גדולים מהפריימוורק כמו קסם. אתגר נוסף הוא השינויים התכופים בסגנון העבודה, מה שמייצר צורך לשכתב קוד קיים רק בשביל שהמערכת לא תרגיש מיושנת ושיהיה קל יותר להשתלב באקוסיסטם. רק בשנים שאני עובד בריאקט עברתי מכתיב האוביקטים לכתיב הקלאסים, מכתיב הקלאסים לכתיב ה Hooks ועכשיו עדיין בעולם ה Hooks אנחנו רואים מעבר מעולם של אפליקציות צד-לקוח לאפליקציות Full Stack. כל שינוי כזה הוא רעידת אדמה וזה קשה במערכות גדולות להתבסס על פריימוורק שמשתנה בצורה כל כך דרסטית כל כך מהר.

ניסוי Next - טעינת מידע אחרי עליית העמוד עם use

01/03/2025

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

המשך קריאה

איך להשתמש ב Next.JS בתור Client Side Router

28/02/2025

בונים אפליקציית Client Side בלבד ב React? תשמחו לשמוע שאתם יכולים לעשות את זה עם next.js גם בלי להשתמש בשרת שלהם, ולבנות את האפליקציה בדיוק כמו שבונים אפליקציית vite רגילה. יותר מזה, עם next אתם כבר מקבלים Router צד לקוח ויכולת לשדרג בעתיד לאפליקציית נקסט הכוללת גם שרת. בואו נראה איך זה עובד.

המשך קריאה