תומרקוד

לפני כמה חודשים, בערך ביום ש OpenClaw יצא, ניסיתי לשחק איתו. הרעיון תפס אותי: עוזר אישי שאני יכול לכתוב לו בווטסאפ, והוא באמת יכול לעבוד בשבילי. לא רק לענות על שאלות, אלא גם לבדוק קוד, לקרוא logs, להריץ פקודות, לכתוב סיכומים, להזכיר לי דברים, ולעדכן את ההתנהגות שלו כשאני מבקש. אבל בפועל זה הרגיש לי לא יציב. זה נתקע, קרס, ולא נתן לי מספיק ביטחון בשביל לחבר לזה דברים אישיים. אז נטשתי את זה. בשבוע האחרון חזרתי קצת לשחק עם עוזרי AI. ניסיתי שוב את OpenClaw. ניסיתי גם את Hermes. בשניהם לא קיבלתי את החוויה שדמיינתי. בסוף החוויה הכי חלקה הייתה עם NanoClaw. ה setup שבסוף עבד לי הוא NanoClaw + WhatsApp + Codex. בפוסט הזה אסביר איך הייתי מקים את זה היום. למה דווקא NanoClaw האתר של הפרויקט: https://nanoclaw.dev הקוד בגיטהאב: https://github.com/nanocoai/nanoclaw מה ששכנע אותי לנסות אותו הוא לא רשימת פיצ׳רים ארוכה, אלא הכיוון: פחות מערכת ענקית עם מיליון קונפיגורציות, ויותר משהו קטן יחסית שאפשר להבין, להריץ, ולשנות עם coding agent. יש פה גם סיפור ישראלי נחמד. מאחורי NanoClaw עומד גבריא...

כשעובדים עם Claude Code או Codex לאורך זמן, כמעט תמיד מגיע רגע שבו צריך התערבות ידנית. אישור להריץ פקודה, שאלה על שינוי קוד, או החלטה קטנה שחוסמת את ההתקדמות. הבעיה היא שזה קורה דווקא כשאני לא ליד המחשב. רציתי פתרון שיאפשר לי להמשיך סשנים קיימים מהטלפון, בלי לפתוח פורטים לאינטרנט, בלי חיבורים מסוכנים, ובלי לשנות את צורת העבודה הרגילה שלי. אחרי ניסוי וטעייה, הסטאפ שעובד לי בצורה יציבה משלב שלושה כלים: Tailscale ליצירת רשת פרטית בין המחשב לטלפון tmux בשביל סשנים ארוכים ומתמשכים בטרמינל Termius לחיבור SSH נוח מהטלפון הפתרון בקצרה הרעיון פשוט. לא צריך לאפשר גישה מהאינטרנט. צריך לאפשר גישה רק לעצמך. הארכיטקטורה נראית כך: טלפון │ │ Termius │ Tailscale ▼ רשת פרטית מוצפנת ▼ מחשב │ │ SSH │ tmux ▼ Claude Code / Codex כל התקשורת מתבצעת בתוך רשת פנימית מוצפנת. המחשב לא חשוף לאינטרנט הציבורי בכלל. הערת סקיוריטי אני לא נכנס כאן לעומק של אבטחה או מודל איומים. כל אחד צריך לעשות את המחקר שלו ולהחליט אם הסטאפ הזה מתאים לו. למי שרוצה לקרוא לעומק: https://tailscale.com/security-policies...

