ארכיון חודשי: ינואר 2021

תכנות בווינדוז – 2020-2021

במהלך 2020 יצרתי מערכות הרצות על Windows. זה לא במקום עולם הלינוקס שאני מפתח בו, אבל כן קשור לעולם שאני חי בו – פיתוח מערכות רשת, טלפוניה ומערכות IT.

מי שלא מכיר, הייתי בעבר מתכנת Windows, פיתחתי בעיקר עם VB/VBA ודלפי, כך שהזיכרון שלי על win api הדהים אותי שעדיין קיים ורלוונטי יחסית.

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

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

אחד הדברים הראשונים שכל מתכנת בעולם הלינוקס מגלה – Windows אינה מערכת קלה לפיתוח בה. היא גורמת לכל דבר שמרגיש מאוד קל ופשוט בלינוקס להיות מסורבל ומסובך בWindows ברמה שגורמת לפעמים לתסכול רב.

המערכת שאני כותב היא cross platform וכתובה ב Go. בלינוקס היה לי מאוד קל להתחבר לlibc כאשר אין לי binding או חבילה מוכנה בGo (ואין לי את הזמן ליצור את התמיכה בכל הapi set ואני צריך רק פונקציות וstruct מסוימים מאוד), אבל בווינדוז אני מוצא את עצמי עובד מאוד קשה מול COM או פשוט ליצור ב VS איזשהו DLL שאני כותב ב C/++ ‎ (משלב בין שניהם כי לא באמת רגיל לתכנת ב ++C).

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

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

בזמן התמודדות הבעיות הבנתי למה לינוקס נוח עבורי כל כך, בזמן שפיתוח בWindows ממש לא (אפל איפשהו באמצע). בעיה מוזרה שהיתה לי – יוצר קובץ (בינארי ו/או טקסט) כותב אליו, עושה close ואולי אפילו flush לפני – מנסה לגשת אליו ממערכת אחרת והקובץ לא קיים, או בגודל 0.
הבעיה היתה שבעוד שה File Descriptor (או Handle בWindows) שוחרר, מערכת ההפעלה עדיין לא כתבה את המידע או כל המידע לקובץ בפועל. עד עכשיו אני לא יודע למה, וזה גם לא מתרחש כל הזמן.

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

עוד בעיה – יצרתי dll ב ++C (או חצי ++C וחצי C מבחינת התחביר), לדעתי ייצאתי (כלומר export) את כל הפונקציות שרציתי, אבל בפועל לא הצלחתי לעשות לכולן link. בלינוקס אני יכול עם objdump לראות מה ייצאתי בפועל, אבל בווינדוז? אני צריך כלי חיצוני שלא מגיע עם VS.

ניסיתי גם להדפיס למסך תוכן שהוא utf-8 לא הכל מוצג. עכשיו שאלות – האם זה פונטים? האם זה באג שלי?
הcmd לא כזה ברור אם הוא מסוגל להציג את זה בכלל (הבעיה היתה הגדרות locale של פונטים). למשל בלינוקס הרצה של טקסט מול od -x תעזור לי מאוד לראות ב hex האם מדובר בבעיה שלי או משהו אחר.

כאשר ניסיתי לעבוד ב VS עם breakpoints להבין את הבעיה למעלה הגעתי למצב שהווינדוז נתקע עם 100% cpu במשך 45 דקות. מה שקרה בסוף זה אתחול כפוי של מערכת ההפעלה כי שום דבר לא הגיב לי.
זה נמשך 45 דקות כי הייתי צריך להתמודד בין לבין עם משהו אחר אז השארתי את זה לרוץ בזמן שעברתי וכשחזרתי זה עדיין היה תקוע.

כאשר אני כותב מערכות לווינדוז, אני מרגיש כמו משהו זר שאיכשהו בכל זאת זה עובד, אבל בקסם, בעוד שלינוקס זורם לי מאוד למרות שאני עובד ב ‎(neo)vim, וטרמינל בעיקר במקום איזשהו IDE גדול.

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

זו כמובן התחושה שלי בנושא.

ממשקי משתמש – יצירתיות מול שימושיות

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

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

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

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

נלקחת מ: https://commons.wikimedia.org/wiki/File:Mission_Accomplished_-ALS_Ice_Bucket_Challenge(14848289439).jpg

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

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

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

זה התחיל בערך בעשור האחרון – יותר ויותר חברות הולכות לאנשים שהמקצוע שלהם – "חווית משתמש" ו/או "תכנון ממשקים", ונראה כי מאז שזה מתרחש – לי קשה מאוד להתמודד עם הרבה מאוד תכנים. שמתי לב כי ככול שהממשק נקי יותר וממוקד יותר במה שאני צריך ממנו – ככה קל לי יותר לעבוד איתו, בעוד שככול שהוא עשיר יותר בצבעים וכו' קשה לי להתמודד איתו.

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

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

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

עלייתן ונפילתן של רשתות חברתיות – דעה

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

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

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

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

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

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

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

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

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

להמשיך לקרוא

אם או אחרת?

לאחרונה היה לי חצי דיון בטוויטר לגבי מתודולוגיה תכנותית – האם יש מצבים בהם יש מקום להשתמש בelse כאשר יש שאלת תנאי.

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

למשל ראו את קוד גו הבא:

...
a := 1
if b > 12 {
  a = 2
}
...

למעשה הצבתי ערך ברירת מחדל ל a של 1 ואם משתנה בשם b גדול מהמספר 12, אז אציב את הערך 2.

כאן אני יכול להסכים כי אין צורך ב else.

אבל לא תמיד המצב הוא כזה פשוט:

...
err = nil
if b > 12 {
   callOneFunc()
} else {
  err = callSecondFunc(b)
}
...

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

אבל אחרת, הרץ פונקציה המועבר אליה b והחזר שגיאה (במידה ויש).

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

אבל, יש מצבים בהם אני יכול לוותר לגמרי לשאלת התנאי:

...
caller := map[bool] func(i int)error {
  true: callOneFunc,
  false: callSecondFunc,
}

err = caller[b > 12](b)
...

כאן יצרתי מערכת של רישום פונקציות שונות על ידי שימוש ב hash map. כאשר לא משנה מה התוצר, אני יכול להריץ פונקציה בעלת אותה חתימה, אבל ללא צורך בתנאי כלשהו, אלא רק בתשובה בוליאנית. כמובן שאפשר גם לייצג ככה switch case ללא default, כל עוד האיבר בהכרח חייב להיות קיים.

אז מה "נכון"?

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

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

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

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

...
func ExecIfBigger(b int) {
  if b > 12 {
    callOneFunc()
  }
}

...

ExecIfBigger(b)
if b <= 12 {
  err = callSecondFunc(b)
}
....

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

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

מה דעתכם בנושא?