ToCode

# מאיפה להתחיל בתיאוריה כשבאים לבנות פיצ'ר זה בכלל לא חשוב ממה מתחילים. בפרקטיקה זאת יכולה להיות השאלה שתקבע את גורל הפיצ'ר. יהיו מתכנתים שיבחרו להתחיל מה UI ויבנו קודם את ה HTML/CSS (או יקנו תבנית מתאימה) יהיו את אלה שיעדיפו להתחיל מבסיס הנתונים וקודם כל יגדירו את הטבלאות וקוד צד השרת. יהיו מתכנתים שיבחרו להתחיל מכתיבת בדיקות אוטומטיות. כן, הבדיקות ייכשלו אבל לפחות יהיה לנו כיוון למה צריך לממש כדי שהן יעברו בסוף. ויהיו את אלה שיחפשו קודם האם יש ספריה קיימת שפותרת את הבעיה בלי שיצטרכו לכתוב שורת קוד אחת. וכל עוד אתם בתוך ה Comfort Zone שלכם אז הבחירה מאיפה להתחיל את הפיצ'ר הבא נראית שקופה, כמעט אוטומטית. ככה אנחנו עובדים פה. אבל אז מגיע רגע שיוצאים מאזור הנוחות, ופתאום צריך לבנות משהו שלא חשבת עליו קודם: פיצ'ר שאין לו קוד צד-שרת; או פיצ'ר חדש שהוא כולו בבסיס הנתונים או בכלל רץ ב Serverless. הסכנות בבחירת נקודת התחלה לא נכונה היא הערכה לא נכונה של עלות המשך הפיתוח, בזבוז זמן על דברים לא חשובים ובסוף גם אובדן הפיצ'ר כולו. אם אני צריך לפתח מערכת Serverless על אמזון ואני לא מכיר בכלל את העבודה עם אמזון, אני יכול לבלות עכשיו שבועות בללמוד איך עובד מנגנון ה IAM שלהם ומה חוקי אבטחת המידע שאני צריך. אבל אז אני אמצא את עצמי חודשיים וחצי לתוך הפיתוח כשעוד לא התחלתי לבנות שום דבר שמנהל המוצר או המשתמשים שלי יכולים לראות, ובהרבה מערכות סיפור כזה יכול לקבור לגמרי את הפיצ'ר כי העולם יזרוק דברים יותר חשובים לכיוון שלכם. הערכת זמנים טובה, התייעצות ויותר מחשבה על סדר הפיתוח יכולים לעשות פלאים לתהליך הפיתוח אצלכם, גם אם בסוף הפיצ'ר יראה בדיוק אותו דבר.

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

x = 10_000_000;

# prints: 10000001
console.log(x + 1);

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

# perl
use v5.32;

my $x = 10_000_000;
say($x + 1);

רובי לקחה כל מה שיכלה מפרל וזה כמובן עובד גם שם:

# ruby

x = 10_000_000
puts x + 1

ופייתון שהוסיפה את הסימן באזור גירסה 3.6:

x = 10_000_000
print(x+1)

ג'אווה 7 לקחה את אותו סימן והקוד הבא עובד שם:

public class Main {
  public static void main(String [] args) {
    int x = 10_000_000;
    System.out.println(x + 1);
  }
}

ורק C++ בחרה בסימן המוזר של גרש בודד:

#include <iostream>
using namespace std;

int main() {
  int x = 10'000'000;
  cout << x + 1 << endl;
}

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

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

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

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

