ToCode

# דיאלוגים מודאליים בדפדפן לפעמים יש לי אמונות והרגלים כל כך עתיקים שאפילו כשיש מסביב רמזים לשינוי אני לא טורח לבדוק אותם. דיאלוגים מודאליים ב HTML? אין דבר כזה. צריך ליצור אלמנט ולהשתמש ב CSS כדי לתת "הרגשה של מודאלי". ככה זה היה תמיד. כן טוב, מה שהיה הוא לא מה שיהיה. כרום 37, אדג' 79, פיירפוקס 98, אופרה 24, ספארי 15.4 ואפילו דפדפני המובייל - כולם תומכים היום תמיכה מובנית וטבעית באלמנט dialog ויודעים להציג דיאלוג מודאלי בלי שום ספריה ובצורה נגישה. בואו נראה איך זה עובד. ## דוגמה 1 - דיאלוג עם כפתור סגירה בשביל ליצור דיאלוג מודאלי אני רק צריך אלמנט מסוג dialog ב HTML:

<p>
  Hello World
  <button id="show">show dialog</button>
</p>
<dialog id="modal">
  <p>Dialog Content</p>
  <button>Close</button>
</dialog>

בשביל להציג או לסגור את הדיאלוג אני משתמש ב JavaScript. הפונקציה showModal מציגה את הדיאלוג בצורה מודאלית, והפונקציה close סוגרת את הדיאלוג:

document.querySelector('#show').addEventListener('click', () => {
  const dialog = document.getElementById("modal");
  dialog.showModal();
})

document.querySelector('#modal button').addEventListener('click', () => {
  const dialog = document.getElementById("modal");
  dialog.close();
});

כשהדיאלוג פתוח אי אפשר ללחוץ על הכפתורים הרגילים שנמצאים על העמוד ובשינוי פוקוס עם טאב אנחנו נשארים בתוך הדיאלוג - ולחיצה על Escape סוגרת אוטומטית את הדיאלוג. קסום. <iframe height="300" style="width: 100%;" scrolling="no" title="Untitled" src="https://codepen.io/ynonp/embed/PoxrOjq?default-tab=html%2Cresult" frameborder="no" loading="lazy" allowtransparency="true" allowfullscreen="true"> See the Pen <a href="https://codepen.io/ynonp/pen/PoxrOjq"> Untitled</a> by Ynon Perek (<a href="https://codepen.io/ynonp">@ynonp</a>) on <a href="https://codepen.io">CodePen</a>. </iframe> ## דוגמה 2 - דיאלוג לא מודאלי אם אתם רוצים שהעמוד ימשיך לתפקד תוך כדי שהדיאלוג מוצג אז הדיאלוג שלכם נקרא "דיאלוג לא מודאלי", ותוכלו להשתמש בפונקציה show בשביל להציג את הדיאלוג בצורה כזאת:

document.querySelector('#show').addEventListener('click', () => {
  const dialog = document.getElementById("modal");
  const counter = dialog.querySelector('.counter');
  counter.textContent = Number(counter.textContent) + 1;
  dialog.show();
})

document.querySelector('#modal button').addEventListener('click', () => {
  const dialog = document.getElementById("modal");
  dialog.close();
});

והנה גם הוא באייפריים בשביל משחקים: <iframe height="300" style="width: 100%;" scrolling="no" title="Untitled" src="https://codepen.io/ynonp/embed/ZEmgYmZ?default-tab=html%2Cresult" frameborder="no" loading="lazy" allowtransparency="true" allowfullscreen="true"> See the Pen <a href="https://codepen.io/ynonp/pen/ZEmgYmZ"> Untitled</a> by Ynon Perek (<a href="https://codepen.io/ynonp">@ynonp</a>) on <a href="https://codepen.io">CodePen</a>. </iframe> ## דוגמא 3 - דיאלוגים מחזירים ערך ואם הסיפור עד כאן לא היה מספיק משוגע, תשמחו לשמוע שדיאלוגים יכולים גם להציג טפסים ולהחזיר ערך שייצג את הערכים שהמשתמש בחר דרך הטופס. אם בתוך דיאלוג יש טופס, ולטופס הזה יש מאפיין method עם הערך dialog, אז בלחיצה על כפתור של הטופס הדיאלוג אוטומטית ייסגר, ומאפיין returnValue של הדיאלוג יכיל את ה value של הכפתור שנלחץ. בדוגמה הבאה שמתבססת על דוגמה מהתיעוד הדיאלוג כולל טופס עם תיבת בחירה:

