ToCode

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

# היום למדתי: פקודות שמתחילו ב git מחפשים דרך קלה להריץ Shell Script בתור git alias? מסתבר שכל מה שצריך זה לשנות את השם של הסקריפט. כשגיט מקבל פקודה שהוא לא מכיר הוא באופן אוטומטי מנסה לחפש תוכנית על המחשב שמתחילה במילה git אחריה מקף ואז שם הפקודה, ואם מוצא הוא פשוט יריץ אותה. כל כך שמחתי לגלות את זה שיצרתי סקריפט בשם git-visit, נתתי לו הרשאות הרצה ושמרתי במקום נגיש בתוך ה PATH:

#!/bin/bash

xdg-open $(git remote -v | cut -d @ -f 2 | cut -d ' ' -f 1 | head -1 | sed 's/:/\//' | sed 's/.git$//' | sed s'/^/https:\/\//') >& /dev/null &

ועכשיו מכל תיקיה עם פרויקט גיט שמחובר לגיטהאב אפשר לכתוב:

$ git visit

ודף הפרויקט בגיטהאב ייפתח בדפדפן.

הבעיה עם Tailwind היא שבעבודה רגילה עם הפריימוורק יש נטיה לכתוב את כל העיצוב בתוך ה HTML ואז כשיש מספר אלמנטים עם עיצוב זהה נוצרת כפילות ב HTML וקשה בשינוי אחד להשפיע על כולם. אם ניקח את הדוגמה שהדבקתי בתחילת הפוסט, היא תיארה כרטיס אחד בטבלת מחירים. קל לדמיין שנרצה עוד שני כרטיסים כדי להשוות וככה נקבל ערימה של קוד כפול. להגנתם של טיילוינד צריך להגיד שהם כן חשבו על הבעיה ויצרו מנגנון בשם apply שבדיוק מאפשר להוציא אוסף של הגדרות tailwind לתוך קלאס חדש. זה מחזיר את הבעיה אלינו המתכנתים שנוטים לא להשתמש מספיק במנגנונים גנריים במצבים כמו כתיבת CSS. ## המכוער - תזכיר לי שוב מה זה p-2 הבעיה השניה עם Tailwind נוגעת ל Workflow. בהנחה שאין לכם תמיכה מספיק טובה ב IDE, אתם הולכים לבלות הרבה זמן בתיעוד שלהם כדי להבין איזה קלאס בדיוק אומר "ריפוד של 8 פיקסלים". בתיעוד רשימת הקלאסים לריפוד או באופן כללי לגדלים מציגה את הערכים ב rem-ים:

p-0     padding: 0px;
p-px padding: 1px;
p-0.5 padding: 0.125rem;
p-1     padding: 0.25rem;
p-1.5 padding: 0.375rem;
p-2     padding: 0.5rem;
p-2.5 padding: 0.625rem;
p-3     padding: 0.75rem;
p-3.5 padding: 0.875rem;
p-4     padding: 1rem;

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

# הטוב, הרע והמכוער עם Tailwind CSS טיילווינד סי אס אס הוא כנראה ספריית ה CSS הטרנדית ביותר כיום. אפשר לחשוב עליו כתגובת נגד לספריות כמו Antd ולדומיננטיות של JavaScript Frameworks: בגישה של antd אתה ממילא הולך להשתמש בפריימוורק אז הנה ספריית קונפוננטות שתתאים לכל פריימוורק שתבחר; בגישה של טיילווינד הנה דרך לכתוב CSS מודרני בלי JavaScript ולשתף את העבודה עם אחרים. אבל התיאוריה הזאת מקבלת ב Tailwind מימוש די מוזר שמתבסס על Utility Classes. זה אומר שבמקום ספריית קומפוננטות שנותנת קלאס ל"גלריית תמונות", קלאס ל"טבלה" וקלאס ל"כרטיס", אנחנו מקבלים בטיילוינד קלאס ל-"ריפוד של 32 פיקסלים" או קלאס ל"צבע רקע אפור". אם לא ראיתם אף פעם קוד HTML שמשתמש בטיילוינד הנה דוגמה לאחד, רק שימו לב לקחת אוויר לפני שקוראים:

