ToCode

# הסבלנות משתלמת? קושי אמיתי בחיים הוא לדעת מתי להחליט ומתי לחכות עם ההחלטה. בנדלן יש לפעמים את התחושה שככל שמחכים המחיר רק עולה וכדאי לקנות בית הכי מוקדם שאפשר - אבל מה לגבי פיתוח? האם גם אצלנו "המחירים רק עולים"? נו, לפעמים. אני יכול להתקשקש שעות בבניית קונפיגורציית Webpack הכי מושלמת שאפשר, כשברור שהייתי יכול להתחיל לעבוד גם בלי שום קונפיגורציה ואפילו בלי וובפאק, ולהוסיף אותו במועד מאוחר יותר אחרי שהאפליקציה עובדת; מצד שני ככל שאני אחכה עם הקמת תשתית לבדיקות אוטומטיות כך יהיה לי יותר קשה להתחיל לכתוב את הבדיקות כשהמערכת גדלה ואני רק אצבור פער, כלומר המחיר יעלה. אני יכול להתקשקש שעות בבחירת פיתרון לסריקה אוטומטית של הקוד שלי כדי לחפש בעיות אבטחה בספריות שאני תלוי בהן ואולי אפילו לבנות מנגנון אוטומטי שיודיע לי כל פעם שהתגלתה חולשה חדשה בספריה שאני תלוי בה, כשברור שעדיף לי להתקדם עם הפיתוח ולשדרג תלויות כל פעם כשיש לי זמן לזה. לעומת זאת כדאי לי מאוד ללמוד על אבטחת מידע לפני שאני כותב שורת קוד ראשונה של פרויקט אמיתי, כי לתקן ארכיטקטורה לא מאובטחת רק נהיה יותר קשה ככל שהמערכת גדלה. אני יכול להתקשקש שעות בבניית העיצוב הכי יפה לאפליקציה שלי במקום לרוץ עם HTML/CSS פשוט ומדויק, כשברור שלפני שהמערכת עובדת ולפני שיש לי משתמשים אף אחד אפילו לא רואה את העיצוב החדשני. מצד שני אם לא אשקיע ב UX טוב לפני שאני מתחיל לכתוב את הקוד מחיר התיקון רק יעלה ככל שהמערכת הופכת מורכבת יותר. יותר מדי פעמים אנחנו נתקעים על החלטות לא חשובות ועוצרים תהליך פיתוח שלם כשאפשר בקלות לעקוף אותן, ויותר מדי פעמים אנחנו משאירים החלטות חשובות לסוף כשמחיר התיקון רק עולה עם כל יום שעובר. כשאתם תקועים על החלטה (או חושבים לדלג עליה) שווה לשאול את עצמכם "אם אני עכשיו טועה, כמה יעלה לי לתקן את זה בעוד חצי שנה?"

# איך להפעיל Selenium עם דפדפן בלי GUI על Github Actions אחד הדברים שאני אוהב ב Github Actions (בטח יש את זה גם ב Gitlab ובמקומות אחרים, פשוט אני עובד בינתיים עם גיטהאב) הוא העובדה שכבר בסביבת ברירת המחדל שלהם הם התקינו המון המון ספריות וקינפגו את הכל שיעבוד יפה יחד. בסיפור היום רציתי להפעיל את Selenium אבל לא במצב Headless Chrome אלא במצב עבודה של כרום רגיל, ועל שרת מרוחק כלומר בלי GUI. עם גיטהאב אקשנס זה לקח פחות מעשר דקות עבודה. הנה מה שצריך: ## הסקריפט זה סקריפט לדוגמה שמריץ Chrome במצב גרפי רגיל באמצעות סלניום אבל בתוך סביבה גרפית שנקראת Xvfb. סביבה זו היא פשוט סביבה גרפית וירטואלית כך שמבחינת כרום הוא כותב למסך רגיל אבל מבחינת השרת אין שום פלט:

from pyvirtualdisplay import Display
from selenium import webdriver

with Display() as disp:
    driver = webdriver.Chrome()
    driver.get('https://www.tocode.co.il')
    print(driver.title)
    driver.close()

הסקריפט נכנס לאתר טוקוד ולוקח משם את שורת הכותרת וידפיס אותה למסך. אם תתקינו את הספריות ותריצו אצלכם על המכונה, ובהנחה ש Xvfb מקונפג כמו שצריך, מה שתראו זה רק את שורת הכותרת של הדף הראשי באתר בלי שום GUI מהדפדפן. ## ה Workflow בשביל להריץ את זה אוטומטית בתוך Github יצרתי תיקיה בשם .github, בתוכה תיקיה בשם workflows ובתוכה קובץ בשם selenium.yml. זה התוכן שלו:

name: selenium-demo

on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: [3.8]

    steps:
    - uses: actions/checkout@v2
    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v1
      with:
        python-version: ${{ matrix.python-version }}
    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install -r requirements.txt
    - name: Run file
      run: |
        python print_tocode_header.py

השוס כאן הוא שאין שום התקנה של xvfb, כרום או כרומדרייבר. זה הכל מגיע אוטומטית מ Github Actions בזכות הבחירה ב ubuntu-latest בתור סביבת ההרצה. ## ריפוזיטורי לדוגמה רוצים לראות את הקוד בפעולה? כל מה שצריך לעשות זה fork לריפו שלי ואז להכניס שינוי כלשהו לקוד. באופן אוטומטי ה Workflow ירוץ בכל קומיט שלכם: https://github.com/ynonp/github-selenium-xvfb-demo אפשר לראות את תוצאות ההרצה בטאב Actions לדוגמה אלה ההרצות לדוגמה שאני ביצעתי בשביל לכתוב את סקריפט הדוגמה: https://github.com/ynonp/github-selenium-xvfb-demo/actions

# העולם לא צריך עוד Pull Request אוקטובר מגיע וכל שנה מחדש אירוע Hacktoberfest של Digital Ocean מעורר תגובות דומות: מתחזקים של פרויקטי קוד פתוח לא מבינים למה פתאום הם מקבלים PR-ים מיותרים מאנשים שלא מבינים כלום בפרויקט שלהם. התרבות הפופולרית מעודדת מתכנתים במיוחד צעירים להשתתף "בקהילת המפתחים", ללכת לכנסים להגיש Pull Requests, להשתתף בפרויקטי קוד פתוח ואפילו להרים פרויקט משלהם. אבל לפעמים נדמה לנו שהעבודה נעשית יותר בשביל להגיד "עשיתי" מאשר בשביל לייצר איזושהי תרומה אמיתית לקהילה. הדרך לתרום קוד מתחילה בשאלות - מה המטרה של פרויקט הקוד הפתוח הזה? מה הם צריכים? ואיך אני יכול לעזור להם? וכן זה יכול לקחת זמן לייצר מערכת יחסים טובה עם מנהלי הפרויקט ולאט לאט לקבל משימות יותר רציניות. הטיפ החשוב לגבי קוד פתוח הוא ש PR איכותי שהתקבל לפרויקט קוד פתוח גדול שווה הרבה הרבה יותר מ-10 PR-ים שמתקנים שגיאות כתיב, אינדנטציה או מוסיפים שורה לתיעוד. העולם לא צריך עוד PR, הוא צריך עזרה בעבודה הקשה שאין לו זמן לכתוב לבד.

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

# איפה כונן D? אחד הקשיים בלימוד שפה חדשה הוא ללמוד את כל המילים - במקום מיטה לדעת להגיד bed ובמקום שולחן table זה תיק רציני. ועד כמה שזה נראה קשה האתגרים האמיתיים הם להבין את המילים שלא קיימות בשפת האם שלך ולהבין את הדרכים החדשות לשאול את השאלות. כך כשאנחנו עוברים מ Windows ל Linux ברור שנצטרך להתרגל לכתוב ls במקום dir כל פעם שרוצים להציג את רשימת הקבצים. אבל הרבה יותר מוזר יהיה הרגע שנשאל "איך מגיעים לכונן D". ההבנה שכונן הוא בעצם תיקייה ושאנחנו צריכים לעשות פעולת mount כדי שנוכל לגשת לכונן הזה היא יותר ממה שרציתי לדעת. ואפילו יותר מסובך יהיה להתרגל ללכת קודם כל לשורת הפקודה במקום לממשק הגרפי כדי לפתור בעיות, או להתרגל לעבוד בתור משתמש רגיל במקום בתור מנהל מערכת. העניין הוא שהדברים הולכים יחד ועד שלא מתרגלים לעבודה משורת הפקודה או לעבודה בתור משתמש רגיל קשה לראות את ההיגיון בהרבה מאוד בחירות אחרות של המערכת. אין תשובה קלה לשאלה "מתי מדברים ב Past Perfect Simple", כי לפני שעונים עליה צריך להתרגל לדבר אנגלית.

