Site Logo
כניסה

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

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

כל הנושאים aoc2023 C++ docker git jquery Mobile newsletter Node.js perl python React ruby TypeScript vim אבטחת מידע דיבור מול קהל יומי יזמות לינוקס ותשתיות מדריך Vue למתחילים מדריך Webpack נגישות אתרים פיתוח צד-לקוח קריירה

אף אחד אף פעם לא ירצה את זה

26/04/2022
יומי

הפונקציות atob ו btoa של JavaScript משמשות להמרה של מחרוזות ל Base64 ובחזרה. מכל מיני אילוצים טכניים מאפייני שפת JavaScript החליטו שהן יעבדו טוב רק על מחרוזות ASCII כלומר מחרוזות באנגלית בלבד. אז אני יכול לכתוב:

> btoa("ninja")
'bmluamE='

אבל לא יכול לכתוב:

> btoa('תפוז')
Uncaught:
DOMException [InvalidCharacterError]: Invalid character
    at new DOMException (node:internal/per_context/domexception:70:5)
    at __node_internal_ (node:internal/util:497:10)
    at btoa (node:buffer:1229:13)

לכן ה Best Practice בשביל להשתמש בפונקציות אלה הוא להשתמש בעוד המרה לפני הפעלתן. כך מהתיעוד:

function utf8_to_b64( str ) {
  return window.btoa(unescape(encodeURIComponent( str )));
}

function b64_to_utf8( str ) {
  return decodeURIComponent(escape(window.atob( str )));
}

הקידוד ל Base64 בשיטה שמוצעת בתיעוד הוא בדיוק מה שאני מקבל משפה כמו Ruby כברירת מחדל. הבחירה של מתכנני JavaScript לבנות API שיעבוד רק על טקסטים מסוימים היא מוקש שמחכה להתפוצץ. אלה בדיוק הבאגים שקורים רק ללקוח ספציפי ואחרי זה קשה למצוא אותם.

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

חדש ב Node 18 - תמיכה מובנית ב Fetch API

25/04/2022
יומי
Node.js

גירסה 18 של נוד מביאה איתה לא מעט חידושים: התמיכה ב ES Modules השתפרה פלאים, הוסיפו מודול מובנה להרצת בדיקות יחידה, ונוספה תמיכה לשני ממשקי רשת מהדפדפן שהם Fetch API ו Web Streams API.

בפוסט זה אציג את השימוש ב Fetch API ב Node.

המשך קריאה

ארבע עצות לעצמאים בתחילת הדרך

24/04/2022
יומי

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

המשך קריאה

היום למדתי: ההבדל בין URL ל URI

22/04/2022
יומי

לא להאמין שהעברתי חיים שלמים בלי לדעת את זה, אבל אם גם אתם פתאום לא בטוחים אז הגעתם למקום הנכון. קודם כל משמעות ראשי התיבות דומה - URL הוא Uniform Resource Locator ו URI הוא Uniform Resource Identifier. ההבדל ביניהם הוא עדין אבל חשוב:

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

https://schema.org/Person
foo://example.com:8042/over/there?name=ferret#nose
urn:oasis:names:specification:docbook:dtd:xml:4.1.2
urn:isbn:0-486-27557-4
https://stackoverflow.com/questions/4913343/what-is-the-difference-between-uri-url-and-urn
data:,Hello%20World

חלק מה URI-ים מתיחסים למסמך ספציפי ברשת ומסבירים איך להגיע אליו. למשל ה URI הזה:

https://stackoverflow.com/questions/4913343/what-is-the-difference-between-uri-url-and-urn

הוא קישור ל Stack Overflow. הוא סוג של "מצביע" לדף בפרוטוקול https. מזהים כאלה נקראים URL-ים, כי הם מספקים דרך לאתר (to locate) את המשאב שהם מזהים. הרבה פעמים, וזה קצת מבלבל, ה URI יהיה בעצם כתובת אינטרנט של דף שלא באמת קשור לדבר שהוא מזהה. לדוגמה ב HTML 4 מסמך היה מתחיל בשורה:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
        "http://www.w3.org/TR/html4/strict.dtd">