<!-- A modal dialog containing a form -->
<dialog id="favDialog">
  <form method="dialog">
    <p>
      <label>
        Favorite animal:
        <select>
          <option value="default">Choose…</option>
          <option>Brine shrimp</option>
          <option>Red panda</option>
          <option>Spider monkey</option>
        </select>
      </label>
    </p>
    <div>
      <button value="cancel">Cancel</button>
      <button id="confirmBtn" value="default">Confirm</button>
    </div>
  </form>
</dialog>
<p>
  <button id="showDialog">Show the dialog</button>
</p>
<output></output>

# כמה פחדים אמיתיים מ WEI משמעות ראשי התיבות WEI היא Web Environment Integrity. זהו API שנתמך כבר בכרום אבל עדיין לא סטנדרטי שמטרתו לוודא בצד השרת שהדפדפן שפונה לקבל את התוכן הוא דפדפן "אותנטי". אפשר לחשוב על WEI בתור Captcha משודרג - משתמש גולש לאתר, האתר דורש מהדפדפן להוכיח שהוא בן אדם שמשתמש בדפדפן "רגיל", הדפדפן פונה לשרת אימות עם ה URL אותו הוא רוצה למשוך, מקבל טוקן ומשתמש בטוקן כדי לחזור לשרת המקורי ולקבל את התוכן. ההבדל המרכזי בין מנגנון זה לבין Captcha הוא שבדרך כלל Captcha חוסם רק מביצוע פעולות באתר, ו WEI יחסום בכל פניה לתוכן. אלה הפחדים המרכזיים של מפתחים והקהילה מ API זה: 1. חסימת מתחרים - אם חברת דפדפנים אחת (אה לא אמרתי? ה API הוצע ונדחף על ידי גוגל) יכולה להחליט אם דפדפן מסוים הוא "אותנטי" כדי לגשת לתוכן, הם יוכלו לחסום דפדפנים מתחרים או להשתמש בכח שלהם כדי לקבוע איזה יכולות דפדפן חייב לממש. 2. אוטומציה - הכנסת תקן WEI תהפוך פרויקטי תחביב וגם פרויקטים יותר גדולים שמתבססים על אוטומציה להרבה יותר קשים. זאת בעצם חסימה מוחלטת של כל אפשרות ל Web Scraping. 3. פרטיות - איך השרת של גוגל ידע אם אתה בן אדם שגולש דרך דפדפן אמיתי? האם נתוני שימוש או נתונים התנהגותיים כלשהם ישודרו מהדפדפן לשרת האימות? האם תהיה לנו שליטה על הנתונים שנשלחים? 4. תוספים לדפדפן - האם תוספים לדפדפן יוכלו למשוך מידע מאתרים? או לחסום מידע מאתרים? איך כל העסק ישפיע על עולם פיתוח התוספים? ברמה האישית אוטומציה של עולם הווב היתה תמיד אחת הסיבות שלי לבחירה בעולם זה. היכולת לבנות כלים קטנים שעוזרים לי בלי לבקש רשות מאף אחד היא בבסיס של החופש שלי היה כל כך חשוב בעת גלישה ברשת. יהיה מאוד חבל להיפרד מחופש זה בגלל שגוגל החליטו שהחופש שלי פוגע להם בהכנסות מפירסומות. כרגע מוזילה עדיין מסרבים לממש את התקן. נמשיך לעקוב ונקווה לטוב.

אתגר אחרון בעבודה עם neo4j הוא בבדיקות ובפרט בהרצה מקבילית של בדיקות. אם הבדיקות שלי מכילות איזשהו קוד שקשור לבסיס נתונים הן צריכות להתחבר לבסיס נתונים אמיתי. אין גירסת In Memory או משהו שיישמר בקובץ בודד כמו sqlite. לכן בשביל להריץ בדיקות במקביל ומהר נצטרך לכתוב את כל הקוד של המערכת כך שיוכל לעבוד בתוך טרנזאקציה למצב "בדיקות", להעביר מהבדיקה טרנזאקציה ובסוף הבדיקה לעשות Rollback. לא סוף העולם אבל היה נחמד אם היתה כבר תשתית שעושה את זה בתור פלאגין ל pytest. בינתיים אופציה יותר קלה שאני בחרתי היתה לאפס את כל ה DB בין בדיקות עם fixture אוטומטי. עובד אבל הרבה יותר לאט. שורה תחתונה ארבעה חודשים לתוך הפרויקט אני עדיין מאוד אוהב את neo4j, אבל גם שמח שהחסרונות מתחילים להופיע. האתגר הגדול הבא יהיה ביצועים, אבל על זה עדיין מוקדם לדבר.

