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

• רק בתור עצמאי הצלחתי לעבוד במה שאני רוצה באמת

• בתור שכיר במקצוע שלי הייתי מרוויח רבע

• רציתי לבחור איזה פרויקטים אני לוקח ועל מה אני עובד

• רציתי לבחור עם איזה אנשים אני עובד (ועם מי אני לא עובד)

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

• חיפשתי דרך לבלות יותר זמן עם הילדים

• חיפשתי הכנסה נוספת

• תמיד חלמתי להקים עסק שיצליח בגדול

• כולם במשפחה שלי עצמאיים

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

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

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

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

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

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

2. שימרו לכל פרויקט סט בדיקות אוטומטיות ומכונה שיכולה להריץ בדיקות אלה.

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

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

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

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

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

אבל המציאות לא עובדת ככה-

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

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

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

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

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

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

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

בפוסט זה אדגים איך לכתוב אפליקציית Node.JS ו Express פשוטה, ששולפת מידע מבסיס נתונים באמצעות ספריית Knex.JS ומציגה אותו בתור טבלה ב HTML. חסרי הסבלנות ביניכם מוזמנים לדלג על ההסבר ולקפוץ ישר לקוד במאגר: https://github.com/ynonp/node-knex-ejs-demo

לכל השאר - בואו נראה איך זה עובד.

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

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

דוגמאות? בטח-

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

$ git ls-files

ולא מקבלים כלום או מקבלים רק את הקבצים שנמצאים אצלכם בתיקיה הפנימית. במקום זה, תוכלו לכתוב:

$ git ls-files :/

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

או, נניח שאתם באותה תיקיה פנימית ובהפעלת סטטוס אתם מקבלים:

On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   ../agenda.md

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        ./
        ../react-list/

no changes added to commit (use "git add" and/or "git commit -a")

מה שאומר שגם התיקיה שאני נמצא בה אינה שמורה בגיט, גם הקובץ agenda.md שנמצא בתיקיה מעליי השתנה וגם התיקיה react-list שנמצאת בתיקיה מעליי אינה שמורה בגיט.

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

$ git add :/

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

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

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

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

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

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

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

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

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

עד שהיינו צריכים לשנות משהו.

כי הבעיה עם CSS היא שהכל תלוי שם בהכל: מאפיין של גודל גופן על אלמנט מסוים משפיע על הגופן אצל הילדים שלו, מאפיין position באלמנט מסוים משפיע על ההתנהגות של מאפייני top ו left אצל הילדים שלו. בקיצור CSS מרגיש כמו מגדל קלפים - זה עובד, אבל שינוי הכי קטן ודברים יוצאים מהמקום.

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

אז ב Tailwind CSS אני יכול לכתוב שורת HTML כזאת:

<img
    src="http://placekitten.com/100/100" 
    alt="cat"
    class="py-4 pl-4 aspect-square"
/>

ואני אקבל תמונה של חתלתול עם ריפוד עליון וריפוד משמאל של 16 פיקסלים כל אחד ומאפיין aspect-ratio עם ערך של 1/1.

ומה כל כך מלהיב בלהעביר את כל כללי העיצוב ל HTML? אם נחזור לסיפור של הפרילאנסר, לתחזק קוד Tailwind CSS של מישהו אחר (בהנחה שאנחנו מכירים טיילווינד) זה הרבה יותר קל מלתחזק קוד CSS של מישהו אחר. אני לא צריך להיכנס ולהבין איזה קלאסים הוא בחר ומה המבנה ב HTML שמתאים לקוד ה CSS הקיים; הכל פשוט מופיע מול העיניים.

רוצים לדעת עוד על טיילווינד והקלאסים שלו? הפוסט הזה הוא מקום טוב להתחיל בו: https://codingthesmartway.com/tailwind-css-for-absolute-beginners/

וכמובן התיעוד המעולה שלהם בקישור: https://tailwindcss.com/docs/installation

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

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

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

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