ToCode

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

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

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

import random

x = random.randint(0, 10)
y = random.randint(0, 10)

print("{} + {} = ?".format(x, y))
guess = int(input())

if x + y == guess:
    print("Bravo!")
else:
    print("Better luck next time...")

קל לראות שיש בתוכנית בעיה - אם משתמש כותב במילים את התשובה במקום לכתוב את המספר התוכנית תתרסק:

7 + 0 = ?
seven
Traceback (most recent call last):
  File "/home/ynon/tmp/blog/error1.py", line 7, in <module>
    guess = int(input())
ValueError: invalid literal for int() with base 10: 'seven'

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

$ python2 error.py

10 + 10 = ?
__import__('os').mkdir('yay')
Traceback (most recent call last):
  File "error1.py", line 7, in <module>
    guess = int(input())
TypeError: int() argument must be a string or a number, not 'NoneType'

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

# תוכנית וובינרים לחודש הקרוב אחרי הפסקה ארוכה מדי אני חוזר להעביר וובינרים בימי חמישי בבוקר. בינתיים אין עדיין רשימת דיוור מסודרת אז אני מנצל את הבלוג כדי לספר מה הולך להיות. ביום חמישי הקרוב אדבר על Vue.JS בוובינר שמיועד למתכנתי ווב שלא ראו עדיין את הפריימוורק ואפילו יתאים אם ביליתם את השנים האחרונות במערה ולא ראיתם אף JavaScript Framework מודרני. אראה לכם איך לפתוח פרויקט Vue מההתחלה ואיך לשלב Vue בתוך פרויקט Node.JS שלכם, ואחר כך נראה את שיטת העבודה עם קומפוננטות ואיך היא עוזרת לנו לכתוב קוד נקי ובקלות. זה הקישור להרשמה: https://www.tocode.co.il/workshops/109 ביום חמישי שאחריו (ה 14.10) אעביר שעה על React Testing Library. המפגש הזה יתמקד בטיפים ודוגמאות לאנשים שכבר מכירים טוב ריאקט וכותבים בדיקות ב react-testing-library או ספריה אחרת. אז אם התחלתם לכתוב בדיקות UI ונתקעתם או שהיו לכם שאלות או שפשוט רוצים לראות עוד גישה לכתיבת הבדיקות הוובינר הזה בשבילכם. זה הקישור להרשמה: https://www.tocode.co.il/workshops/108 ביום חמישי שאחריו (ה 21.10) אני הולך להעביר שעה על קוברנטס לאנשים שלא ראו אף פעם את קוברנטס או שניסו להתקרב, ראו איזה yaml וברחו באימה. אנחנו נתקדם לאט מנקודת מבט של מפתחים ונראה איך לגשת לקוברנטס ואיך הוא יכול אפילו לעזור לנו. זה הקישור להרשמה: https://www.tocode.co.il/workshops/107 וביום חמישי האחרון של החודש (ה 28.10) ניקח צעד אחורה מעולם הווב ונלך לראות מה חדש ב Python 3.10, כשהפיצ'ר שייקח לנו את עיקר הזמן בוובינר יהיה ה Pattern Matching ואני אשתדל להספיק לדבר על עוד 2-3 פיצ'רים קטנים יותר. זה הקישור להרשמה: https://www.tocode.co.il/workshops/110 מקווה לראות אתכם במפגשים ואם יש לכם רעיונות לטכנולוגיות שהייתם רוצים לשמוע וובינר עליהן או להעביר וובינר עליהן שלחו אימייל ואשמח להוסיף לרשימה.

# היום למדתי: סדר המפתחות ב JSON.stringify הנה תרגיל JavaScript נחמד שאולי ילמד אתכם משהו חדש על JSON.stringify (לפחות אותי הוא לימד). קחו רשימה של אוביקטים ורשימה נפרדת של מפתחות, משהו בסגנון הזה:

const keys = ['a', 'b'];
const data = [ { a: 10, b: 20, c: 30 }, { a: 10, b: 20, c: 40 }, { a: 10, b: 12, c: 50 } ];

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

const groups1 = [ { a: 10, b: 20, c: 30 }, { a: 10, b: 20, c: 40 } ];

כי לשני האוביקטים בשדה a יש את הערך 10 ובשדה b יש את הערך 20, והקבוצה השניה תהיה האוביקט היחיד:

const group2 = [ { a: 10, b: 12, c: 50 } ];

