ToCode

סביבת base היא הסביבה שהגיעה עם anaconda וכוללת את כל החבילות שאנשי Data Science יכולים לחלום עליהן. אנחנו נשאיר אותה בצד רגע ובשביל המשחק ניצור לנו סביבה חדשה עם התקנה חדשה של פייתון. הפקודה הבאה מציגה את כל גירסאות הפייתון שאנקונדה יודע לעבוד איתן:

$ conda search python

אני יכול לראות בסוף הרשימה את גירסה 3.9.1. בואו נתקין אותה וניצור ממנה סביבת קונדה חדשה. אגב בנושא שמות, הפקודה conda היא מנהל החבילות והפצת הפייתון המלאה נקראת אנקונדה:

$ conda create -n py39-conda python=3.9.1 

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

$ conda env list

# conda environments:
#
base                  *  /home/ynon/anaconda3
py39-conda               /home/ynon/anaconda3/envs/py39-conda

ואני יכול להיכנס לסביבה החדשה עם הפקודה:

$ conda activate py39-conda

## התקנת חבילה עם conda בתוך סביבת קונדה אני מתקין חבילות חדשות שוב עם הפקודה conda. בואו נתקין את NumPy בסביבה החדשה:

$ conda install numpy

אפשר גם לחפש חבילות עם conda search (כמו שחיפשנו את פייתון) או לבחור ולהתקין גירסה מסוימת של חבילה. מאחר ואנחנו כבר בתוך הסביבה אפשר לכתוב סקריפט שמשתמש ב NumPy ולהפעיל אותו בלי בעיה. סביבת Conda למעשה כוללת גם גירסת פייתון שהיא התקינה, וגם את כל החבילות שמותקנות בתוך גירסה זו. אנחנו יכולים להחליט ליצור סביבת Conda עבור פרויקט מסוים או עבור אוסף פרויקטים, ולהחליף סביבה כשעוברים לעבוד על פרויקט אחר. ## יצירת קובץ requirements.txt מתוך סביבת conda בדומה לעבודה עם venv, גם קונדה מאפשר יצירת קובץ requirements.txt שיכיל את רשימת כל הספריות שהתקנו בתוך הסביבה והגירסאות שלהן. אפשר ליצור את הקובץ עם pip freeze כמו שאתם מכירים, או באמצעות conda עם הפקודה:

$ conda list -e

# This file may be used to create an environment using:
# $ conda create --name <env> --file <this file>
# platform: linux-64
_libgcc_mutex=0.1=main
blas=1.0=openblas
ca-certificates=2020.12.8=h06a4308_0
certifi=2020.12.5=py39h06a4308_0
ld_impl_linux-64=2.33.1=h53a641e_7
libedit=3.1.20191231=h14c3975_1
libffi=3.3=he6710b0_2
libgcc-ng=9.1.0=hdf63c60_0
libgfortran-ng=7.3.0=hdf63c60_0
libopenblas=0.3.10=h5a2b251_0
libstdcxx-ng=9.1.0=hdf63c60_0
ncurses=6.2=he6710b0_1
numpy=1.19.2=py39h87658db_0
numpy-base=1.19.2=py39h0f7b65f_0
openssl=1.1.1i=h27cfd23_0
pip=20.3.3=py39h06a4308_0
python=3.9.1=hdb3f193_2
readline=8.0=h7b6447c_0
setuptools=51.0.0=py39h06a4308_2
sqlite=3.33.0=h62c20be_0
tk=8.6.10=hbc83047_0
tzdata=2020d=h14c3975_0
wheel=0.36.2=pyhd3eb1b0_0
xz=5.2.5=h7b6447c_0
zlib=1.2.11=h7b6447c_3

נשים לב שמשהו פה לא נראה כמו קובץ ה requirements.txt שאנחנו רגילים מעבודה עם pip. מספרי הגירסאות ייחודיים לאנקונדה ובשביל להתקין את הקובץ הזה על מכונה אחרת נצטרך להשתמש ב conda עצמו (הפקודה מופיעה בהערה בראש הקובץ). ## יצוא ויבוא סביבות קונדה שיטה יותר מקובלת להעביר מידע על גירסאות והתקנות בין מכונות באנקונדה היא יצוא ויבוא סביבות. זה נראה כך:

$ conda env export --from-history

name: py39-conda
channels:
  - defaults
dependencies:
  - python=3.9.1
  - numpy
prefix: /home/ynon/anaconda3/envs/py39-conda

$ conda env export --from-history > environment.yml