# ארבעה חסרונות מורגשים של neo4j (אחרי 4 חודשים של עבודה) התחלתי לעבוד עם neo4j באפריל בהתרגשות גדולה וגם כתבתי עליו כמה פוסטים באותה תקופה. ארבעה חודשים לתוך הפרויקט החסרונות מתחילים להיות יותר מורגשים, למרות שעדיין מוקדם ורק כשהפרויקט יעלה לפרודקשן אוכל לענות על שאלת המחץ לגבי הביצועים ואם הוא מצליח לסחוב משתמשים אמיתיים. בינתיים קבלו ארבעה חסרונות של neo4j שיכולים ממש להרגיז בזמן פיתוח- ## רק בסיס נתונים אחד ברישיון החופשי מגבלה ראשונה ומאוד מוזרה של הגירסה החופשית של neo4j היא ששרת בסיס נתונים יכול להחזיק רק בסיס נתונים אחד. זה אומר שאם התקנתם neo4j על מחשב הפיתוח שלכם אתם תקועים עם בסיס נתונים אחד לפיתוח. בשביל להריץ בסיס נתונים אחד לפיתוח, אחד ל Staging ואחד לבדיקות יש להריץ 3 עותקים של neo4j, כל אחד בתור דוקר קונטיינר משלו עם מיפוי לפורטים שונים. כשנשאלו לגבי הפיצ'ר התגובה של neo4j היתה- > Presently there are no plans to move the multi-DB feature into community edition. Usually that feature is used by SaaS customers who are Enterprise users. There's good product-market fit there. ## אין דרך קלה לזכור שינויים מחיקה רכה ושמירת שינויים היסטוריים הם מנגנונים קשים למימוש בכל בסיס נתונים, אבל בבסיסי נתונים טבלאיים לפחות יש הרבה כלים קיימים ומימושים שאפשר להיעזר בהם. ג'מים כמו Discard או paper_trail של ריילס מטפלים ברוב מה שצריך מהקופסה כדי לא לאבד מידע. ב neo4j צריך לעשות הכל לבד, ומבנה בסיס הנתונים לפעמים לא עוזר. בפרט neo4j מאפשר לשמור מידע בצמתים או בקשתות שמחברות בין הצמתים. בשביל לשמור היסטוריה לצומת אני יכול "להוציא" את הדברים שנשמרים בצומת (הסטייט) לצמתים נפרדים שיהיו מקושרים אליו, כאשר כל שינוי יווצר צומת State חדש שיהיה מחובר בקשת עם לייבל STATE וכל הסטייטים הקודמים יהיו מחוברים בקשת מסוג OLD_STATE ועל הקשת נוכל לשמור את תאריך השינוי. שמירת היסטוריה של חיבורים תהיה קצת יותר מסובכת כי אי אפשר לחבר "קשת" ל"קשת" או "צומת" ל"קשת", ואז צריך לשחק עם לייבלים של קשתות. אם תצטרכו לממש שמירת היסטוריית שינויים ב neo4j אני ממליץ על ההרצאה הזו שעוברת על מספר טכניקות מרכזיות עם דוגמאות קוד. ## שגיאות כתיב בשאילתות יוצרות משתנים חדשים שפת השאילתות של neo4j מדליקה וגמישה וכל הדברים האלה, אבל יש לה גם חיסרון - היא לא מספיק רגישה לשגיאות כתיב. למשל בבסיס נתונים דמיוני של סרטים שאילתה כזו יכולה להחזיר את כל הסרטים בהם שיחק תום הנקס:

MATCH (tom:Person{name:"Tom Hanks"})-[:ACTED_IN]-(movie:Movie)
RETURN movie;

ואפשר להמשיך ולהחזיר את שמות כל הבמאים של אותם סרטים:

MATCH (tom:Person{name:"Tom Hanks"})-[:ACTED_IN]-(movie:Movie)
MATCH (director:Person)-[:DIRECTED]-(movie)
RETURN director.name;

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

MATCH (tom:Person{name:"Tom Hanks"})-[:ACTED_IN]-(movie:Movie)
MATCH (director:Person)-[:DIRECTED]-(movei)
RETURN director.name;

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

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