להתחיל מקום חדש כמעט תמיד מלווה בהתרגשות ולחץ. מצד אחד אתה רוצה להוכיח את עצמך, מצד שני אתה לא בטוח עד הסוף מה מצופה ממך ואיך נראה שבוע או ספרינט “טוב” בעיני מי שמנהל אותך. ב־11 השנים האחרונות התחלתי תפקיד בצוות חדש חמש פעמים (כולל שני מעברים בתוך אותה חברה), אבל מה שבאמת עזר לי להבין את התמונה היה דווקא כשנהייתי ״באדי״ – וליוויתי מעל 25 אנשים חדשים בכניסה שלהם לצוות שבו עבדתי. במקומות מסוימים תפקיד ה־״באדי״ מתמקד ביום הראשון – לקלוט את העובד, לוודא שיש לו סביבת עבודה, הרשאות, כיסא ושולחן. אבל במקרה שלי (ושל המנהלים שעבדתי איתם) זה תמיד הלך רחוק יותר: לנסות לייצר התחלה חלקה לא רק לוגיסטית, אלא גם מקצועית. להבין מה היכולות של מי שעומד מולי, מה הוא אוהב יותר ומה פחות, ולנסות להתאים לו – יחד עם ראש הצוות – את המשימות שיכולות לתת לו גם אימפקט וגם ביטחון עצמי. הפוסט הזה עוסק בכמה דברים (אולי קצת פחות טריוויאליים לחלק) שאני זיהיתי שיכולים לעזור מאוד בכניסה לצוות חדש – ואולי גם לעובדים ותיקים שרוצים להתחיל “פרק חדש” באותו מקום. תיאום ציפיות אמיתי פעמים רבות, במיוחד בהתחלה, יש פער בין...

מה לי ולזה כשנכנסתי לצבא הגעתי כמעט בלי ניסיון למסלול שכולם בו כבר עשו הרבה מאוד דברים כבני נוער – חלקם עם תואר שעשו בתיכון, חלקם מתכניות סייבר יוקרתיות. אחרי כשנתיים הציעו לי לנהל אנשים פי שניים ממני בגיל, ולעלות לדיונים עם בכירים – וגם שם אמרתי לעצמי: מה לי ולזה? איך אני יכול לנהל מישהו עם 15 שנות ניסיון? אחרי זה, לקראת השחרור, התקבלתי להרצות בכנס Appium העולמי בהודו ודיברתי על מתי לא להשתמש בכלי שהכנס היה עליו – מול היוצרים של Selenium ו-Appium. הייתי בטוח שאני עושה פדיחות מטורפות. אחר כך הגעתי לסטארטאפ ושאלתי את עצמי איך אני אצדיק את המשכורת שקיבלתי (שהייתה די מוגזמת לתקופה). משם למיקרוסופט - המגרש של הגדולים. בכל שיחה אמרתי לעצמי "וואו, הפערים ביני לבינם עצומים. איך אי פעם אגיע לרמה הזו?" גם שם, עברו כמה חודשים, המשימות נעשו ברורות יותר, והיום אני אולי בעמדה טובה, אבל גם עכשיו כשאני עומד מול שינוי או משימה חדשה, תסמונת המתחזה תוקפת חזק. הפחד הוא אותו פחד ישן: "מה אם יגלו?" מה אם יגלו שאני לא מתכנת מספיק טוב, שאני לא מכיר לעומק את המוצר, שאני לא ברמה שכולם ...

