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

לטייפסקריפט יש פיצ'ר ממש חמוד לעבודה עם קבצי JSON שנקרא resolveJsonModule. אנחנו מגדירים ב tsconfig.json את האופציה באופן הבא:

{
  "compilerOptions": {
    "resolveJsonModule": true,
    "esModuleInterop": true
  },
  "include": ["src"]
}

ואז כותבים:

import settings from './settings.json';

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

[{
  "repo": "TypeScript",
  "dry": false,
  "debug": false
}]

ואני אנסה לכתוב בקוד:

import settings from './settings.json';
console.log(settings[0].foo);

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

בעבודה עם קבצי JSON גדולים שווה להכיר את האופציה allowArbitraryExtensions של טייפסקריפט, אופציה שבעזרתה נוכל להגדיר את הטיפוס של ה JSON ידנית, נחסוך לטייפסקריפט עבודה וכך נקבל VS Code מהיר יותר והגדרות טיפוסים אמינות. ה tsconfig.json נראה ככה:

{
  "compilerOptions": {
    "allowArbitraryExtensions": true,
    "resolveJsonModule": true,
    "esModuleInterop": true
  },
  "include": ["src"]
}

ובתיקיית src אנחנו יוצרים קובץ בשם של ה json אבל עם d באמצע וסיומת ts, לדוגמה אם ל json שלי קוראים deposits.json אז אני יוצר קובץ בשם deposits.d.json.ts. בקובץ הגדרת הטיפוס אני כותב:

export interface SavingsData {
  INTERESTSDATE: string;
  SAVINGSPROGRAMBYAGE: string;
  AGE: string;
  BANK: string;
  SAVINGSPLAN: string;
  SAVINGSPERIOD: string;
  FIXEDWITHOUTLINKAGEVAL: number;
  FIXEDLINKEDCONSUMERPRICEINDVAL: number;
  VARIABLESPREAD: number;
}

declare const array: Array<SavingsData>;
export default array;

ומפה אנחנו מסודרים. אפשר לייבא את הקובץ deposits.json אפילו שהוא שוקל 10 מגה וטייפסקריפט ישתמש בהגדרת הטיפוס שבנינו במקום לקרוא את הקובץ ולנסות להבין את הטיפוס לבד.

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

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

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

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

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

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

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

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

האמת שלא מעט דברים:

1. אין לי זמן להשקיע בפרויקט עכשיו.

2. אין לי רעיון טוב.

3. יש לי יותר מדי רעיונות.

4. אין לי מושג איך מתחילים.

5. חבל על הזמן, ממילא לא יצא מזה כלום.

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

בתחילת מרץ אני מתכוון לפתוח קבוצת מנטורינג לעבודה על פרויקט Full Stack במשך ארבעה שבועות ובאמצעות שילוב כלי AI עם כל הסטאק הטכנולוגי שאנחנו כבר מכירים. העבודה בקבוצה תתן לכם את המקום והכלים ליצור פרויקט מאפס ועד פרודקשן, ואתם לא לבד: אנחנו נקיים מפגשים קבוצתיים בזום בהם נלמד אחד מהשני ונציג את העבודה שעשינו, נחזיק קבוצת דיונים בווטסאפ ותקבלו פגישות אחד על אחד איתי לייעוץ טכנולוגי ו Code Review ספציפי על הפרויקט. העבודה במסגרת קבוצתית ועם מטרה ברורה של בניית פרויקט תתן גם לכם את המוטיבציה להתאמץ יותר ולהגיע לקו הסיום עם פרויקט בפרודקשן.

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

https://www.tocode.co.il/contacts/new

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

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

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

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

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

2. אוביקט המידע הזה הופך ל Store של רידאקס ונשלח לצד הלקוח.

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

קוד ה Server Side Rendering יכול לעבוד עם אוביקט המידע שהשרת הכין וקוד צד לקוח יכול לעשות dispatch ל Actions לתוך אוביקט המידע הזה.

הריפו של הדוגמה זמין כאן:

https://github.com/ynonp/next-pages-redux

בואו נראה איך זה עובד.

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

ב Vue אנחנו יוצרים משתנה סטייט עם הפקודה ref ומקבלים משהו שאפשר לכתוב אליו וגם לקרוא ממנו לדוגמה הקוד הבא מציג מונה לחיצות עם משתנה סטייט ששומר את מספר הלחיצות:

<script setup>
import { ref } from 'vue'

const counter = ref(0)
function inc() { counter.value++ }
</script>

<template>
  <p>{{counter}}</p>
  <button @click="inc">+1</button>
</template>

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

בדוגמת ההתחלה המהירה של Redux Toolkit הם מציעים את הקוד הבא עבור סלייס של מונה:

import { createSlice } from '@reduxjs/toolkit'

const initialState = {
  value: 0,
}

export const counterSlice = createSlice({
  name: 'counter',
  initialState,
  reducers: {
    increment: (state) => {
      state.value += 1
    },
    decrement: (state) => {
      state.value -= 1
    },
    incrementByAmount: (state, action) => {
      state.value += action.payload
    },
  },
})

// Action creators are generated for each case reducer function
export const { increment, decrement, incrementByAmount } = counterSlice.actions

export default counterSlice.reducer

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

export interface CounterSliceState {
  value: number
  status: "idle" | "loading" | "failed"
  foo: string
  bar: number
  buz: Array<string>
}

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

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

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

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

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