ToCode

# כלים ופרויקט צד גיטהאב נותנים לכם היום מקום לאחסן קוד גם לפרויקט פרטי לגמרי בחינם. אתם יכולים לשתף פעולה עם עוד חבר או חברה, לבנות דף בית ב Github Pages ואפילו להריץ בצורה אוטומטית לגמרי בדיקות אחרי כל קומיט כדי לעבוד כמו המקצוענים. גם אם אתם לא יודעים לעצב ב Theme Forest תוכלו למצוא עשרות תבניות יפות לאתרים, כל תבנית באזור ה 15$. יכול להיות שתצטרכו להתאים טיפה לפרויקט שלכם אבל זה לא ייקח יותר מיום עבודה. לינוד ו Digital Ocean ישמחו למכור לכם שרת VPS במחיר של 10$ לחודש שיכול להריץ את הפרויקט שלכם בלי למצמץ. אם אתם לא בקטע של התקנות תוכלו להעלות קצת את הסכום ולקבל מכונה מותקנת מ Heroku. הם גם יוכלו להוסיף לכם אוטומטית מכונות כשהפרויקט יתחיל לצבור תאוצה. אחרי שיש לכם דף נחיתה אפשר להתחיל לבנות רשימת תפוצה של מתעניינים ראשונים במערכת עם מיילצ'מפ. עד אלפיים נרשמים ראשונים זה חינם. פייפאל לוקחים עמלה רק מכל תשלום שבוצע ואין דמי מנוי חודשיים. הם גם לא דורשים מכם לעבור תהליך רישום מסובך או לחתום באופן אישי על מסמכים. הם מציעים SDK בהמון שפות כך שממש קל לשלב סליקה בפרויקט שלכם. האינטרנט מציע את כל הידע שצריך בשביל הצד הטכני של בניית פרויקט צד, ואם אתם מעדיפים משהו יותר מסודר מנוי לטוקוד יעלה לכם 117 ש"ח לחודש, והקורסים כאן ילמדו אתכם את כל מה שצריך: לינוקס בשביל להתקין את השרת, נוד ומונגו בשביל ה Backend וכמובן HTML, CSS ו React בשביל הפרונט. וזמן לקודד? אותו קיבלתם מהקורונה, ואפילו יותר מדי ממנו. עזבו את החדשות, הכל שם ממילא יוצא אותו דבר כל פעם שנכנסים. יותר טוב להתחיל לבנות את הפרויקט צד הקטן שתמיד דיברתם עליו.

# קוראים לזה JSON כשדאגלס קרוקפורד הכריז בתחילת שנות ה 2000 שהכתיב הזה שכולנו משתמשים בו כדי לכתוב אוביקטים ב JavaScript הוא בעצם רעיון טוב לפורמט העברת מידע באופן כללי בין מערכות וקרא לדבר הזה JSON הוא שינה את העולם. הוא נתן לאנשים את המילה שהם חיפשו כדי לשנות את המערכות שהם כתבו, ולאט לאט מערכות עברו להעביר מידע ב JSON במקום ב XML. היום אי אפשר לדמיין מערכת שתשלח מידע בפורמט אחר. שנים אחר כך כש Webmasters עברו לקרוא לעצמם Front End Developers אנשים לא הבינו בהתחלה מה המקצוע הזה בכלל אומר. לאט לאט ביססו הפרונטאנדיסטים את מעמדם בתור המתכנתים שכותבים בעיקר JavaScript ולא נוגעים ב PHP, בניגוד לוובמאסטרים של פעם שעשו הכל. השם איפשר לאנשים להגיד "אני מתכנת Front End" בצורה שאחרים יבינו על מה אתה מדבר, וכך נוצר תפקיד חדש בתעשיה. או בואו ניזכר רגע באחד הספרים הכי משפיעים על פרדיגמת ה Object Oriented Programming - הספר Design Patterns של הרביעיה, שבסך הכל נתן שמות לתבניות שכולם השתמשו בהן גם לפני. אבל בזה שהוא נתן להם שמות הוא הפך אותן ללגיטימיות והפך את השיח סביבן לאפשרי. אחת המתנות הכי יפות שאנחנו יכולים לתת לחבר או חברה בתחילת דרכם המקצועית היא השמות: אה, "אני רואה שכתבת כאן Decorator", או "נראה לי ששווה לך להחליף את זה ב IIFE". הצבעה על השם נותנת לגיטימציה ועוזרת לדבר על הדברים בצורה מדויקת.

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

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

nthice = [lambda x: x * n for n in range(1, 10)]
print(nthice[2](3))

בראש שלי דמיינתי שהקוד ייצור מערך של תשע פונקציות - מה שאכן קרה:

>>> [lambda x: x * n for n in range(1,10)]
[<function <listcomp>.<lambda> at 0x10124a0d0>, <function <listcomp>.<lambda> at 0x10124a160>, <function <listcomp>.<lambda> at 0x10124a1f0>, <function <listcomp>.<lambda> at 0x10124a280>, <function <listcomp>.<lambda> at 0x10124a310>, <function <listcomp>.<lambda> at 0x10124a3a0>, <function <listcomp>.<lambda> at 0x10124a430>, <function <listcomp>.<lambda> at 0x10124a4c0>, <function <listcomp>.<lambda> at 0x10124a550>]

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

# שבעה נושאי Front End שכדאי להשלים בזמן הקורונה התפנה לכם זמן בגלל הקורונה? כבר אין מה לראות בנטפליקס? הנה רשימת קריאה קצרה של נושאים שאם אתם מתכנתי Front End יש סיכוי מסוים שדילגתם עליהם בשוטף ושיעזרו לכם לעשות עבודה הרבה יותר טובה כשהמשבר ייגמר. הרשימה לא לפי סדר מסוים ומשקפת את דעתי האישית בלבד. היא גם לא כוללת נושאים חדשים כמו הודיני או פריימוורקים מלהיבים שאני מניח שאם יתפסו אתם כבר תמצאו את הדרך ללמוד לבד. אני מתמקד רק בנושאים וותיקים שעברו להרבה אנשים מתחת לרדאר. וכמובן מוזמנים להוסיף בתגובות דברים ששכחתי. הראשון הוא CSS Grid. גריד יצא קצת אחרי פלקסבוקס ותפס פחות תשומת לב. הוא נתמך היום בכל הדפדפנים, חוסך הרבה עבודה ומאפשר הרבה עיצובים חדשים. האתר learncssgrid.com מציע מדריך טוב ו gridbyexample מראה הרבה דוגמאות לדברים פשוטים שאפשר לבנות עם גריד. המלצה שניה היא Service Worker. נושא מאוד מעניין שעוזר לבנות עמודי Offline, לשלוח נוטיפיקציות ולשפר ביצועים בעמוד. אפשר להתחיל עם דף ההסבר של MDN בקישור https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers, להמשיך עם זה של גוגל ולסיים בטוטוריאל בקישור https://github.com/Itera/learn-service-worker שכולל משימות לימודיות לכתיבת Service Workers. זה ייקח לכם יום-יומיים יחד עם כל המשימות אבל לדעתי שווה את ההשקעה. מספר שלוש הוא SVG. עם כל ההתלהבות מ CSS וכל האנימציות ודברים מדליקים שאפשר לעשות, אנחנו שוכחים ש SVG מציע הרבה מאוד יכולות שלפעמים יהיה קשה לייצר באמצעות CSS. הוא נתמך בכל הדפדפנים ויכול להיות הפיתרון הטוב ביותר שאתם לא מכירים. המדריך בקישור https://flaviocopes.com/svg/ מאוד מפורט. הרביעי שלי הוא נגישות אתרים. אני יודע אתם אומרים לעצמכם למי באמצע משבר הקורונה אכפת מ WCAG2. אבל באמת שחוקי הנגישות הולכים להישאר איתנו הרבה אחרי משבר הקורונה. הבעיה הכי גדולה כאן היא שזה הנושא שהכי פחות כיף ללמוד אותו, יש המון חומר לקרוא, וגם אחרי שקוראים את הכל עדיין צריך לשחק עם התוכנות כדי להבין יותר טוב איך ליישם את מה שלמדתם. מצד שני אתם תקועים בבית, קורונה מסביב - לא יהיה זמן טוב מזה לקרוא את ההנחיות. מתחילים כאן https://www.w3.org/TR/WCAG/ ואחרי שסיימתם ממשיכים לפירוט כאן https://www.w3.org/WAI/WCAG21/Understanding/. מספר חמש הוא ביצועים. היה על זה באזז מטורף לפני כמה שנים אבל אם במקרה פספסתם אז הקורס של איליה גריגוריק עדיין זמין ביודסיטי והוא מעולה. זה הקישור https://www.udacity.com/course/website-performance-optimization--ud884. לאיליה יש גם ספר על הנושא ששווה לקרוא אחרי הצפיה בוידאו בקישור הזה https://hpbn.co/. השישי הוא קל ונקרא Content Security Policy. משום מה המון אנשים שדיברתי איתם עוד כשהיה מותר לפגוש אנשים מחוץ למסך לא הכירו את זה ולא הבינו עד הסוף את הסכנות ב XSS. אם גם אתם נופלים לקטגוריה הזאת לא צריך להסס ותוכלו לנצל את הסגר כדי לרוץ לסגור את הפער. הייתי מתחיל מהמאמר הזה מ phpguide.co.il שמסביר מה זה XSS, ואחרי זה הולך לבלות איזה חצי יום עם משחק ה XSS. משם ממשיכים לדף ההסבר ב MDN בקישור https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP, ויש גם תקציר בעברית של רן בר זיק. בסוף אחרי אחרי שהבנתם איך CSP עובד המאמר Postcards from the post-XSS world מדמיין קווים כלליים לאיך אנשים יעקפו את ההגנות שלו בעתיד (הוא נכתב ב 2011). יותר מעניינת היא המצגת בקישור https://www.blackhat.com/docs/us-17/thursday/us-17-Lekies-Dont-Trust-The-DOM-Bypassing-XSS-Mitigations-Via-Script-Gadgets.pdf שמסבירה טכניקות מודרניות לעקוף CSP באתרים שמשתמשים בפריימוורקס פופולריים. ואחרון לרשימה זו הוא נושא שמתכנתי JavaScript רבים מתבלבלים בו ואני מדבר על Promises ו Async/Await. הטקסט בקישור https://blog.bitsrc.io/understanding-javascript-async-and-await-with-examples-a010b03926ea מציע הסבר מפורט, עדכני ומלא דוגמאות לכל מה שקשור לתכנות אסינכרוני ב JavaScript ושווה לקרוא אותו ולנסות להריץ בעצמכם את כל הדוגמאות שם. ובואו נקווה שאחרי שנסיים ללמוד את כל מה שברשימה כאן הקורונה כבר יהיה מאחורינו ונוכל לחזור לרדוף אחרי פריימוורקים חדשים כמו בימים הטובים.

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

