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

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

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

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

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

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

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

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

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

היום אני שמח להעלות לאוויר את קורס Front End החדש כאן ב ToCode, אחרי עדכון מקיף של הקורס לעולם פיתוח Front End בשנת 2020. קורס זה מסיים סידרה של קורסים שעבדתי עליה ונותן לנו כאן בטוקוד את מסלול Full Stack הטוב בארץ למתכנתים.

אם אתם כבר יודעים לכתוב קוד ורוצים להיכנס לעולם ה Full Stack, הנה רשימת הקורסים שלכם, כולם כלולים במחיר המנוי (117 ש"ח לחודש נכון לכתיבת הפוסט). קשה לי להאמין שתספיקו ללמוד את כולם בחודש אחד, אבל גם אם ייקח לכם שנה המחיר עדיין משתלם.

1. קורס Front End למתכנתים - הקורס הראשון במסלול ילמד אתכם כל מה שצריך לדעת על עולם פיתוח Web בצד הלקוח: תלמדו איך עולם האינטרנט עובד, איך מתחילים לכתוב אתרים עם HTML, איך לעצב אותם עם CSS (כן כולל flexbox, grid וכל שאר החידושים) וכמובן JavaScript לעומק כולל פיתוח מונחה עצמים ותקשורת Ajax ו Web Sockets.

2. קורס Node.JS ו MongoDB ישלים לכם את ה Stack עם תכני Back End. בקורס תלמדו Node.JS מההתחלה, פיתוח מערכות צד שרת עם Express, חיבור לבסיס נתונים (מונגו וגם SQL), ניהול משתמשים ואבטחה ובניית API.

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

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

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

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

מקווה שתהנו מהמסלול, ינון

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

וזה הזוי-

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

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

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

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

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

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

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

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

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

ב 2008 דאגלס קרוקפורד פירסם את הספר JavaScript: The Good Parts שטילטל את עולם פיתוח ה Web. באותו ספר קרוקפורד הציע תבניות לעבודה עם JavaScript כדי לבנות בתוך שפת JavaScript את המבנים שמתכנתי Java היו רגילים למצוא בתוכניות שלהם, מבנים כמו מחלקה, ירושה ומשתנים פרטיים.

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

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

var Mammal = function (name) {
  this.name = name;
};

Mammal.prototype.get_name = function (  ) {
  return this.name;
};

Mammal.prototype.says = function (  ) {
  return this.saying || '';
};

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

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

קוד Angular שמתכנת ווב יכתוב היום יהיה כתוב בסגנון הזה:

import { Component } from "@angular/core";

@Component({
  selector: "app-root",
  templateUrl: "./app.component.html",
  styleUrls: ["./app.component.css"]
})
export class AppComponent {
  title = "CodeSandbox";
}

שבכלל כתוב ב TypeScript.

ב Vue קוד טיפוסי משתמש באוביקט פשוט:

import { reactive, computed } from 'vue';

export default {
  setup() {
    const state = reactive({
      count: 0,
      double: computed(() => state.count * 2)
    });
    function increment() {
      state.count++;
    }
    return { state, increment };
  }
};

ובריאקט הבסיס לרוב הקומפוננטות הוא הפונקציה:

export default function App() {
  return (
    <div className="App">
      <h1>Hello CodeSandbox</h1>
      <h2>Start editing to see some magic happen!</h2>
    </div>
  );
}

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

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

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

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

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

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

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

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

Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off.

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

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

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

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

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

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

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

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

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