ToCode

# ארבעה מכשולים שמונעים מאיתנו ללמוד טכנולוגיה חדשה בתור מתכנתים אנחנו יודעים שהעולם הטכנולוגי משתנה כל הזמן, שחשוב ללמוד טכנולוגיות חדשות (גם בלי קשר לחיפוש עבודה או שינוי קריירה) ושככל שנקפיד ללמוד טכנולוגיות חדשות כל הזמן ולהפוך את הלימוד לחלק בלתי נפרד מהחיים שלנו, כך יהיה לנו קל יותר לפתח קריירה לטווח הרחוק ולהישאר רלוונטים. ולמרות שרובנו מבינים את החשיבות של לימוד טכנולוגיות חדשות, בפועל כשאנחנו מנסים לשלב לימוד איכותי של טכנולוגיה אנחנו מגלים שהמשחק הרבה יותר קשה ממה שקיווינו. המעבר בין "שיחקתי קצת עם Elixir" לבין "אני מבין לעומק את Elixir, Pheonix ו Erlang ומסוגל לבנות קוד מקצועי בזה" דורש השקעת זמן ויותר מזה דורש התגברות על מכשולים פנימיים שמונעים מאיתנו ללמוד את הטכנולוגיה לרמה אליה אנחנו רוצים להגיע. ארבעת המכשולים שנראה בפוסט מופיעים אצל כל אחד ואחת שמגיעים ללמוד טכנולוגיה חדשה. הם לא סימנים שהלימוד לא בשבילכם או שאתם לא טובים מספיק. הם בסך הכל חלק מתהליך הלימוד שהמוח שלנו עובר בדרך מכאן לשם. אבל רק אם נבין אותם ונדע לצפות להם, נוכל להתגבר עליהם כשהם מגיעים ולהצליח ללמוד את הטכנולוגיה החדשה לרמה אליה אנחנו רוצים להגיע. ## בלבול (Confusion) מכשול מספר אחד נקרא "בלבול" והוא קורה כשאני מתחיל ללמוד טכנולוגיה חדשה ומרגיש ששום דבר לא מצליח או שאני לא מבין אפילו מאיפה להתחיל. אני יכול לפתוח Tutorial ולא להצליח להריץ את הקוד בו, או לקרוא ספר או לצפות במדריכים ביוטיוב וכל פעם מחדש אני מרגיש שאני מבין מה הראו במדריך אבל לא יודע ליישם. הבעיה עם בלבול היא שהתגובה האינטואיטיבית שלנו רק מחמירה את הבעיה: כשאני מנסה להריץ דברים וכלום לא עובד אני רץ לאינטרנט לחפש פיתרונות, או רץ לחפש מדריכים אחרים שיותר יתאימו לי. במקום להתקדם וללמוד אני מבזבז זמן יקר בחיפוש אחר תשובות כשהאמת היא שהשאלות שלי בכלל לא רלוונטיות או יעלמו מעצמן עם התקדמות הלימוד. הדרך לצאת מהבלבול הוא דווקא ללכת נגד האינטואיציה ולהפסיק לחפש עוד מקורות לימוד. הפיתרון הנכון הוא פשוט להתקדם, גם אם זה לוקח יותר זמן ממה שקיווית וגם אם זה אומר לשבת עכשיו שבוע לכתוב תוכנית שבשפה אחרת היית כותב אותה בשעה. רק בהליכה קדימה אפשר יהיה לצאת מהבוץ ולהתחיל לשאול את השאלות הנכונות. ## עומס יתר מכשול שני הוא עומס יתר וזה מה שקורה כשאנחנו מחפשים להבין הכל לגבי הטכנולוגיה: איך זה עובד, איזה בעיות יהיו בכל מקרי הקצה האפשריים, איך זה מתנהג על כל הפלטפורמות, מה בדיוק ההבדלים בין שיטת עבודה אחת לאחרת, מה ה Best Practices, איזה ספריות עזר צריך להוסיף למערכת וכו'. קחו לדוגמה ספריה כמו React: אפשר ללמוד את ריאקט מהר מאוד אם מתמקדים בספריה עצמה ובצורת הפעולה שלה, אבל אם מתחילים לקרוא שאלות מראיונות עבודה ומנסים להבין גם את React וגם את Redux וגם את MobX וגם את create-react-app וכל הדברים שבתוכו וכמובן את Styled Components ו React Router - אז מרוב דברים שכאילו חייבים לדעת בשביל להשתמש בריאקט אנחנו רק שוקעים בתוך ייאוש שלעולם לא נצליח ללמוד את זה, שריאקט גדולה עלינו ושצריך לוותר. הפיתרון לעומס יתר הוא פשוט להבנה אבל קשה לביצוע - הוא דורש למצוא דרך פשוטה והגיונית ללמוד את הטכנולוגיה ולהיצמד אליה, ייקח כמה שייקח. רק באמצעות פוקוס על הדבר החשוב הבא אפשר יהיה לכסות בסוף את הטכנולוגיה במלואה. ## התנגדות (Resistance) "בתוך הנפש עומד אביר ומולו דרקון. אתה האביר, ההתנגדות היא הדרקון". זה ציטוט של סטיבן פרספילד מתוך הספר Do The Work שמדבר בצורה חדה על נושא ההתנגדות הפנימית. הרעיון בגדול הוא שלמוח שלנו יש כוח אבולוציוני מדהים להתאמץ להישאר בסטטוס קוו. לימוד טכנולוגיה חדשה פותח את הדלת לשינוי ושינויים זה דבר מפחיד. ההתנגדות נמצאת שם מהרגע הראשון והיא תעשה הכל כדי למצוא את התירוצים לכישלון עוד לפני שכתבתם את שורת הקוד הראשונה. ההתנגדות תגרום לכם להרגיש שעברתם את הגיל, או שאתם עדיין לא בגיל, או שיש לכם יותר מדי ילדים, או פחות מדי זמן או כסף, או כל סיפור אחר שצריך בשביל להישאר איפה שאתם נמצאים ולא ללמוד את הדבר החדש הזה שאתם רוצים ללמוד. אין דרך קלה להתמודד עם התנגדות פנימית. כן כדאי לזכור שהיא שם, להזכיר לעצמכם את הסיבה בשבילה אתם לומדים את הדבר החדש וליצור סדר יום ושיגרת לימודים. ולקרוא את הספר של סטיבן פרספילד. ## הסחות דעת

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