test 'should subscribe to blog mailing list' do
  visit blog_index_url
  fill_in :email, with: @email
  click_button I18n.t('sign_up_email')

  assert_selector 'p', text: I18n.t('subscriptions.success')
  assert Subscriber.exists?(email: @email)
end

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

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

# תשעים ושלוש אחוז נתח שוק בסקר המפתחים של סטאק אוברפלו האחרון הם שאלו את המפתחים באיזה תוכנת ניהול גירסאות אנחנו משתמשים. לא תופתעו לשמוע שכמעט 94% מהמשיבים בחרו בגיט, ועוד 4% ענו שלא משתמשים בשום תוכנת ניהול גירסאות. איך תוכנת ניהול גירסאות אחת מצליחה להשתלט כך על העולם? אני לא יודע, אבל אלה כמה סיבות שאני יכול לנחש- 1. כל אחד יכול לפתוח מאגר אצלו ולהתחיל לעבוד (משמעותית יותר קל מ SVN שהיה פופולרי לפני גיט, ועוד עשרות תוכנות ניהול גירסאות מתחרות עם שרת מרכזי). 2. גיטהאב סיפק פלטפורמה מעולה למתכנתי קוד פתוח שהיו צריכים לעבוד עם מתכנתי קוד פתוח אחרים. היכולת למזלג פרויקט, לשלוח Pull Requests והאיחסון החינמי לפרויקטים משכו את המפתחים שעזבו את SourceForge. ואם רצית להצטרף לפרויקט קוד פתוח או פרויקט המאוחסן על גיטהאב היית צריך ללמוד גיט. גיטהאב הפך את גיט לאופנתי. 3. בסקר של אקליפס מ 2009, חמשים ושמונה אחוז מהמשיבים השתמשו עדיין ב SVN. ב 2011 גיטהאב עקף בפופולריות את SourceForge ושם התחיל אפקט כדור השלג. ב 2015 גיט עדיין עמד על 69% נתח שוק, מספר שהפך ב 2018 ל 87% כשמייקרוסופט רכשה את גיטהאב והכניסה את גיט גם לארגונים גדולים. כשאנחנו מסתכלים על כלי כל כך דומיננטי קשה לדמיין אפילו משהו אחר, ובטח משהו אחר שמישהו ירצה להשתמש בו. לחזור ל SVN? מרקוריאל? לא תודה. ובכל זאת גם בשוק שנראה סגור לגמרי יש עדיין פרויקטי צד מעניינים. אחד מהם הוא כלי בקרת תצורה בשם pijul שלוקח גישה שונה מאוד לניהול שינויים כשהדגש שם הוא על ה"שינויים" ולא על מצב הפרויקט בנקודה של קומיט. יצליח? כנראה שלא. אבל גם גיט לא יהיה איתנו לנצח, ובטוח יהיה מעניין לראות איך יראה העולם אחריו.

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

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

כל מילה https://j11g.com/2023/08/07/the-legacy-of-bram-moolenaar/

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