# מה בכל זאת כן עובד ב Zoom בעקבות פוסט שהעליתי לפני כמה ימים נגד הדרכות בזום לא מעט אנשים מיהרו להגיב שלא הכל רע בזום וזו דווקא אחלה פלטפורמה. והאמת שהם צודקים בהרבה מקרים זום היא אחלה תוכנה. אני מנוי משלם ומאוד מרוצה של זום עוד הרבה לפני הקורונה וכנראה אמשיך הרבה אחרי. הבעיה היא לא בזום אלא בשימוש לא נכון שאנשים עושים בה. אז בשביל שלא נצא עם הרגשה שלילית הנה כמה דברים שעובדים לי ממש טוב בזום ושווה גם לכם לנסות: ## פגישות סינכרון (מה שנקרא Stand Up Meeting) כשיום עבודה מתחיל בעשר דקות זום בהשתתפות כל חברי הצוות לתזכורות חשובות ועדכונים אנחנו יודעים שיום העבודה הזה הולך להיות הרבה יותר ממוקד, במיוחד כשהצוות מבוזר. אין מה לעשות קשה מאוד לקיים שיגרת עבודה וסינכרון כשאנחנו רחוקים אחד מהשני, והעובדה שיש מקום שבו כולם מסתכלים עליך ומקשיבים לך עוזרת לאנשים להתרכז בדברים החשובים. חשוב לשים לב בפגישות כאלה לקצר, להיות ממוקדים ולשלוח אג'נדה ברורה לפני הפגישה. כשפגישת סינכרון מתארכת מעבר ל 10-15 דקות זה כבר מתחיל לשעמם ולבזבז את הזמן של כולם. ## עבודה בקבוצות קטנות להשגת תוצרים ברורים אם אני צריך לשבת לכתוב פיצ'ר עם עוד חבר זום יכול להיות כלי עבודה מדהים. אני משאיר את הזום פתוח, כל אחד עובד על החלק שלו וכשצריך לדבר שולחים פינג לצד השני ועולים לשיחת Voice. בזכות IDEs בענן אנחנו יכולים לעבוד על אותה סביבת פיתוח ממש ואותו הקוד, וכך אני יכול לראות את העבודה של החבר או החברה בזמן שהם מקלידים ולשאול שאלות כשמשהו נראה לי מוזר. שעתיים של עבודה כזו בשיתוף פעולה, שרוב הזמן נמצאים ב Mute אבל כן מדברים כשצריך, או בפורמט של Pair Programming יכולות להיות מאוד פרודוקטיביות - הרבה יותר מאשר אם אני צריך לשלוח כל פעם שאלה בסלאק ולחכות לתשובה כתובה. ## מפגשי סינון ומכירה או וובינרים לקבוצה הומוגנית וובינרים שמתחילים ב 100 משתתפים ומסתיימים עם 10 משתתפים פעילים הם בעיניי מעולים, כי הם עוזרים לאותם עשרה אנשים שבאמת מתעניינים במוצר שלך להבין שיש פה משהו מעניין. הוובינרים האלה מעניינים כי הם עוברים ב Live ולכן הרבה אנשים נרשמים, וכן 90% מהאנשים עוזבים באמצע או פשוט מפסיקים להקשיב בשלב מסוים. הוובינרים האלה עובדים לא בגלל שהמרצה מצליחה להתאים את עצמה לקהל (זה לא אפשרי בפורמט של זום), אלא דווקא בגלל שהיא לא עושה את זה. וכן, השתתפתי גם בוובינרים שהיו מבוססי Q&A וגם הם תמיד הגיעו לאותו מקום: מרצה שבאה להעביר מסר מסוים ובוחרת את השאלות שמתחברות לאג'נדה שלה, וקהל שמאוד שמח לקבל את המסר הזה. אם הצלחתם לסיים וובינר עם 10 משתתפים פעילים רוב הסיכויים שה 10 האלה גם ימשיכו לקנות את המוצר שלכם. וככל שאתם מעלים את האחוזים כך מצבכם טוב יותר. כאן בטוקוד העברתי המון וובינרים (לימודיים לא מכירתיים) בשיטה זו ואתם יכולים לראות את ההקלטות בדף הקלטות מוובינרים. חלק מההקלטות ידברו אליכם, חלק יהיו לכם מהירים מדי וחלק איטיים מדי. וזה הגיוני. המטרה היא לספר סיפור ואם הסיפור מדבר אליכם מה טוב. ## מפגשי תרגול כשכולם באותו קצב עולם חדש וגדול שזום פתחה בתקופה האחרונה הוא העולם של מפגשי תרגול בו כולם מתקדמים באותו קצב: שיעורי ריקוד בזום, אימוני ספורט בזום, שיעורי בישול או קיטנת מדעים. המשותף לכולם הוא שהמרצה מראה משהו ואז כולם חוזרים על זה. המרצה יכולה להסתכל איך כל אחד מבצע ולתקן טעויות בזמן אמת (תלוי בגודל הקבוצה ובמרצה כמובן). מפגשים כאלה הם הרבה הרבה יותר כיפיים מלנסות לבשל לפי הוראות ביוטיוב: כשאתה מבשל בזום ומפשל בתחילת המתכון יהיה מי שיתקן אותך בזמן אמת ולא תצטרך לחכות שהעוגה תצא שטוחה מהתנור בשביל להבין את הבעיה. גם תרגול שפות יכול לעבוד בזום, אם המרצה מוכן להעביר את המיקרופון בסבב ולהקשיב לכל אחד מדבר, או אם עובדים בשיטה של משחקי חברה ושאלונים (למשל חידוני אוצר מילים) זה גם אחלה כי אפשר לקבל אווירה של משחק או תחרות וכך יש יותר חשק להתאמן.

