ToCode

זמן לקבור את זה מה עושה ראשת הצוות שמגלה שאין תשתית בחברה לבדיקות אוטומטיות למערכת? מה עושה המפתחת שמבינה שבלי אתר תיעוד אף אחד לא יבין את הפריימוורק שהיא בונה? התרבות בתעשייה שלנו מעודדת יזמות כולל יזמות פנימית. אנחנו מעדיפים לפתור בעיות עם הכלים שעומדים לרשותנו, ואם אין פיתרון טוב מכניסים כלים חדשים. מפתחת שתביא פריימוורק עם תיעוד ובדיקות תקבל יותר קרדיט על העבודה שלה, אפילו אם זה היה מעבר לדרישות. ראש הצוות שיצליח להוריד את כמות הבאגים באמצעות שילוב מערכת בדיקות אוטומטיות יזכה בתהילה ובצדק. האתגר הוא מה שקוראים בטעות Job Security - הצורך של אותם אנשים להמשיך לתחזק את המוצרים שהם הכניסו אפילו אחרי שהם ממשיכים לתפקידים חדשים בחברה ולפעמים גם בתור פרילאנסרים אחרי שעוזבים את החברה. המשך תחזוקת מוצרים ישנים זה לא באינטרס של אף אחד. החברה מפסידה כי היא תלויה במפתח בודד, המפתח מפסיד כי הוא לא מצליח להתפנות 100% לפרויקטים חדשים, והפרויקט מפסיד כי יגיע יום שכל הקוד הזה יגיע לפח ונצטרך לכתוב מערכת חדשה. מוצרים פנימיים, כמו מוצרים חיצוניים, יכולים "לתפוס" או לא. יוניקס החלה את דרכה כמוצר פנימי, אבל ברגע שכולם בחברה השתמשו בה היה ברור שאין דרך חזרה. תשתית בדיקות פנימית שמישהו בנה בשביל הצוות שלו יכולה בקלות להפוך למוצר ליבה של החברה ולקבל צוות שאחראי להרחיב ולפתח אותה. ובאותה מידה מוצרים פנימיים, כמו מוצרים חיצוניים, יכולים להישאר בשימוש של מספר קטן של מפתחים ולהמשיך להיות מתוחזקים על ידי אותו מפתח אומלל שכתב אותם לפני שנים. כשזה קורה וכח האינרציה הוא הדבר היחיד שמשאיר אותם בחיים שווה לתכנן מועד סיום חיים לאותם מוצרים. האתגר מבחינת החברה הוא שלכאורה אנחנו רק מרוויחים - יש לנו מוצר עם אפס עלות תחזוקה כי אלברט מהפיתוח מתחזק אותו בנוסף לעבודה הרגילה שלו ולא מתלונן. בטווח הרחוק מועד התשלום יגיע ובריבית, כשאלברט מהפיתוח יחליט לעזוב ונמצא את עצמנו מחפשים מפתח TypeScript שגם יודע awk בשביל להחליף אותו.

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