בכל כמה שנים יש “רעידת אדמה” בעולם ההיי-טק. פעם זה היה ה־Cloud, אחר כך Docker ו-Kubernetes, אחר כך המעבר למיקרו-סרוויסים. היום זה ה-AI. פתאום בכל שיחה שומעים על Copilot, על Agents, על LLMs. כולם מדברים על איך זה ישנה את הדרך שבה אנחנו כותבים קוד, מתכננים מוצרים, ואפילו חושבים על העבודה שלנו. בשנה האחרונה במיקרוסופט שמים דגש גדול על AI — בהטמעת כלים, בשילוב רכיבי AI בקוד שלנו, וגם בשימוש יומיומי בפרודוקטיביות כמו כתיבת דוקומנטציה ובדיקות. ובכל פעם שאני שומע על עוד גל פיטורים "בשם ההתייעלות והעברת אחריות ל-AI" — אני עוצר לחשוב: האם הנתיב שאני הולך בו הוא הנתיב הנכון לעתיד הזה? כי מצד אחד, אני סיניור במוצר עם אלפי לקוחות, עם עבודה שוטפת אינסופית — תיקוני באגים, שיחות עם לקוחות, תכנון פיצ'רים וגרסאות. ומצד שני, יש עולם שרץ מסביבי במהירות מטורפת, ואני לא רוצה למצוא את עצמי "לא רלוונטי" עוד כמה שנים. אף אחד לא יודע באמת איך השוק ייראה, אבל הפוסט הזה מסכם את המחשבות והמסקנות שלי — ומה אני באופן אישי בוחר לעשות כדי להישאר רלוונטי. להיות Early adopter - אבל לא...

     כשאנחנו מתחילים לגעת בשפות תכנות, פעמים רבות אנחנו מנסים לחקות את מה שאנחנו כבר יודעים ומכירים משפות קודמות בשפה אחרת. זו אמנם יכולה להיות דרך להכנס לכתיבת קוד מהר יותר, אבל כשנוקטים בגישה הזו עלולים לפספס יכולות ייחודיות לשפה שנותנות דרכים הרבה יותר יעילות ועוצמתיות לפתור בעיות. בכל שפת תכנות יש מבני נתונים בסיסיים שמאפשרים ייצוג של אפשרויות שונות, ובמקרים רבים כשנרצה להשתמש בכאלה נפנה ל enums. באצמצעות enums נוכל לייצג אוסף מוגדר של ערכים, אבל ב-Rust יש להם יכולות מתקדמות שמקנות להם גמישות ועוצמה המקדימות בהרבה את מה שמוכר לנו משפות אחרות.  הפוסט הזה ידבר על למה enums ב-Rust כל כך ייחודיים ואיך ניתן להשתמש בהם לפולימורפיזם בצורה שלא אפשרית ברוב השפות. Enums בראסט ברוב השפות, enums מייצגים אוסף קבוע וסגור של ערכים שניתן לבחור מתוכם. לדוגמה, אפשר להשתמש ב-enum כדי לייצג ימים בשבוע, צבעים או סוגי אירועים. אבל enums מסורתיים הם בדרך כלל מבנים די מוגבלים. ב-Rust, לעומת זאת, enums הם הרבה יותר גמישים; הם מאפשרים לכל variant (או ערך) לשאת נתונים משלו ולהשתמש במערכת ה...

אחרי 10 שנים בתחום, ו3 שנים במיקרוסופט, סוף סוף הגעתי לדרגה המיוחלת - סיניור. את הקריירה שלי התחלתי בצבא, 3 שנים סדיר, שנה וחצי קבע, (בתוך כל זה גם ניהלתי צוות כשנתיים), יצאתי לאזרחות להיות ״סיניור״ בסטארטאפ, הייתי שם שנתיים וקצת ואז התחלתי להתראיין למיקרוסופט. המגייסת פנתה אליי, היו לי ארבעה ראיונות לא רעים בכלל, ואז בשיחת השכר היא אמרה לי ״אתה מיועד לדרגת Software Engineer II״. ישר שאלתי בביטחון מופרז - ״למה לא סיניור? היום אני מתפקד כסיניור ויש לי 7 שנות ניסיון״ ואז היא ענתה משפט שלקח לי קצת זמן להבין כמה הוא נכון - ״כולם פה היו סיניור לפני שהגיעו למיקרוסופט״. אז קיבלתי את ההצעה והזכות להגשים את החלום ולהצטרף למיקרוסופט, והיום, 3 שנים אחרי קודמתי שתי דרגות (מ61 ל 63) וקיבלתי את הטייטל - סיניור. בפוסט הזה אני רוצה לשתף קצת ממה שלמדתי בדרך. למרות שבכל חברה יש מערכת קידומים שונה, אני מאמין שהנקודות הבאות יהיו רלוונטיות לכל עובד בכל חברה. חשוב לי להגיד, זה לא פוסט best practices לקידום, אלא החוויה האישית שהתאימה לפרופיל, לאישיות ולחוזקות שלי ולא בהכרח תהיה דומה בין עובד לעובד. שלושת מעג...