import re

if re.search(r'([a-z])\1', 'hello'):
    print("yay")
    

## הפונקציה fullmatch פונקציית fullmatch היא חידוש של פייתון 3.4. השם שלה יחסית לא מבלבל והיא בעצם מחפשת התאמה מלאה בין הטקסט לביטוי הרגולארי. אפשר לדמיין שהיא מוסיפה לביטוי הרגולארי שלנו את התווים \A ו \z להתחלה ולסוף של הביטוי. אישית אני לא משתמש בפונקציה זו וכשצריך אני מוסיף את סימני תחילת שורה וסוף שורה לביטוי בצורה מסודרת, אבל אני יכול לדמיין למה אנשים יחשבו שהיא יותר נוחה. הקוד הבא לדוגמה ידפיס רק את ה yay אבל לא ידפיס את ה no, כי אומנם קיימת אות כפולה בטקסט אבל יש שם עוד תווים לפניה ואחריה:

import re

if re.search(r'([a-z])\1', 'hello'):
    print("yay")

if re.fullmatch(r'([a-z])\1', 'hello'):
    print("no...")

הקוד הבא ידפיס yay כי הביטוי הרגולארי מכסה את כל הטקסט:

import re

if re.fullmatch(r'h.*o', 'hello'):
    print("yay")

## הפונקציה match הפונקציה match היא עבורי המבלבלת ביותר במודול. קודם כל כי היא לא פועלת כמו אף פונקצית חיפוש ביטויים רגולאריים מקבילה בשפות אחרות אבל היא לקחה את השם הכי מקובל לפונקציות חיפוש בביטויים רגולאריים. למי שלא זוכרים, הפונקציה match מחפשת התאמה לביטוי הרגולארי החל מתחילת המחרוזת, כלומר היא רק מוסיפה \A בתחילת הביטוי. הנה כמה דוגמאות להמחשה - התוכנית מדפיסה רק את הודעות ה yay ולא את ה no:

import re

if re.match(r'h.*o', 'hello'):
    print('yay')
    
if re.match(r'h', 'hello'):
    print('yay')
    
if re.match(r'o$', 'hello'):
    print('no')

שורה תחתונה: נשתמש ב re.search בכל הזדמנות, נשתמש ב re.fullmatch בשביל לספר למי שקורא את הקוד שיש פה חשיבות להתאמה מלאה, ונתרחק מ re.match כי רוב הסיכויים שמי שקורא את הקוד לא יזכור את ההבדל הדק בינה לבין fullmatch.

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

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

