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

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

בכניסה לטכנולוגיה חדשה הרבה אנשים מחפשים את ה Tutorial שיראה להם איך לכתוב תוכנית Hello World פשוטה ואז ממשיכים לכתוב פרויקטים יותר ויותר מתוחכמים כדי ללמוד את היכולות של הכלי.

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

1. מי כתב את זה?

2. למה?

3. איזה טכנולוגיה זה בא להחליף?

4. איזה טכנולוגיות אחרות פותרות את אותה בעיה?

5. למה, לדעת מי שכתב את זה, כדאי לי להשתמש בזה ולא בטכנולוגיות האחרות?

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

7. באיזה מצבים לא יהיה לי כדאי להשתמש בזה?

8. מי היום מתחזק את הפרויקט?

9. מתי יצאה הגירסה הקודמת? איזה שינויים היו בה? והגירסה שלפניה?

10. האם יש מי שמארגן כנסים על הטכנולוגיה הזו?

11. מתי היה הכנס האחרון? איפה? מי דיבר שם? מי בא?

12. יש הרצאות מוקלטות משם?

13. יש בלוגרים או בלוגים שכותבים ספציפית על טיפים לטכנולוגיה זו? על מה הם כתבו לאחרונה?

14. מתי צפויה הגירסה הבאה?

15. מי משתמש בטכנולוגיה ולאיזה מטרות?

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

אז כתבתם בדיקות אוטומטיות לפרויקט - מזל טוב! בטח שמתם לב שיש פרויקטים בגיטהאב שמציגים Badge מדליק כזה שאומר שהבדיקות עברו (או שלפרויקט יש תיעוד, או שהפרויקט נחמד או כל דבר אחר שאתם רוצים לכתוב שם) ושאלתם את עצמכם, איך גם אני מקבל כזה Badge יפה להראות לחברים?

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

1. צרו פרויקט עם בדיקות אוטומטיות ודרך אוטומטית להריץ אותן בתוך Github Actions. אני יצרתי לדוגמה פרויקט Python שמשתמש ב Pytest בקישור הזה https://github.com/ynonp/pytest-webinar-demos/.

2. בשביל לגרום לבדיקות האוטומטיות לרוץ בכל קומיט יצרתי Workflow בתיקיית .github/workflows. בתוך קובץ ה workflow יש שדה בשם name שאותו צריך לזכור. אם אתם לא בטוחים לגבי מבנה הפרויקט או תוכן קובץ ה workflow אפשר בכיף לקחת מהדוגמה שלי במאגר.

3. אחרי שהבדיקות רצות באופן אוטומטי גיטהאב יוצר קובץ SVG עם המילה Passing (במקרה הטוב) או Failing (במקרה הרע). הנתיב לקובץ האוטומטי הזה מורכב מהנתיב למאגר שלכם, אחרי זה המילה workflows ואז שם ה workflow (זה שזכרנו בסעיף הקודם). במקרה שלי הנתיב הוא: https://github.com/ynonp/pytest-webinar-demos/workflows/tests/badge.svg.

4. עכשיו כל מה שנשאר זה לצרף את התמונה לתוך ה readme.md של המאגר, אצלי הוספתי את השורה הבאה לקובץ ה readme.md:

![Tests](https://github.com/ynonp/pytest-webinar-demos/workflows/tests/badge.svg)

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

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

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

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

אני יכול להתקשקש שעות בבניית העיצוב הכי יפה לאפליקציה שלי במקום לרוץ עם HTML/CSS פשוט ומדויק, כשברור שלפני שהמערכת עובדת ולפני שיש לי משתמשים אף אחד אפילו לא רואה את העיצוב החדשני. מצד שני אם לא אשקיע ב UX טוב לפני שאני מתחיל לכתוב את הקוד מחיר התיקון רק יעלה ככל שהמערכת הופכת מורכבת יותר.

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

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

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

אוקטובר מגיע וכל שנה מחדש אירוע Hacktoberfest של Digital Ocean מעורר תגובות דומות: מתחזקים של פרויקטי קוד פתוח לא מבינים למה פתאום הם מקבלים PR-ים מיותרים מאנשים שלא מבינים כלום בפרויקט שלהם.

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

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

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

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

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

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

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

כך כשאנחנו עוברים מ Windows ל Linux ברור שנצטרך להתרגל לכתוב ls במקום dir כל פעם שרוצים להציג את רשימת הקבצים. אבל הרבה יותר מוזר יהיה הרגע שנשאל "איך מגיעים לכונן D". ההבנה שכונן הוא בעצם תיקייה ושאנחנו צריכים לעשות פעולת mount כדי שנוכל לגשת לכונן הזה היא יותר ממה שרציתי לדעת.

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

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

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

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