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

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

<div />
<div />
<div />
<div />

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

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

<div>
    <div>
        <div>
            <div></div>
        </div>
    </div>
</div>

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

function Counter(props: { initialValue: number, step: number }) {
}

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

interface ICounterProps {
  initialValue: number;
  step: number;
  buttonText?: string;
}

function Counter(props: ICounterProps) {
}

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

interface ICounterProps {
  initialValue: number;
  step: number;
  buttonText?: string;
  turboButtonText?: string;
  turboStep?: number;
}

function Counter(props: ICounterProps) {
}

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

interface ICounterProps {
  initialValue: number;
  step: number;
  buttonText?: string;
}

interface ICounterWithTurboProps extends ICounterProps {
  turboButtonText: string;
  turboStep: number;
}

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

function Counter(props: ICounterProps|ICounterWithTurboProps) {
  const {
    initialValue,
    step,
    buttonText = 'Increase',
    turboButtonText,
    turboStep,
  } = props as ICounterWithTurboProps;
}

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

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

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

מתי עוצרים? מתי למדתם "מספיק להיום"? אולי...

• בסיום השיעור (כשהשעון מראה 12, בעוד 20 דקות)

• בסוף הפרק

• אחרי שאסיים את כל התרגילים

• אחרי שאפתור את הבאג, או כשהקוד יעבוד

• עד שהאוכל יגיע

• עד שתיכנס שיחת טלפון מעניינת

• עד שתגיע הודעה חשובה בווטסאפ

• עד שאירדם

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

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

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

ובשביל ששני חלקים עצמאיים במערכת יעבדו יחד הם צריכים לתקשר.

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

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

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

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

ביום חמישי הקרוב אני אקח שעה כדי לדבר עם אלה מכם שירצו להצטרף על מערכות מבוזרות, ארכיטקטורת Micro Services ובמיוחד על רכיב התקשורת RabbitMQ. הבחירה ב RabbitMQ מקרית לגמרי ויום אחד בטח נעשה את אותו וובינר עם Kafka.

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

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

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

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

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

לפרטים נוספים והרשמה שווה לבקר בדף הוובינר בקישור: https://www.tocode.co.il/workshops/115

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

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

1. להוריד את תחושת הסיכון.

2. לעבור להסתכל על הסיכוי.

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

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

2. אפשר לספר על ההוא שזכה והחיים שלו עכשיו השתנו מקצה לקצה.

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

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

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

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

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

בחצי שעה ביום אפשר ללמוד שפה חדשה (או שפת תכנות חדשה).

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

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

בחצי שעה ביום אפשר להיכנס לכושר ולהרגיש מלאי אנרגיה כל השבוע.

ובטח לכם יש עוד אינסוף רעיונות של דברים שהייתם רוצים לעשות.

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

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

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

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

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

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

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

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

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