# גם תהליכי עבודה זה תשתית רכיבי תשתית בקוד שלנו הם הדברים שאנחנו משתמשים בהם שוב ושוב בהרבה מקומות וכך הם חוסכים לנו זמן קידוד - במקום לכתוב ולדבג כל פעם מחדש את אותו דבר, אני משתמש במשהו קיים. שווה לזכור שתהליך פיתוח תוכנה כולל יותר מכתיבת קוד. תהליך הפיתוח צריך לתת לנו תשובה לשאלות: 1. איך מדבגים את זה? 2. מה מינימום בדיקות שצריך לכתוב בעבודה על פיצ'ר? 3. למה אנחנו עושים Mock בבדיקה? ולמה לא? 4. מה שומרים ב git? 5. מה הפורמט של הודעת קומיט? 6. איך מעלים גירסה? 7. איך פותחים פרויקט חדש? מה צריך להתקין כשמקבלים מחשב חדש? 8. מה עושים כשכמה אנשים צריכים לעבוד על פיצ'רים שונים בפרויקט? אם כל פעם שנגיע לאחד המצבים האלה נצטרך לגלות מחדש מה עושים בו, העבודה תהיה איטית ולא קונסיסטנטית. בארגונים טובים התשובות לשאלות אלה ועוד כבר נמצאו, תועדו וכתובות במסמכים מסודרים.

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

$ sudo apt-get install pm-utils

חבילת pm-utils כוללת שתי פקודות מעניינות. הראשונה מכניסה אותנו למצב חיסכון בחשמל:

sudo pm-powersave true

והשניה חוזרת למצב עבודה רגיל:

sudo pm-powersave false

פקודות אלה מחפשות סקריפטים בתוך תיקיית /etc/pm/power.d ויריצו את כל הסקריפטים שם לפי סדר, כשכל סקריפט מופעל עם הפרמטר true או false (הפרמטר true מציין כניסה למצב חיסכון בחשמל, false מציין יציאה ממצב זה). עד לפה הכל טוב ויפה אבל רובנו לא הולכים לזכור כל פעם שאנחנו מנתקים את המחשב מהחשמל גם להריץ את הסקריפט של pm-powersave ולכן צריך עוד שינוי קטן כדי שמנגנון זה ירוץ אוטומטית בעת ניתוק או חיבור המחשב לחשמל. אחרי חיפוש קצר ברשת מצאתי שדרך קלה לעשות את זה היא להוסיף udev rule. בתור מנהל מערכת ניצור את הקובץ /etc/udev/rules.d/99-powersave.rules ובתוכו נכתוב:

SUBSYSTEM=="power_supply", ATTR{online}=="0", RUN+="/usr/sbin/pm-powersave true"
SUBSYSTEM=="power_supply", ATTR{online}=="1", RUN+="/usr/sbin/pm-powersave false"

לאחר מכן הפעילו את הפקודה הבאה כדי לרענן את כללי ה udev:

udevadm control --reload-rules && udevadm trigger

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

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

# טעות בתהליכי עבודה כשחברת פינבוט מספרת לנו שזליגת המידע המטורפת ממנה היא תוצאה של טעות אנוש במעבר לענן של אמזון אני מקבל את הרושם שהם לא יודעים מה זה טעות אנוש, או שאנחנו לא מתכוונים לאותו דבר. טעויות אנוש קורות: כשמתכנת עושה Deploy ל Production במקום לסביבת הטסט זו טעות אנוש; כשאתה מוחק בטעות את הקובץ package.json במקום את package-lock.json זו טעות אנוש; אפילו כשאתה מריץ את הטסטים בטעות על מכונת הפרודקשן ומוחק את כל בסיס הנתונים זו טעות אנוש. טעות אנוש קורית לבן אדם שיודע מה צריך לעשות ובטעות עשה את הדבר הלא נכון. מצד שני בפינבוט לפי הכתבה קוד המקור של המערכת היה גלוי לכל ברשת, וכלל אסימונים לגישה לשירותי הענן בהם השתמשו. הכנסת אסימוני גישה לתוך קוד המקור והשארת קוד המקור עם האסימונים גלוי ברשת אינן טעויות אנוש אלא טעויות בתהליכי עבודה: זה לא משהו שקורה שניה אחת ומיד אחרי זה אתה קולט מה עשית ומתחרט על זה, אלא בעיה שקיימת במערכת לאורך זמן ואנשים רואים ומתעלמים (או לא שמים לב). היתרון בטעויות בתהליכי עבודה הוא שיחסית קל לפתור אותן - מוסיפים בדיקות אבטחה תקופתיות ועוברים להשתמש בפריימוורק שמצפין את הסודות במקום להשאיר הכל גלוי בקוד המקור. אני לפחות ארגיש הרבה יותר בטוח אם במקום לזרוק "טעות אנוש" בלי לחשוב על זה, ההודעה לציבור תסביר שהיו טעויות בתהליכי עבודה ותפרט מה התיקונים שבוצעו.