<div class="relative flex pb-5 space-x-5 border-b border-gray-200 lg:space-x-3 xl:space-x-5">
    <svg class="w-16 h-16 text-green-400 rounded-2xl" viewBox="0 0 150 150" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"><defs><rect x="0" y="0" width="150" height="150" rx="15"></rect></defs><g fill="none" fill-rule="evenodd"><mask fill="#fff"><use xlink:href="#plan1"></use></mask><use fill="currentColor" xlink:href="#plan1"></use><circle fill-opacity=".3" fill="#FFF" mask="url(#plan1)" cx="125" cy="25" r="50"></circle><path fill-opacity=".3" fill="#FFF" mask="url(#plan1)" d="M-33 83H67v100H-33z"></path></g></svg>
    <div class="relative flex flex-col items-start">
        <h3 class="text-xl font-bold">Basic Plan</h3>
        <p class="tracking-tight text-gray-500">
            <span class="text-sm transform inline-block -translate-y-2.5 relative">$</span>
            <span class="text-3xl font-bold text-gray-800">10</span>
            <span class="text-sm -translate-y-0.5 inline-block transform">/ user</span>
        </p>
    </div>
</div>

הקלאס border-gray-200 קובע את צבע הרקע לגוון מסוים של אפור והקלאס text-green-400 קובע את צבע הטקסט לגוון מסוים של ירוק. אתם מוזמנים לנסות לנחש מה אומר כל אחד מהקלאסים האחרים. אז האם שווה לכם לנסות את טיילוינד לפרויקט הבא שלכם? הנה הטוב הרע והמכוער של הספריה. ## הטוב - זה עובד נתחיל בחדשות הטובות - טיילוינד עובד. כשלא צריכים לחפש איזה קומפוננטת antd בדיוק תתאים, אפשר להסתכל על העמוד, לכתוב את כללי העיצוב כמו Inline Styles ולראות איך דברים נבנים לאט צעד אחר צעד. ובתור בונוס מיוחד אתם לא צריכים להמציא שמות מוזרים לקלאסים רק בשביל שתוכלו להדביק קצת CSS על אלמנט. אבל מה שיותר טוב כאן מ Inline Style הוא שב Inline Style כל מספר או כל ערך הוא "קסום", הוא הגיע משום מקום ולא תמיד ברור באיזה ערך להשתמש במקום חדש. אם ניקח את דוגמת הצבעים, אז העובדה שיש לי קלאס text-green-200 אבל אין לי קלאס text-blue-200 אומרת שבפלטת הצבעים בפרויקט שלי יש צבע ירוק והוא מוגדר להיות בערך מסוים. אגב את הצבעים והפונטים אנחנו מגדירים בקובץ קונפיגורציה של tailwind ויש לנו שליטה מלאה על הערכים. הדבר החשוב כאן הוא ש Tailwind עוזר לנו לסדר איזה "כללי CSS" מותר לכתוב בפרויקט, כלומר באיזה צבעים מותר להשתמש, מה הריפודים המקובלים, מה גדלי הגופן שנשתמש בהם וכך הלאה. בצורה כזאת אנחנו כותבים Inline Style אבל עם קצת יותר סדר וקצת יותר כללים מאשר מאפיין style רגיל. גם שיתוף קוד עם חברים הוא ממש פשוט ולא צריך שהחבר ישתמש באותו JavaScript Framework שלי (למעשה אין כאן JavaScript Framework בכלל), ויש המון דוגמאות ברשת לעיצובים שאנשים הכינו עם טיילוינד. ואם אתם מאלה שמעדיפים להשתמש בקומפוננטות מוכנות אז פרויקט משלים בשם Tailwind UI כולל אוסף של אינסוף קומפוננטות טיילוינד (בתשלום וברישיון דרקוני) שתוכלו לקנות לפרויקט שלכם. יש גם פרויקט קוד פתוח בשם Daisy UI שמציע קומפוננטות פחות יפות אבל בחינם. בעבודה עם טיילוינד קל להיכנס לרצף עבודה ולעצב בכיף את העמוד בלי לפחד שכל חלק חדש שאנחנו מכניסים לא יהיה תואם לשאר הדף, אבל גם בלי להתעצבן שקומפוננטה מסוימת שמצאנו לא עובדת בדיוק כמו שאנחנו צריכים במערכת שלנו. ## הרע - מנגנון Extracting Components דורש משמעת שאין לנו

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