כמה מחשבות על סטאק אוברפלו ו AI למה Stack Overflow לא רוצים ש Chat GPT יענה על שאלות? ומה זה אומר על שאר הדברים שאנחנו רוצים או לא רוצים לעשות עם AI? נתחיל עם המקרים הקלים - אם אני צריך להוסיף ניתוב לפרוקסי חדש על שרת ה Apache שלי ברור שאני יכול להשתמש ב AI כדי לייצר את קובץ ההגדרות. גם בשביל ליצור מניפסט לקוברנטיס, להמיר קובץ JSON ל YAML וליצור נתונים אקראיים לבדיקות. כל המקרים האלה נראים הגיוניים כי אלה דברים שיכולתי בקלות למצוא בתיעוד ברשת, אפשר להגיד שה AI לא חסך לי פה המון עבודה. אבל זאת רק ההתחלה. מה לגבי הקוד האמיתי? עדיין נראה לי הגיוני לבקש מ AI לכתוב לי שאילתת SQL, גם אם היא מסובכת, לבנות בשבילי בלוק CSS גם אם הוא משתמש ביכולות CSS שאני לא ממש מכיר ואפילו לעצב ולצייר קוד לקומפוננטת ריאקט כולל הפונקציונאליות שלה. בכל המקרים האלה אני כבר לא חושב על התוצאה שה AI מייצר בתור משהו שהייתי יכול למצוא ברשת, אלא אני חושב על ה AI בתור מישהו שעובד בשבילי. מעין עוזר וירטואלי שנכנס לקוד ועוזר לי למצוא תקלות ולהוסיף פיצ'רים קטנים. אפשר לדמיין שבגלל שאני משלם סכום חודשי ל Open AI אז אני יכול להשתמש בקוד של אותו עוזר וירטואלי באותו אופן שהייתי יכול להעסיק מתכנת אמיתי ולהשתמש בקוד שהוא כותב (רק הרבה יותר זול). מסיבות אלה אנחנו גם מרגישים בנוח לתת ל AI לבנות עבורנו דפי נחיתה, לעזור בניסוח מיילים, להעלות רעיונות חדשים (שיום אחד גם נציג אותם בפגישה בתור רעיונות שלנו), לייצר גרפיקה או מוזיקה ועוד עבודות קריאייטיב שיהיו זמינות לנו בלי זכויות יוצרים. אז מה לגבי Stack Overflow? ופוסטים לבלוג? או ציוצים באיזה רשת חברתית? או אפילו ברכת יום הולדת לקרוב משפחה? עכשיו זה נראה ברור - המשחק הוא לא כמה ה AI נותן תוצאה טובה, אלא כמה חשוב לנו תוכן אותנטי באותם מצבים. כשאנחנו מחפשים תשובה של בן אדם ומגיעים לטקסט של AI זה פוגע באמון שלנו באותו מדיום. אם מישהו פעם אחת ישלח לי ברכה שכתב AI אני לא אקרא יותר את הברכות שאותו חבר ישלח בעתיד. אם אגלה שבלוגר פעם אחת פירסם פוסט שכתב עבורו AI אני לא אטרח לקרוא את הפוסטים של אותו בלוגר בעתיד. מעבר לשאלת הדיוק, הבחירה של סטאק אוברפלו ואתרים רבים נוספים היא בחירת כיוון, איזה סוג אתר אנחנו רוצים להיות ואיזה סוג משתמשים אנחנו רוצים שיגיעו. לאורך זמן אני לא אתפלא אם התשובות של Chat GPT יהיו טובות יותר מהתשובות שנמצא בסטאק אוברפלו, כשם שההסברים שלו יכולים להיות טובים יותר מפוסטים בבלוגים או ציוצים ברשתות חברתיות. אבל דווקא ככל שההסברים של ה AI ימשיכו להשתפר זה רק ידגיש את המקום של תוכן מקורי, יצירתי ואישי שבני אדם כותבים.

ערך ריק בממשק אחד הדברים שתמיד מבלבלים אותי הוא המשמעות של ערכים ריקים בתוך ממשקים. כמה דוגמאות מהתקופה האחרונה: 1. ב Rails אפשר להגדיר ב config.hosts רשימה של דומיינים מורשים. מערך ריק אומר שכל הדומיינים מורשים, ולכן אם אני "רק" מוסיף ערך למערך בעצם אני מפעיל בדיקת אבטחה חדשה. 2. ב Gremlin הפקודה g.V(id) מחזירה צומת מהגרף לפי id. אפשר להעביר מספר מזהים כדי לקבל מספר צמתים למשל g.V(2, 3, 5) יחזיר את הצמתים 2, 3 ו-5. העברה של ערך ריק (בלי כלום בתוך הסוגריים) מחזירה את כל הצמתים בגרף. 3. הפקודה cat ביוניקס לוקחת שם קובץ ומציגה אותו על המסך. אם נעביר לה מספר קבצים היא תדפיס את כולם, אבל אם לא נעביר אף שם היא תדפיס את התוכן של STDIN שלה, כלומר תכנס למצב של קליטת שורות ותחזור על כל שורה שאנחנו כותבים עד שנלחץ Ctrl+D לסיים את הקלט. יצירת התנהגות שונה לפונקציה עבור ערך ריק יכולה להיות טריק חמוד ליודעי דבר וגם לקצר קצת את הקוד ולכן הרבה פעמים זה קיצור שמפתה להכניס. בפועל הקיצורים האלה הרבה פעמים מבלבלים משתמשים חדשים ורק הופכים את הממשק שלכם לפחות ידידותי.

