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

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

את אותו הגיון אפשר לקחת גם לקריירה האישית או הלימודית שלנו-

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

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

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

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

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

הכלי awk היה לאורך שנים ועודנו אחד הכלים המרכזיים לעיבוד טקסט בסביבת יוניקס. הוא פותח בשנות ה 70 בחברת Bell Labs על ידי שלושה מפתחים ששמותיהם נתנו לכלי את שמו: Alfred Aho, Peter Weinberger ו Brian Kernighan. הייחודיות של awk היא שמצד אחד הוא כולל אלמנטים מתקדמים משפות תכנות כמו משתנים, מערכים, מילונים ואפילו אפשרות להגדיר פונקציות; אבל מצד שני זה כלי סקריפטים שהשימוש בו מאוד ממוקד לפיענוח טקסטים.

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

לשים חגורה לפני שמתחילים לנסוע.

לצחצח שיניים לפני שהולכים לישון.

לבדוק מה מצב הזיכרון והדיסק כשמתחילים לחקור תקלה.

להסתכל בלוגים.

להוסיף הודעת הדפסה (או Breakpoint) במצב פיתוח.

לגבות את המחשב כל יום.

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

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

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

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

$ echo hello world | tee a b c d >& /dev/null

וזה עובד גם ב bash וגם ב zsh. אבל מסתבר שב zsh יש עוד טריק איתו אפשר לוותר על tee:

$ { echo hello world } > a > b > c > d

וזה יוצר ארבעה קבצים שנקראים a, b, c ו d בהתאמה ובתוך כל אחד מהם כותב את הטקסט hello world.

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

$ { echo hello world } > {a..d}

נ.ב. את הפקודה המרכזית אני מקיף בסוגריים מסולסלים כי אחרת zsh לא תמיד יודע שהיא נגמרה. הסבר מדויק אפשר למצוא בתיעוד שלהם כאן: https://zsh.sourceforge.io/Doc/Release/Redirection.html#Multios

המשפט "לעולם לא אהיה רוכב אופניים" יכול להביע אחד משני פחדים מאוד שונים:

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

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

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

וכן גם לכתוב קוד.

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

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

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

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

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

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

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

https://cli.github.com/manual/installation

על מק זה היה באמצעות brew install gh, ועל חלונות מורידים קובץ התקנה מהקישור https://github.com/cli/cli/releases/tag/v2.11.3. יש גם התקנה ללינוקס אבל אני אתן לכם להיכנס לקישור בשביל למצוא את ההוראות.

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

$ gh auth login

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

ואחרי החיבור נוכל להשתמש בפקודה הבאה כדי ליצור Pull Request משורת הפקודה. בדוגמה שלי אני שולח PR למשתמש ynonp-test ולפרויקט cli-pull-request-demo:

gh pr create -R ynonp-test/cli-pull-request-demo --title "Pull request title" --body "Pull request body"

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

והקוד שלכם - האם הוא יהיה יותר טוב ככל שהמפתחים מכירים יותר לעומק את הטכנולוגיה? ככל שהמפתחים ישנים יותר טוב ורגועים יותר? ככל שהשעות שמושקעות בקידוד מושקעות 100% בקידוד?

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