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

לכלים יש השפעה דרמטית על הפרודוקטיביות שלנו. הם יכולים להפוך אותנו לפי 10 יותר מהירים או פי 10 יותר איטיים.

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

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

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

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

ב Unix תו סוף שורה הוא \n. ב Windows זה \r\n. ולכן סקריפט שאני כותב למשל ב Notepad ואנסה להריץ ב WSL ייכשל עם הודעת שגיאה בסגנון הבא:

-bash: ./test.sh: /bin/bash^M: bad interpreter: no such file or directory

עם כל זה אנחנו יכולים לחיות בקלות ופשוט לא לכתוב Shell Scripts ב notepad, אבל מה קורה כשכלי שאנחנו כן צריכים מחליט לשנות את תווי סוף השורה בסקריפטים שמישהו אחר כתב?

הכלי שאני מדבר עליו הוא גיט.

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

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

*.sh        text eol=lf

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

למידע נוסף על gitattributes וכל הדברים שתוכלו לכתוב בו שווה לבקר בספר בקישור: https://www.git-scm.com/docs/gitattributes

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

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

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

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

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

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

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

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

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

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

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

אם אתם עדיין לא מנויים אז גם היום הוא יום טוב להירשם: https://www.tocode.co.il/quickjoin

ולינק אחרון לסיום - בתחילת ספטמבר אעביר כאן וובינר עם עיקרי הדברים על ריאקט נייטיב ואפשרות לשאול שאלות. הכניסה חינם וצריך רק להירשם בקישור: https://www.tocode.co.il/workshops/118

רשימה חלקית של דברים שמתיישנים במערכת שלנו, למרות שממש לא נגענו בהם:

1. בדיקות - רק נסו להריץ בדיקות אחרי כמה חודשים בלי הרצה.

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

3. קוד תשתית סופר גנרי - כי הדרישות מהמערכת השתנו בחמש שנים האחרונות, ואותו קוד תשתית גנרי עכשיו רק מעכב אתכם.

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

5. כלי עבודה - נו, חוץ מ vim.

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

לא צריך יותר מכמה דקות ביוטיוב כדי להיתקל בסרטים שמכילים את המילים Full Course: סרטים של שעתיים, שלוש ואפילו 8 שעות על טכנולוגיה מסוימת, בה מרצה בדרך כלל נחמד מספר ומספר על הטכנולוגיה, ואפילו בונה פרויקטים לדוגמה וכמובן הכל מצולם ומסודר. פה למשל יש מדריך פייתון של 4 שעות עם 35 מיליון צפיות: https://www.youtube.com/watch?v=rfscVS0vtbw

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

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

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

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

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

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

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

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

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

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

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

1. משחק סנייק

2. משחק טטריס

3. בלוג

4. צ'ט מיידי מרובה משתמשים

5. שידור וידאו "חי" עם הערות מהצופים

6. ניהול כספים אישי

7. משגר משימות (בסנון הזה)

צוותים שעובדים ב Agile רגילים להשתמש בקוד בתור הדרך "לגלות" את הבעיה או מה הלקוח רוצה. בין שנים עשר העקרונות האג'יליים השניים האלה מעבירים את המסר:

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

2. תוכנה עובדת היא המדד העיקרי להתקדמות.

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

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

אבל הבעיה שאנחנו לא חיים בספרינט בודד.

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

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

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

2. תשומת לב מתמשכת למצויינות טכנית ועיצוב ותכנון נכון מגדילים את היכולת האג'ילית.

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

החבילה json-to-ts היא חבילת JavaScript מדליקה (כתובה בטייפסקריפט כמובן) שיכולה לחסוך הרבה עבודה כשכותבים קוד שעובד מול APIs. התפקיד שלה הוא פשוט לקחת אוביקט JSON ולהפוך אותו ל Interface בטייפסקריפט, ואנחנו יכולים להשתמש בה בתוך תוכנית בצורה הבאה:

import JsonToTS from 'json-to-ts';
import fetch from 'node-fetch';
const url = process.argv[2];

async function main() {
  const json = (await (await fetch(url)).json());
  JsonToTS(json).forEach( typeInterface => {
    console.log(typeInterface)
  })
}

main();

ניקח URL לדוגמה שמחזיר אוביקט JSON:

$ curl https://swapi.dev/api/people/1/ | jq

{
  "name": "Luke Skywalker",
  "height": "172",
  "mass": "77",
  "hair_color": "blond",
  "skin_color": "fair",
  "eye_color": "blue",
  "birth_year": "19BBY",
  "gender": "male",
  "homeworld": "https://swapi.dev/api/planets/1/",
  "films": [
    "https://swapi.dev/api/films/1/",
    "https://swapi.dev/api/films/2/",
    "https://swapi.dev/api/films/3/",
    "https://swapi.dev/api/films/6/"
  ],
  "species": [],
  "vehicles": [
    "https://swapi.dev/api/vehicles/14/",
    "https://swapi.dev/api/vehicles/30/"
  ],
  "starships": [
    "https://swapi.dev/api/starships/12/",
    "https://swapi.dev/api/starships/22/"
  ],
  "created": "2014-12-09T13:50:51.644000Z",
  "edited": "2014-12-20T21:17:56.891000Z",
  "url": "https://swapi.dev/api/people/1/"
}

וזה מה שיוצא כשאני מעביר אותו לתוכנית שלי:

$ node tsify.mjs https://swapi.dev/api/people/1/

interface RootObject {
  name: string;
  height: string;
  mass: string;
  hair_color: string;
  skin_color: string;
  eye_color: string;
  birth_year: string;
  gender: string;
  homeworld: string;
  films: string[];
  species: any[];
  vehicles: string[];
  starships: string[];
  created: string;
  edited: string;
  url: string;
}

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

interface https://swapi.dev/api/people/1/

ויהפוך את זה אוטומטית לתוצאה של הסקריפט.

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

1. קוד שגורם לדברים לעבוד מהר יותר

2. קוד שפותר באג ללקוח

3. קוד שחוסך עבודה למתכנתת שכתבה אותו

4. קוד שמוסיף פיצ'ר שכל הלקוחות רואים

5. קוד שמוסיף פיצ'ר שרק חלק מהלקוחות רואים

6. קוד שגורם לדברים להיראות יפה יותר

7. טקסט שמסביר מה קוד שכתבתי עושה

8. קוד שמשפר את החוויה כשיש מצב שגיאה

9. קוד שבודק קוד אחר

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

11. קוד שעוזר לי להבין רעיונות חדשים

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

איזון בקוד יוצר מערכות יציבות יותר ומתכנתים שמחים יותר.