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

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

אני בחיים לא אבין את זה

14/01/2020

״זה מסובך מדי״

״כל האנשים שיודעים את זה התחילו בגיל הרבה יותר צעיר״

״זה ייקח יותר מדי זמן״

״זה בעצם לא שווה את ההשקעה״

״אולי בשנה הבאה אהיה יותר זמין לנסות ללמוד שוב״

״אני ממילא לא הולך להשתמש בזה״

״עד עכשיו הסתדרתי טוב בלי לדעת את זה״

״אני בחיים לא אבין את זה״

״גם אם אצליח להבין בחיים לא אהיה טוב בזה״

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

בואו נבנה את React.lazy כדי להבין איך הוא עובד

13/01/2020

הפונקציה React.lazy משמשת לטעינה עצלה של פקדי ריאקט, כלומר היא תאפשר לנו בצורה מאוד קלה להגדיר שפקד ריאקט מסוים לא ייכלל בקובץ ה JS הגדול של העמוד וייטען רק אם מישהו ינסה לעשות לו render. דוגמא פשוטה לשימוש בה אפשר למצוא בתיעוד והיא נראית כך:

const OtherComponent = React.lazy(() => import('./OtherComponent'));

function MyComponent() {
  return (
    <div>
      <Suspense fallback={<div>Loading...</div>}>
        <OtherComponent />
      </Suspense>
    </div>
  );
}

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

קסם? לא ממש. רוב מה ש React.lazy עושה אנחנו יכולים לעשות נפלא גם בלעדיו - בואו נראה איך.

המשך קריאה

טיפ Python: שימוש ב ExitStack כדי לצמצם with-ים מקוננים

12/01/2020

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

def v1(fin_name, fout_name):
    with open(fin_name, encoding='utf8') as fin:
        with open(fout_name, 'w') as fout:
            for line in fin:
                fout.write(line)

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

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

הנה הקוד אחרי שהוספתי את ExitStack:

from contextlib import ExitStack
def v2(fin_name, fout_name):
    with ExitStack() as stack:
        fin  = stack.enter_context(open(fin_name, encoding='utf8'))
        fout = stack.enter_context(open(fout_name, 'w'))
        for line in fin:
            fout.write(line)

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

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

פשוט כי זה עבד

11/01/2020

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

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

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

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

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

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

חדש באתר: קורס ריאקט לייב - לומדים חודשיים עם מרצה ויוצאים עם פרויקט ביד

08/01/2020

הי חברים,

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

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

אני יכול לדלג על קטעים שלא מעניינים אותי.

אני יכול להתאמן בלי שאף אחד מסתכל.

ואני יכול לשאול שאלות בלי להרגיש שרק אני לא הבנתי.

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

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

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

הקורס הראשון יהיה React ומיועד למתכנתים שכבר יודעים לכתוב קוד Front End, מכירים JavaScript ברמה סבירה אבל מכל מיני סיבות לא הצליחו עדיין להיכנס לשוק העבודה למשרות ה Front End הטובות באמת. הקורס ייפתח באמצע מרץ ויימשך חודשיים.

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

לכל הפרטים על קורס ריאקט הקרוב מוזמנים לקפוץ לדף הנחיתה החדש שבניתי בקישור https://www.tocode.co.il/bundles/react

נתראה בקורס ינון

בואו נכתוב קומפוננטה שניתנת לעריכה ב React

07/01/2020

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

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

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

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

function EditableLabel_View(props) {
  const { text, startEdit } = props;
  return (<p onClick={startEdit}>{text}</p>);
}

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

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

function EditableLabel_Edit(props) {
  const { text, setText, done } = props;

  function doneIfEnter(e) {
    if (e.keyCode === 13) {
      done();
    }
  }

  return (
    <input
      type="text"
      value={text}
      onChange={(e) => setText(e.target.value)}
      onBlur={done}
      onKeyDown={doneIfEnter}
      />
  );
}

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

function EditableLabel(props) {
  const [text, setText] = useState(props.text);
  const [edit, setEdit] = useState(false);

  if (edit) {
    return <EditableLabel_Edit text={text} setText={setText} done={() => setEdit(false)} />
  } else {
    return <EditableLabel_View text={text} startEdit={() => setEdit(true)} />
  }
}

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

class App extends React.Component {
  render() {
    return (
      <div>
        <EditableLabel text="Hello world" />
      </div>
    );
  }
}

ואפשר לראות את הקסם כולו בפעולה בקודפן הבא:

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

function makeEditableComponent(View, Edit) {
  return function EditableLabel(props) {
    const [data, setData] = useState(props.defaultValue);
    const [edit, setEdit] = useState(false);

    if (edit) {
      return <Edit data={data} setData={setData} done={() => setEdit(false)} />
    } else {
      return <View data={data} startEdit={() => setEdit(true)} />
    }
  }
}

היתרון הוא שעכשיו קל מאוד לייצר את EditableLabel או כל קומפוננטה דומה פשוט באמצעות הפעלת הפונקציה:

const EditableLabel = makeEditableComponent(EditableLabel_View, EditableLabel_Edit);

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

זה אף פעם לא משתלם להתחיל מאפס

06/01/2020

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

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

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

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

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

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

אבל... אני לא רוצה להיות מפתח Mobile כל החיים אבל ... כולם מדברים על Machine Learning אבל ... שמעתי ש Full Stack זה המקצוע הכי טוב למתכנתים אבל ... בדיקות אוטומציה זה משעמם

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

סדר פעולות

05/01/2020

  1. לבנות משהו פשוט לפי Tutorial.

  2. לבנות משהו קצת יותר גדול לבד.

  3. לקרוא ספר.

  4. לקרוא קוד של אחרים.

  5. לשמוע הרצאות מכנסים ביוטיוב.

  6. לעשות Refactoring לקוד שכבר כתבנו.

  7. לחזור לסעיף (2)

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