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

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

שני סוגים של חלומות לא ריאליסטים:

1. אף אחד אף פעם לא הצליח לעשות את זה.

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

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

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

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

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

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

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

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

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

מימוש ברירת המחדל של shouldComponentUpdate מחזיר תמיד true, מה שאומר שכל שינוי ב props או ב state של הפקד יביא להפעלת render מחדש. מחלקת אב בשם React.PureComponent מספקת מימוש קצת יותר יעיל שמבצע השוואת Shallow Comparison בין ה props החדש לישן ובין ה state החדש לישן, ורק אם יש הבדל יחזיר true.

לכן בשביל לזהות ולתקן פעולות render מיותרות נרצה לבצע:

1. לוודא ש render מופעל יותר פעמים ממה שהיינו רוצים (אפשר לשים נקודת עצירה או אפילו הדפסת console.log)

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

3. אם גילינו שהמימוש שלנו מבצע Shallow Compare - אפשר למחוק את הפונקציה שכתבנו ולהחליף את היררכיית הירושה כך שהפקד יירש מ PureComponent (לא חייבים).

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

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

class Item extends React.PureComponent {
  render() {
    const cls = this.props.winner ? 'red box' : 'grey box';
    return <div className={cls} onClick={this.props.onClick} />
  }
}

class App extends React.Component {
  constructor(props) {
    super(props);
    this.state = { winner: 4 };
  }

  shuffle() {
    this.setState({
      winner: _.random(10),
    })
  }

  render() {
    return (
      <div>
        {_.range(10).map(i => (
          <Item winner={this.state.winner == i} onClick={() => this.shuffle()} />
        ))}
      </div>
    );
  }
}

ReactDOM.render(<App />, document.querySelector('main'));

קודם כל נרצה לשאול - בעת לחיצה על אחד הכפתורים (שגורמת להזזה של הריבוע האדום); כמה render-ים מבוצעים? דרך קלה לענות על זה היא להוסיף פקודת console.count בתוך פונקציית ה render של Item. כלומר הקומפוננטה תיראה כך:

class Item extends React.PureComponent {
  render() {
    console.count('Item::render');
    const cls = this.props.winner ? 'red box' : 'grey box';
    return <div className={cls} onClick={this.props.onClick} />
  }
}

התוצאה הלא מפתיעה היא שאחרי כל לחיצה יש לנו 10 הודעות:

console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Item::render: 1
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Item::render: 2
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Item::render: 3
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Item::render: 4
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Item::render: 5
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Item::render: 6
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Item::render: 7
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Item::render: 8
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Item::render: 9
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Item::render: 10

זה בטח לא דבר טוב - היינו מעדיפים שהפונקציה render תיקרא רק פעמיים: אחת עבור הריבוע שהופך מאפור לאדום והשניה עבור הריבוע שהופך מאדום לאפור. מאחר והריבועים יורשים כולם מ PureComponent זה אומר שאחד השדות ב props או ב state יצא שונה בכל אחד מהריבועים. בשביל לגלות איזה שדה זה נוסיף מימוש משלנו עם הודעות הדפסה מתאימות:

class Item extends React.Component {
  shouldComponentUpdate(nextProps, nextState) {
    const sameWinner = nextProps.winner === this.props.winner;
    const sameOnClick = nextProps.onClick === this.props.onClick;
    console.log('<<<<<- ');
    console.log('Same class: ', sameWinner);
    console.log('Same on click: ', sameOnClick);
    console.log('>>>>>- ');
    return !(sameWinner && sameOnClick);
  }

  render() {
    console.count('Item::render');
    const cls = this.props.winner ? 'red box' : 'grey box';
    return <div className={cls} onClick={this.props.onClick} />
  }
}

והתוצאה:

<<<<<- 
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Same class:  true
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Same on click:  false
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 >>>>>- 
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Item::render: 1
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 <<<<<- 
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Same class:  true
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Same on click:  false
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 >>>>>- 
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Item::render: 2
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 <<<<<- 
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Same class:  true
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Same on click:  false
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 >>>>>- 
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Item::render: 3
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 <<<<<- 
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Same class:  true
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Same on click:  false
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 >>>>>- 
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Item::render: 4
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 <<<<<- 
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Same class:  true
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Same on click:  false
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 >>>>>- 
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Item::render: 5
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 <<<<<- 
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Same class:  false
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Same on click:  false
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 >>>>>- 
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Item::render: 6
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 <<<<<- 
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Same class:  false
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Same on click:  false
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 >>>>>- 
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Item::render: 7
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 <<<<<- 
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Same class:  true
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Same on click:  false
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 >>>>>- 
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Item::render: 8
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 <<<<<- 
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Same class:  true
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Same on click:  false
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 >>>>>- 
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Item::render: 9
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 <<<<<- 
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Same class:  true
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Same on click:  false
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 >>>>>- 
console_runner-1df7d3399bdc1f40995a35209755dcfd8c7547da127f6469fd81e5fba982f6af.js:1 Item::render: 10

ואכן אנחנו רואים בהדפסה שרק הריבועים שצריכים להשתנות קיבלו ערכים אחרים כשאנחנו משווים את props.winner, אבל בהשוואת props.onClick כל ריבוע קיבל ערך אחר בכל render. הסיבה נעוצה בשורה:

          <Item winner={this.state.winner == i} onClick={() => this.shuffle()} />

בכל פעם שאנחנו מפעילים את ה render של App אנחנו גם יוצרים פונקציית onClick חדשה! ולכן כל render של Item מקבל בתור Property את ה onClick החדשה, ההשוואה מחזירה שיש הבדל ב Property זה וכך מגיעים לקריאות מיותרות ל render. דרך קלה לתקן את זה אחרי שהבנו את הבעיה היא להעביר את ה bind לבנאי כך שפקד App יראה כך:

class App extends React.Component {
  constructor(props) {
    super(props);
    this.state = { winner: 4 };
    this.shuffle = this.shuffle.bind(this);
  }

  shuffle() {
    this.setState({
      winner: _.random(10),
    })
  }

  render() {
    return (
      <div>
        {_.range(10).map(i => (
          <Item winner={this.state.winner == i} onClick={this.shuffle} />
        ))}
      </div>
    );
  }
}

ואכן אחרי השינוי כל לחיצה מייצרת רק שתי הדפסות Item::render במקום 10. הקוד המתוקן המלא נמצא בקודפן הזה:

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

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

אלה חלק מה"תבלינים" שאני משתמש בהם כשאני מנסה ללמוד טכנולוגיה חדשה:

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

2. ללכת למיטאפ או לשמוע הרצאה ביוטיוב

3. לקרוא שטויות ברדיט בפורום של הטכנולוגיה הזאת

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

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

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

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

מה שקורה בפועל מאוד שונה (בתכנות בטוח, בשפות כנראה שלא). אחרי שלומדים טכנולוגיה אחת מגלים שאותם העקרונות שהשקעת 80% מתהליך הלמידה בלהבין אותם, עקרונות אלה ממש רלוונטיים לעוד 50 שפות תכנות וטכנולוגיות מקבילות. כלומר אחרי שלמדתם פייתון אם תרצו ללמוד רובי תצטרכו "להשלים" רק 20% ממה שלמדתם.

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

-7 שנות ניסיון בפיתוח Frontend. Angular הכרחי. המשרה מיועדת לנשים וגברים כאחד.

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

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

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

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

אז איך קאפצ'ה בכלל עובדת? ואיך היא יכולה להישבר? טוב ששאלתם.

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

רואים כבר איפה זה יכול להישבר?

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

הנה התרחיש הבעייתי:

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

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

3. השרת שולח לספק הקאפצ'ה שלו את מזהה הקאפצ'ה והפיתרון ומקבל תשובה שהכל תקין וזה אכן פיתרון טוב לקאפצ'ה.

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

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

מה יותר קשה - למצוא את העבודה הראשונה בהייטק או להתקדם לעבודה השניה? למצוא את הלקוח הראשון בתור עצמאי או להתקדם ללקוח החמישי? לבנות את המשחק הראשון ב App Store או הרביעי?

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

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

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

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

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