הונו משתלב עם מנגנון הבדיקות האוטומטיות של דינו בצורה מובנית. ניצור תיקייה בשם tests ובתוכה קובץ בשם tests/demo1_test.ts עם התוכן הבא:

import { expect } from "jsr:@std/expect";
import demo1 from '../routes/demo1.ts';

// basic test
Deno.test("simple test", async () => {
  const res = await demo1.request('/text')
  expect(res.status).toBe(200)
  expect(await res.text()).toBe('Hello Hono!')
});

אפשר להפעיל את הבדיקה עם:

$ deno test

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

deployctl deploy

משורת הפקודה ולעקוב אחר ההוראות. הפרויקט שלי זמין כבר בקישור: https://ynonp-hono-demo.deno.dev/demo1/api/hello ואתם מוזמנים לעבור על הקוד המלא בגיטהאב בקישור: https://github.com/ynonp/hono-demo סך הכל העבודה עם הונו היתה כל מה ש Express היה פעם - כיף, עובד בלי כאב ראש ועושה כל מה שצריך.

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

deno run -A npm:create-hono@latest my-app

אני בוחר את דינו בתור סביבת הריצה וזה הכל. עכשיו אפשר להפעיל VS Code בתיקייה ולהתחיל לעבוד. הדבר הראשון שאני רוצה לשנות בהגדרות הפרויקט יהיה בקובץ deno.json וזה להוסיף לתבנית משימה של פיתוח שתעבוד במצב watch. אני מעדכן את הקובץ ואחרי השינוי הוא נראה כך:

{
  "imports": {
    "hono": "jsr:@hono/hono@^4.5.10"
  },
  "tasks": {
    "start": "deno run --allow-net main.ts",
    "dev": "deno run --allow-net --watch main.ts"
  },
  "compilerOptions": {
    "jsx": "precompile",
    "jsxImportSource": "hono/jsx"
  },
  "deploy": {
    "project": "b737e735-3715-4077-a44b-782fc7424cb5",
    "exclude": [
      "**/node_modules"
    ],
    "include": [],
    "entrypoint": "main.ts"
  }
}

השורה היחידה שהוספתי היא הערך dev בתוך האוביקט tasks. משורת הפקודה אני מפעיל:

deno task dev

ויש לי שרת שמקשיב על פורט 8000 ואני יכול להתחיל לעבוד, הקוד כתוב בטייפסקריפט וכל שינוי קוד אוטומטית מרענן את השרת. דוגמה 1 - החזרת מידע אני יוצר תיקיה חדשה בשם routes ובתוכה קובץ בשם demo1.ts עם התוכן הבא:

import { Hono } from "hono";

const router = new Hono();
let counter = 0;

router.get('/text', (c) => {
  return c.text('Hello Hono!')
})

router.get('/api/hello', (c) => {
  return c.json({
    ok: true,
    message: 'Hello Hono!',
  })
})

router.get('/api/counter', (c) => {
  return c.json({
    value: counter++,
  })
})

export default router;

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

import { Hono } from 'hono'
import demo1 from './routes/demo1.ts';

