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

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

מציפיות לתוכנית עבודה

21/11/2024

יש שתי בעיות עם ציפיות גבוהות מדי:

  1. כשזה לא מצליח אנחנו נוטים להתאכזב ולהתייאש.

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

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

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

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

מה באמת הבעיה בדוגמת ריאקט הזו

20/11/2024

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

https://matanbobi.dev/posts/stop-passing-setter-functions-to-components

הקוד שהוא הדביק נראה ככה:

// Form.jsx 
function Form() { 
    const [formData, setFormData] = useState({ name: '' }); 
    return (
        <div>
            <h1>Form</h1> 
            {/* Pass the setter function down to ChildComponent */}
            <Input name={formData.name} setFormData={setFormData} />
            <button onClick={() => console.log(formData)}>Submit</button> 
        </div> 
    ); 
};

// Input.jsx
function Input({ name, setFormData }) { 
    const handleInputChange = (event) => { 
        // Directly using the setFormData setter function from the parent
        setFormData((prevData) => ({ ...prevData, name: event.target.value })); 
    }; 

    return ( 
        <div>
            <label> 
                Name: 
                <input type="text" value={name} onChange={handleInputChange} /> 
            </label>
        </div> 
    ); 
};

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

setFormData((prevData) => ({ ...prevData, name: event.target.value })); 

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

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

// Form.jsx 
function Form() { 
    const [name, setName] = useState(''); 
    const [favoriteColor, setFavoriteColor] = useState('#000000);

    return (
        <div>
            <h1>Form</h1> 
            <Input label="Name" value={name} setter={setName} />
            <Input label="Favorite Color" value={favoriteColor} setter={setFavoriteColor} />
        </div> 
    ); 
};

// Input.jsx
function Input({ label, value, setter }) { 
    const handleInputChange = (event) => { 
        setter(event.target.value);
    }; 

    return ( 
        <div>
            <label> 
                {label}: 
                <input type="text" value={value} onChange={handleInputChange} /> 
            </label>
        </div> 
    ); 
};

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

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

אנחנו בונים

19/11/2024

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

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

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

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

כמה באמת עולה כרטיס לוטו?

18/11/2024

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

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

  1. "אם לא תנסה איך תזכה"

  2. "זה רק 20 ש"ח, חבל לא לנסות"

  3. "ממילא אין לי משהו אחר לעשות עם הכסף"

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

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

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

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

סקאלת הישגיות - סקרנות

17/11/2024

  • הולך ל Chat GPT ומבקש פיתרון.

  • הולך ל Chat GPT ומבקש 3 פיתרונות, עם יתרונות וחסרונות של כל אחד כדי שאוכל לבחור את הטוב ביותר.

  • הולך ל Chat GPT ומבקש כיוון כללי לפיתרון. את השאר אמצא בגוגל ובתיעוד.

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

  • כותב לבד POC, מחפש לשבור אותו ורק כשהכל עובד ואני מבין כל פסיק מוחק את ה POC וכותב את הקוד האמיתי.

  • כותב לבד קוד אמיתי אחרי מחקר וכתיבת POC, ואז מוסיף בדיקות ותיעוד.

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

קל מדי זה לא סימן טוב

16/11/2024

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

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

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

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

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

ארבעה דברים שממש אהבתי ב Nuxt

14/11/2024

נוקסט היא גירסת ה Full Stack של Vue המאפשרת פיתוח יישומים מלאים עם Server Side Rendering. אני חייב להודות שכשהתחלתי לשחק עם הפריימוורק הייתי בטוח שאני הולך לפגוש עוד next.js ושמחתי למצוא מספר פיצ'רים ייחודיים שמיד עשו חשק ללמוד יותר. אלה הדברים שכבר ממבט ראשון על nuxt אהבתי במיוחד:

  1. יבוא אוטומטי - כן אני יודע VS Code משלים פקודות import בלי מאמץ ובכל זאת אין קוד תמיד עדיף על קוד שנכתב מהר. קטע כזה עובד ב nuxt בלי שנצטרך להוסיף שום פקודת import:
<script setup lang="ts">
/* ref() and computed() are auto-imported */
const count = ref(1)
const double = computed(() => count.value * 2)
</script>
  1. מערכת מודולים מובנית - לקח לי שתי לחיצות להוסיף את Tailwind לאפליקציית ה nuxt שבניתי דרך מנגנון המודולים שלהם. יש מודולים לחיבור לבסיסי נתונים, לחיבור לפורטלי תשלום, לניהול משתמשים, מוניטורינג של האפליקציה ועוד.

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

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

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

זהירות פלסטר - מתוקן

12/11/2024

המתכון הוא פשוט-

  1. כותבים קוד תשתית.

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

  3. מתקנים את התשתית.

  4. בונים את הפיצ'ר עם התשתית החדשה.

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

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

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