לאחר מכן נעתיק את הקובץ environment.yml למכונת היעד ושם נפעיל את הפקודה הבאה כדי ליצור את הסביבה:

conda env create -f environment.yml

## אז במה לבחור? אחרי כל מה שכתבנו על אנקונדה השאלה לדעתי נשארת - האם לבחור ב Anaconda או ב pip וחבריו? היתרונות של אנקונדה ברורים: 1. כלי אחד שעושה את הכל. 2. פיתרון טוב יותר מ pip לנושא ניהול התלויות. 3. מעבר חלק יותר בין סביבות והתקנות אמינות יותר.

# קונדה-מה? לפני כמה ימים כתבתי כאן על ניהול גירסאות בפייתון ועבודה על מספר גירסאות במקביל. באותו פוסט השמטתי בכוונה את אנקונדה, שהוא כלי מאוד פופולרי בעולם ה Data Science שנועד לפתור בדיוק את אותה בעיה של עבודה על מספר סביבות פייתון במקביל על המכונה. בהמשך לאותו פוסט נראה רק הוגן לכתוב גם איך החיים נראים באנקונדה כדי שתוכלו לבחור את הגישה ושיטת העבודה המתאימה לכם. ## שתי הבעיות הגדולות של אנשים עם pip פיפ הוא כלי ניהול החבילות של פייתון, ולמרות שהוא עושה הרבה דברים נכון יש לו שתי בעיות שממש יכולות להרגיז, ובמיוחד כשמגיעים לעבוד על חבילות גדולות: 1. פיפ לא כל כך טוב בניהול תלויות. אם התקנתי NumPy בשביל פרויקט ואחרי חצי שנה אני מתקין חבילה אחרת לגמרי שתלויה בגירסה מתקדמת יותר של NumPy, אז פיפ לא יזכור שפעם הוא התקין לי NumPy בגירסה ישנה יותר ועכשיו אולי הקוד שלי תלוי בגירסה הישנה יותר, ופשוט ינסה לשדרג את NumPy כדי שיתאים למה שהחבילה החדשה צריכה. זה אומר שכל התקנת חבילה עלולה לשבור לנו קוד קיים. 2. פיפ לא כל כך טוב בחבילות שמערבות קוד C. בחבילות כאלה לפעמים צריך לקמפל דברים מקומית בזמן ההתקנה, ופיפ יצטרך שכל כלי הפיתוח בעזרתם מקמפלים דברים יהיו מותקנים לכם על המכונה. כך לדוגמה לא מזמן ביליתי מספר שעות בהתקנת p5 על מחשב חדש, בגלל שההתקנה דרשה המון ספריות וכלים שבכלל לא קשורים לפייתון רק בשביל החיבור לקוד נייטיב. העובדה שהתקנת p5 עבדה חלק על מחשב אחר רק כמה ימים קודם רק החמירה את מצב הרוח, כי בעבודה עם pip אין לי דרך לדעת שחבילה מסוימת על מכונה מסוימת הולכת לעשות בעיות. ## המטרה של אנקונדה אנקונדה לוקח כיוון אחר והרבה יותר בוגר בגישה לניהול חבילות: במקום להפיץ לכם קוד מקור ותתמודדו אתם עם הקומפילציה, אנקונדה כבר מגיע עם חבילות מקומפלות לכל סביבה שאפשר לדמיין. בנוסף בכל התקנה אנקונדה ידווח לכם איזה ספריות הולכות לשנות גירסאות כדי שתוכלו לקבל החלטה מושכלת האם אתם באמת רוצים להמשיך בתהליך למרות הסיכון. אנקונדה הוא הפצת פייתון שכוללת מאות חבילות הקשורות לעולם ה Data Science וכוללת כלי בשם Conda שהוא מנהל חבילות שיודע לעבוד עם חבילות בינאריות ומנהל תלויות טוב יותר בהשוואה ל pip. מסיבה זאת חבילות שזמינות דרך אנקונדה יותקנו בלי בעיה בכל מקום ופרויקטים שמשתמשים באנקונדה יעבדו בצורה אמינה יותר בין מכונות. אנקונדה הוא הפצה מסחרית, שכוללת רכיבי קוד פתוח חופשיים לשימוש (אותם נראה בהמשך הפוסט) בשילוב עם חבילות תמיכה. הבחירה באנקונדה מאוד מקובלת בעולם ה Data Science אבל היא יוצרת תלות בתוכנה מסחרית שלא כולם אוהבים ולכן אנחנו פחות רואים אותה בעולמות אחרים של פייתון. אנקונדה תומכת בכל מערכות ההפעלה ובעמוד הזה תמצאו הוראות התקנה על חלונות, מק ולינוקס: https://docs.anaconda.com/anaconda/install/ ## התקנת פייתון חדש ויצירת סביבה עבורו אחרי שסיימתי להתקין את אנקונדה אני יכול להפעיל משורת הפקודה את הפקודה conda כדי להתחיל ליצור סביבות. לפני שהפעלתי את סביבת האנקונדה הראשונה שלי אני מפעיל את פקודת ה info כדי לראות שהכל מותקן כמו שצריך:

$ conda info

     active environment : None
            shell level : 0
       user config file : /home/ynon/.condarc
 populated config files : /home/ynon/.condarc
          conda version : 4.8.3
    conda-build version : 3.18.11
         python version : 3.8.3.final.0
       virtual packages : __glibc=2.31
       base environment : /home/ynon/anaconda3  (writable)
           channel URLs : https://repo.anaconda.com/pkgs/main/linux-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/linux-64
                          https://repo.anaconda.com/pkgs/r/noarch
          package cache : /home/ynon/anaconda3/pkgs
                          /home/ynon/.conda/pkgs
       envs directories : /home/ynon/anaconda3/envs
                          /home/ynon/.conda/envs
               platform : linux-64
             user-agent : conda/4.8.3 requests/2.24.0 CPython/3.8.3 Linux/5.4.0-58-generic ubuntu/20.04.1 glibc/2.31
                UID:GID : 1000:1000
             netrc file : None
           offline mode : False

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

$ conda env list
# conda environments:
#
base                  *  /home/ynon/anaconda3

נ.ב. - אחרי שכתבתי את זה הגעתי במקרה לקישור המרתק הזה: https://berthub.eu/articles/posts/reverse-engineering-source-code-of-the-biontech-pfizer-vaccine/ שמספר על מבנה החיסון לקורונה (מראה את רצף ה RNA ששתלו בו) וגם שם אותו סיפור חוזר - המון טריקים בבניית ה RNA לחיסון היו ידועים כבר תקופה ארוכה. בלי להתבסס על העבודה הקודמת זה פשוט לא היה מצליח. קשה מאוד להבין התפתחויות גדולות בתוך עולם תוכן אם אנחנו לא חלק מהפעילות השוטפת ורואים את ההתפתחות ההדרגתית

# לא חדש רובי 3 יצא השבוע ואחד הפיצ'רים המלהיבים בו הוא התמיכה ב Type Hints. אבל כשנכנסים לפרטים מזהים ש: 1. התמיכה ב Type Hints היא בסך הכל שילוב כברירת מחדל של ספריה שכבר קיימת תקופה ארוכה שנקראת rbs. 2. התחביר של Type Hints מוכר כבר לכל מי שהיה בשיחה הזאת - והוא פשוט תחביר rbs. 3. ה Type Checker (נקרא steep) לא נכלל כחלק מרובי, אבל גם הוא כבר נמצא בפיתוח תקופה ארוכה ומתמודד מול Type Checker בתחביר אחר שנקרא Sorbet. אז אותה הודעה על תמיכה ב Type Hints שעשויה להישמע מלחיצה למי שקורא את זה בפעם הראשונה בהכרזה על הגירסה (וואו מטורף עכשיו יש לי דבר חדש וגדול ללמוד מאפס), תישמע די סתמית למי שכבר נמצא בתוך השיח וכבר שיחק עם rbs בשנה וחצי האחרונות. והלקח כאן הוא גדול יותר מרובי ויכול לעזור בכל שפה: אנחנו לא יודעים איזה רעיון חדש הולך לנצח ואיזו שיטה חדשה תהפוך לדרך הסטנדרטית לעשות דברים, אבל זה אף פעם לא נוחת עלינו מהשמים. בכל טכנולוגיה בה אתם עובדים בצורה רצינית משתלם גם להקשיב לשיח הפנימי ולנסות כל הזמן רעיונות חדשים. כך כשהרעיונות האלה יהפכו לדבר הגדול הבא אתם תוכלו לחייך מהפינה שלכם ולהגיד ברוגע "אה סבבה אני כבר מכיר את זה".

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

C:\MyPythonEnvs\helloworld\bin\activate.bat

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

$ pip install pyglet