אבל לדפדפנים לא היה אכפת אם הייתם טועים בכתובת האינטרנט שמופיעה שם. הסיבה שיש כתובת אחרי ה DOCTYPE היא רק בשביל לזהות את הגירסה של ה HTML, ובעצם השורה מתפקדת בתור URI ולא URL - אף אחד לא משתמש בה כדי לקרוא את המסמך שנמצא בה. אותו סיפור קורס ב XML Namespaces וגם במזהים של schema.org.

בקיצור אם יש לנו כתובת שמזהה מסמך ואנחנו משתמשים בה כדי להגיע למסמך הזה נקרא לה URL. אם יש לנו מזהה ייחודי של "משהו" שאנחנו לא צריכים באמת להגיע אליו אנחנו קוראים לזה URI.

למידע נוסף שווה לקרוא את הפוסט הזה מהבלוג של auth0 שעוזר לחדד את ההבדל בין המושגים: https://auth0.com/blog/url-uri-urn-differences/

הדרישה שלא כותבים במודעת הדרושים

21/04/2022
יומי

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

"מבין או מבינה את הסיפור"

להבין את הסיפור זה אומר שאת יכולה לראות קוד של מערכת ולהבין:

  1. מה המטרות של הקוד הזה

  2. מה האילוצים שהקוד צריך להתמודד איתם

  3. מה היו האילוצים של מי שכתבה את הקוד

  4. איזה חלקים שם בכוונה ומה שם בטעות

  5. מה הולכות להיות הבעיות בקוד הזה בעתיד הקרוב

  6. איזה בעיות סביר להניח שיהיו לקוד הזה בעתיד היותר רחוק

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

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

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

שמונה דוגמאות ל Ruby One Liners משורת הפקודה ביוניקס

20/04/2022
יומי

רובי אומנם נחשבת לשפה High Level שעוזרת למתכנתים לכתוב קוד קריא, אבל לרובי יש גם צד אפל במשפחה וזו המורשת שהיא קיבלה מ perl. בדומה ל perl, גם לרובי יש מצב שורת פקודה שבעזרת כמה מתגים בהרצה יאפשר לכם כוחות על יוניקסאיים. הנה 8 דוגמאות להפעלת רובי משורת הפקודה-

המשך קריאה

אין בעיה של מקום

19/04/2022
יומי

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

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

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

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

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

  1. אנחנו נשמור עליך נתונים X, Y ו Z.

  2. הנתונים יישמרו לתקופה של Y שנים.

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

  4. אתה יכול לבקש שנתונים מסוימים יימחקו דרך הקישור הזה.

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

פיתרונות פשוטים, פיתרונות מסובכים וקיפאון

18/04/2022
יומי

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

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

כמה חודשים אחרי זה נתקלתי בהם שוב - נו, שאלתי, "איך הלך עם ההתאמה של create-react-app?", והתשובה היתה קצת מפתיעה. החלק הצפוי הוא שהם באמת ניסו את הרעיון שלי לעשות התאמה של cra לצרכים שלהם וויתרו על זה די מהר. העסק היה מסובך מדי ותמיד היו דברים חשובים יותר לעשות. ברור שזה אחלה פיתרון אם זה היה עובד, אבל הוא דורש יותר מדי עבודה.

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

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

אבל הם לא היו צריכים.

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

חמש תשובות יותר טובות מ"נראה אחלה"

17/04/2022
יומי

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

  1. מתי הספקת לעשות את כל הריפקטורינג הזה?

  2. בשביל מה היית צריכה לגעת במודול ההוא - הוא עבד מעולה קודם

  3. וואו איך הכל נטען כל כך מהר!

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

  5. התיעוד נראה מעולה

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

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