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

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

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

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 יחד עם כמה מחשבות על איך העסק הזה הולך להיראות בעתיד.

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

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

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

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

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

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

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

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

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

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

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

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