# הזמנה לוובינר: בניית פרויקט צד-לקוח עם Vite פיתוח פרויקטי צד לקוח היה פעם הדבר הכי קל בעולם - יוצרים קובץ עם סיומת html, שומרים ופותחים בדפדפן. אבל הגישה הזאת הפסיקה לעבוד ככל שהפרויקטים הפכו מורכבים יותר. הדרישה לכתוב אינסוף קבצי JavaScript בפרויקט הביאה לפיתוח של כלים שמאחדים את כל הקבצים האלה לקובץ אחד. הדרישה ל CSS יותר מתוחכם הביאה לפיתוח של scss, ובשנים האחרונות הדרישה ל JavaScript יותר מתוחכם הביאה לפיתוח שפות שמתקמפלות ל JavaScript ולכלים שרצים על קבצי המקור לפני שאלה מגיעים לדפדפן. במקביל יותר ויותר פיצ'רים של עולם הווב פשוט לא עבדו כשהדף נטען מ file-url ודרשו שימוש בשרת, אפילו שרת מקומי, רק בשביל לעבוד בסביבת הפיתוח. היום כמעט כל פריימוורק לפיתוח ווב מגיע עם כלי משלו לבניית תבנית לפרויקט, שלרוב מבוססת על webpack. וובפאק הוא מעולה ומספק אינסוף אפשרויות להתאמה אישית של הפרויקט, אבל בגלל זה הוא גם מסובך וקצת איטי. הכלי vite שפיתוח Evan You (היוצר של vue) נועד לתת תבנית אחידה לבניית פרויקטים, לכל הפריימוורקים המרכזיים, ועם חווית מתכנת טובה יותר מזו שאנחנו מקבלים מכלים כמו create-react-app. הפרויקט קטן יותר, נבנה יותר מהר, שרת הפיתוח יהיה מהיר יותר ואותו הכלי יעזור לנו לבנות פרויקטים לריאקט, ל Vue, ל Svelte או לפרויקט ללא פריימוורק בכלל. אם בא לכם לראות את הקסם בפעולה, לראות איך להתחיל פרויקטים מכל הסוגים ולהבין מה הופך את ויט לכל כך מהיר מוזמנים להצטרף אליי ביום חמישי בבוקר לוובינר של שעה על ויט. במהלך הוובינר אני מתכנן: 1. להראות איך מתקינים את ויט על המכונה. 2. להראות איך בונים פרויקטים בפריימוורקים המרכזיים. 3. להראות מה מיוחד ב vite ומה הקסם שגורם לו לעבוד כל כך מהר. 4. לדבר קצת על סוגי פרויקטים מיוחדים ואיזה התאמות צריך לבצע בקונפיגורציה בשביל לתמוך בהם. 5. לענות על שאלות שלכם לגבי הכלי. הוובינר יתקיים ביום חמישי הקרוב (ה 30.9) בשעה עשר בבוקר. תהיה הקלטה אבל יותר כיף להגיע ללייב כי אז אפשר לשאול שאלות ולהתפרץ. השתתפות בחינם והרישום בדף האירוע כאן: https://www.tocode.co.il/workshops/106 נתראה בחמישי ינון

      <action name="Execute">
        <command>brightnessctl set +2000</command>
      </action>
    </keybind>

    <keybind key="XF86MonBrightnessDown">
      <action name="Execute">
        <command>brightnessctl set 2000-</command>
      </action>
    </keybind>

זה מתחיל בכפתורי ה Winkey+חץ כדי לתפוס את חצי המסך הימני או השמאלי, Winkey+למעלה כדי למקסם את החלון ו Winkey+למטה כדי לבטל את המיקסום. אחר כך שני כפתורי הבהירות (יש לי אותם במקלדת) כדי לשלוט בתיאורה האחורית של המסך באמצעות תוכנת brightnessctl. למרות ש xml הוא עדיין דרך מיושנת לתאר קונפיגורציות, קובץ ההגדרות של אופנבוקס די אינטואיטיבי ואם מסתבכים יש גם תוכנה בשם obconf שנותנת ממשק גרפי לעדכון ההגדרות. משתמשים באופנבוקס ויש לכם טיפים נוספים לשתף? אל תשמרו בבטן וספרו פה בתגובות, במייל או בטלגרם.