const app = new Hono()
app.route('demo1', demo1);

Deno.serve(app.fetch)

עכשיו בדפדפן אני גולש ל localhost:8000/demo1/text כדי לראות את הטקסט, ל localhost:8000/demo1/api/hello כדי לראות את האוביקט הראשון ול localhost:8000/demo1/api/counter כדי לראות את האוביקט השני. דוגמה 2 - גישה לפרמטרים של הבקשה בואו נפתח קובץ נוסף בשם routes/demo2.ts והפעם עם התוכן הבא:

import { Hono } from "hono";

const router = new Hono();

router.get('hello', (c) => {
  const name = c.req.query('name') ?? 'Guest';
  return c.text(\Hello! ${name}\);
});

router.post('item', async (c) => {
  const props = await c.req.json();
  console.log(props);
  return c.json(props);
})

export default router;

הקובץ מגדיר שני נתיבים - נתיב אחד לוקח את הפרמטר name מה Query String ומחזיר טקסט שכולל את הערך של הפרמטר או שם ברירת מחדל. הנתיב השני לוקח את גוף הבקשה בתור אוביקט JSON ומחזיר אותו. בשביל לחבר אותם לאפליקציה צריך רק להוסיף את השורה:

app.route('demo2', demo2);

לקובץ main.ts, וכן אפילו לא צריך לסגור ולפתוח את התוכנית הכל פשוט מתרענן ומראה את הנתיבים המעודכנים. דוגמה 3 - שליחת HTML הקובץ השלישי שלנו נקרא routes/demo3.tsx, וכן הסיומת היא tsx ולא ts הפעם. זה התוכן שלו:

import { Hono } from "hono";

const router = new Hono();

const View = ({name = "Guest"}) => {
  return (
    <html>
      <body>
        <h1>Hello! {name}</h1>
      </body>
    </html>
  )
}

router.get('/', (c) => {
  return c.html(<View name="ynon" />)
})

export default router;

אתם לא טועים - זה נראה כמו JSX וזה אכן זה. ל Hono יש דרך מובנית ופשוטה לכתוב HTML באמצעות jsx. יש שם עוד כל מיני קיצורים גם ל CSS ואפילו ספריית JavaScriptשהולכת עם זה ומאפשרת להוסיף תמיכה ב Hooks כמו useEffect, אבל זה כבר סיפור לפוסט אחר. בדיקות אוטומטיות

אין או יש מקום בדיסק? הפלט של שתי הפקודות האלה על השרת הפתיע אותי -

ynon@schooler-prod-2:~$ touch a
touch: cannot touch 'a': No space left on device

ynon@schooler-prod-2:~$ df -h
Filesystem                                               Size  Used Avail Use% Mounted on
udev                                                     7.9G     0  7.9G   0% /dev
tmpfs                                                    1.6G  8.5M  1.6G   1% /run
/dev/sda                                                 315G  103G  197G  35% /
tmpfs

איך יכול להיות ש touch לא יכול ליצור קובץ חדש ומתלונן שאין מספיק מקום על הדיסק, כש df מראה שיש דווקא המון מקום? האם df משקר? האם יש corruption במערכת הקבצים? מה קורה פה? ייתכן. אבל לפני שרצים להפעיל fsck שווה לנסות גם את df -i. מערכות קבצים בלינוקס צריכות לשמור בנוסף לקבצים עצמם גם אינדקס שמקשר בין שם הקובץ לתוכן שלו על הדיסק. האינדקס הזה גם תופס מקום והמבנה שלו יוצר מגבלה על מספר הקבצים שאפשר לשמור בתיקייה. הפקודה df -i מציגה כמה קבצים אפשר לשמור על כל כונן וכמה יש לכם, בלי קשר לגודל שלהם. כשיש מקום על הדיסק אבל אין מספיק inodes פנויים, הפקודה touch (ויצירת קבצים באופן כללי) יציגו את אותה הודעת שגיאה מבלבלת No space left on device, למרות שהם היו צריכים להגיד Not enough free inodes on device.

