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

כשדאגלס קרוקפורד הכריז בתחילת שנות ה 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 במקום בעשר. אם הטעות הגיעה גם אליכם אני מתנצל. ובכל מקרה ההזמנה לקבוצת הפיתוח מתאימה גם אם לא הייתם בוובינר. וכמובן אנסה לפרסם הקלטה בימים הקרובים אז שווה לעקוב בעמוד הקלטות מוובינרים כאן באתר.

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

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

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 יש סיכוי מסוים שדילגתם עליהם בשוטף ושיעזרו לכם לעשות עבודה הרבה יותר טובה כשהמשבר ייגמר.

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

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

המלצה שניה היא Service Worker. נושא מאוד מעניין שעוזר לבנות עמודי Offline, לשלוח נוטיפיקציות ולשפר ביצועים בעמוד. אפשר להתחיל עם דף ההסבר של MDN בקישור https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerAPI/UsingServiceWorkers, להמשיך עם זה של גוגל ולסיים בטוטוריאל בקישור 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 ושווה לקרוא אותו ולנסות להריץ בעצמכם את כל הדוגמאות שם.

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

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

אגב- ביום חמישי הקרוב אני ודני נעביר וובינר על תכנות פונקציונאלי עם Clojure. אם בא לכם לשמוע יותר על תכנות פונקציונאלי ממש שווה לבוא. פרטים בקישור https://www.tocode.co.il/workshops/95.

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

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

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

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

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

גיטהאב פתחו לאחרונה את מנגנון ה 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 החיים דבש. כל אחד שיריץ את התוכנית יבין שיש פה באג ויוכל להחליט אם שווה להתאמץ לתקן אותו או שנישאר עם הבעיה.

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

אז לא.

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

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

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