# האם Openbox הוא מנהל החלונות המושלם? אחרי תקופה ארוכה עם i3 ו gnome לסירוגין התחלתי לגלות את Openbox, שנראה שמצליח לפתור את כל הבעיות שהיו לי עם השניים הקודמים. הנה בקצרה הדברים ש Openbox עושה נכון עבורי וקצת קונפיגורציה למי שרוצה להתחיל לשחק איתו. ## מה הבעיה שלך עם i3? כשרק עברתי ללינוקס השקעתי הרבה (מאוד) זמן בלימוד וקונפיגורציה של i3 ובאמת חשבתי שהקונספט של Tiling Window Manager הוא חיסכון גדול בזמן ומחשבה. והוא באמת כזה לתוכניות מסוימות אבל עם הזמן מסתבר שלא לכל התוכניות: זום, תוכנות מסרים מיידיים, מנהל קבצים - כל אלה עובדים טוב יותר בתור חלונות קטנים ומודאליים שמרחפים מעל החלונות הקיימים כשצריך אותם ונעלמים כשלא צריך אותם. ל i3 יש תמיכה בחלונות צפים אבל היא מוגבלת. זום אף פעם לא עבד לי שם טוב וחלונות נעלמו כל הזמן, וגם תוכנות אחרות התנהגו בדרכים יצירתיות מדי פעם. בתיאוריה אפשר לעשות הרבה עבודת הכנה ולהגדיר מראש איזה חלונות צריכים להיות תמיד צפים ואיזה צריכים להיות תמיד Tiled, אבל בפועל זה עבד רק רוב הזמן. בעיה נוספת שהיתה לי עם i3 קשורה למעבר בין Workspaces. מאחר וכל מסך מחולק לאריחים אז עשיתי לי הרגל לשים אפליקציות מסוימות ב Workspaces מסוימים. הבעיה שאני לא הבן אדם הכי מסודר בעולם ומהר מאוד האפליקציות היו מוצאות את הדרך ל Workspaces אחרים - וכך מצאתי את עצמי משוטט בין Workspaces למצוא את החלונות שרציתי. בסופו של דבר אחרי חודשים עם i3 הוא לא הוכיח תרומה משמעותית לפרודוקטיביות שלי. את המסוף ממילא אני יודע לחלק לאריחים באמצעות tmux, ושאר התוכנות עבדו יותר טוב בתור חלונות צפים. ## מה הבעיה שלך עם gnome? אחרי שהאסימון לגבי i3 נפל עברתי לחפש מנהל חלונות "שגרתי" יותר וכמובן שנפלתי על gnome. עכשיו גנום של אובונטו באמת מעולה: יש לו את ה gnome shell עם המון יכולות ותוספים, ואפשר להגדיר שם מיפויי מקשים בקלות ובאמת להתאים את המראה וההתנהגות בדיוק למה שאתם צריכים. אחרי שסידרתי את כל החלונות במקום ולמדתי את קיצורי המקשים כבר הייתי מוכן לחתום עם גנום על התחייבות שימוש לעשר שנים. אבל אז הוא נזכר לספר לי שכששמים כל כך הרבה יכולות במנהל חלונות אז גם צריכת הזיכרון לאט לאט תעלה, ושכשנותנים לכל אחד לכתוב תוסף ל gnome-shell אז חלק מהתוספים האלה יהיו גרועים וישברו דברים במקומות אחרים ורחוקים. בהתחלה חשבתי לוותר על תוספים אבל בלעדיהם אפשרויות הקסטומיזציה של גנום יחסית מוגבלות. אחרי זה חשבתי שאני יכול לחיות עם התוספים ופשוט לעשות Restart ל Session כל כמה ימים. בסוף המשכתי הלאה בחיפושים. ## שלום Openbox וככה הגעתי ל Openbox שהוא שילוב מעניין בין השניים: מצד אחד מנהל חלונות מינימליסטי, בעל קובץ קונפיגורציה מרכזי אחד ובלי שום "קישוטים", אבל מצד שני סטנדרטי בגישה שלו לחלונות ולא מסדר אותם בשבילכם. פשוט אבל עובד. כרגע הבעיה היחידה שלי עם אופנבוקס היא הממשק ב Alt Tab (כלומר המעבר בין חלונות) שמציג את החלונות אחד מתחת לשני במקום אחד ליד השני. ## קצת קונפיגורציה בשביל ליהנות מאופנבוקס הייתי צריך ממש מעט שינויים מהקונפיגורציה הסטנדרטית. באופן רגיל קבצי ההגדרות נשמרים בתיקיית ~/.config/openbox. קובץ ההגדרות הראשי נקרא rc.xml ויש גם קובץ בשם autostart שקובע איזה יישומים ייפתחו כשתיכנסו למערכת. אגב בנוסף אליו אופנבוקס גם קורא את רשימת היישומים מ ~/.config/autostart ויריץ גם אותם. ב autostart שלי שמתי רק שורה אחת שמפעילה את xfce4-panel :

