ToCode

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

However, I don't see an integration available for audio transcription in the current platform. This would significantly limit the tool's usefulness.

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

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

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

import { Atom, atom, PrimitiveAtom } from "jotai";

export const countersAtom = atom<Array<PrimitiveAtom<number>>>([]);
export const maxValueAtom = atom((get) =>
  get(countersAtom).reduce((acc, val) => (acc > get(val) ? acc : get(val)), 0)
);

export type CounterAtomType = typeof countersAtom extends Atom<Array<infer T>> ? T : never;

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

'use client';
import { useAtom, atom } from "jotai";
import { maxValueAtom, countersAtom } from "@/lib/counters";
import Counter from './counter';

export default function App() {
  const [counters, setCounters] = useAtom(countersAtom);
  const [maxValue, _] = useAtom(maxValueAtom);
  const createCounter = () => {
    setCounters((counters) => [...counters, atom(0)]);
  };

  return (
    <div className="App">
      <h1>Hello Jotai</h1>
      <p>Max value = {maxValue}</p>
      <button onClick={createCounter}>Create Counter</button>
      {counters.map((counter, idx) => (
        <Counter myAtom={counter} />
      ))}
    </div>
  );
}

וככה נתקעתי עם הפונקציה createCounter בתוך הקומפוננטה והגדרת האטום בקובץ נפרד. איך אני משתמש ב Jotai היום במבט שני כל מה שהיה צריך זה להזיז קצת פונקציות ממקום למקום כדי לשפר את הקוד. אני מזיז את הלוגיקה לתוך הקובץ בו האטומים הוגדרו ומקבל:

export const createCounterAtom = atom(null, 
  (_get, set, _update) => set(countersAtom, counters => [...counters, atom(0)]));

export const deleteCounterAtom = atom(null,
  (_get, set, toDelete: PrimitiveAtom<number>) => set(countersAtom, counters => counters.filter(c => c !== toDelete)))

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

'use client';
import { useAtomValue, useSetAtom } from "jotai";
import { maxValueAtom, countersAtom, createCounterAtom } from "@/lib/counters";
import Counter from './counter';

export default function App() {
  const counters = useAtomValue(countersAtom);
  const maxValue = useAtomValue(maxValueAtom);
  const createCounter = useSetAtom(createCounterAtom)

  return (
    <div className="App">
      <h1>Hello Jotai</h1>
      <p>Max value = {maxValue}</p>
      <button onClick={createCounter}>Create Counter</button>
      {counters.map((counter, idx) => (
        <Counter myAtom={counter} key={idx} />
      ))}
    </div>
  );
}

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

import {test} from 'node:test';
import assert from 'node:assert';
import { maxValueAtom, countersAtom, createCounterAtom } from "@/lib/counters";
import { createStore } from 'jotai'

test('demo test', () => {
  const store = createStore()
  store.set(createCounterAtom, null);
  store.set(createCounterAtom, null);
  store.set(createCounterAtom, null);

  const countersAtomValue = store.get(countersAtom);
  store.set(countersAtomValue[0], 4);
  store.set(countersAtomValue[1], 2);
  store.set(countersAtomValue[2], 1);

  const maxValue = store.get(maxValueAtom);
  assert(maxValue === 4);
})

ארבעה דברים שאהבתי בפליירייט (ואחד שאהבתי פחות) פליירייט היא ספריית כתיבת בדיקות מקצה לקצה לאפליקציות ווב שמתאימה לפייתון, TypeScript / JavaScript, ג'אווה ודוטנט. בזכות כמה פיתרונות ורעיונות ייחודיים ועוד כמה רעיונות טובים שהם אספו ממקומות אחרים העבודה עם פליירייט מרגישה נכונה מהרגע הראשון. הנה 4 דברים שאני מאוד אהבתי בספריה ואחד שפחות. נתחיל בטובים: 1. תיעוד - אני יודע זה כאילו לא חלק מהספריה אבל האמת שכשמתחילים לעבוד עם ספריה ומגלים עמודי תיעוד מושקעים שכוללים גם הסבר מפורט, גם וידאו כשצריך וגם מדריכים ו Best Practice אתה כבר מרגיש בידיים טובות. 2. כתיבת בדיקות באמצעות הקלטה - מתוך שורת הפקודה כתבתי npx playwright test --debug ונכנסתי למצב הדיבאג של הבדיקות, שם היה לי דפדפן שהראה את העמוד וכפתור "הקלטה" שפשוט מתרגם את הפעולות שלי לקוד בדיקה. נכון הוא לא ידע לכתוב את ה expect כי הוא לא ידע למה לצפות, אבל כל השאר עבד ממש בסדר. זו בדיקה לדוגמה שכתבתי לאתר טוקוד באמצעות המקליט שלהם:

test('sign up to receive daily posts', async ({page}) => {
    await page.goto('https://www.tocode.co.il/blog');
    await page.getByRole('textbox', { name: 'you@wherever.you.are' }).click();
    await page.getByRole('textbox', { name: 'you@wherever.you.are' }).fill('ynon@tocode.co.il');
    await page.getByRole('button', { name: 'שלחו לי למייל' }).click();
    await expect(page.getByText('נשלח אליך מייל עם קישור לאישור ההרשמה. יש לפתוח את המייל וללחוץ על הכפתור לאישור')).toBeVisible();
})

3. תמיכה מלאה בכל הדפדפנים וגדלי המסך - באמצעות הגדרה בקובץ קונפיגורציה הצלחתי מאוד מהר לבדוק על יותר או פחות דפדפנים וגם לבחור אמולטורים לגדלי מסך שונים באמצעות פיצ'ר Device Mode של הדפדפנים. הנה דוגמה לקונפיגורציה:

import { defineConfig, devices } from '@playwright/test'; // import devices

export default defineConfig({
  projects: [
    {
      name: 'chromium',
      use: {
        ...devices['Desktop Chrome'],
      },
    },
    {
      name: 'Mobile Safari',
      use: {
        ...devices['iPhone 13'],
      },
    },
  ],
});

4. העדפה לכתיב ה Role - למרות שבתור כותב בדיקה זה יכול לעייף, אבל ההעדפה של פליירייט לכיוון Locators שמשתמשים ב Aria Role עוזרת להדגיש את ה Role של כל דבר באתר ולראות מהר כשהגדרות ה Aria לא נכונות, וזה אפילו לפני שסיימנו לכתוב את הבדיקות. אגב יש להם גם תוסף לבדיקת בעיות נגישות והכל משולב בפנים שימו לב לדוגמה הזו:

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright'; // 1

test.describe('homepage', () => { // 2
  test('should not have any automatically detectable accessibility issues', async ({ page }) => {
    await page.goto('https://your-site.com/'); // 3

    const accessibilityScanResults = await new AxeBuilder({ page }).analyze(); // 4

    expect(accessibilityScanResults.violations).toEqual([]); // 5
  });
});

5. ומה פחות? אני מצאתי את כתיב ה expect מבלבל במיוחד כשחלק מהבדיקות סינכרוניות ואחרות אסינכרוניות לדוגמה שתי הבדיקות האלה אינן זהות:

await expect(page).toHaveURL('...');
await expect(page.url()).toBe('...');

בראשונה toHaveURL היא בדיקה אסינכרונית שמחכה עד שה URL ישתנה בעקבות לחיצה או הפניה, אבל הבדיקה השניה היא בדיקה מיידית כי page.url היא פונקציה סינכרונית ו toBe היא בדיקה סינכרונית. ה await בשורה השנייה לא עושה כלום כיוון שאין שם שום Promise. בפועל מבנה זה דורש להסתכל על הטיפוסים כל פעם שכותבים בדיקה כדי להבין אם פונקציית הבדיקה היא סינכרונית או אסינכרונית. סך הכל מאוד אהבתי את פליירייט ואם אתם צריכים ספריית בדיקות End To End לפרויקט אין ספק שמדובר בבחירה טובה ובטוחה.

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

<details >
<summary>Toggle me</summary>
  <div > 
    <p>Look there's no JavaScript involved ... yay</p> 
  </div> 
</details>

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

details:open > summary {
  background-color: pink;
}

:is(select, input):open {
  background-color: pink;
}

או ב open בתוך סוגריים מרובעים שכן עובד גם בספארי:

details summary {
  background: pink;
}

details {
  background: lightgreen;
}

details[open] summary {
  background: red;
}

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

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