בעבודה מתוך PyCharm הסביבה הוירטואלית נוצרת אוטומטית כשאני יוצר פרויקט חדש והתקנת מודולים מתוך התפריט אוטומטית תתקין אותם לתוך הסביבה הוירטואלית של הפרויקט. אחרי ההתקנה אני יכול לכתוב קובץ Python שמשתמש במודול pyglet ולהפעיל אותו:

$ python hellopyglet.py

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

pip freeze > requirements.txt

ועל מכונת היעד בשביל להתקין את כל המודולים עם הגירסאות הנכונות מתוך הקובץ requirements.txt נפתח סביבה וירטואלית חדשה ובתוכה נפעיל:

$ pip install -r requirements.txt

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

# טיפים לעבודה יעילה על מספר סביבות פייתון במקביל ברירת המחדל בהתקנת פייתון היא התקנה גלובאלית לכל המערכת. יש בזה משהו מאוד נוח כשרק מתחילים לתכנת ופשוט אפשר לכתוב כל קוד פייתון שרוצים ולהריץ אותו בלי שנצטרך לדאוג להתקנות או הגדרות. הבעיה מתחילה כשהפרויקט שלנו גדל ואנחנו מתחילים להשתמש בחבילות חיצוניות, או כשאנחנו רוצים להפעיל על אותה מכונה מספר תוכניות Python שכל אחת נכתבה בזמן שונה ונבדקה על גירסת פייתון שונה. בעולם הפייתון פותחו המון כלים ושיטות עבודה כדי לעזור לנו לעבוד בצורה יעילה תוך התקנת מספר גירסאות במקביל. בגלל שיש המון כלים מצד אחד קל ללכת לאיבוד ולא לדעת במה לבחור, ומצד שני יש המון שיטות עבודה טובות ודרכים יעילות בהן אנשים רגילים לעבוד. בהמשך הפוסט אספר על שיטת העבודה שלי לניהול מספר פרויקטים בגירסאות פייתון שונות ואנסה לעשות סדר במושגים כדי שיהיה לכם קל לבחור את הכלים ושיטת העבודה המתאימים לכם. ## התקנת מספר גירסאות פייתון עם pyenv האתגר הראשון שלנו בעבודה עם פייתון הוא לברוח מההתקנה הגלובאלית של גירסה אחת של פייתון למכונה ולעבור למבנה של התקנה קלילה יותר בה אנחנו יכולים להתקין עוד גירסאות בלי לגעת בתיקיות מערכת וגם לעבור בין גירסאות מותקנות בצורה חלקה. אני משתמש בכלי בשם pyenv בשביל זה. פייאנב מתקין תיקיה של קבצי הפעלה "מזויפים" (נקראים shims) ובאופן אוטומטי כשאנחנו מפעילים את הפקודה python מתוך תיקיית ה shims הפקודה מזהה איזה גירסת פייתון אנחנו "צריכים" ומפעילה את הגירסה הנכונה. עכשיו צריך להגיד אני משתמש בחלק מאוד קטן מהיכולות של pyenv ונעזר בו רק בשביל להתקין גירסאות פייתון על המחשב ולעבור ביניהן. אני לא משתמש במנגנון שלו שמאפשר בחירת גירסת פייתון ספציפית לפרויקט או במנגנון האינטגרציה עם סביבות וירטואליות. בשביל להתקין את pyenv יש לכם תהליך די מסורבל אבל לשמחתנו חד פעמי שמתואר טוב בדף ה README שלהם. זה הלינק עבור מכונות מק ולינוקס: https://github.com/pyenv/pyenv וזה הלינק עבור מכונות ווינדוס: https://github.com/pyenv-win/pyenv-win אחרי שסיימנו את ההתקנה אפשר להתחיל לבלות. הפקודה הבאה מציגה את כל גירסאות הפייתון המותקנות אצלי על המכונה:

$ pyenv versions
  system
  3.8.6
* 3.9.0b5 (set by /home/ynon/.pyenv/version)

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

$ pyenv shell 3.8.6
$ python --version
Python 3.8.6

פייאנב מתקין את כל הקבצים שלו בתיקיית ~/.pyenv. בתוך תיקיה זו נמצאת תיקיית versions בה נמצאות כל הגירסאות שהוא התקין. בשביל להתקין גירסה חדשה משתמשים ב install:

$ pyenv install 3.9.0b5