/usr/bin/xfce4-panel &

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

    <keybind key="A-space">
      <action name="Execute">
          <command>/home/ynon/bin/switchkblayout.sh</command>
      </action>
    </keybind>

    <keybind key="W-Left">
      <action name="Unmaximize"/>
      <action name="MoveResizeTo">
        <x>0</x>
        <y>0</y>
        <width>50%</width>
        <height>100%</height>
      </action>
    </keybind>
    <keybind key="W-Right">
      <action name="Unmaximize"/>
      <action name="MoveResizeTo">
        <x>-0</x>
        <y>0</y>
        <width>50%</width>
        <height>100%</height>
      </action>
    </keybind>
    <keybind key="W-Up">
      <action name="Maximize"/>
    </keybind>
    <keybind key="W-Down">
      <action name="Unmaximize"/>
    </keybind>

    <keybind key="XF86MonBrightnessUp">

# דוקר: מה שלא צריך לדעת הקובץ הבא הוא קובץ Dockerfile תקין לגמרי שאני משתמש בו במצב פיתוח לפרויקט Node.JS:

FROM node:16

WORKDIR /app

הוא עובד אם מצמידים אליו קובץ docker-compose.yml שממפה את תיקיית הפרויקט לתיקיית /app על הקונטיינר, מגדיר את הפקודה להרצה ופותח את הפורטים המתאימים. אבל המרחק בין ה Dockerfile הקטנצ'יק שלי ל Dockerfile אמיתי של מצב פרודקשן הוא עצום. בתור התחלה דוקרפייל של פרודקשן צריך באמת לבנות אימג', הוא צריך להעתיק את הקבצים הרלוונטים מהפרויקט לתיקיית /app, הוא צריך להתקין את התלויות בתוך האימג' כדי שלא ייווצרו בעיות תאימות, הוא צריך לאתחל קבצים שאפשר לאתחל בעת יצירת האימג', הוא צריך לכלול קובץ Entrypoint מסודר שיוכל להריץ קוד איתחול לקונטיינר כשזה עולה, ועוד ועוד. וגם אחרי שתצליחו לגרום לזה לעבוד אנחנו עדיין רחוקים מאוד מדוקרפייל של גדולים - כי הגדולים מתחילים בכלל בלי דיסטרו, מייצרים דוקרפייל נפרד לפי מערכת הפעלה, מקפידים להשתמש כמו שצריך בשכבות וב Multi Stage Builds ומבינים איזה חלקים באימג' צריכים לאפשר קסטומיזציה. ובחזרה לשאלה מהכותרת- בניית Dockerfile מסודר לפרודקשן למערכת דורשת מיומנות והשקעת זמן. זו בדיוק מה ש Devops יודעים ואוהבים לעשות. כמפתחים שבונים מערכת אנחנו לא צריכים לדעת הכל על Docker, אבל כן יש כמה דברים שבלעדיהם אנחנו אבודים: 1. חשוב להכיר את ה "מה" - מה זה אומר לרוץ בתוך קונטיינר, מה המגבלות של הקונטיינר. 2. חשוב לדעת לעבוד עם Docker משורת הפקודה: להתחבר לקונטיינר, לראות את הלוגים, להיכנס לקונטיינר מסוים בסביבת פרודקשן, ליצור Volumes ולמחוק אותם, ליצור רשתות ולמחוק אותן, לפרסם אימג' למאגר ולהבין מה זה בכלל מאגר. להבין איך בונים ומוחקים אימג'ים וקונטיינרים, מה נשמר ב Cache ומתי צריך למחוק אותו. 3. חשוב לדעת לעבוד עם docker-compose, כי זה כלי שבעיקר מתכנתים משתמשים בו כדי ליצור לעצמנו סביבת פיתוח מהירה למערכת שמורכבת מהרבה סרביסים. צריך לדעת לכתוב את קבצי ההגדרות שלו ולהבין איזה אפשרויות קסטומיזציה קיימות לכל סרביס. אתם רוצים להיות מסוגלים לכתוב קובץ הגדרות שיהיה כמה שיותר קרוב למערכת הפרודקשן האמיתית, כולל העברת בקשות נכנסות דרך Nginx וכתיבה ללוג מרכזי. 4. חשוב להבין איך נשמר מידע רגיש, מה זה Secrets ואיך לנהל אותם. 5. חשוב להבין את ההבדל בין קונטיינר לאימג': מה קורה כשבונים אימג'? מה יכול להיות באימג'? מה קורה כשקונטיינר עולה? מה זה Entrypoint Script ומה ההבדל בינו לבין Dockerfile? איך מחכים שסרביסים מסוימים יהיו זמינים לפני שקונטיינר עולה, ואיך מריצים קוד איתחול בעליה של קונטיינרים. 6. חשוב להבין איך קונטיינרים מתקשרים אחד עם השני ועם העולם החיצון, על איזה רשת הם מדברים ואיך פותרים בעיות DNS או בעיות תקשורת בין קונטיינרים במצב פיתוח. תכסו את ששת הסעיפים האלה ולאנשי ה Devops אצלכם יהיו חיים הרבה יותר קלים כשהם יבואו להפוך את קבצי ה Dockerfile הקטנים שתכתבו לקבצי הגדרות אמיתיים, ואת קבצי ה docker-compose.yml הקטנים שלכם להגדרות קוברנטס.

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

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

