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

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

והתרגיל-

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

{
    a: [
        { a1: 10, a2: 20 },
        { a3: 40, a4: 50 },
        { a1: 20, a2: 20 },
    ],
    b: {
        b1: 'yay',
        b2: 'jaj',
        b3: [
            { b33: 'yay' },
            { b33: 'jaj' },
            { b44: 'zaz' },
        ]
    },
}

כתבו פונקציה בשם groupByDepth שמקבלת את האוביקט מחזירה את כל המפתחות שלו מסודרים לפי העומק. בחישוב העומק אנחנו בודקים כמה אוביקטים ללא מערכים יש מעל המפתח. באוביקט הדוגמה a הוא בעומק 1 וכך גם b, אבל a1 הוא כבר בעומק 2 ו b33 הוא בעומק 3. סך הכל אם נפעיל את הפונקציה על אוביקט הדוגמה נרצה לקבל:

{
    1: [ 'a', 'b' ],
    2: [ 'a1', 'a2', 'a3', 'a4', 'b1', 'b2', 'b3' ],
    3: ['b33', 'b44'],
}

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

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

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

כשאפל הוציאו את ה Touch Bar הם היו בטוחים שזה האייפון הבא. אבל למבקרים לא אכפת כמה הם השקיעו בבניה של זה ורוב הקהל לא הבין למה צריך את זה.

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

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

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

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

import React from 'react';

function Yo() {
  React.useEffect(function() {
    alert('bye bye');
  }, []);

  return <p>Yo</p>;
}

export default function App() {
  function handleClick() {
  }

  return (
    <div className="App">
      <Yo />
      <button onClick={handleClick} >Say bye bye</button>
    </div>
  );
}

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

אין צורך לשנות את הקוד של Yo ואין לבצע כל שינוי ויזואלי בממשק.

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

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

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

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

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

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

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

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

$ pip install coconut

ואחרי ההתקנה אפשר ליצור תוכניות קוקונאט בתוך קבצים עם סיומת coco או להפעיל את ה interpreter עם הפקודה coconut ולהריץ ביטויי קוקאנט. ויש גם סביבת הרצה נוחה בענן בקישור: https://cs121-team-panda.github.io/coconut-interpreter/.

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

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

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

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

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

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

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

שתי הזדמנויות לעבודה יותר יעילה-

1. לזהות בעיות שאתם כבר יודעים איך לפתור ולבנות להן פיתרון מהיר יותר (או הכי טוב - אוטומציה)

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

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

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

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

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

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

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

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

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

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

2. העלאת גירסה ב Zero Downtime Deployments.

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

4. אבסטרקציה של Cron Jobs ומעקב אחרי הג'ובים שרצו או נכשלו.

5. ניהול אוטומטי של "סודות".

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

סך הכל אחרי שמתרגלים העבודה עם קוברנטס היתה לי (ותהיה לכם) קלה יותר מאשר העלאת קונטיינרים ידנית לשרת או עבודה עם docker-compose.

ביום חמישי הקרוב בשעה 10:00 בבוקר אני מתכוון להעביר בזום וובינר של שעה עם הסבר הכי פשוט שאפשר על קוברנטס, על היכולות שלו, על מה צריך להתקין בשביל לעבוד איתו והדגמה של העלאה לענן אפליקציה בעזרת קוברנטס. כן נדרש ידע קודם ב Docker ורצוי היכרות עם Node.JS. אם יש לכם V בשתי הקופסאות האלה מוזמנים להירשם למפגש בקישור:

https://www.tocode.co.il/workshops/107

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

נתראה בחמישי, ינון