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

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

חבר שואל - יש לי פרויקט flask שמשתמש ב Psycopg ואני צריך לשכתב את רוב הקוד שעובד עם בסיס הנתונים. שווה לי ללמוד SQLAlchemy בשביל זה?

קל לראות למה לא:

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

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

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

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

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

1. האם את ספריית תצוגה לצד לקוח, שנועדה לעזור לצוותים גדולים לתחזק אתרים עם יותר מדי קוד JavaScript?

2. האם את ספריית Full Stack שנועדה לעזור למפתחים להעלות מהר יותר פרויקטים לאוויר?

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

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

5. האם את ספריית צד לקוח שאני יכול להכניס לכל פרויקט או ספריית Full Stack שדורשת קוד מיוחד בצד השרת על מנת לעבוד בצורה מיטבית?

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

Whether you work on your own or with thousands of other developers, using React feels the same. It is designed to let you seamlessly combine components written by independent people, teams, and organizations.

ואני רוצה לקחת אותם ברצינות, אבל יודע שפרויקטי ריאקט שאני ראיתי לא "הרגישו אותו דבר". פרויקט צד-לקוח שמשתמש ב Redux ומחזיק את הלוגיקה והפעולות מחוץ לריאקט, ירגיש מאוד שונה מפרויקט שמעביר את כל עומס העבודה לקומפוננטות וישתמש ב react-query כדי למשוך מידע מהשרת ולשמור אותו בקונטקסט, ושני אלה ירגישו שונה מפרויקט שמשתמש ב Zustand, Valtio או Jotai. פרויקט שמשתמש ב Shadcn ו Tailwind ירגיש מאוד שונה מפרויקט שמשתמש ב Styled Components. ועוד לא דיברנו על next לעומת remix לעומת redwood לעומת tanstack start.

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

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

API_KEY=abcdefg

ואחרי זה לקרוא את משתני הסביבה באמצעות:

console.log(process.env.API_KEY);

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

API_KEY=abcd$e$fgh#abc123

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

API_KEY="abcd$e$fgh#abc123"

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

API_KEY="abcd\$e\$fgh#abc123"

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

source .env

עובד עם מרכאות ו Backslash כמו שכתבתי, אבל לא עובד אם במקום מרכאות יהיה גרש בודד.

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

שני דברים קרו בשנים האחרונות ששינו את התמונה: בצד של ריאקט שינויים בפריימוורק קודם כל ביוזמת דן אברמוב ולאחר מכן בהובלת Vercel הפכו את ריאקט לפריימוורק הרבה יותר מסובך ממה שהיה כשאני התחלתי לעבוד איתו. לא כולם זוכרים אבל היו חיים לפני רידאקס, וכשרידאקס נכנס דברים באמת הפכו ליותר מסובכים. דן אברמוב הוביל את המעבר ל Hooks שנראה כמו שיפור מכתיב הקלאסים אבל יצר הרבה אי הבנות בעיקר סביב useEffect וכל נושא ה Memoization של useMemo ו useCallback. ואז הגיעו ורסל עם next.js והפכו את ריאקט לפריימוורק Full Stack. וכן זה נחמד אם אתם צריכים לכתוב אפליקציית Full Stack ב next.js, אבל כל מי שרוצה ספריה פשוטה לפיתוח ממשק משתמש קצת נשאר מאחור.

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

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

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

קורס Vue.JS

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

בטווח הרחוק יש דברים אחרים שמפריעים לי בקוד:

1. קומפוננטה של מעל 100 שורות.

2. לוגיקה בתוך JSX.

3. קומפוננטה שמקבלת יותר מ-4 פרופס.

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

5. לוגיקה (פונקציות) בתוך קומפוננטה, במקום ב Custom Hook או קובץ נפרד.

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

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

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

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

ואולי כל מה שאנחנו יודעים על קוד הולך להשתנות ונוכל להמשיך הלאה לכתוב בלי להכיר את הפרטים? אולי נוכל לכתוב רק עם "הבנה"?

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

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

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

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

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

הקוד הבא ב Vue מראה על המסך את הטקסט Hello Vue:

<template>
    <template v-if="true">
        <p>Hello Vue</p>
    </template>
</template>

אבל זה כבר לא מראה כלום:

<template>
    <template>
        <p>Hello Vue</p>
    </template>
</template>

בואו נראה למה.