ואם אתם עובדים עם IDE לדוגמה PyCharm אפשר פשוט לטעון כל אחת מגירסאות הפייתון שהותקנו לתוך ~/.pyenv/versions ל PyCharm כדי שגם הוא ידע לעבוד איתן. ## יצירת סביבה לאוסף פרויקטים עם venv עכשיו אנחנו יודעים להתמודד עם מספר פרויקטי פייתון שכל אחד מהם צריך גירסת פייתון אחרת, אבל עדיין נשארה בעיה מה קורה אם יש לי מספר פרויקטים שעובדים כולם על אותה גירסת פייתון אבל עם מודולים חיצוניים אחרים. בשביל לפתור את זה יש לנו קונספט נוסף להכיר שנקרא Virtual Environment. סביבה וירטואלית היא כמו התקנה נפרדת של פייתון אבל רק בשביל המודולים החיצוניים. כל פעם שאנחנו "נכנסים" לסביבה וירטואלית הכלים pip ו python יסתכלו על המודולים שמותקנים בתוך סביבה זו, וכשאנחנו יוצאים מהסביבה הוירטואלית הכלים יחזרו להסתכל על גירסת הפייתון הכללית. סביבה וירטואלית גם היא לא משויכת ספציפית לפרויקט וזה בעצם משהו שאני "נכנס" אליו כשאני רוצה להתחיל לעבוד על הפרויקט או על כמה פרויקטים שקשורים אחד לשני וצריכים את אותם מודולים. אפשר ליצור סביבה וירטואלית פר-פרויקט, או משותפת לכמה פרויקטים או כל שילוב שתרצו. בעבודה עם PyCharm ביצירת פרויקט חדש בצורה אוטומטית תיווצר לנו גם סביבה וירטואלית בשבילו. בעבודה משורת הפקודה מחוץ ל PyCharm אני משתמש בפקודה הבאה כדי ליצור סביבה וירטואלית עבור גירסת הפייתון הנוכחית:

python -m venv ~/python-venvs/helloworld

סביבה וירטואלית צריכה להישמר בתיקיה ושם התיקיה הוא הפרמטר שהעברתי ~/python-venv/helloworld. לאחר יצירת הסביבה אני נכנס אליה עם הפקודה:

$ source ~/python-venvs/helloworld/bin/activate

או בחלונות באמצעות הפקודה:

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

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

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

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

function padded(num) {
  return num > 10 ? String(num) : '0' + num;
}

נו, מביך והכל אבל פה בבלוג מותר לדבר על הכל, אפילו על טעויות Off By One. קודם כל הבאג למי שלא ראה מיד קשור לסימן ה"גדול מ-" שהיה צריך להיות "גדול-שווה" או גדול מ-9. עשר הוא גם מספר דו-ספרתי. אבל יותר מעניין - איך מונעים שטויות כאלה בעתיד? הנה שלושה רעיונות: 1. כיוון אחד יהיה לבדוק טוב יותר. כלומר לכתוב לכל פונקציה קטנה תוכנית בדיקה שתוודא שהפונקציה באמת תמיד עושה את מה שהיא אמורה לעשות. במקרה של padded כנראה שבבדיקה רגילה לא הייתי חושב לבדוק דווקא את 10 (כי אם הייתי חושב עליו כשכתבתי את הקוד ממילא הבאג לא היה קורה), ולכן צריך לחשוב על בדיקה שרצה בלולאה על כל המספרים מ-0 עד 99, שולחת אותם ל padded ומוודאת שהאורך של התוצאה הוא תמיד 2. הסיכוי לכתוב קוד בדיקה מהסוג הזה על כל פונקציה קטנה שאני כותב הוא באזור ה-0. 2. כיוון שני יהיה להשתמש בספריה חיצונית. במקרה של padded הספריה החיצונית אפילו די מפורסמת ונקראת left-pad. הקוד היה נראה כך:

impor leftPad from 'left-pad';

function padded(num) {
    return leftPad(String(num), 2, '0');
}

זה ממש פשוט אבל קצת מביך להשתמש בספריה חיצונית בשביל דבר כל כך פשוט כמו ריפוד משמאל. 3. כיוון שלישי ספציפי למקרה הזה הוא להיזכר שאחרי הפארסה של left-pad כבר הוסיפו ל JavaScript את הפונקציונאליות והיום היה אפשר לכתוב את הקוד הזה:

function padded(num) {
    return String(num).padStart(2, '0');
}

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

function padded(num) {
    return ('0' + num).slice(-2);
}

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

הי חברים בימים האחרונים הבוט נכנס לתרדמת אז הערוץ לא עודכן. הערתי אותו עכשיו וגם הדבקתי את הפוסט האחרון. כל הפוסטים נמצאים גם באתר אם אתם מתגעגעים והבוט נרדם שוב: https://www.tocode.co.il/blog/