ToCode

# הנקודותיים שלפני הטוקן בעבודה עם Azure Devops API מתוך קוד Back End, ה API של Azure Devops צריך לדעת שהיישום שלי מורשה לקבל מידע ועבור איזה משתמש הוא מורשה לקבל את המידע. פיתרון קלאסי לבעיה כזאת הוא OAuth, וזה באמת עובד כשאני כותב אפליקציית ווב, אבל בכתיבת אוטומציה שלא קשורה לממשק גרפי מסוים לא תמיד זה נוח. במקום זה הייתי רוצה לקבל טוקן לצד שרת ותמיד לעבוד איתו. ב Azure Devops API טוקן כזה כבר לא מונפק ב OAuth אלא בשיטת אימות ישנה יותר שנקראת Basic Auth. ב Basic Auth אנחנו צריכים להעביר שם משתמש וסיסמה בתוך ה Authorization Header של הבקשה, והטוקן משמש בתור הסיסמה. את שם המשתמש משאירים ריק. כל הסיפור הזה הוא הקדמה לתשובה ב Stack Overflow שמסבירה איך לדבר עם ה API הזה מפייתון:

import requests
import base64

pat = 'tcd******************************tnq'
authorization = str(base64.b64encode(bytes(':'+pat, 'ascii')), 'ascii')

headers = {
    'Accept': 'application/json',
    'Authorization': 'Basic '+authorization
}

response = requests.get(
    url="https://dev.azure.com/jack0503/_apis/projects?api-version=5.1", headers=headers)
print(response.text)

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

import requests
import base64

def basic_authorization_header(username: str, password: str):
    return 'Basic '+str(base64.b64encode(bytes(username + ':'+pat, 'ascii')), 'ascii')

# Personal Access Token received from the web UI
pat = 'tcd******************************tnq'

headers = {
    'Accept': 'application/json',
    'Authorization': basic_authorization_header(username='', password=pat)
}

response = requests.get(
    url="https://dev.azure.com/jack0503/_apis/projects?api-version=5.1", headers=headers)
print(response.text)

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

# למה כל כך מסובך? למה אתה מסתבך עם Deployment דרך קוברנטיס? אצלנו פשוט עושים rsync לשרת והכל עובד. למה את צריכה לכתוב סקריפט שיבצע את השינוי המבני ב DB בצורה מתועדת? אצלנו אני מתחבר ל DB ומריץ את הפקודות מתוך ה phpmyadmin. למה אתה מסתבך עם Ansible? בעשרים דקות אני מרים לך שרת לינוקס עם כל התוכנות עליו. מה פתאום Micro Service בענן? פשוט תבנה Dockerfile ותפעיל docker compose. למה אתם כל כך מסתבכים עם גיט? יותר קל לשמור גירסאות של הפרויקט בצד כל פעם שמעלים גירסה. --- אל תוותרו על השאלות האלה. "למה כל כך מסובך" זו נקודת ההתחלה הטובה ביותר לכניסה לטכנולוגיה חדשה. הדבר החדש מסובך כי הוא צריך לטפל במקרים ושיטות עבודה איתם הדבר הישן לא מצליח להתמודד. רק כשנתחיל לראות את אותם מקרים שהדבר "הפשוט" לא פותר, אפשר יהיה להתחיל להבין את הדבר החדש.

