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

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

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

class Task < ActiveRecord::Base
    validates :name, presence: true
    validates :description, presence: true, unless: :new_record?
end

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

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

בחזרה ל unless שלנו. בשביל לגלות למה קוד מסוים נכנס למערכת אני משתמש ב git blame:

$ git blame -- app/models/task.rb | grep unless

ומוצא שהשורה נכנסה בקומיט מספר c8fd7f671 עם ההודעה המופלאה:

Squashed commit of the following:

ואחריה רשימה של עשרות קומיטים שאוחדו לקומיט מספר c8fd7f671 הקסום.

בלי ה Squash Commit הצעד הבא שלי היה להפעיל:

$ git log -p c8fd7f671

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

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

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

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

function InputWithLabel(props: {...}) {
    const { label } = props;
    return (
        <label>{label}</label>
        <input type="text" {...props} />
    );
}

ל TypeScript יש פיתרון נוח למצבים אלה שנקרא React.ComponentProps וזה נראה כך:

type InputProps = React.ComponentProps<'input'>

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

function InputWithLabel(props: { label: string } & InputProps) {
  const { label } = props;
  return (
    <>
      <label>{label}</label>
      <input type="text" {...props} />
    </>
  );
}

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

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

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

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

וזה עבד, לפחות עד שעליתי לפרודקשן.

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

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

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

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

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

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

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

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

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

>>> 'one two three'.split(' ')
['one', 'two', 'three']

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

>>> 'one   two   three'.split(' ')
['one', '', '', 'two', '', '', 'three']

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

>>> 'one    two   three'.split(None)
['one', 'two', 'three']
>>> 'one    two   three'.split()
['one', 'two', 'three']

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

>>> '-'.join(['yo', 'dog'])
'yo-dog'

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

>>> text = 'split    and    join'
>>> ' '.join(text.split(' ')) == text
True

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

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

חיסרון שני בגישה הוא שאנחנו תקועים עם הממשק וחיבור המקשים שג'ימייל בחרו בשבילנו.

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

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

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

1. לשמור עותק של כל המיילים אצלכם על המכונה

2. לקרוא ולכתוב אימייל דרך תוכנת דואר משורת הפקודה שנקראת mutt

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

• יש לך הנדימן להמליץ לי?

• יש לך טכנאי מזגנים טוב להמליץ?

• יש לך טכנאי מזגנים שמכיר טוב מזגני טורנדו?

• יש לך טכנאי מזגנים שמכיר טוב מזגני טורנדו ישנים?

• יש לך טכנאי מזגנים שמכיר טוב מזגני LG תעשייתיים משנת 2008?

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

בתור פרילאנסרים בתוכנה אתם יכולים לבחור את המשבצת שלכם. במקום להיות "מתכנתת Mobile" את יכולה לבחור להיות:

• זאת שיודעת למצוא ולתקן זליגות זיכרון ביישומי Objective C

• זאת שיודעת להתאים את הקוד לכל מכשירי Android שיצאו אי פעם

• זאת שיודעת לכתוב פלאגינים ל React Native כדי לחבר יותר יכולות של המכשיר לאפליקציות RN

• זאת שיודעת איך לתקן את הקוד כדי שאפל יסכימו להכניס את האפליקציה לחנות

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