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

בדוגמת ההתחלה מהירה של Redux Tolkit הם יוצרים וימייצאים את מחסן המידע באותה שורה באופן הבא:

import { configureStore } from '@reduxjs/toolkit'
import counterReducer from '../features/counter/counterSlice'

export const store = configureStore({
  reducer: {
    counter: counterReducer,
  },
})

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

export function createStore(initialState) {
  return configureStore(Object.assign({}, {
    reducer: {
      counter: counterReducer,
    },
  },
  initialState ? { preloadedState: initialState } : {}));
}

וככה אני יכול להשתמש בפונקציה כדי לבדוק את ה store בכל state ראשוני שארצה:

test('inc from 10 to 11', () => {
  const store = createStore({ counter: { value: 10 }});
  store.dispatch(increment());
  expect(store.getState().counter).toEqual({ value: 11 });
});

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

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

תוכנות כמו virtualbox או vmware הופכות את ההתקנה של מכונת לינוקס וירטואלית למאוד פשוטה, ובזכותן אפשר להתנסות עם הפצות חדשות ולהינות מהסביבה הגרפית השונה ומהאווירה השונה של כל הפצה. אבל לפעמים אנחנו רק רוצים להריץ משהו במסוף או לבדוק משהו יותר קטן, או לחלופין להריץ מספר מכונות בלי GUI שיתקשרו ביניהן ברשת. למצבים האלה תוכנות הוירטואליזציה עשויות להיות "יותר מדי". תוכנת Multipass מציעה פיתרון הרבה יותר מדויק ואלגנטי למי שרוצה להרים מכונות אובונטו וירטואליות, נטולות ממשק גרפי, על המכונה המקומית.

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

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

mkdir foo
touch foo/bar
cp /etc/passwd foo

אז אני יכול אחרי זה לכתוב:

fc -l mkdir cp

ולקבל את רשימת כל הפקודות מ mkdir עד cp כולל:

544      mkdir foo
545      touch foo/bar
546      cp /etc/passwd foo

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

mkdir bar
touch bar/bar
cp /etc/passwd bar

שומר ויוצא וכך יצרתי את תיקיית bar בדיוק כמו שיצרתי קודם את תיקיית foo.

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

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

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

ואותו הבדל תוקף אותנו גם כשאנחנו באים לשדרג את הקריירה או הקוד שלנו:

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

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

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

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

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

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

ריילווי היא אחת מחברות הענן החדשות האלה והנה כמה דברים שנראה לי שתאהבו בה:

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

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

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

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

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

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

הטריגר ב Github Action יראה כך:

on:
  push:
    tags:
      - 'deploy-*'

ואז אפשר ליצור את התג עם תוספת של timestamp ולדחוף אותו לשרת עם הפקודות:

$ git tag deploy-$(date +%s)
$ git push --tags