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

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

.text {
  font-size: 300%;
}

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

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

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

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

התחביר מאוד דומה ל Media Query ומספק שני פיצ'רים שימושיים:

1. יחידות מידה חדשות, בדומה ל vw ו vh, רק שהפעם יהיו יחסיות לגודל הקונטיינר.

2. שאילתת @container חדשה שמאפשרת להגדיר כללי עיצוב מסוימים אם הקונטיינר שלי מתאים לשאילתה.

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

container-type: 'size';

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

.text {
  background: blue;
  // cqw -> container width
  font-size: 4cqw;
  padding: 10px;
}

או להוסיף שאילתה ולהפעיל כלל עיצוב מסוים רק אם הקונטיינר עומד בתנאי:

@container (min-width: 700px) {
  .text {
    background: orange;
  }
}

דוגמה? בטח. נסו את הקודסנדבוקס הבא: https://codesandbox.io/s/cool-phoebe-kkmpr6

או בהטמעה כאן:

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

הקוד הבא מבלבל:

let x = "hello, "
x += "world"
console.log(x);

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

קל להיווכח בזה באמצעות הוספת משתנה:

> x = "hello, "
'hello, '
> y = x
'hello, '
> x += "world"
'hello, world'
> x
'hello, world'
> y
'hello, '

אם ה += היה משנה את המחרוזת אז היינו רואים את השינוי גם ב y, בדיוק כמו שקורה בעבודה על מערכים:

> x = [1, 2, 3]
[ 1, 2, 3 ]
> y = x
[ 1, 2, 3 ]
> x.push(4)
4
> x
[ 1, 2, 3, 4 ]
> y
[ 1, 2, 3, 4 ]

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

דוגמה? תמיד. הקוד הבא מייצר כפתור שבלחיצה עליו יקפיץ הודעת alert:

const main  = document.querySelector('main');
main.innerHTML += '<button>button 1</button>';
main.querySelector('button').addEventListener('click', () => {
  alert('1');
})

ועכשיו אני לוקח את אותו קוד ומוסיף לו שורה:

const main  = document.querySelector('main');
main.innerHTML += '<button>button 1</button>';
main.querySelector('button').addEventListener('click', () => {
  alert('1');
});

main.innerHTML += '<p>Click for magic</p>';

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

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

const id = searchParams.id || throw new Error("id is required");

הסיבה היא ש throw הוא Statement ולכן אפשר להשתמש בו רק כפקודה מלאה. אבל מה שיותר מעניין הוא כמה המבנה הזה לא חסר לאף אחד. הרי מבנה כזה היה אחד הנפוצים בשפה כמו perl עם שורות כמו:

open FILE, "filename.txt" or die "Cannot open file: $!\n";

או:

chdir('/etc') or die "Can't change directory";

אז למה בעצם לא היינו צריכים את זה ב JavaScript? כמה השערות-

1. אנחנו פחות זורקים שגיאות ב JavaScript - בניגוד ל perl שם כשמנסים להריץ סקריפט מי שהריץ את הסקריפט רואה את השגיאה ועוד יכול לעשות משהו, ב JavaScript זריקה של Exception במצב כזה פשוט תציג שגיאה לקונסול, ורוב הזמן אף אחד לא יראה אותה. לכן רוב הזמן הטיפול בשגיאות ב JavaScript הוא מקומי.

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

const { id, page, limit } = searchParams;
if (!id) {
    throw new Error("id is required");
}

מה אתכם? יצא לכם להתגעגע למבנה של || throw ב JavaScript? אם כן ספרו מתי, ואם לא ספרו מה עשיתם במקום.

כשחלום פוגש את המציאות הוא אף פעם לא יפגוש מציאות שמתאימה לו במאה אחוז. אם החלום היה יכול לקרות בתור מציאות הוא כבר היה קורה ולא היה חלום.

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

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

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

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

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

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

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

def longer_than(n: int, items: list[str]) -> list[str]:
    return [I for I in items if len(i) > n]

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

print(longer_than(3, ((1, 2, 3), (2, 3, 4, 5, 6), range(10))))

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

def longer_than(n: int, items: Iterable[Sized]) -> list[Sized]:
    return [I for I in items if len(i) > n]


print(longer_than(3, ((1, 2, 3), (2, 3, 4, 5, 6), range(10))))

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

long_items = longer_than(3, ((1, 2, 3), (2, 3, 4, 5, 6), range(10)))
print(long_items[0][0])

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

הפיתרון כמו שאני מקווה שאתם כבר יודעים הוא TypeVar שמוכן לקבל כל טיפוס יותר ספציפי מ Sized, כלומר:

T = TypeVar('T', bound=Sized)  
def longer_than(n: int, items: Iterable[T]) -> list[T]:
    return [I for I in items if len(i) > n]

long_items1 = longer_than(3, ((1, 2, 3), (2, 3, 4, 5, 6), range(10)))
print(long_items1[0][0])  

long_items2 = longer_than(3, ['abc', 'abcdefg', 'as'])
print(long_items2[0].capitalize())

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

״איך את בונה תיבה עם השלמה אוטומטית שתהיה נגישה?״

״איך אתה בונה Checkbox שישתמש בתמונה מותאמת אישית וגם יאפשר ניווט מקלדת?״