# איך לבדוק פרויקט Python אוטומטית עם Github Action גיטהאב פתחו לאחרונה את מנגנון ה CI שלהם שנקרא Github Action לכולם, כך שגם אתם יכולים בלחיצת כפתור להוסיף מנגנון בדיקות ו Deployment אוטומטי לפרויקט שלכם. האוטומציה בגיטהאב כל כך פשוטה שזה ממש פשע לא להשתמש בזה. בפוסט זה נראה איך לבדוק באופן אוטומטי פרויקט ווב בעזרת סלניום כך שהבדיקה תרוץ מחדש כל פעם שאנחנו דוחפים קוד חדש. מנגנון Github Actions יריץ בשבילכם קוד על מכונה וירטואלית בעזרת דוקר. הקוד הזה יכול לעשות כל מה שתרצו, אבל לרוב נשתמש בו כדי להריץ בצורה אוטומטית את הבדיקות שכתבנו, להריץ Linter על הקוד וכמובן לבנות את המערכת ולהעלות את התוצאה לשרת ה Production. בדוגמא כאן אנחנו ניקח פרויקט שמכיל תיקיית בדיקות עם ספריית pytest ונגרום לגיטהאב להריץ את הבדיקות כל פעם שאנחנו דוחפים קוד חדש. מערכת הבדיקות משתמשת ב Selenium ותריץ את הבדיקה על דפדפן פיירפוקס שרץ במצב Headless, כלומר ללא ממשק משתמש. בשביל להתחיל להשתמש ב Github Actions אתם צריכים ליצור Workflow. זה בעצם קובץ yml שמסביר לגיטהאב מה יהיה בתוך הקונטיינר שהוא ירים. את ה Workflow אנחנו שומרים בתוך תיקיה בשם .github/workflows בתוך תיקית הפרויקט. אני קראתי לקובץ test.yml וכתבתי בו את התוכן הבא:

# This workflow will install Python dependencies, run tests and lint with a variety of Python versions
# For more information see: https://help.github.com/actions/language-and-framework-guides/using-python-with-github-actions

name: pytest-demo

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

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: Test with pytest
      run: |
        pip install pytest
        python -m pytest

הקובץ מתקין קונטיינר דוקר מתוך אימג' שנקרא ubuntu-latest. אימג' זה כולל גם התקנה של פיירפוקס לכן לא צריך להתקין אותו בנפרד. הוא יתקין את כל הספריות שרשומות בקובץ requirements.txt בפרויקט ולאחר מכן ימשיך להרצת pytest. וזה כל מה שצריך בשביל שגיטהאב יריץ בשבילנו את כל הבדיקות בצורה אוטומטית. אתם יכולים לראות את התוצאה בפרויקט שיצרתי בקישור https://github.com/ynonp/pytest-action-demo. למעלה בתפריט נוסף פריט בשם Actions. כניסה אליו מראה לי את כל הקומיטים שבפרויקט ועבור כל קומיט האם הבדיקות שלו הצליחו או לא. במסגרת תוכנית החינם של גיטהאב אתם מקבלים אלפיים דקות בחודש של מכונת דוקר שרק מחכה להתקין את התלויות שלכם ולהריץ את הבדיקות. גיטהאב עצמם אגב יצרו המון תבניות לקובץ ה Workflow עבור שפות תכנות וסביבות עבודה שונות. אם יש לכם פרויקט בשפה אחרת שווה להעיף מבט בקישור https://github.com/actions/starter-workflows/tree/master/ci ואני בטוח שתמצאו סטארטר טוב לשפה שלכם, וגם אם לא זה די פשוט לקחת אחד מהקיימים ולהתאים אותו.

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

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