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

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

חכו שניה עם הקוד הגנרי

21/05/2018

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

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

בדיוק בגלל זה אני אוהב קודם לכתוב את הקוד בגירסא הלא גנרית שלו. הנה Person ו Film לצורך הדוגמא:

class Person extends React.Component {
  constructor(props) {
    super(props);
    this.state = { loading: false };
  }

  componentDidUpdate(prevProps, prevState) {
    if (prevProps.id !== this.props.id) {
      this.fetchData();
    }
  }

  componentDidMount() {
    this.fetchData();
  }

  fetchData() {    
    this.setState({ loading: true });

    const { id } = this.props;
    $.get(`https://swapi.co/api/people/${id}`).then(res => {
      this.setState({
        data: res,
        loading: false,
      })
    });
  }

  renderLoading() {
    return <p>Loading data for id: {this.props.id}</p>
  }

  renderData() {
    const { data } = this.state;
    if (!data) { return false; }

    return (
      <div>
        <p><b>Name:</b> {data.name}</p>
        <p><b>Gender:</b> {data.gender}</p>
      </div>
    )
  }

  render() {
    if (this.state.loading) {
      return this.renderLoading();
    } else {
      return this.renderData();
    }
  }
}

class Film extends React.Component {
  constructor(props) {
    super(props);
    this.state = { loading: false };
  }

  componentDidUpdate(prevProps, prevState) {
    if (prevProps.id !== this.props.id) {
      this.fetchData();
    }
  }

  componentDidMount() {
    this.fetchData();
  }

  fetchData() {    
    this.setState({ loading: true });

    const { id } = this.props;
    $.get(`https://swapi.co/api/films/${id}`).then(res => {
      this.setState({
        data: res,
        loading: false,
      })
    });
  }

  renderLoading() {
    return <p>Loading data for id: {this.props.id}</p>
  }

  renderData() {
    const { data } = this.state;
    if (!data) { return false; }

    return (
      <div>
        <p><b>Title:</b> {data.title}</p>
        <p><b>Director:</b> {data.director}</p>
      </div>
    )
  }

  render() {
    if (this.state.loading) {
      return this.renderLoading();
    } else {
      return this.renderData();
    }
  }
}

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

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

@swapiClient('https://swapi.co/api/people')
class Person extends React.Component {
  render() {
    const { data } = this.props;
    if (!data) { return false; }

    return (
      <div>
        <p><b>Name:</b> {data.name}</p>
        <p><b>Gender:</b> {data.gender}</p>
      </div>
    )
  }
}

@swapiClient('https://swapi.co/api/films')
class Film extends React.Component {
  render() {
    const { data } = this.props;
    if (!data) { return false; }

    return (
      <div>
        <p><b>Title:</b> {data.title}</p>
        <p><b>Director:</b> {data.director}</p>
      </div>
    )
  } 
}

ברגע שזיהינו את החלקים המשותפים קל הרבה יותר להוציא החוצה את המשותף למקום אחד ולהשאיר רק את השונה בפקדים עצמם. זה אגב הקוד עבור ה Higher Order Component לקוד המשותף:

function swapiClient(baseUrl) {
  return function(Component) {
    return class SwapiClient extends React.Component {
      constructor(props) {
        super(props);
        this.state = { loading: false };
      }

      componentDidUpdate(prevProps, prevState) {
        if (prevProps.id !== this.props.id) {
          this.fetchData();
        }
      }

      componentDidMount() {
        this.fetchData();
      }

      fetchData() {    
        this.setState({ loading: true });

        const { id } = this.props;
        $.get(`${baseUrl}/${id}`).then(res => {
          this.setState({
            data: res,
            loading: false,
          })
        });
      }

      renderLoading() {
        return <p>Loading data for id: {this.props.id}</p>
      }

      render() {
        const { data } = this.state;

        if (this.state.loading) {
          return this.renderLoading();
        } else {
          return <Component data={data} />
        }
      }
    }
  }
}

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

כוכב נולד

20/05/2018

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

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

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

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

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

מה ההבדל בין מפתח Full Stack למפתח Front End?

19/05/2018

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

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

קוד צד-שרת זה החלק שרץ על השרת (בדרך כלל PHP וגם Java וכו׳), וקוד צד-לקוח זה החלק שרץ על המחשב של הגולשים (HTML / CSS / JavaScript). בעבר היה תפקיד שנקרא מתכנת Web (או וובמסטר) שכתב גם PHP וגם JavaScript.

בשנים האחרונות, פחות או יותר החל מ 2012, עולם ה JavaScript מאוד התקדם ומתכנתים שהתמקצעו בזה הצליחו להגיע להישגים מאוד טובים בפיתוח - ולבנות ממשקים הרבה יותר יפים ומהירים ממה שהיה אפשר בעבר. לכן מתכנתים רבים בחרו לעזוב את ה PHP לגמרי ולהתמקד רק בפיתוח JavaScript/HTML/CSS. היום קוראים להם Front End Developers. בשנים מאז 2012 תפקיד Front End הפך מאוד פופולרי בחברות ובעצם היום אין כמעט מתכנתי Web או וובמאסטרים אלא רק מתכנתי Front End.