למידע נוסף על הספריה ועוד אינסוף דוגמאות שווה לבקר באתר שלהם בקישור: https://observablehq.com/plot/

הכירו את Observable Plot - הגירסה הקלה של D3 אני אוהב את D3 כי אפשר לעשות איתו הכל ויש אינסוף דוגמאות ברשת, אבל אי אפשר להכחיש ש D3 קצת מסובך וכולל שפה ומושגים שלא לכולם יש כח להכיר. אם אתם רק צריכים להוסיף איזה גרף למסכי הניהול שלכם בלי יותר מדי אינטרקציה ספריית Observable Plot יכולה לתת פיתרון מהיר. השימוש העיקרי שלה אגב הוא בתוך מחברות ג'ופיטר כשצד השרת הוא deno. דוגמה 1 - ציור הפונקציה x בריבוע בדוגמה הראשונה נראה גרף פשוט של הפונקציה x בריבוע. את observable plot אפשר לטעון דרך jsdeliver ישירות לדפדפן עם הפקודה:

import * as Plot from "https://cdn.jsdelivr.net/npm/@observablehq/plot@0.6/+esm";

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

const data = Array.from({length: 100}, (_, i) => {
  let x = i - 50;
  return {x, y: x * x};
});

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

const plot = Plot.plot({
  marks: [
    Plot.line(data, {x: "x", y: "y", stroke: "blue"})
  ],
  x: {label: "x"},
  y: {label: "f = x²"},
})

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

const wordFrequency = [
  {word: "quick", count: 4},
  {word: "brown", count: 2},
  {word: "fox", count: 2},
  {word: "jumps", count: 1},
  {word: "over", count: 1},
  {word: "the", count: 5},
  {word: "lazy", count: 3},
  {word: "dog", count: 2},
  {word: "is", count: 3},
  {word: "very", count: 2},
  {word: "and", count: 1},
  {word: "agile", count: 1},
  {word: "not", count: 1},
  {word: "as", count: 1},
  {word: "but", count: 1},
  {word: "certainly", count: 1}
];

וכן אין בעיה לקחת מחרוזת ולייצר את המידע הזה דינמית, פשוט רציתי להראות כאן את המידע כמו שהוא עובר ל Observable Plot. בחלק השני אני יוצר את ה SVG:

const plot = Plot.plot({
  marks: [
    Plot.barY(wordFrequency, {x: "word", y: "count", sort: {x: "y", reverse: true}})
  ],
  x: {
    label: "Word",
    tickRotate: -45
  },
  y: {
    label: "Frequency",
    tickFormat: d => d, // Ensure only integer ticks are shown
    ticks: Math.max(...wordFrequency.map(d => d.count)) + 1 // Set the number of ticks to match the highest count
  },
  height: 400,
  width: 600
});

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

Plot.barY(wordFrequency, {x: "word", y: "count", sort: {x: "y", reverse: true}})

התוצאה שוב בקודפן: https://codepen.io/ynonp/pen/gONdwZK?editors=1010 או מוטמעת: <iframe height="300" style="width: 100%;" scrolling="no" title="Untitled" src="https://codepen.io/ynonp/embed/gONdwZK?default-tab=html%2Cresult" frameborder="no" loading="lazy" allowtransparency="true" allowfullscreen="true"> See the Pen <a href="https://codepen.io/ynonp/pen/gONdwZK"> Untitled</a> by Ynon Perek (<a href="https://codepen.io/ynonp">@ynonp</a>) on <a href="https://codepen.io">CodePen</a>. </iframe>

