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

טיפים קצרים וחדשות למתכנתים

היום למדתי: מפרידי מספרים בכל מיני שפות

14/10/2020

היום גיליתי שגם ב 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;
}

ברוזטה קוד אפשר למצוא רשימה יותר מקיפה למרות שאישית את רוב השפות שם לא הכרתי.

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

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

13/10/2020

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

  1. אם אני יכול בתור משתמש לשרוף לעצמי את המסך, אז מי שכתב את הדרייבר עשה עבודה לא טובה.

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

  3. אם אני יכול בתור משתמש להפיל את השרת לכל המשתמשים האחרים אז מי שכתב את המערכת לא עשה עבודה טובה בכלל.

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

מדריך קוד: בואו נכתוב אפליקציית הודעות בזמן אמת עם Pheonix ו React

12/10/2020

פיניקס היא פריימוורק צד השרת האהובה עליי בימים אלה. היא לקחה הרבה השראה מ Rails, כתובה בשפת Elixir ורצה בתוך המכונה הוירטואלית של Erlang. היא מספקת ביצועים מעולים ליישומים המבוססים על Web Sockets (קצת כמו Node.JS), ובאותו הזמן מגיעה עם כל הבטריות בפנים (קצת כמו Rails).

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

המשך קריאה

עזבו - שגם לא יראה נקי

11/10/2020

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

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

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

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

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

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

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

מחשבים לא משקרים

10/10/2020

שלוש מילים ששינו את חיי.

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

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

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

אפס טעויות

09/10/2020

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

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

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

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

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

הפיצ'רים החדשים בפייתון 3.9 שאני כבר לא יכול לחיות בלעדיהם

08/10/2020

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

המשך קריאה

מסביב

07/10/2020

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

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

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

  2. למה?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

איך לקבל Badge מדליק שהבדיקות בפרויקט שלך עוברות

06/10/2020

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

הסבלנות משתלמת?

05/10/2020

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

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

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

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

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