/var/lib/gems/1.9.1/gems/nokogumbo-1.1.2/lib/nokogumbo.rb:24: [BUG] Segmentation fault
ruby 1.9.3p448 (2013-06-27 revision 41675) [x86_64-linux]

-- Control frame information -----------------------------------------------
c:0026 p:---- s:0094 b:0094 l:000093 d:000093 CFUNC  :parse
c:0025 p:0094 s:0090 b:0090 l:000089 d:000089 METHOD /var/lib/gems/1.9.1/gems/nokogumbo-1.1.2/lib/nokogumbo.rb:24
c:0024 p:0021 s:0086 b:0086 l:000085 d:000085 METHOD /var/lib/gems/1.9.1/gems/nokogumbo-1.1.2/lib/nokogumbo.rb:8
c:0023 p:0016 s:0082 b:0082 l:001fb8 d:000081 EVAL   (irb):4
c:0022 p:---- s:0080 b:0080 l:000079 d:000079 FINISH
c:0021 p:---- s:0078 b:0078 l:000077 d:000077 CFUNC  :eval
c:0020 p:0028 s:0071 b:0071 l:000070 d:000070 METHOD /usr/lib/ruby/1.9.1/irb/workspace.rb:80
c:0019 p:0033 s:0064 b:0063 l:000062 d:000062 METHOD /usr/lib/ruby/1.9.1/irb/context.rb:254
c:0018 p:0031 s:0058 b:0058 l:001b48 d:000057 BLOCK  /usr/lib/ruby/1.9.1/irb.rb:159
c:0017 p:0042 s:0050 b:0050 l:000049 d:000049 METHOD /usr/lib/ruby/1.9.1/irb.rb:273
c:0016 p:0011 s:0045 b:0045 l:001b48 d:000044 BLOCK  /usr/lib/ruby/1.9.1/irb.rb:156
c:0015 p:0144 s:0041 b:0041 l:000024 d:000040 BLOCK  /usr/lib/ruby/1.9.1/irb/ruby-lex.rb:243
c:0014 p:---- s:0038 b:0038 l:000037 d:000037 FINISH
c:0013 p:---- s:0036 b:0036 l:000035 d:000035 CFUNC  :loop
c:0012 p:0009 s:0033 b:0033 l:000024 d:000032 BLOCK  /usr/lib/ruby/1.9.1/irb/ruby-lex.rb:229
c:0011 p:---- s:0031 b:0031 l:000030 d:000030 FINISH
c:0010 p:---- s:0029 b:0029 l:000028 d:000028 CFUNC  :catch
c:0009 p:0023 s:0025 b:0025 l:000024 d:000024 METHOD /usr/lib/ruby/1.9.1/irb/ruby-lex.rb:228
c:0008 p:0046 s:0022 b:0022 l:001b48 d:001b48 METHOD /usr/lib/ruby/1.9.1/irb.rb:155
c:0007 p:0011 s:0019 b:0019 l:000fd8 d:000018 BLOCK  /usr/lib/ruby/1.9.1/irb.rb:70
c:0006 p:---- s:0017 b:0017 l:000016 d:000016 FINISH
c:0005 p:---- s:0015 b:0015 l:000014 d:000014 CFUNC  :catch
c:0004 p:0183 s:0011 b:0011 l:000fd8 d:000fd8 METHOD /usr/lib/ruby/1.9.1/irb.rb:69
c:0003 p:0039 s:0006 b:0006 l:0008b8 d:0011c8 EVAL   /usr/bin/irb:12
c:0002 p:---- s:0004 b:0004 l:000003 d:000003 FINISH
c:0001 p:0000 s:0002 b:0002 l:0008b8 d:0008b8 TOP   