אחת התכונות החזקות ביותר בראסט היא מקביליות ואסינכרוניות, וכשמדברים על תכנות אסינכרוני tokio  היא הספרייה הנפוצה ביותר. אחד הפיצ׳רים המרכזיים שטוקיו מאפשרת הוא channels, אשר מאפשרים תקשורת בין חלקים שונים בתכונה שלנו. קיימים בראסט מגוון סוגים של channels שמגיעים ממגוון ספריות (כמו crossbeam , std::mpsc וכו׳). בפוסט אדבר על Tokio Channels, ומתי ואיך נשתמש בהם. מהם צ׳אנלים? כשם כן הם - ״ערוצים״ אשר מאפשרים דרך לשלוח נתונים בין חלקים שונים של תוכנה (בדרך כלל בין threads או tasks). צ׳אנלים מורכבים משני מרכיבים עיקריים:  שולח (Sender):  החלק ששולח נתונים ו מקבל (Receiver): החלק שמקבל נתונים. MPSC (Multi Producer Singler Consumer) הספריה tokio מאפשרת לנו שימוש בצ׳אנלים מסוג MPSC - כלומר, מספר tasks יכולים לשלוח מידע אל מקבל יחיד. וזה נותן לנו יכולת נוחה וישירה להעביר מידע מאיזה סוג שנבחר, אל task מקבל שבו נעבד את המידע ונתמודד איתו. דוגמה פשוטה: בדוגמה הזו אנחנו רואים את יצירת השולח והמקבל tx ו rx. לאחר מכן, יצירת task ברקע ששולח בלולאה 10 מספרים באמצעות tx אל ה task הראשי בו ...

כחלק מהמסע שלנו לניהול שגיאות נכון  נפל לנו האסימון שלהשתמש ב unwrap או expect  יכול להיות רעיון לא כל כך טוב ועלול להביא לסיום מיידי של הפרוסס שלנו במקרים שאולי לא התכוונו אליהם. אז השתמשנו ב clippy deny unwrap used  שגרם לקומפילציה לא לעבור במידה ונכנס unwrap לקוד. המקום היחיד בו היינו צריכים להשאיר unwrap היה בסט הוולידציות ההתחלתי בעליה של הפרוסס שלנו, בפונקציית ה main. לדוגמה - בניסיון למשוך את הקונפיגורציה הראשונית בעליה - אם נכשלנו מסיבה כלשהי נהרוג את הפרוסס. לימים פונקציית ה main הכילה יותר ויותר ולידציות כאלה ובנוסף גם התחלנו להרוג את הפרוסס שלנו כחלק מתהליך פונקציונאלי תקין במקרים מסויימים (exit code). בפוסט אנסה להציג את האלטרנטיבה שבחרנו לטיפול בשגיאות ב main באמצעות unwrap איך נראה main סטנדרטי הפריע לי בעין לראות כל כך הרבה unwrap וחיפשתי דרך נקייה יותר לנהל את השגיאות שעלולות לצוץ ב main. באחת מעשרות השיחות הטכניות שלי על ראסט עם המנטור שלי , הוא העלה את האופציה פשוט להחזיר result מפונקציית ה main וככה אם תוחזר שגיאה ב main היא תפועפע שכבה אחת והתכנית תסגר...

אחד הדברים שלקח לי זמן להתרגל אליהם בראסט היה העובדה שאין method overloading וגם אין תמיכה בערכים דיפולטיים לפרמטרים של בפונקציות. כלומר, באותו ה namespace תוכל להיות לנו רק פונקציה אחת עם אותו השם וכשאנחנו מגדירים פונקציה אנחנו לא נוכל לקבוע לפרמטרים שלה ערכים דיפולטיים כדי להקל על המשתמש ב API. זאת להבדיל משפות כמו C#, C++, Java שתומכות ביכולות. בפוסט הזה נדבר על איך Builder Pattern יכול לעזור לנו להתגבר על המגבלות הללו. מה זה Builder Pattern ה"בילדר" היא תבנית עיצוב ממשפחת ה " creational " שמאפשרת לנו לייצר אובייקטים בצורה של הדרגתית וגמישה יותר משימוש ב constructor רגיל. באמצעות הבילדר נוכל להפריד את הרכבת שדות האובייקט מיצירתו בפועל.  התבנית שמישה ב Rust במיוחד משום שבאמצעותה אנחנו יכולים לייצר מבנים (structs) מורכבים, לבחור אילו שדות נרצה לאתחל, וגם לתת ערך דיפולטי לאיזה שדה שנרצה. מימוש ה Builder נתחיל בלייצר struct פשוט של Person שיכיל שדות שנהפוך לאופציונאליים בעוד רגע באמצעות הבילדר. השלבים הבאים יהיו: 1. נייצר מבנה של PersonBuilder שיהיה אחראי על בניית הא...