כן ריאקט נהיה מסובך מדי ריאקט תמיד היה מסובך אבל סוג הסיבוך השתנה. פעם היה קשה להבין את הרעיון של ריאקט אבל ה API שלו היה יחסית קטן, בטח בהשוואה לאנגולר. מפתחי ריאקט שהכרתי לפני 8 שנים ידעו בעל פה מה עושה כל פקודה בספריה. היום הסיפור קצת יותר מסובך, ובשביל להוכיח את זה אני רק אזרוק פה רשימה של Hooks מהתיעוד. נסו לספור כמה אתם מכירים או בכמה השתמשתם: 1. useId 2. useDeferredValue 3. useDebugValue 4. useInsertionEffect 5. useImperativeHandle 6. useOptimistic 7. useSyncExternalStore 8. useActionState 9. useFormStatus הבעיה עם עומס ה Hooks היא שכל Hook נועד לפתור בעיה מאוד ספציפית. חלקם באמת פשוטים כמו useDebugValue אבל כל אחד מהרשימה הזאת מתאר "מעקף" או בעיה שאי אפשר לפתור עם הכלים הרגילים של ריאקט. בעולם מושלם כל ה-9 האלה וכנראה גם חלק מה Hooks היותר שגרתיים היו בנויים בתור ספריות חיצוניות עבור אותם מקרים שצריכים אותם.

מה עושים במקום URL Params באפליקציית צד לקוח עם Next.js הבאג הזה ב Next עורר דיון סוער: https://github.com/vercel/next.js/discussions/64660 בקצרה כשאני בונה אפליקציית צד-לקוח בלבד עם output: 'export' ב next.js אי אפשר להשתמש בנתיבים דינמיים, כלומר נתיב כזה לא יעבוד:

/blog/[slug]

ההסבר הוא שכשנקסט רואה כזה דבר הוא לא יודע איזה קובץ HTML לבנות, כי צריך לזכור שכל מנגנון הניתוב של נקסט באפליקציית צד לקוח בנוי על זה שהוא מריץ את קבצי הקומפוננטות לפי מערכת הקבצים ומייצר מערכת קבצי HTML מקבילה לקבצי ה JavaScript, כלומר מרנדר את כל קבצי ה page.tsx ושומר את התוצאות בתור HTML-ים. ואם נשים בצד את כל הפיתרונות המתוחכמים ואת כל התקוות שבקרוב החברים ב Vercel יפתרו את זה (הם הבטיחו פיתרון באזור מאי-יוני), אבל כבר בינתיים אפשר לבנות פיתרון מקביל ודי פשוט - במקום להשתמש ב Route Params נשתמש ב Search Params, כלומר הנתיב יהיה:

/blog/post?slug=hello-world

בקוד next קצת נודניק ובשביל לגשת ל Search Params אני צריך לעטוף את הקומפוננטה ב Suspense לכן מבחינת קוד ב page.tsx אני כותב:

'use client'
import ShowPost from './show-post';
import { Suspense } from 'react';

export default function BlogPost() {
  return (
    <div>
      <Suspense fallback={<p>Loading post</p>}>
        <ShowPost />
      </Suspense>
    </div>
  )
}

וב show-post.tsx יש לי:

'use client'
import Link from 'next/link';
import { getPost } from '@/lib/blog';
import { useSearchParams, notFound } from 'next/navigation';

export default function BlogPost() {
  const slug = useSearchParams().get('slug')!;    
  const post = getPost(slug);
  if (!post) {
    return <p>Not flund. slug = {slug}</p>
  }

  return (
    <div>
      <h1>{post.title}</h1>
      <p><Link href="/blog">Back to blog</Link></p>
      <p>{post.fulltext}</p>
    </div>
  )
}

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

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

טיפ פייתון: המרה לבוליאנים הקוד הזה עובד יפה בפייתון:

import re

if re.search('a', 'hello'):
    print("a found in hello")
else:
    print("a not found in hello")

אבל זה לא כל כך:

if 'hello'.find('a'):
    print("found a")
else:
    print("a not found")

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

>>> None.__bool__()
False
>>> (-1).__bool__()
True

מה עם דוגמת הביטוי הרגולארי?

>>> re.search('a', 'hallo')
<re.Match object; span=(1, 2), match='a'>
>>> re.search('a', 'hallo').__bool__()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 're.Match' object has no attribute '__bool__'. Did you mean: '__copy__'?
>>> re.search('a', 'hallo').__len__()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 're.Match' object has no attribute '__len__'. Did you mean: '__le__'?

לביטוי רגולארי אין __bool__ ואין __len__ לכן הוא מחזיר True. והנה ניסוי עם קלאסים שלי:

class Foo:
    def __bool__(self):
        return False

class Bar:
    pass

f = Foo()
if f:
    print("Foo 1")
else:
    print("Foo 2")

b = Bar()
if b:
    print("Bar 1")
else:
    print("Bar 2")

הפלט כצפוי Foo 2 ו Bar 1.

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