אז הלכתי לבדוק מי זה הנוקוגומבו הזה ומסתבר שזה ג'ם שמשתמשים בו מג'ם שנקרא sanity ובו אני משתמש כדי לנקות תווי HTML לפני שאני מכניס אותם למסך. התיקון? ברגע שאנחנו מבינים ומוצאים את הבעיה זה החלק הקל - פשוט משדרגים גירסה של Sanity והכל התחיל לעבוד. לא פחות מעניין מהתיקון זה מה עושים כדי שהבעיה לא תקרה פעם הבאה שאני מעלה גירסה. אז יש לי סט בדיקות מסוים על האתר שבודק flow-ים מרכזיים כמו שהקורסים עובדים, אבל האמת שעד עכשיו לא חשבתי שהבלוג יישבר ובאמת לא היתה עליו אף בדיקה. אני אוהב לכתוב בדיקות על תרחישים שנשברים ורק אחרי שדברים נשברים כי אחרת לא יוצאים מזה, אז כבר עם התיקון הוספתי את קובץ הבדיקות הבא:

# coding: utf-8
require 'rails_helper'

describe 'Blog', type: :system do
  before do
    create(:blog_post, slug: 'post1', title: 'post 1')
    create(:blog_post, slug: 'post2', title: 'post 2')
  end

  it 'shows index page' do
    visit blog_index_path
    expect(page).to have_title 'tocode | הבלוג של ינון פרק'
  end

  it 'shows a post page' do
    visit blog_path(id: :post1)
    expect(page).to have_title 'tocode | post 1'
  end
end

הי חברים לפני כמה ימים כתבתי כאן על הכלי vite שמאפשר חווית פיתוח טובה ומהירה יותר לפרויקטי ווב בשבוע הבא יום חמישי בעשר בבוקר אעביר וובינר של שעה בו אראה את הכלי, במה הוא שונה מ webpack ואיך הוא עוזר לכם לפתח יותר בקלות פרויקטים. אם בא לכם להצטרף (זה חינם, תהיה גם הקלטה) מוזמנים דרך הקישור: https://www.tocode.co.il/workshops/106