# חיסכון? לא בטוח האימרה המפורסמת של דונלד קנות' הולכת ככה- > “The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.” ואפשר להבין את הסיפור בשתי דרכים, שתיהן נכונות. המסר הברור הוא שעדיף לנו למקד את המאמצים שלנו בכתיבת תוכנה יעילה. בהתחלה אין לנו מושג איזה חלקים באמת יעבדו לאט, ולכן שווה לחכות עם האופטימיזציה עד שמשהו באמת נשבר. המסר היותר עדין הוא שלפעמים דווקא הניסיון לחסוך עלול לסבך אותנו עוד יותר. לא רק במובן שנעבוד יותר קשה בבניית אותה מערכת, אלא גם שנקבל באגים שבלי אותו ניסיון לא היינו חולמים עליהם. ואת זה אנחנו מכירים: שומרים מידע ב Cache רק בשביל לגלות שהאפליקציה מציגה מידע לא עדכני למשתמש כי שכחנו לרענן את ה Cache; מוסיפים useCallback או useMemo בריאקט וטועים ברשימת התלויות, כך שהקומפוננטה לא מתעדכנת; בונים מערכת שתדע להתמודד עם עומס חריג ולהעלות קיבולת דינמית עם Micro Services ו Kubernetes רק בשביל לגלות שמרוב חלקים נעים אנחנו מאבדים הודעות ב Message Queue. הדרך לבניית מוצר תוכנה שעובד היא איטית וארוכה. בנו את הפיצ'רים נכון ובצורה שמאפשרת שידרוג והחלפה בלי לשבור את כל המערכת. את האופטימיזציות והביצועים רצוי להשאיר לסוף.

# איך להוציא בקשת HTTP ב Clojure קלוז'ר מאוד נדיבה בפונקציות שקשורות לנתונים ועיבוד מידע ברמה שמזכירה את רובי, אבל בכל מה שקשור ל"בטריות" הן הושארו בחוץ - אין דרך מובנית בשפה לקרוא JSON, אין מנגנון log מובנה בשפה וגם, במה שקשור לפוסט שלנו, אין דרך מובנית בשפה לשלוח בקשת HTTP. התפיסה של קלוז'ר היא שאלה דברים שאמורים להיות מפותחים בספריות הרחבה או להשתמש ביכולות של השפה המארחת, כלומר ב JVM או בדפדפן. לכן אפשר לתרגם את השאלה איך להוציא בקשת HTTP בקלוז'ר לשאלות המקבילות בשפות המארחות - "איך להוציא בקשת HTTP ב Java", ו"איך להוציא בקשת HTTP ב JavaScript מתוך דפדפן". בואו נראה את התשובות ואיך הן מתורגמות לקלוז'ר. ## איך להוציא בקשת HTTP ב Clojure שרץ ב JVM באופן רגיל תוכנית קלוז'ר רצה בתוך המכונה הוירטואלית של Java, ולכן בקשת HTTP של קלוז'ר תצטרך להשתמש בקלאסים המתאימים מ Java. התוכנית הבאה ב Java שולחת בקשת HTTP ומדפיסה את התשובה:

import java.io.IOException;
import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;

public class Main {
  public static void main(String[] args) throws Exception {
    HttpClient client = HttpClient.newHttpClient();
    HttpRequest request = HttpRequest.newBuilder()
      .uri(URI.create("https://dummyjson.com/products"))
      .build();
    HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());
    System.out.println(response.body());
  }
}

ואת זה אפשר בקלות לתרגם לקלוז'ר:

(import
  (java.net URI)
  (java.net.http HttpResponse$BodyHandlers)
  (java.net.http HttpClient HttpRequest))

(defn -main []
  (let [client (HttpClient/newHttpClient)
        request (.build (HttpRequest/newBuilder
                          (URI/create "https://dummyjson.com/products")))
        response (.send client request (HttpResponse$BodyHandlers/ofString))]
    (println (.body response))))

(-main)

## איך להוציא בקשת HTTP ב ClojureScript ומה בנוגע ל ClojureScript? הוא רץ בתוך דפדפן ולכן הבסיס שלנו יהיה שליחת בקשת HTTP מתוך JavaScript. הקוד נראה כך:

async function main() {
  const res = await fetch("https://dummyjson.com/products");
  const data = await res.json();
  console.log(data);
}

main();

אז אומנם אין await מובנה ב ClojureScript אבל עדיין אפשר להשתמש ב Promises עם then ולקבל את אותו הקוד בגירסת קלוז'ר:

(->
 (js/fetch "https://dummyjson.com/products")
 (.then #(.json %))
 (.then #(js->clj %))
 (.then #(println %)))

היתרון של גירסת ה ClojureScript הוא שגם קיבלנו פיענוח של ה JSON (בניגוד ל Java שהחזיר רק מחרוזת). הפקודה js->clj הפכה את מבנה הנתונים למפה קלוז'רית ולכן אפשר לעדכן את הקוד כדי להדפיס רק שדה מסוים ממנו, למשל רק את רשימת המוצרים:

(->
 (js/fetch "https://dummyjson.com/products")
 (.then #(.json %))
 (.then #(js->clj %))
 (.then #(println (get % "products"))))

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

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

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

  redis:
    image: redis
    ports:
      - 6379:6379

אחרי שעתיים הרדיס התרסק ובלוג הופיעה הודעה דומה להודעה הבאה (רק עם תאריך אחר בהתחלה):

1:S 25 Jun 2021 00:48:12.902 * MASTER <-> REPLICA sync started

הפעלה מחדש של רדיס, הכל שוב עבד ואחרי שעתיים הודעת השגיאה חזרה ללוג. בגלל שזה שרת בדיקות לאף אחד לא היה אכפת, וההודעה קוטלגה בתור מוזרות של העולם שבטח תיפטר לבד כשנעבור לשרת אמיתי. יכולים לראות מה הבעיה האמיתית שם? ## פיתרון הדבר הכי חשוב לעשות עם בעיות כאלה הוא פשוט להתיחס אליהן, לא לטאטא מתחת לשטיח. הרי זה לא יכול להיות משהו גדול - כולם משתמשים ברדיס מתוך קונטיינרים והכל עובד ליותר משעתיים. גם אם ההשפעה של התקלה נראית סופר שולית (מה הבעיה לעשות ריסטרט לרדיס פעם ביום על שרת הבדיקות), זה עדיין משהו שאפשר ושווה לתקן בקלות. במקרה שלנו התשובה עלתה בחיפוש מהיר ב Stack Overflow: https://stackoverflow.com/questions/68124389/redis-error-condition-on-socket-for-sync-connection-refused הגדרת ה ports ב docker-compose.yml גרמה לרדיס להקשיב לפקודות מכל העולם. מספיק לקבל פקודה מרושעת אחת והרדיס מפסיק לעבוד, וממילא באימג' ברירת המחדל החיבור הוא ללא סיסמה. ולכן גם הפיתרון הפשוט: מוחקים את הגדרת ה ports. אפשר להחליף אותה ב expose ואפשר גם על זה לוותר. מה שחשוב זה לא להשאיר את פורט 6379 פתוח לכל העולם על שרת, כי אפילו אם זה רק שרת בדיקות יש מי שסורק את כל כתובות ה IP של העולם בחיפוש אחר רדיסים פתוחים.

# לימוד מהיר זה אשליה בפוסט האחרון שלו קנט דודס מציע לנו להפסיק להיות ג'וניורים. ספציפית הוא כותב- > it really doesn't take much time for a developer staying on top of these advancements in their area of interest to reach a level of familiarity that rivals those with decades of experience. וגם במודגש- > Staying on top of a few chosen technologies allows anyone to become an expert in them rather quickly. שיטת מחשבה כזאת יכולה לדכא הרבה מתכנתים וותיקים. אם אחרי עשרות שנים במקצוע יכול לבוא איזה ילד וללמוד את כל מה שאני יודע בחודשיים, אז מה אני עושה פה? עדיף לעבור לניהול או פרודאקט, איפה שהניסיון הנצבר שווה ערך. כבני אדם אנחנו מחפשים תמיד את הצמיחה, את הלמידה ואת השיפור. ברור שאם בעסקי התוכנה היינו כותבים קוד ובסוף החודש מוחקים את כל מה שכתבנו ומתחילים מאפס המוטיבציה של רוב המתכנתים היתה יורדת משמעותית. אנחנו רוצים להשקיע במערכת שתפתור בעיות ותצליח לאורך זמן, ואנחנו רוצים להשקיע בידע ובניסיון שלנו כדי לבנות פיתרונות טובים יותר בעתיד. מה שמביא אותי לשתי מחשבות בעקבות הפוסט של קנט- 1. הניסיון שלי הראה אחרת: ככל שאני פוגש יותר מתכנתים אני יכול לראות את האפקט של ניסיון. מתכנתים ומתכנתות עם ניסיון לומדים דברים יותר מהר, מסוגלים להתמודד טוב יותר עם בעיות ולראות את התמונה הגדולה. בכל קורס שאני מלמד אלה המתכנתים הוותיקים ששואלים את השאלות הקשות, ויודעים להשוות (גם אם לא תמיד בצורה מדויקת) בין הטכנולוגיה שאני מלמד לטכנולוגיות אחרות מהעבר. 2. הדרך ללמוד טכנולוגיה היא להתעניין בה ולחפש את העומק. אם הגישה מראש היא שפריימוורקים מתחלפים כל הזמן, ושכל פריימוורק חדש דורש להתחיל ללמוד מאפס, אז יהיו לנו פחות כלים לחפש את העומק הטכנולוגי. בעצם האמונה שאפשר תוך כמה חודשים להשתלט על טכנולוגיה מסוימת ולהגיע בה לרמת מומחיות היא נבואה שמגשימה את עצמה, והיא מונעת מאיתנו לחפש את הלימוד שלוקח שנים. לניסיון יש ערך, וככל שנאמין בזה ונתאמץ לחפש את הערך כך נמצא יותר ממנו.

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

# File: a.py
import b

def hi(n):
    print("Hello from a")
    if n < 10:
        b.hi(n+1)

hi(0)

# File: b.py

import a

def hi(n):
    print("hello from b")
    if n < 10:
        a.hi(n+1)

אם נשמור את קטעי הקוד בקבצים בשמות a.py ו b.py בהתאמה ונריץ python a.py נקבל את השגיאה:

Hello from a
Traceback (most recent call last):
  File "/Users/ynonp/tmp/python/circular/a.py", line 1, in <module>
    import b
  File "/Users/ynonp/tmp/python/circular/b.py", line 1, in <module>
    import a
  File "/Users/ynonp/tmp/python/circular/a.py", line 8, in <module>
    hi(0)
  File "/Users/ynonp/tmp/python/circular/a.py", line 6, in hi
    b.hi(n+1)
    ^^^^
AttributeError: partially initialized module 'b' has no attribute 'hi' (most likely due to a circular import)

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

import a

והבין שעליו לסיים קודם עם a ורק אז יוכל לחזור לסיים עם b. לכן כשמפעילים את hi מתוך המודול a פייתון עדיין לא סיים לאתחל את b ולא מצא עדיין את הפונקציה hi ממנו. במבנה כל כך קטן יש מגוון דרכים להתמודד עם התלות המעגלית: אפשר לחבר את שתי הפונקציות לאותו קובץ או להוציא את הקריאה ל hi לקובץ שלישי. אבל במבנים יותר מורכבים לפעמים האופציות האלה לא אפשריות. האק מרושע שיכול לעזור במצבים כאלה הוא להעביר את ה import לתוך הפונקציה. אחרי השינוי המודול b.py נראה כך:

# File: b.py

def hi(n):
    import a
    print("hello from b")
    if n < 10:
        a.hi(n+1)

הפעלה חוזרת והכל עכשיו עובד:

Hello from a
Hello from a
hello from b
Hello from a
hello from b
Hello from a
hello from b
Hello from a
hello from b
Hello from a
hello from b
Hello from a
hello from b
Hello from a
hello from b
Hello from a
hello from b
Hello from a
hello from b
Hello from a
hello from b
Hello from a

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

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

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