# למה זה לא מתרסק (או: בעיות שלא רואים) כל החיים לימדו אותי שצריך לסגור קובץ אחרי שפותחים אותו כי אחרת אתה לוקח יותר מדי File Handlers ממערכת ההפעלה ובסוף הם ייגמרו והתוכנית תתרסק. ועוד הם אמרו שב Python אני יכול להשתמש ב with כדי שהקובץ ייסגר אוטומטית ולא יהיו לי בעיות. אז יום אחד הלכתי לבדוק את הסיפור הזה וכתבתי את הקוד הבא:

for _ in range(100_000):
    fout = open('output.txt', 'w')
    fout.write("hahaha\n")

מאחר ומספר ה File Handlers הפתוחים בלינוקס שלי מוגבל ל 1024, ציפיתי להתרסקות מהירה. היא לא הגיעה. מחשבים רוצים לעזור (חוץ מ C++, אבל היא באמת מסיפור אחר), ובמקרה של פייתון הניסיון הזה מתבטא בזה שפייתון שמה לב שכל איטרציה של הלולאה מאבדת את הגישה ל File Handle הקודם שנוצר ולכן מרשה לעצמה לסגור את הקובץ, גם בלי close וגם בלי with. האם זה אומר שכדאי לי להתרגל לכתוב כך קוד? אני לא בטוח. יש תוכניות ששומרות הרבה אוביקטים בזיכרון ושם יכול להיות שפייתון לא ימחק את ה File Handles שיצרנו כי התוכנית עדיין שומרת מצביע אליהם. אולי יותר מטרידה האפשרות שקוד שמופיע במערכת ישתכפל (כי מתכנתים רגילים לעשות copy-paste ממקומות אחרים בקוד) ויגיע למקומות בהם הוא כן יוביל לזליגת קבצים פתוחים. לקריאה נוספת בנושא שווה לקרוא את הפוסט הבא של ראובן לרנר שגם עשה ניסויים עם מימושים נוספים של פייתון (pypy ו jython): https://lerner.co.il/2015/01/18/dont-use-python-close-files-answer-depends/.

# איך נוצר חוב טכני אנשים אוהבים לדבר על "חוב טכני" כאילו זו בחירה, כאילו אנחנו קמים יום אחד ואחרי התלבטות מחליטים "היום אני אכתוב קוד גרוע כדי שהפיצ'ר יעבוד מהר יותר". כן, יש מצבים כאלה, אבל הם לא הרוב. חוב טכני נוצר כשאנחנו מזניחים את התשתיות שלנו עד שבסוף הן נשברות: 1. כשאנחנו לא משקיעים כמה שעות כל שבוע בשידרוג תלויות בפרויקט. 2. כשאנחנו לא מבצעים סקר אבטחת מידע תקופתי. 3. כשאנחנו לא בודקים פעם בכמה חודשים שאפשר לחזור מגיבוי. 4. כשאנחנו לא עושים Refactoring ביום יום, אלא משאירים את זה ליום אחד כשיהיה זמן. 5. כשאין לנו תשתית בדיקות או שאנחנו מוכנים להשלים עם בדיקות שנכשלות. ברוב המקרים חוב טכני הוא תוצאה של תהליכי עבודה. הוא נוצר לאורך זמן ובגלל זה קשה לתקן אותו. גם אם אני אחליט לקחת שלושה חודשים רק ל"תיקון הקוד" והחזרת החוב הטכני, מהר מאוד אני אמצא את עצמי שוב באותו מצב. מערכת טובה היא כזאת שמנקה את עצמה כל יום קצת וכך החוב הטכני נשאר תמיד בשליטה.