כי השדה b מכיל בו ערך שונה - הערך 12. האינטואיציה הראשונה לפיתרון בעזרת lodash היא כנראה הפונקציה groupBy: לוקחים מכל אוביקט רק את המפתחות שמעניינים אותנו, מפעילים עליהם JSON.stringify כדי לקבל מחרוזת וזה יהיה המפתח ל groupBy. הנה הקוד:

// DO NOT USE - HAS A BIG BUG

const groups = _.groupBy(data, obj => JSON.stringify(_.pick(obj, keys)));

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

> JSON.stringify({ a: 10, b: 20 }, ['a', 'b'] )
'{"a":10,"b":20}'
> JSON.stringify({ a: 10, b: 20 }, ['b', 'a'] )
'{"b":20,"a":10}'
> JSON.stringify({ a: 10, b: 20 }, ['b'] )
'{"b":20}'

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

const groups = _.groupBy(data, obj => JSON.stringify(_.pick(obj, keys), keys));

# שלושה טיפים לכתיבה טכנית שמשאירה רושם טוב אם אתם כותבים משהו שהמטרה שלו להשאיר על הקוראים שלכם רושם ש"הבן אדם הזה יודע על מה הוא מדבר" - כמו למשל פוסט לשיתוף בלינקדאין, פוסט אורח בבלוג מפורסם או אפילו קובץ readme ליד פרויקט שאתם מצרפים לקורות חיים - מאוד חשוב לשים לב למספר פרטים קטנים שיכולים לקלקל את כל הרושם, במיוחד אם אתם באמת אנשים שיודעים על מה אתם מדברים. הנה שלושה טיפים שבלעדיהם כל פוסט טכני עלול לשקוע ולעשות יותר נזק מתועלת: ## היו ספציפיים הבור הראשון שאנחנו אוהבים ליפול בו קורה כשאנחנו כותבים על יותר נושאים ממה שאנחנו צריכים או על נושא יותר מדי רחב. באופן כללי פוסטים יכולים להתפרס לעומק או לרוחב, והמטרה שלכם כדי לעשות רושם טוב היא ללכת כמה שיותר לעומק. ככל שאתם יותר מדויקים בנושא יש לכם יותר מקום להיות עדינים ולדבר על ניואנסים ספציפיים של אותו דבר. הכותרות הבאות הן דוגמאות טובות לפוסטים ממוקדים: 1. איך עובד Find My iPhone כשהאייפון כבוי 2. מה חדש בריאקט 18 3. איך פרצנו אלפי חשבונות Azure 4. איך לבנות אינטגרציה בין Airflow ל lakeFS 5. ה Git Aliases האהובים עליי לעומתן עם הכותרות הבאות הרבה יותר קשה להשאיר רושם טוב: 1. איך לפרוץ ל APIs ב 2021 2. מבוא ל Deep Learning 3. מדריך מקיף על Airflow 4. האלמנטים של גיט 5. הכל על אימות זהות והרשאות גישה זה לא שאי אפשר לכתוב תוכן טוב לכותרות מהסוג השני, אלא שזה דורש הרבה יותר השקעה ויש הרבה יותר סיכוי לטעויות. אם המטרה שלכם היא להשאיר רושם מקצועי טוב תעשו לעצמכם טובה ותבחרו נושא קטן שאנשים שכבר נמצאים עמוק בתוך התחום ישמחו לקרוא עליו. ## עשו את הקריאה כשאתם כותבים בשביל אנשי מקצוע שמבינים בתחום והמטרה שלכם היא להיכנס ולהרשים אותם אתם חייבים להכיר את עולם התוכן של אותם אנשי מקצועי, וזה אומר שחייבים לקרוא את הדברים שהם קוראים ולהכיר את הדברים שהם מכירים. אם אתם כותבים על ה Git Aliases האהובים עליכם ומתלהבים מאיזה alias שהצלחתם לייצר אפילו שבגירסאות חדשות של גיט ההתנהגות שלו כבר מובנית במערכת אז רק יריתם לעצמכם ברגל. זאת עוד סיבה שאתם רוצים לכתוב על נושא כמה שיותר ממוקד - ככל שהנושא יותר ממוקד יש פחות סיכון שתפספסו מידע חשוב שכל העולם מכיר. ## עריכה, עריכה ועריכה כמעט תמיד ברצף כתיבה יהיו טעויות או רעיונות שפשוט לא מוסברים מספיק טוב וצריך לקרוא את הפוסט או המאמר עוד כמה פעמים ואולי לתת לחברים לקרוא כדי "לנקות" את הבעיות האלה. בעיה נוספת היא פיסקאות שמבוססות על איזשהו רושם שיש לכותב לגבי איך דברים עובדים אבל שלא נבדק עד הסוף ולכן כולל טעויות ואי דיוקים. הסיפור כאן הוא שרוב האנשים שיודעים על מה הם מדברים לא יטרחו להשאיר לך הודעה שאומרת שבפיסקה מסוימת כתבת דברים לא הגיוניים. הם פשוט יקבלו את הרושם שאתה לא מבין מספיק וימשיכו הלאה. בדוגמה מפוסט שפרסמתי אתמול, קוד bash הזה:

#!/bin/bash

for f in [0-9][0-9]*
do
  number=${f%%-*}

  mv "$f" $(printf "%02d-${f#*-}" $((number + 1)))
done

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

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

01-hello
02-some-text
03-i-like-bash
04-zsh-is-ok-too
05-byebye

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

01-hello
03-i-like-bash
04-zsh-is-ok-too
05-byebye

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

#!/bin/bash

for f in [0-9][0-9]*
do
  number=${f%%-*}
  number=${number#0}
  (( number < 2 )) && continue

  mv "$f" $(printf "%02d-${f#*-}" $((number - 1)))
done

שתי הפקודות הראשונות בלולאה חותכות מהמשתנה f את כל מה שבא אחרי המקף הראשון, ואחרי זה מוחקות את האפס שבהתחלה, כך שאנחנו נשארים רק עם המספר ללא הריפוד. הפקודה הבאה היא תנאי מקוצר, אפשר לקרוא אותה בתור "אם number קטן מ-2 המשך לאיטרציה הבאה". כמובן שאת המספר 2 צריך להחליף במספר הקובץ שמוחקים. והפקודה השלישית היא המורכבת ביותר, היא משתמשת בדולר-ואז-פעמיים-סוגריים כדי להוריד אחד מ number, ואת התוצאה מעבירה בתור פרמטר שני לפונקציה printf שמרפדת אותו ב-0 ומצמידה אליו את שם הקובץ בלי המספר שבהתחלה. וכן, הכתיב המצחיק של ה f עם הסולמית אומר למחוק מהמשתנה f את כל מה שבא לפני המקף הראשון. ## פיתרון 2 - אפשר למספר הכל מחדש גישה קצת יותר גמישה פשוט תמספר מחדש את כל הקבצים, כי בינינו יכול להיות שמחקו יותר מקובץ אחד ועדיף להמשיך לעבוד גם במצבים מוזרים כאלה. הרעיון הוא כזה:

#!/bin/bash -e

number=1

for f in [0-9][0-9]*
do
  newname=$(printf "%02d-${f#*-}" $number)
  (( number++ ))

  [[ "$f" == "$newname" ]] && continue

  mv "$f" "$newname"

done

אנחנו לוקחים את רשימת כל הקבצים בתיקיה ומתבססים על זה שה glob מחזיר את הקבצים לפי סדר מילוני. עכשיו אפשר לרוץ בלולאה על הקבצים ולכל אחד לתת שם חדש שמתאים לאינדקס שלו. הפעולה number++ בתוך סוגריים עגולים כפולים מעלה ב-1 את המשתנה, וה printf אחראי על יצירת השם החדש. הפעם ההחלטה לדלג לקובץ הבא תלויה בשם הקובץ החדש והאם השמות זהים. בעיקרון אפשר לוותר על הבדיקה כי mv ממילא ייכשל אם שמות הקבצים זהים אבל אני מעדיף לא להכשיל תוכניות באמצע סקריפט. ## עכשיו אתם 1. בפיתרון הראשון הורדתי את האפס שריפד את המספר שלפני שם הקובץ (שורה שניה בתוך הלולאה). מה יקרה אם נוותר על שורה זאת ונשאיר את האפס? 2. בפיתרון הראשון השתמשתי בסוגריים עגולים כפולים בשביל התנאי המקוצר אבל בפיתרון השני בסוגריים מרובעים כפולים. מה ההבדל בין השניים? איך היה נשבר קוד הפיתרון השני אם הייתי כותב בו סוגריים עגולים במקום מרובעים? 3. יש לכם רעיונות נוספים לפיתרון? מוזמנים לשתף בתגובות.

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

תוכנית וובינרים מלאה לחודש אוקטובר עלתה לאתר: https://www.tocode.co.il/workshops מוזמנים להירשם לוובינר/ים שמעניינים אתכם

הסקר נגמר תודה לכל המשתתפים