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

הם לא הולכים ביחד, והבעיה שהאיפור רק מחמיר את המצב. נפלתי במקרה על הדף הזה היום: https://docs.npmjs.com/docker-and-private-modules

זה מתוך התיעוד של npm. הדף מסביר איך ליצור קובץ .npmrc בתור Docker Image, למשל בשביל למשוך אימג' ממאגר פרטי. הם ממליצים להשתמש ב Dockerfile הבא:

FROM risingstack/alpine:3.3-v4.3.1-3.0.1
ARG NPM_TOKEN
COPY .npmrc .npmrc
COPY package.json package.json
RUN npm install
RUN rm -f .npmrc
# Add your source files
COPY . .
CMD npm start

ובתבנית הבאה עבור npmrc:

//registry.npmjs.org/:_authToken=${NPM_TOKEN}

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

בשביל המשחק לקחתי את ה Dockerfile שלהם ובניתי ממנו אימג' וגם פירסמתי אותה ב Dockerhub. תראו אם תצליחו לגלות מה הערך של NPM_TOKEN בדוגמה שלי: https://hub.docker.com/layers/ynonp/dtest/latest/images/sha256-7eb4139557b15d6dd86cd5d9511863aaa03cb4271f3f799d701d5c80aa357575?context=explore&tab=layers.

ש: איך אני מריץ שאילתת SQL מתוך הדפדפן?

ת: אתה לא

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

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

ספריית Vue היא ספריית JavaScript לפיתוח מבוסס קומפוננטות. היא נחשבת לאחת מספריות הפיתוח הפופולריות היום יחד עם React ו Angular. מה שמייחד את Vue הוא המאמץ של כותביה לבנות ממשק שיהיה מאוד ידידותי לאנשים חדשים ויאפשר כניסה קלה לעולם של קומפוננטות.

פרק זה הוא הפרק החמישי במדריך. אלה החלקים הקודמים:

1. פרק 1 - פיתוח קומפוננטה ראשונה

2. פרק 2 - תקשורת בין קומפוננטות

3. פרק 3 - תבניות דינמיות

4. פרק 4 - ממשק ההרכבה Composition API

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

הקוד הבא מתאר שתי קומפוננטות, שתיהן קוראות ל useEffect:

import { useEffect, useState } from "react";

export default function Page(props) {
  useEffect(function () {
    document.title = "Page";
  }, []);

  return <Content />;
}

function Content(props) {
  const [title, setTitle] = useState(document.title);

  useEffect(function () {
    setTitle(document.title);
  }, []);

  return <p>Page title = {title}</p>;
}

והשאלות:

1. איזה אפקט ירוץ קודם?

2. מה יהיה תוכן העמוד אחרי רינדור הקומפוננטה Page?

3. איך אפשר לשנות את סדר האפקטים ולקבל תוצאה שונה על העמוד?

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

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

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

1. בעבודה אני כותב דברים בטכנולוגיה X; פרויקט צד מאפשר לי לגלות טכנולוגיות חדשות.

2. בגלל שאני אוהב את הכלבים שלי אני נהנה לכתוב מוצרים שמשמחים אותם.

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

תחביב. שם עצם - זכר. עִסּוּק מְסֻיָּם שֶׁאָדָם עוֹסֵק בּוֹ מִתּוֹךְ חִבָּה וְעִנְיָן בִּשְׁעוֹת הַפְּנַאי מֵעֲבוֹדָתוֹ, עִסּוּק שֶׁלֹּא לְשֵׁם פַּרְנָסָה אוֹ רְוָחִים, “הוֹבִּי”: פְּלוֹנִי בַּעַל תַּחְבִּיב שֶׁל אִסּוּף בּוּלִים. הוּא עוֹסֵק בְּצִיּוּר כְּתַחְבִּיב.

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

.. שלוש שעות יותר מאוחר

• נראה לי שהצלחתי לבנות סקריפט קטן שמריץ כל קובץ בדיקות בתהליך אחר!

... שבועיים יותר מאוחר

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

... שלושה חודשים יותר מאוחר

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

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

למה כתבת את השורה הזאת?

• כי זאת הדרך שתמיד כתבתי כזה קוד

• כי מצאתי את זה בגוגל

• כי מצאתי את זה ב Stack Overflow

• כי ראיתי את זה בסרט ביוטיוב

• כי ראיתי מנגנון דומה במקום אחר במערכת

• כי זה מה שהציע המתכנת הבכיר

• כי זה מה שהציע החבר לידי

• כי זה עבד

עכשיו מה יקרה אם תמחק אותה?

ואיך היה אפשר לכתוב את זה אחרת?

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

כדי לראות את הקושי במימוש מנגנון ריאקטיבי ב JavaScript נתבונן בקטע הקוד הבא:

const input = document.querySelector('input');
const output = document.querySelector('output');

output.value = input.value;

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

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

const input = document.querySelector('input');
const output = document.querySelector('output');

input.addEventListener('input', () => {
    output.value = input.value;
});

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

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

התיאוריה של פריימוורק ריאקטיבי פשוטה: אם אני כול להחליף את document.querySelector ולייצר אוביקט שלי שעוטף את ה DOM Element, אני אוכל לזהות מתי מישהו מנסה לקרוא מידע משדה value שלי, ולייצר אירוע שיפעיל את הקוד הזה מחדש כל פעם שערך השדה מתעדכן. בפועל הפריימוורקים שבנו מנגנון כזה מסתבכים כל אחד במקרי קצה אחרים. הנה שתי דוגמאות פשוטות מ Vue ו MobX ואחריהן סיכום עם המלצה.

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

1. חלק 1 - קומפוננטה ראשונה

2. חלק 2 - העברת מידע בין קומפוננטות

3. חלק 3 - תבניות דינמיות

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

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

1. את תראי גם איך להעלות את הסקין לאקסבוקס?

2. איך מפעילים מיינקרפט?

3. איך משחקים מיינקרפט?

4. את תראי איך למצוא סקינים באינטרנט?

5. זה עובד על Windows 10?

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

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

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

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

אם יש לכם Engagement ו Context, כל מפגש שתעבירו, בזום או בחיים האמיתיים, יהיה זמן שהושקע כמו שצריך.