# חמישה דברים שהייתי משנה בקלוז'ר קלוז'ר היא שפה פונקציונאלית יחסית פשוטה ופופולרית (יחסית לשפה פונקציונאלית) שרצה בתוך ה JVM. בזכות תחביר ליספי ומבני נתונים מגוונים ובנויים בשפה, וכמובן בזכות העובדה שהכל Immutable, הרבה אנשים אוהבים אותה. אני כתבתי פוסט מבוא לקלוז'ר בעבר כאן: https://www.tocode.co.il/blog/2019-11-hello-clojure וגם העברתי יחד עם חבר וובינר על קלוז'ר שמוקלט כאן: https://www.tocode.co.il/past_workshops/95 אבל למרות כל הדברים הטובים שסיפרתי שם על קלוז'ר, יש גם כמה דברים שמפריעים לי בשפה במיוחד בעבודה על פרויקטים גדולים. ומאחר וריק היקי יוצר השפה בדיוק עזב עכשיו את העבודה בניובנק אולי חלק מהרעיונות פה ימצאו אוזן קשבת ופנויה לשינויים. ## חוסר יכולת להגדיר טיפוסים לפרמטרים וערכי החזר של פונקציות אופנות משתנות עם הזמן ובתכנות אחת האופנות הכי משמעותיות שהשתנתה בשנים האחרונות היתה חוסר הרצון של מתכנתים להגדיר טיפוסים. אחרי שראינו כמה קל להגדיר טיפוסים בשפה כמו TypeScript אנחנו לא רוצים לחזור אחורה. היום אנחנו יודעים שקומפיילר יכול להסיק המון מסקנות (Type Inference) גם בשפות דינמיות. אנחנו יודעים שכתיב הטיפוסים לא צריך להיות מעיק, ולא חייבים לאפיין היררכיות ירושה מסובכות כדי לקבל ביטחון גדול יותר בקוד שלנו. הבחירה של קלוז'ר להישאר מחוץ למשחק הטיפוסים היא כרגע המחסום המשמעותי ביותר בין קלוז'ר ליישומים גדולים. ## אקוסיסטם האקוסיסטם של קלוז'ר מורכב ממעט פרויקטים גדולים ומשמעותיים ולצדם הרבה מאוד פרויקטי קוד פתוח שלא ממש מתוחזקים. וזאת בעיה כי בניגוד לפייתון, הרבה דברים בקלוז'ר כן דורשים התקנה של ספריות חיצוניות או שימוש בכלים של Java. בין הדברים שלא נכללים בספריה הסטנדרטית יש לנו: עבודה עם http, קריאה וכתיבת JSON, CSV ו XML, עבודה עם קבצים מכווצים, חיפוש glob במערכת הקבצים, הצגת ממשק גרפי, עבודה עם אזורי זמן ועוד. ## קשה לדבג קוד פונקציונאלי מצד אחד מאוד קל לכתוב קוד קלוז'ר כי העבודה דרך ה REPL אומרת שאנחנו כל הזמן "מנסים" דברים עד שמשהו עובד, אבל מצד שני אחרי שיש לי כבר פונקציה ומשהו בהפעלה לא עובד אני צריך להתאמץ כדי להבין מה קרה שם. לדוגמה נניח שיש לי פונקציה שמקבלת מידע על משתמש ומחזירה אם כתובת המייל שלו חוקית, משהו כזה:

(defn is-valid-email [user]
    (let [email (:email user)]
        (re-matches #".+\@.+\..+" email)))

וגיליתי שמשהו בה לא נכון, אז בשביל להפעיל אותה אני צריך שיהיה לי מילון של user. עכשיו נכון בדוגמה הקטנה זה משהו שמאוד קל ליצור, אבל בדוגמאות יותר גדולות כש user יכול להיות אוביקט שמייצג שאילתה מבסיס נתונים או קובץ אז יהיה יותר קשה ליצור אחד רק בשביל לנסות את הפונקציה. ונכון תיאורטית אפשר תמיד לפרק את הקוד ליותר פונקציות קטנות שאת הפרמטרים שלהן יהיה קל ליצור בתוכנית בדיקה, אבל בעולם האמיתי כשמגיעים כבר לקוד עם תקלה היית רוצה פשוט לשים נקודת עצירה ולראות מה הערכים או להוסיף הודעות הדפסה, ובקוד ליספי לא תמיד יש איפה. ## צ'ט ג'י-פי-טי לא ממש יכול לעזור בדומה לאקוסיסטם, גם התיעוד על קלוז'ר ברשת עדיין לא מספיק משמעותי ולכן כשאתם נתקעים קשה למצוא תשובות ב Stack Overflow ו Chat GPT לא ממש מצליח לעזור. זה אולי לא ממש אשמת קלוז'ר אבל זה בהחלט משהו לקחת בחשבון לפני שבוחרים בה לפרויקט גדול. ## רצפים עצלים אחת התכונות היפות של קלוז'ר היא גם אחת המבלבלות - וזה ה Lazyness של השפה. שימו לב לתוכנית הבאה:

(defn sum-numbers [nums]
  (map println nums) ;; Let's print each number for debugging.
  (reduce + nums))

(sum-numbers (range 10))

;; => 45
;; But where are the printlns?

הקוד מחזיר 45 כצפוי, אבל לא מדפיס את כל המספרים שקיבל כי map מחזירה Lazy Sequence שאף אחד לא משערך. גם התוכנית הזאת יכולה להפתיע כי למרות ה catch היא תזרוק Exception:

(defn safe-invert-seq [s]
  (try (map #(/ 1 %) s)
       ;; For the sake of the example, let's return an empty list if we
       ;; encounter a division by zero.
       (catch ArithmeticException _ ())))

(safe-invert-seq (range 10))

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