לגבי Full Stack זה סיפור אחר אבל קשור- יחד עם העליה בפופולריות של JavaScript מתכנת בשם ריאן דל עשה עבודה שאיפשרה להריץ קוד JavaScript גם בצד השרת במקום PHP. הוא התבסס על מנוע הרצת JS שקיים בדפדפן כרום ונקרא V8. הסביבה שהוא בנה נקראת node.js. עד כמה שאני זוכר ריאן כבר לא מעורב בפיתוח node.js אבל הכלי עדיין מאוד פופולרי ויצר תנועה חדשה של מפתחי JavaScript שחזרו לכתוב את צד השרת אבל הפעם לא ב PHP אלא ב node.js, כלומר נשארו ב JavaScript. מאחר ולהרים סביבת node.js זה יותר מורכב מלהרים סביבת PHP מתכנתים אלו גם למדו על ניהול שרת ובניית בסיס נתונים. לאט לאט נוצרה קבוצה גדולה של מתכנתים חלקם הגיעו מ Front End ובעזרת node.js כתבו גם צד-שרת, וחלקם עשו מהלך הפוך והיו מתכנתי צד-שרת שלמדו Front End אבל המשיכו לכתוב את שתי הטכנולוגיות. היום המונח מפתח Full Stack מתיחס למתכנתים שמבצעים עבודת פיתוח מוצר מקצה לקצה, ולא קשור דוקא ל node.js. מפתחי Full Stack רבים ישתמשו ב Go, Python או Ruby לפתח את קוד צד השרת.

בגדול בדרך כלל מתכנתי Full Stack פחות מקצועיים בפיתוח צד-לקוח ממתכנתי Front-End אבל יש להם אוריינטציה יותר טובה כשמדובר בפיתוח מערכת שלמה.

ואחרי כל זה שווה גם לשאול - מה כדאי ללמוד?

התשובה שלי כמו בהרבה מקרים היא שזה תלוי:

  1. אם יש לכם רקע בעיצוב או שאתם מאוד נמשכים לעולם של פיתוח ממשקים אז ברור ש Front End זה ה-דבר.

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

  3. אם אתם מחפשים לבנות מוצר משלכם אז כמובן שתצטרכו Full Stack (או לעבוד עם חבר שמכיר את עולם ה Back End).

געגועים ל perl

18/05/2018

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

לפני שנגיע למחשב בואו נסכים ש 17% מע"מ ממחיר של 300 ש"ח נותן 51 ש"ח. במספרים זה ייצא 300 כפול 17 חלקי 100, האפסים יורדים ונשארנו עם 3 כפול 17 כלומר 51.

אבל מה שברור לכם לא תמיד ברור למחשב. כך פייתון:

>>> 300 * 0.17
51.00000000000001

ורובי:

2.3.1 :001 > 300 * 0.17
 => 51.00000000000001 

ואפילו JavaScript:

> 300 * 0.17
51.00000000000001

ורק פרל הישנה היתה מספיק חכמה לתת תשובה נכונה:

$ 300 * 0.17
51

הסיבה קשורה לאופן שבו השפות האלה מייצגות מספרים ואפשר לקרוא על הסברים לרוב על התופעה בקישור: http://floating-point-gui.de

ותמיד כדאי לזכור שמחשבים לא משקרים אבל לפעמים הם רואים דברים אחרת מכם.

לאט אבל בטוח

17/05/2018

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

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

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

לאט אבל בטוח עובד, אבל לאט.

מרחק בלימה

15/05/2018

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

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

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

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

אפקט הרשת של שפות תכנות

14/05/2018

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

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

לדוגמא כדי לכתוב אפליקציות ל iPhone צריך לדעת Swift או Objective C מה שמעלה את הערך של שפות אלו. כדי לכתוב אפליקציות לאנדרואיד תרצו לדעת Java או Kotlin מה שמעלה את הערך של שפות אלו. כשיצאה PhoneGap (והיום עם גדילתה של React Native) היא איפשרה כתיבה של יישומי Mobile באמצעות שפת JavaScript - מה שהפך את JavaScript להרבה יותר פופולרית.

ובחזרה לעתיד - מייקרוסופט הודיעה השבוע שתאפשר כתיבת פונקציות JavaScript מתוך אקסל. התחביר כמובן ES6. אלקטרון מאפשר להשתמש ב JavaScript ES6 כדי לבנות יישומים לשולחן העבודה. React Native ו PhoneGap מאפשרים פיתוח יישומי Mobile עם ES6 וכמובן כל הדפדפנים וכל ה Web Frameworks הפופולריים תומכים תמיכה מלאה ב JavaScript ES6. אם הייתי מחפש שפה עם אפקט רשת טוב ללמוד היום זו כנראה תהיה JavaScript ES6.

אימות קלט בצד הלקוח

13/05/2018

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

לא קלה דרכנו

12/05/2018

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

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

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

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