״איך תבני גלריית תמונות ב HTML/CSS אם כל התמונות בגדלים שונים?״

״איך תציג על המסך תמונה עם אפקט Scale כשעוברים עליה עם העכבר?״

כל אלה שאלות שפעם אפשר היה להשתמש בהן בראיונות עבודה, אבל היום הפכו ללא רלוונטיות. אם מתכנת יכתוב לי היום שהוא לא הצליח לבנות Checkbox שיש בו גם תמונה וגם ניווט מקלדת זה יישמע מאוד מוזר. ״למה אתה שואל אותי? יש Chat GPT״.

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

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

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

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

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

״מה עבד לך?. אולי חלק מזה יעבוד גם לי (ואולי לא, וזה גם בסדר).״

שגיאת כתיב מקרית בהתקנת חבילות הובילה אותי לקובץ cmd-list.js במאגר npm/cli, ומשם לקטע הבא מתוך אוביקט aliases:

in: 'install',
ins: 'install',
inst: 'install',
insta: 'install',
instal: 'install',
isnt: 'install',
isnta: 'install',
isntal: 'install',
isntall: 'install',

מה קורה כאן? אז הכי אחורה שהצלחתי להגיע עם זה היה ה PR הזה שהוסיף את ה alias בשביל לא להרגיז את אלכס סקסטון. אותו אלכס אגב פירסם באיזה גיסט מאותה תקופה את הלוג הבא מעבודה עם npm עם הכותרת How Dare You:

$ npm isntall
npm ERR! Darwin 14.0.0
npm ERR! argv "node" "/Users/alexsexton/.nave/installed/0.10.33/bin/npm" "isntall"
npm ERR! node v0.10.33
npm ERR! npm  v2.1.7
npm ERR! code MODULE_NOT_FOUND

npm ERR! Cannot find module '/Users/alexsexton/.nave/installed/0.10.33/lib/node_modules/npm/lib/isntall.js'
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR!     <http://github.com/npm/npm/issues>

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/alexsexton/stripe/dashboard-ui/npm-debug.log

לימים נוספו עוד alias-ים נוספים ל install ולפקודות רבות נוספות, כשההסבר הרשמי לכולם (מתוך הדיון כאן) הוא:

npm is not here to punish people for spelling mistakes. npm is here to install your packages, even if you type "isntall".

גישה חיובית ולא מאוד נפוצה.

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

#[macro_use] extern crate rocket;

#[get("/hello/<name>/<age>")]
fn hello(name: &str, age: u8) -> String {
    format!("Hello, {} year old named {}!", age, name)
}

#[launch]
fn rocket() -> _ {
    rocket::build().mount("/", routes![hello])
}

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

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

הדוגמה הבאה ממחישה את הקונספט לא רע:

#[get("/sensitive")]
fn sensitive(key: ApiKey) { /* .. */ }

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

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

/// This route is chosen if the request guard for User passes (e.g. logged in).
#[get("/")]
fn home(user: User, _cookies: Cookies) -> Markup {
    html! {
        head {
            title {"Welcome | Auth0 Rocket Example"}
            link rel="stylesheet" href="static/css/style.css";
        }
        body{
            h1 {"Guarded Route"}
            div {p {
                "You logged in successfully."
            }}
            div {p {
                "Email: " (user.email)
            }}
            div {p {
                a class="login" href="/profile" {"Another private route"}
            }}
        }
    }
}

כשהקוד של User הוא:

#[derive(Debug, Serialize, Deserialize)]
struct User {
    user_id: String,
    email: String,
}

impl<'a, 'r> FromRequest<'a, 'r> for User {
    type Error = ();
    fn from_request(request: &'a Request<'r>) -> Outcome<User, ()> {
        let session_id: Option<String> = request
            .cookies()
            .get("session")
            .and_then(|cookie| cookie.value().parse().ok());
        match session_id {
            None => {
                println!("no session id");
                rocket::Outcome::Forward(())
            }
            Some(session_id) => {
                println!("session id: {}", session_id);
                let db = State::<DB>::from_request(request).unwrap();
                let session_key = make_key!("sessions/", session_id);
                match db.get(&session_key.0) {
                    Ok(Some(sess)) => {
                        let sess: Session =
                            deserialize(&sess).expect("could not deserialize session");
                        if sess.expired() {
                            return rocket::Outcome::Forward(());
                        }
                        let user_key = make_key!("users/", sess.user_id);
                        match db.get(&user_key.0) {
                            Ok(Some(user)) => {
                                let user: User =
                                    deserialize(&user).expect("could not deserialize user");
                                rocket::Outcome::Success(user)
                            }
                            _ => rocket::Outcome::Forward(()),
                        }
                    }
                    _ => rocket::Outcome::Forward(()),
                }
            }
        }
    }
}

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

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

def show
    @post = Post.find(params[:id])
    authorize! :read, @post
    render plain: "Welcome #{current_user.name}"
end

או ל Express שם אפשר להשתמש ב Middlewares בשורת הגדרת הפונקציה:

app.get('/post/:id', authorize_user, (req, res) => {
    const user = res.locals.user;
    res.send(`Welcome! ${user.name}`);
});

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