אם הגעת לכאן במקרה אני ממליץ להתחיל בפוסט הראשון והשני על מנת לקבל רקע. החלק השלישי במסע שלנו לניהול שגיאות היה ההטמעה של anyhow . הספרייה מספקת מספר פיצ'רים נחמדים מאוד שמקלים על הפיתוח ומייפים את הקוד, מייעלים את ניהול השגיאות, ואפילו עוזרים לאחר השגיאה בניתוח שלה. anyhow::Result כמו שבפוסט הקודם ראינו שאפשר להשתמש ב box dyn Error כערך החזרה של השגיאות שלנו וכך לאפשר פעפוע של כל שגיאה שמממשת את Error trait - הספרייה anyhow נותנת לנו type נוח יותר לשימוש ובשימוש בו אנחנו לא צריכים לציין את סוג השגיאה שלנו. אבל יש בעיה קטנה, אם נשתמש ב anyhow באופן הזה אמנם נרוויח את היכולת לבצע פעפוע של כל שגיאה מבלי להוסיף אותה ל TomerCodeError type שהגדרנו בפוסט הקודם, אבל אנחנו מאבדים את השימוש בשגיאה המותאמת אישית שהגדרנו ובכל יכולות ה formatting שהגדרנו לה. בשביל לפתור את הבעיה הזו כל מה שצריך לעשות זה לגרום לשגיאה שאליה anyhow::Result מתייחס להיות אותה שגיאה שהגדרנו. את זה נעשה באמצעות הגדרת alias ל type באופן הבא: כאן בעצם הגדרנו טיפוס Result משלנו, שאיבר השגיאה בו הוא TomerCodeError ועכשי...

בפוסט הקודם דיברתי על הדרך שעשינו מקוד שיכול לקרוס בכל מקום בכל רגע, להפיכת הפרוסס ליציב הרבה יותר באמצעות שימוש ב Result, ופעפוע השגיאות שלנו עם אופרטור `?`. בפוסט הזה נדבר על אחת הספריות המרכזיות בעולם ניהול השגיאות של ראסט ונראה איך היא עוזרת לנו להפוך את ניהול השגיאות שלנו לנוח ויציב הרבה יותר. ברוב המקרים כשנשתמש בכל מיני ספריות צד שלישי וככל שהפרויקט שלנו הופך מורכב יותר אנחנו נתקלים ביותר ויותר סוגי שגיאות בהם אנחנו צריכים לטפל. שימוש ב thiserror הספרייה thiserror עוזרת לנו לעשות סדר בכאוס ומאפשרת לנו להגדיר טיפוס שגיאה משלנו כדי ליצור חוויית ניהול שגיאות אחידה וגנרית בכל הפרויקט. ראסט כשפה נכתבה עם דגש חזק על reducing boilerplate (כלומר - לאפשר למפתחים לא לממש מאפס ספריות וקטעי קוד תשתיתיים שהשפה או ספרייה פשוטה יכולה להנגיש לנו). באותו אופן, גם בעולם ניהול השגיאות קיימות מספר ספריות שמטרתן לגרום לנו לעבוד פחות קשה. thiserror, בין השאר מספקת לנו את ה מאקרו הפרוצדורלי  Error שאפשר להשתמש בו מעל טיפוס השגיאה אותו נרצה לייצר. כאשר נשתמש ב derive Error הטייפ שהגדרנו יממש ב...

