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

אחת היכולות המדליקות של Scss שהרבה זמן היתה חסרה לי ב CSS היא היכולת לארגן Selectors אחד בתוך השני. כלומר במקום לכתוב:

header h1,
header h2,
header h3,
header h4,
header h5,
header h6 {
  font-weight: normal;
}

אנחנו יכולים לכתוב פשוט:

header {
  h1, h2, h3, h4, h5, h6 { font-weight: normal; }
}

מסתבר שממש בקרוב נוכל להתחיל להשתמש בכתיב שנקרא matches כדי להגיע לאותה תוצאה בדיוק ב CSS:

header :matches(h1, h2) {
  font-weight: normal;
}

הבעיה היחידה אגב שבינתיים דפדפנים לא ממש תומכים בכתיב זה. בצד החיובי רובם כן תומכים בדיוק בפיצ'ר הזה בשם אחר - באמצעות מילת הקוד any ותוספת Vendor Prefix. כלומר הקוד הבא כן עובד ברוב הדפדפנים המודרניים היום:

header :-moz-any(h1, h2) {
  font-weight: normal;
}

header :-webkit-any(h1, h2) {
  font-weight: normal;
}

כך שאם אתם מריצים סקריפט שמוסיף Vendor Prefix בצורה אוטומטית או ב prefixfree אתם כבר יכולים להנות מהכתיב החדש (ורק תזכרו שבקרוב הכתיב של any יהפוך ל matches ותהיו מוכנים להחליף כשיגיע היום).

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

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

 public static boolean isPelindrome(int number) {
    String reverseNumberString = new StringBuilder(number).reverse().toString();
    String numberString = String.valueOf(number);
    return reverseNumberString == numberString;
  }

מצאתם את הבעיות? ספרו בתגובות מה זה היה.

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

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

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

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

1. מאתחיל מערך כך שהגודל שלו יהיה זהה למגבלת הבקשות בדקה שאתם צריכים. לדוגמא אם אנחנו רוצים מגבלה של 10 בקשות בדקה ניצור מערך של 10 תאים.

2. בכל תא במערך רושמים את השעה הישנה ביותר שמחשב תומך בה (מיוצגת על ידי המספר 0 - מספר השניות מאז ה 1/1/1970).

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

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

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

הפונקציה המרכזית ברובי מהקוד היא:

    def shift
      time = nil

      @mutex.synchronize do
        time = @ring[@head]

        sleep_until(time + @interval)

        @ring[@head] = Time.now
        @head = (@head + 1) % @size
      end

      time
    end

ואת שאר המחלקה תוכלו למצוא בקוד של הג'ם בגיטהאב Limiter Gem.

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

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

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

אחד הכלים המועילים והמבלבלים בלימוד נושא חדש הוא התבנית והחיפוש אחר התבנית הדומה. מי שמגיע מ Java ל Python ישמח לגלות שהקוד הבא מדפיס עשר פעמים הודעה על המסך:

for i in range(0, 10):
    print("{} Hello World".format(i))

כי זה נראה ממש דומה לקוד ה Java:

for (int i=0; i < 10; i++)
    System.out.println(String.format("%d Hello World", i));

אבל הדמיון הזה הוא רק בראש של מי שחדש ל Python -

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

2. ב Java המשתנה i חי בתוך הלולאה בלבד, אבל ב Python הגדרנו משתנה שמוכר בכל הפונקציה.

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

for (int i=9; i >= 0; i--)
    System.out.println(String.format("%d Hello World", i));

ב Python ניסיון להפוך את סדר המספרים ב range כמובן נכשל ולא מדפיס כלום:

for i in range(10, 0):
    print("{} Hello World".format(i))

ככל שנלך רחוק יותר בחקירה שלנו נגלה שקוד Python עושה דבר דומה לקוד ה Java, אבל בדרך מאוד שונה. בגירסת ה Java אנחנו יודעים מה זה לשמור את המספר 0 במשתנה או לשנות את ערך המשתנה ב-1. בגירסת ה Python בשביל להבין מה קורה בלולאה אנחנו צריכים להבין ש range בכלל מחזירה אוביקט שיש לו פונקציה בשם __iter__, שמחזירה משהו שיש לו פונקציה בשם __next__, ושבצורה אוטומטית for מפעיל את __iter__, לוקח את הדבר שהחזירה ומפעיל עליו __next__ עד שמקבל את ה Exception המיוחד שאומר שנגמרו כל האיברים. כלומר אם אני מנסה מתוך ה REPL להבין למה ה range לא עבד זה עשוי להיות מבלבל. בכתיבה הראשונה שתי הפקודות מחזירות תוצאה דומה:

>>> range(0, 10)
range(0, 10)
>>> range(10, 0)
range(10, 0)
>>>

ורק בהמשך חקירה אני מצליח לראות את הבעיה:

>>> len(range(0, 10))
10

>>> len(range(10, 0))
0

וכמובן:

>>> g = range(0, 10)
>>> i = iter(g)
>>> next(i)
0
>>> next(i)
1

# But ...

>>> g = range(10, 0)
>>> i = iter(g)
>>> next(i)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
StopIteration

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

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

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

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

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

מתכנתי JavaScript רגילים לכתוב קוד בצורה אסינכרונית הרבה יותר מאשר מתכנתי Java, ומתכנתי Java רגילים הרבה יותר לסנכרן משימות בין Threads בהשוואה למתכנתי JavaScript. כל זה למרות שיש ל Java מנגנון תכנות אסינכרוני, ול JavaScript יש WebWorkers ו SharedArrayBuffer.

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

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

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

קשה להאמין שעד לפני 2008 לא היה אתר שנקרא Stack Overflow. רגע מה Stack Overflow עד 1994 לא לכם אינטרנט בבית, וכנראה אפילו קצת יותר מאוחר. זה אומר שאם כתבתם קוד למשל ב 1992, סתם, בבית, בשביל הכיף, ונתקעתם - באמת לא היה את מי לשאול.

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

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

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

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

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

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