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

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

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

מעט אנשים מפרסמים מאמרים חדשים על SQL, ועוד פחות מהם משתפים את המאמרים האלה. מעט אנשים כותבים מאמרים חדשים על REST היום, ועוד פחות מהם משתפים מאמרים כאלה. מעט אנשים יספרו לכם בהתלהבות על Design Pattern מסוימת שהם בדיוק יישמו, ועוד פחות מהם ישתפו מאמר כזה.

ובכל זאת מתכנתים כותבים SQL כל יום (למרות שכולם מדברים על NoSQL או על ORM).

ובכל זאת רוב ה APIs שתעבדו מולם עדיין בנויים על REST (למרות שכולם מדברים על GraphQL).

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

ולמרות שרוב קוד ה JavaScript החדש שנכתב היום משתמש בכתיב Object Oriented ובכל היכולות החדשות של השפה, כל מתכנתי ה JavaScript הרציניים שאני מכיר יודעים איך לעבוד עם Prototype, יודעים מה זה bind ו apply וישמחו לספר לכם למה אף פעם לא כדאי להשתמש ב document.write.

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

אחת הדרכים הכי יעילות ללמוד טוב יותר נושא היא ההליכה עד הקצה, וזה מורכב מ-2 חלקים: למצוא את הקצה, ולעבור אותו. וכן הקצה הוא קודם כל בראש שלכם.

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

$ git checkout -b my-new-feature

ואז לעבוד, לעשות את הקומיטים ובסוף למזג.

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

1. לנסות לשנות את הקוד לפני שיצרתי את הענף (ואז לראות איך ליצור את הענף עם הקוד שכתבתי).

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

3. לנסות דרכים אחרות ליצור את הענף (למשל עם switch או עם branch), ולקרוא בתיעוד מה ההבדל בין הדרכים.

4. לנסות ליצור ענף בשם לא נכון ואז לתקן לו את השם.

5. לנסות ליצור ענף עם שם שכבר קיים ולראות איזה שגיאה מקבלים.

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

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

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

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

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

זה לא קל להביא כלי חדש, זה לא קל ללמוד כלי חדש וזה לא קל להתחיל לעבוד עם כלי חדש. ובכל זאת אנחנו יכולים לבחור:

האם אני רוצה להיות החבר שמביא את הכלי החדש?

האם אני רוצה להיות החברה שלומדת ראשונה ועוזרת לו להטמיע את הכלי?

האם אני מוכן להשקיע רק כשאני רואה שהכלי הזה באמת נותן יותר ערך?

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

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

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

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

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

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

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

האם רצית להרוויח הכי הרבה שאת יכולה?

האם רצית יותר גמישות כדי להיות עם הילדים?

האם חלמת לעבוד מכל מקום בעולם?

האם כדי לקדם נושא שקרוב ללבך?

או שסוג העבודה שאת חולמת לעשות לא זמין לשכירים?

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

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

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

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

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

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

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

השלישי יהיה הפריצה לחשבון ה Rubygem של מאת'יו מאנינג, היוצר של חבילת rest-client ל Ruby. הפורצים השתמשו בחשבון של מאת'יו כדי להעלות גירסא חדשה ל Rubygem הכוללת דלת אחורית כך שכל שרת שמשתמש בחבילה יעבוד בשבילם בכריית ביטקוינים.

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

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

1. חומות הגנה בין יישומים שונים ובין Services שונים.

2. מנגנונים של זיהוי אוטומטי כש Service או מכונה מתחילים להתנהג בצורה חשודה.

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

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

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

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

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

קחו את התוכנית הבאה לדוגמא:

import re
import sys

for line in sys.stdin:
    if re.search(r'\b[A-Z][a-z]*\b', line):
        sys.stdout.write(line)
    else:
        print("No interesting words found")

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

from modulefinder import ModuleFinder
from stdlib_list import stdlib_list
libraries = stdlib_list("3.7")
import sys
finder = ModuleFinder()
finder.run_script('hello.py')

print('Loaded modules:')
for name, mod in finder.modules.items():
    if '.' in name: continue
    if name in sys.builtin_module_names: continue

    print('%s: ' % name, end='')
    if name in libraries:
        print("Builtin module")
    else:
        print("External module")

כמה הערות:

1. בשביל להשתמש ב modulefinder אנחנו צריכים בסך הכל להריץ את הסקריפט עם finder.run_script ואחרי זה לקרוא את הרשימה מ finder.modules.

2. אני משתמש בשתי היוריסטיקות כדי לדעת אם מודול הוא חלק מפייתון. זה מכסה חלק מהמקרים אבל עדיין לא את כולם. הספריה stdlib_list לוקחת מהאתר של פייתון את רשימת המודולים ששייכים לגירסא מסוימת, והמשתנה sys.builtin_module_names מכיל את רשימת המודולים שבנויים לתוך פייתון. עדיין יש מודולים שהם חלק ממודול אחר, לדוגמא _ssl שהוא חלק ממודול ssl ואותם הסקריפט לא מזהה כמודולים פנימיים. רעיונות להיפטר ממודולים אלה יתקבלו בברכה.