מבוא גם כשעולם פיתוח התוכנה מתקדם בקצב משוגע, דבר אחד נשאר קבוע - שגיאות.  לא משנה כמה מנוסים נהיה כמפתחים, שגיאות ומקרים לא צפוים תמיד יצוצו לנו. מה שישנה בסופו של יום זה איך אנחנו מטפלים ומנהלים את אותן שגיאות. בפוסט אדבר על הדרך שאני עשיתי והדברים אותם למדתי כמפתח חדש בראסט, ואיך התמודדתי עם העובדה שבראסט אין אקספשנים וגם לא קונספט של try-catch. מה עשינו לפני בשלבים ההתחלתיים של הקודבייס שלנו, כמעט כל האינטרפייסים וכל הפונקציות פשוט החזירו את הטיפוס עצמו איתו רציתי לעבוד. לדוגמה - אם יש לי אובייקט של Registry ופונקציה get_key, אותה פונקציה פשוט החזירה לי String. חשוב לציין, שעצם העובדה ש get_registry_key מחזירה String איננה הבעיה העיקרית כאן, אפשר לראות שמיד לאחר הקריאות ל open_subkey ו get_value של winreg crate מתלוות קריאות ל unwrap עליהן ארחיב ממש עוד רגע, אבל בינתיים רק אגיד שבכל מקום בו אנחנו רואים unwrap, הקוד שלנו יכול לקרוס (panic) במקרה של None או שגיאה - דבר שלרוב לא נרצה שיקרה בפרודקשן. כשהרצנו את המוצר שלנו על data אמיתי ובסקייל גבוה יותר, מהר מאוד התחלנו לקבל קריסות...

שימוש ב Option::or_else מול שימוש ב Option::or כשאנחנו עובדים עם Rust אנחנו נתקלים הרבה פעמים במקרים בהם נרצה לטפל בהיעדר ערך, כלומר None, ובשביל זה Option נכנס לתמונה. ראסט נותנת לנו כל מיני דרכים לטפל במקרים הללו ושתיים מהדרכים הנפוצות הן or ו-  or_else . בפוסט הזה נדבר על מה הפונקציות האלו עושות ומתי נרצה להשתמש בכל אחת מהן. מה זה or ו or_else Option::or היא פונקציה שמאפשרת לנו לתת ערך דיפולטי ולהחזיר אותו במידה וה Option הוא None Option::or_else  עובדת דומה מאוד אך מצפה ל Closure (פונקציה) כפרמטר - אותה פונקציה היא זו שתחשב את הערך הדיפולטי במידה וערך ה Option הוא None. מתי נשתמש ב - `or` הפונקציה or תהיה שימושית לנו בעיקר כשיש לנו ערך פשוט, ישיר, שלא יאלקץ לנו זכרון מיותר ושעלות החישוב שלו אינה גבוהה. בדוגמה ניתן לראות שיכנס 0 לערך some_value במידה ויהיה None. הכוח של `or_else` עכשיו, נניח שהיה לנו מקרה בו היינו רוצים לחשב ערך באופן מורכב יותר ולהריץ פונקציה כלשהי בהינתן ערך None, זה יכול להיות חישוב כבד, ביצוע קריאה לבסיס נתונים או כל דבר שאינו מקרה של ערך פשוט. בדוגמה ה...

התמזל מזלי ובחודשים האחרונים התחלתי לעבוד מאפס על פרויקט חדש ב-Rust, פרויקט שאמור בקרוב לרדת כחלק ממע' ההפעלה Windows. הכניסה ל Rust החזירה לי את התשוקה לחזור לכתוב קצת בבלוג. Rust שונה מאוד מהשפות העיקריות שעבדתי איתן לפני (python ו c#) בהרבה מובנים כמו ניהול הזיכרון, העובדה שאין קלאסים והורשה, ניהול השגיאות, והקומפיילר שעובד שונה לחלוטין. הפוסט הזה ידבר על Polymorphism, אחת התכונות הבסיסיות, העיקריות והחשובות של תכנות מונחה עצמים. ההבנה של הקונספט היא בעיני הכרחית לכל מפתח על מנת לכתוב קוד מודלרי יותר, פשוט יותר לקריאה, וקל יותר להרחבה. יצא לי לדבר לא פעם על Polymorphism בבלוג וכמובן, בכל פעם שהצגתי אותו (ב c# או python) זה היה באמצעות הגדרת מחלקות וביצוע הורשה בניהן. איך מתבצע פולימורפיזם בראסט? במקרה של ראסט אין את הקונספט של מחלקות וגם אין הורשה, אז מה עושים? כאן מגיע הקונספט של traits. באמצעות שימוש ב traits אנחנו יכולים להגדיר סט חתימות של פונקציות ש type יכול לממש (קצת דומה ל interface). כאשר יש לנו מספר structs שכולם מממשים את אותו ה trait אנחנו יכולים להתייחס אליהם באופן ...