# מילים שקשה להגיד אחד ההבדלים שמתכנתים מאוד רגישים אליו בין שפות תכנות הוא היכולת לבצע בקלות פעולות מסוימות בשפה אחת, כאשר בשפה אחרת צריך לעבוד מאוד קשה בשביל לקבל את אותה התנהגות. כמה דוגמאות שקופצות לראש: לכל פונקציה ב JavaScript יש מאפיין משם length שמחזיר כמה פרמטרים הפונקציה מצפה לקבל. ב Python קצת יותר קשה לגלות את זה אבל עדיין אפשרי עם חבילת inspect, ב Ruby יש לכל פונקציה מאפיין בשם arity שמחזיר את הערך וב Clojure אנחנו צריכים לקפוץ שמיניות באוויר בשביל למצוא אותו. הפונקציה merge של Hash ממזגת בין שני מילונים ב Ruby ומאפשרת לנו בקלות להחליט מה לעשות עם ערכים מתנגשים. כך קוד רובי הבא יכול לשלב בקלות ערכים משני מילונים למילון שלישי:

a = { a: 10, c: 30 }
b = { a: 5, b: 20 }
res = a.merge(b) {|k, v1, v2| v1 + v2 }

# now res is: { a: 15, b: 20, c: 30 }

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

a = { 'a': 10, 'c': 30 }
b = { 'b': 20 }
res = dict(**a, **b)
# now res is: { 'a': 10, 'b': 20, 'c': 30 }

אבל זה לא מה שרצינו ובשביל לשלב את המילונים עם פונקציית חיבור שלנו נצטרך להתאמץ יותר ולכתוב לולאה מסודרת. ויש עוד מאות כעסים קטנים כאלה בכל מעבר בין שפות, וזה בסדר. שווה לזכור שבכל מעבר כזה בין שפות מאוד קל למצוא חבילות שסוגרות את הפער. גם אם ל JavaScript אין את random.randint של פייתון, אנחנו עדיין יכולים לקבל פונקציונאליות זהה מ lodash; חבילת mergedict של פייתון מאפשרת לשלב בצורה אלגנטית בין מילונים ולקבוע מה לעשות עם ערכים מתנגשים בקלות ממש כמו ב Ruby. ההבדלים האמיתיים בין שפות הם לא בפונקציה מסוימת שנמצאת או לא, אלא בגישה ובהשקפת עולם שונה: האם יש Type System? האם הוא מחייב? האם יש Class-ים? האם יש הגבלה על עומק הרקורסיה? איך בונים קוד מקבילי או מבוזר? האם זה מתקמפל? האם זה רץ על המכונה אליה אני מכוון? (וכמובן חוץ מבחירת שפה ברוב הפרויקטים נצטרך לעשות בחירה הרבה יותר קשה ולבחור Framework. אבל זה כבר סיפור ליום אחר).

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

function getPageCache(opt_doc, opt_w3c) {
  var doc = opt_doc || document;
  var w3c = opt_w3c || false;
  // |key| is a long random string, unlikely to conflict with anything else.
  var key = '$cdc_asdjflasutopfhvcZLmcfl_';
  if (w3c) {
    if (!(key in doc))
      doc[key] = new CacheWithUUID();
    return doc[key];
  } else {
    if (!(key in doc))
      doc[key] = new Cache();
    return doc[key];
  }
}

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

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

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

import pandas as pd

url = 'https://raw.githubusercontent.com/guipsamora/pandas_exercises/master/07_Visualization/Titanic_Desaster/train.csv'
titanic = pd.read_csv(url)

s=pd.cut(titanic['Fare'], bins=[0, 10, 20, 50, 100, 1000], right=True)
data = s.value_counts()

print(data)

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

(0, 10]        321
(20, 50]       216
(10, 20]       179
(50, 100]      107
(100, 1000]     53
Name: Fare, dtype: int64

והנה מאפייני הטיטאניק:

In: titanic['Fare'].describe()
Out:

count    891.000000
mean      32.204208
std       49.693429
min        0.000000
25%        7.910400
50%       14.454200
75%       31.000000
max      512.329200
Name: Fare, dtype: float64

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