רק שתי לחיצות הבעיה הכי קשה בבניית מערכת היא ההבנה שמשתמשים לא חיים בעולם שלך ואת הבעיות שלהם אתה עדיין לא יכול לדמיין. לכן הטמעת מערכת טלמטריה ביישום היא תמיד רעיון טוב (או לפחות כל עוד יש זמן להסתכל מה באמת קורה למשתמשים ולהקשיב לבעיות שלהם). את הפוסט היום בנושא אני שמח להקדיש למערכת מספרי החשבוניות החדשה של מס הכנסה. המנגנון אמור להיות סופר פשוט - פעם בשלושה חודשים צריך ללחוץ על כפתור כדי להוכיח שאתה עדיין בחיים, וזה מחבר את מערכת החשבוניות שלך למס הכנסה וכך באופן אוטומטי מערכת החשבוניות מודיעה למס הכנסה כשהוצאת חשבונית, במקום ב 15 לחודש כשתגיש את החשבונית. המנגנון הזה מאפשר לחברים במס הכנסה לתאם בין החשבוניות שאנשים מוציאים לחשבוניות שאנשים מקבלים, וכך הם יכולים לזהות מהר יותר רמאויות (למשל כשמישהו מקבל חשבונית אבל מוציא החשבונית לא דיווח עליה). לדעתי היה להם יותר קל לייצר שיתוף פעולה עם החברות שכבר קיימות לחשבוניות דיגיטליות, אבל אני בטוח שישבו שם אנשים חכמים שבנו את המנגנון וראו דברים שאני לא רואה. מה שהם בטוח לא ראו זה שצרכי אבטחת המידע שלהם לא מסתדרים עם נסיעות לחו"ל משתי סיבות: 1. לא ניתן ללחוץ על כפתור החיבור מרשת אינטרנט בחו"ל. 2. אפילו אחרי שמצליחים להתגבר על 1 באמצעות VPN, כפתור החיבור דורש הקלדה של קוד שנשלח דרך סמס, אבל הסמס לא מגיע לחו"ל. וכך בגלל תזמון גרוע וחוסר תשומת לב שלי לפני הנסיעה לא יכלתי להוציא חשבוניות בשלושה שבועות האחרונים. לקחים- 1. בתור משתמשים, כשמדובר באתרי ממשלה עדיף לא לבלבל את המערכת וללחוץ על כל הכפתורים שלהם מראש. 2. בתור משתמשים, אם יש אופציה עדיף להשתמש באפליקציית אימות כדי להזדהות בהזדהות כפולה (2FA). אם אין אופציה לפחות ננסה להכניס מספר טלפון נוסף. באתר רשות המסים אפשר להיכנס למסך "הפרטים שלי" ושם לבחור "עריכת פרטי התקשרות" ולבחור "אימייל" בתור אמצעי התקשרות מועדף. בצורה כזאת אתם לא תלויים בהעברת סמסים בשביל להיכנס. 3. בתור בוני מערכות, שימו לב שאם המערכת שלכם כבר מאפשרת ללקוחות להזדהות במספר דרכים וודאו שבמסך הכניסה משתמשים יוכלו לבחור את דרך ההתקשרות שמתאימה להם באותו רגע. בנוסף אם צרכי אבטחת המידע שלכם דורשים שאנשים ישתמשו במערכת רק ממדינה מסוימת או לא מאפשרים למשתמשים לגשת למערכת ממדינות מסוימות כדאי לכתוב את זה בצורה ברורה. 4. בתור מנהלי פרויקט או מעצבי מערכת, שימו לב שלפעמים אתם מתכננים Flow מסוים אבל לאורך הזמן דברים משתנים כי אנשי אבטחת מידע באים עם הדרישות שלהם ומתכנתים לא מצליחים ליישם הכל ועוד אילוצים אחרים. אל תשכחו לוודא שה Flow שנוצר בסוף הדרך מספיק טוב בשביל המוצר שלכם, ותקנו את הבעיות כשאתם מזהים אותן - כולל דרך האזנה למערכות הטלמטריה של היישום.

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