# אפס טעויות אני יכול לפתור שלב בדואולינגו עם 3-4 טעויות בלי בעיה, ועם מאמץ אני מצליח להגיע לטעות אחת או שתיים. אבל אפס טעויות? זו כבר רמת קושי אחרת לגמרי. אני יכול לתחזק מערכת עם כמה מאות בדיקות אוטומטיות ולהוסיף פיצ'רים כשלפעמים חלק מהבדיקות נשברות. אבל לעבוד עם שרת CI שצועק עליי כשבדיקה נשברת ולא מקבל את הקומיט שלי, ומנהל צוות שלא מרשה לי לעשות Comment Out לבדיקה זו כבר רמת קושי אחרת לגמרי. ואני יכול בקלות ללמד קורס ולענות נכון על 90% מהשאלות של התלמידים, אבל לענות נכון על כל השאלות זו רמת קושי אחרת לגמרי. הבחירה לכוון לאפס טעויות, גם אם לא תמיד מצליחים, היא קודם כל הקמת ה Constraints המתאימים: להתחיל שלב בדואולינגו רק עם לב אחד כדי שטעות אחת תספיק בשביל להעיף אותי מהמשחק; להקים שרת CI וחוקי אוטומציה שלא יאפשרו לבדיקות להיכשל; ללמד קורסים בחברות ההייטק הכי מקצועיות שמסכימות לקבל אותי, כדי שתמיד יהיה מי שישים לב כשאני טועה. כשאתם מרגישים "תקועים" מבחינה מקצועית או שכבר "הבנתם את העסק", שווה לחפש להוסיף מנגנוני אפס טעויות לתחומים נוספים בעשיה המקצועית שלכם. כל מנגנון כזה שתוסיפו יראה לכם את הדרך לשיפור המקצועי הבא שאתם מחפשים.

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

dark_colors = { 'red': 10, 'black': 20, 'blue': 30 }
light_colors = { 'pink': 5, 'lightblue': 55 }

all_colors = dark_colors | light_colors

print(all_colors)

## מתודות למחיקת תחיליות וסיומות לא עוד משחקים מטופשים עם ביטויים רגולאריים או חישובי אינדקסים! אם יש לכם במשתנה טקסט שאתם יודעים שנגמר במחרוזת מסוימת (או מתחיל במחרוזת מסוימת) תוכלו להשתמש ב removesuffix ו removeprefix כדי להיפטר מהתחילית או הסיומת:

print('I love apples'.removesuffix('apples') + 'bananas')

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

>>> import math
>>> math.lcm(4, 6)
12

אפשר כבר להתקין את הגירסה דרך pyenv ואם אתם רוצים לגלות עוד שווה לבקר בדף הרשמי עם רשימת כל השינויים בקישור https://docs.python.org/3.9/whatsnew/3.9.html

# מסביב בכניסה לטכנולוגיה חדשה הרבה אנשים מחפשים את ה Tutorial שיראה להם איך לכתוב תוכנית Hello World פשוטה ואז ממשיכים לכתוב פרויקטים יותר ויותר מתוחכמים כדי ללמוד את היכולות של הכלי. הרבה פעמים גיליתי שהשיטה הזאת לא עובדת מספיק טוב עבורי ועם הזמן עברתי להתחיל מלימוד הסביבה של הטכנולוגיה, לפני שאני כותב שורת קוד אחת. אני מתחיל עם שאלות כמו: 1. מי כתב את זה? 2. למה? 3. איזה טכנולוגיה זה בא להחליף? 4. איזה טכנולוגיות אחרות פותרות את אותה בעיה? 5. למה, לדעת מי שכתב את זה, כדאי לי להשתמש בזה ולא בטכנולוגיות האחרות? 6. למה, לדעת המשתמשים של זה, כדאי לי להשתמש בזה ולא בטכנולוגיות אחרות? 7. באיזה מצבים לא יהיה לי כדאי להשתמש בזה? 8. מי היום מתחזק את הפרויקט? 9. מתי יצאה הגירסה הקודמת? איזה שינויים היו בה? והגירסה שלפניה? 10. האם יש מי שמארגן כנסים על הטכנולוגיה הזו? 11. מתי היה הכנס האחרון? איפה? מי דיבר שם? מי בא? 12. יש הרצאות מוקלטות משם? 13. יש בלוגרים או בלוגים שכותבים ספציפית על טיפים לטכנולוגיה זו? על מה הם כתבו לאחרונה? 14. מתי צפויה הגירסה הבאה? 15. מי משתמש בטכנולוגיה ולאיזה מטרות? לפעמים, אחרי שאני יודע לספר על כל המסביב, יהיה לי הרבה יותר קל להיכנס לקוד ולשאול את השאלות הנכונות.

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