טיפים קצרים וחדשות למתכנתים
ריאקט הוא קודם כל פריימוורק לפיתוח ממשקים גרפיים, וידוע שאין ממשק גרפי יותר מעניין ממשחק סנייק. אם יש לכם חצי שעה פנויה מוזמנים לבנות איתי משחק סנייק בריאקט כדי ללמוד יותר לעומק על החיבור בין ריאקט לקוד חיצוני.
הצורך המאוד טבעי שלנו למצוא הוראות מדויקות מתחבר יפה לרצון של אתרים רבים להיות ידידותיים, וכך אנחנו מגיעים למשפט הבא בהוראות ההתקנה של rvm:
$ \curl -sSL https://get.rvm.io | bash
שכולל מצד אחד את ה \ בהתחלה כדי להגיע לגירסה האמיתית של curl בלי alias-ים, אבל מצד שני מתעלם מזה שבמחשבים ישנים או כאלה שמאחורי proxy, עלולה להיות בעיה עם התעודות שתכשיל את כל המהלך.
כמובן שהיינו כועסים עליהם באותה מידה אם הם היו מכניסים גם -k להוראות ההתקנה - מה פתאום שמישהו ימליץ לי להתעלם משגיאות אבטחה? ובמיוחד כשאני הולך להתקין כלי רגיש כמו rvm.
לא, מקור הבעיה אינו חוסר דיוק בהוראות. אין הוראות מדויקות מספיק שיתאימו לכולם. מקור הבעיה הוא הניסיון לעזור לאנשים שלא יודעים איך להוריד סקריפט bash ולהריץ אותו, להצליח לעשות את זה בלי להבין את מה שהם עושים.
ההוראות הכי טובות הן אלה שמתארות במילים "מה צריך לעשות" ונותנות לי לשבור את הראש על ה"איך". זה אולי ייקח יותר זמן אבל לפחות יחסוך טעויות ופאדיחות.
כמו שפעם בכמה זמן אתם עוצרים כדי לנקות את הבית, כך גם הקוד שלכם צריך מדי פעם שתיקחו עצירה ותעבירו עליו סמרטוט. וכמו בבית, גם קוד שלא מנקים אותו הרבה זמן מתחיל להראות סימנים של לכלוך וגורם לאנשים חדשים לרצות לברוח.
אז מה עושים? הנה 5 טיפים קצרים שיעזרו לשמור את הקוד שלכם נקי:
לא לפני ה Tutorial הראשון, אלה לא מפחידים, אבל לפני שמתחיל תהליך לימוד אמיתי מגיע הפחד עם הספקות שלו -
"אולי זה לא יצליח",
"אולי אני לא מספיק חכם בשביל להבין את זה",
"אולי יחשבו שאני מתחזה",
"בטח אף אחד לא ירצה להשתמש בתוכנה הזאת",
"אני בטוח כותב את זה לא נכון",
"חייבת להיות דרך יותר יעילה",
"אין מצב שאני חייב לקרוא את כל זה בשביל ללמוד את מה שרציתי"
"בעצם הטכנולוגיה הזאת ממילא לא תהיה פופולרית",
"בעצם הטכנולוגיה הזאת תכף תפסיק להיות פופולרית"
הפחד תמיד שם כדי לשבש את תהליך הלמידה, והכי גרוע שפחד לא נעלם כשמתעצבנים עליו והוא לא נעלם כשמתעלמים ממנו. זה רק מחמיר את המצב. הפחד מתמסמס כשמכירים בו, כשמבינים שהוא בא לאותת לנו משהו וכשמרגיעים אותו. כשאני מסתכל על הסבר מעמיק ומרגיש את כל הגוף שלי רוצה לברוח אני עוצר לקחת אוויר ומנסה להרגיע אותו - "הי פחד, ציפיתי לך. בוא, תראה מה יש לנו לקרוא היום, אולי זה יהיה מעניין."
מתוך וובינר די מוצלח על Vue שהעברתי היום, קצת יותר מדי זמן התבזבז על בעיית CSS לא צפויה. בדוגמה המקורית בוובינר כתבנו סליידר תמונות אבל אני חושב שאפשר לראות את הבעיה בקלות גם עם דוגמה יותר פשוטה, למשל קומפוננטת ה Vue הבאה שכוללת כותרת בצבע כחול:
<script setup>
</script>
<template>
<div>
<h1>Hello World</h1>
</div>
</template>
<style scoped>
h1 {
color: blue;
}
</style>
למרות שמבחינת רשימת כללי העיצוב כל מה שיש ל h1 הוא הצבע הכחול, בפועל אנחנו יודעים שהוא יקבל גם את כל כללי העיצוב שמוגדרים על אלמנטי h1 במקומות אחרים במערכת, כי ככה עובד CSS. אבל יותר מזה, יש גם אוסף די גדול של מאפייני CSS אותם ה h1 שלנו יקבל בירושה מהאלמנטים שמעליו.
הבעיה עם Vue ופיתוח קומפוננטות באופן כללי היא שבזמן כתיבת הקומפוננטה אנחנו לא יודעים איפה היא הולכת להיות במסך ולכן אותה קומפוננטה, כשמופיעה במקומות שונים יכולה לקבל כללי עיצוב שונים. בדוגמה של הכותרת הכחולה שלי, אם אני שם אותה בתוך קומפוננטת App.vue שנראית כך:
<script setup>
// This starter template is using Vue 3 <script setup> SFCs
// Check out https://v3.vuejs.org/api/sfc-script-setup.html#sfc-script-setup
import HelloWorld from './components/HelloWorld.vue'
</script>
<template>
<img alt="Vue logo" src="./assets/logo.png" />
<HelloWorld msg="Hello Vue 3 + Vite" />
</template>
<style>
#app {
font-family: Avenir, Helvetica, Arial, sans-serif;
text-align: center;
color: #2c3e50;
margin-top: 60px;
}
</style>
אז נכון שהצבע הכחול של הקומפוננטה ידרוס את הצבע של #app, אבל הכותרת תקבל מ #app את הגופן והיישור למרכז.
אם נסתכל בכלי הפיתוח של הדפדפן ב Inspect Element על ה h1 אנחנו נראה ברשימת כל כללי העיצוב שחלים עליו את הבלוק של #app עם כל הכללים הרלוונטיים:
font-family: Avenir, Helvetica, Arial, sans-serif;
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;
text-align: center;
color: #2c3e50;
margin-top: 60px;
}
כאשר color מסומן בקו מחוק ו margin מופיע בטקסט חצי שקוף. הקו המחוק מסמן לנו שיש הגדרה אחרת יותר חשובה שמשנה את הצבע, והטקסט החצי שקוף מסמן לנו שמאפיין זה לא עובר בירושה.
ולכן שימו לב- כשאתם לוקחים קומפוננטה (בויו, או בכל פריימוורק אחר) ומגדירים לה רק כללי עיצוב מסוימים, חשוב לוודא בכלי הפיתוח של הדפדפן אם היא לא קיבלה בטעות כללי עיצוב אחרים שלא חשבתם עליהם ועלולים לקלקל לכם את כל העיצוב.
מאפייני CSS הבאים עוברים בירושה ולכן יכולים להגיע לקומפוננטה שלכם גם בלי שהתכוונתם:
אני עובד על הפרויקט -הזה- כדי לשלם את החשבונות
כדי להישאר בחזית הטכנולוגיה
בשביל ההזדמנות לעבוד עם האנשים האחרים בצוות
כדי לכתוב "גוגל" בקורות חיים
כדי שיהיה לי משהו מלהיב לספר במסיבות
כדי ללמוד טכנולוגיה ספציפית שאני חושב שתהיה מאוד מצליחה
כדי להציל את כדור הארץ
כדי לקדם אג'נדה שחשובה לי
כדי להתעשר
כדי לטייל בעולם
כדי לרשום פטנטים
כדי להתפרסם
כדי ללמוד איך עובד סטארטאפ ובעתיד לפתוח אחד משלי
כדי ליצור קשרים איכותיים בתעשיה
כשאנחנו באים לפרויקט עם כוונה ברורה אנחנו יכולים לעשות אופטימיזציה ולקחת אותו לכיוון שמסתדר הכי טוב עם המטרה שלנו, וקל יותר למדוד באיזו מידה הפרויקט הזה הוא הדבר הכי טוב בשבילי היום.
הסוג הקל של בעיות הוא כזה שגורם לתוכנית להתרסק. לדוגמה התוכנית הבאה בשפת פייתון מדפיסה למשתמש תרגיל חיבור אקראי פשוט, מצפה לתשובה ומדפיסה "בראבו" אם התשובה נכונה:
import random
x = random.randint(0, 10)
y = random.randint(0, 10)
print("{} + {} = ?".format(x, y))
guess = int(input())
if x + y == guess:
print("Bravo!")
else:
print("Better luck next time...")
קל לראות שיש בתוכנית בעיה - אם משתמש כותב במילים את התשובה במקום לכתוב את המספר התוכנית תתרסק:
7 + 0 = ?
seven
Traceback (most recent call last):
File "/home/ynon/tmp/blog/error1.py", line 7, in <module>
guess = int(input())
ValueError: invalid literal for int() with base 10: 'seven'
הסוג הקשה של בעיות הוא כזה שגורם לתוכנית להתנהג מוזר, והוא גם זה שיוביל לרוב בעיות אבטחת המידע בקוד שלכם. יותר קשה לראות באותה התוכנית שאם נריץ אותה עם פייתון 2 וננסה לענות תשובה שהיא פקודת פייתון, נוכל לגרום לתוכנית ליצור תיקיה על המחשב (או למחוק אחת):
$ python2 error.py
10 + 10 = ?
__import__('os').mkdir('yay')
Traceback (most recent call last):
File "error1.py", line 7, in <module>
guess = int(input())
TypeError: int() argument must be a string or a number, not 'NoneType'
כמתכנתים אנחנו כל כך רוצים שהקוד שלנו יעבוד שאנחנו מעדיפים להסתכל על ה Happy Path ולתכנן איזה פקודות צריך לכתוב כדי שדברים יעבדו. גישה טובה יותר היא לחפש כמה שיותר נתיבי שגיאות, ולנסות לדמיין כמה שיותר מצבים בהם הקוד שלנו יכול להיכשל. ככל שנכיר את המגבלות בזמן כתיבת הקוד כך נוכל להתכונן טוב יותר לבעיות שיגיעו בפרודקשן. אם יש ספק, העדיפו תמיד ליצור בעיות מהסוג הראשון.
אחרי הפסקה ארוכה מדי אני חוזר להעביר וובינרים בימי חמישי בבוקר. בינתיים אין עדיין רשימת דיוור מסודרת אז אני מנצל את הבלוג כדי לספר מה הולך להיות.
ביום חמישי הקרוב אדבר על Vue.JS בוובינר שמיועד למתכנתי ווב שלא ראו עדיין את הפריימוורק ואפילו יתאים אם ביליתם את השנים האחרונות במערה ולא ראיתם אף JavaScript Framework מודרני. אראה לכם איך לפתוח פרויקט Vue מההתחלה ואיך לשלב Vue בתוך פרויקט Node.JS שלכם, ואחר כך נראה את שיטת העבודה עם קומפוננטות ואיך היא עוזרת לנו לכתוב קוד נקי ובקלות.
זה הקישור להרשמה: https://www.tocode.co.il/workshops/109
ביום חמישי שאחריו (ה 14.10) אעביר שעה על React Testing Library. המפגש הזה יתמקד בטיפים ודוגמאות לאנשים שכבר מכירים טוב ריאקט וכותבים בדיקות ב react-testing-library או ספריה אחרת. אז אם התחלתם לכתוב בדיקות UI ונתקעתם או שהיו לכם שאלות או שפשוט רוצים לראות עוד גישה לכתיבת הבדיקות הוובינר הזה בשבילכם.
זה הקישור להרשמה: https://www.tocode.co.il/workshops/108
ביום חמישי שאחריו (ה 21.10) אני הולך להעביר שעה על קוברנטס לאנשים שלא ראו אף פעם את קוברנטס או שניסו להתקרב, ראו איזה yaml וברחו באימה. אנחנו נתקדם לאט מנקודת מבט של מפתחים ונראה איך לגשת לקוברנטס ואיך הוא יכול אפילו לעזור לנו.
זה הקישור להרשמה: https://www.tocode.co.il/workshops/107
וביום חמישי האחרון של החודש (ה 28.10) ניקח צעד אחורה מעולם הווב ונלך לראות מה חדש ב Python 3.10, כשהפיצ'ר שייקח לנו את עיקר הזמן בוובינר יהיה ה Pattern Matching ואני אשתדל להספיק לדבר על עוד 2-3 פיצ'רים קטנים יותר.
זה הקישור להרשמה: https://www.tocode.co.il/workshops/110
מקווה לראות אתכם במפגשים ואם יש לכם רעיונות לטכנולוגיות שהייתם רוצים לשמוע וובינר עליהן או להעביר וובינר עליהן שלחו אימייל ואשמח להוסיף לרשימה.
הנה תרגיל JavaScript נחמד שאולי ילמד אתכם משהו חדש על JSON.stringify (לפחות אותי הוא לימד). קחו רשימה של אוביקטים ורשימה נפרדת של מפתחות, משהו בסגנון הזה:
const keys = ['a', 'b'];
const data = [ { a: 10, b: 20, c: 30 }, { a: 10, b: 20, c: 40 }, { a: 10, b: 12, c: 50 } ];
והמשימה היא לסדר את data לקבוצות לפי המפתחות ב keys: כל שני אוביקטים שיש להם בדיוק את אותם ערכים למפתחות במערך keys יהיו באותה קבוצה. בדוגמה שלנו הקבוצה הראשונה תהיה:
const groups1 = [ { a: 10, b: 20, c: 30 }, { a: 10, b: 20, c: 40 } ];
כי לשני האוביקטים בשדה a יש את הערך 10 ובשדה b יש את הערך 20, והקבוצה השניה תהיה האוביקט היחיד:
const group2 = [ { a: 10, b: 12, c: 50 } ];
כי השדה b מכיל בו ערך שונה - הערך 12.
האינטואיציה הראשונה לפיתרון בעזרת lodash היא כנראה הפונקציה groupBy: לוקחים מכל אוביקט רק את המפתחות שמעניינים אותנו, מפעילים עליהם JSON.stringify כדי לקבל מחרוזת וזה יהיה המפתח ל groupBy. הנה הקוד:
// DO NOT USE - HAS A BIG BUG
const groups = _.groupBy(data, obj => JSON.stringify(_.pick(obj, keys)));
אבל הקוד הזה מכיל באג שלא תמיד רואים במבט ראשון. סדר המפתחות ב JSON.stringify הוא לא וודאי ולכן במקרים מסוימים ייתכן ששני אוביקטים עם ערכים זהים במפתחות הרלוונטיים יופיעו בשתי קבוצות שונות, כי JSON.stringify יכתוב את המפתחות בסדר שונה.
הפיתרון הוא פשוט ומופיע בתיעוד של JSON.stringify. הפרמטר השני לפונקציה נקרא replacer ותפקידו לעזור לנו לבחור איזה מפתחות להכניס ל JSON ומה יהיה הסדר שלהם. שימו לב:
> JSON.stringify({ a: 10, b: 20 }, ['a', 'b'] )
'{"a":10,"b":20}'
> JSON.stringify({ a: 10, b: 20 }, ['b', 'a'] )
'{"b":20,"a":10}'
> JSON.stringify({ a: 10, b: 20 }, ['b'] )
'{"b":20}'
עכשיו הפיתרון ברור- עלינו להוסיף ל JSON.stringify את מערך המפתחות כדי לוודא שהסדר יהיה אחיד וששני אוביקטים עם אותם מפתחות תמיד יגיעו לאותה קבוצה:
const groups = _.groupBy(data, obj => JSON.stringify(_.pick(obj, keys), keys));
אם אתם כותבים משהו שהמטרה שלו להשאיר על הקוראים שלכם רושם ש"הבן אדם הזה יודע על מה הוא מדבר" - כמו למשל פוסט לשיתוף בלינקדאין, פוסט אורח בבלוג מפורסם או אפילו קובץ readme ליד פרויקט שאתם מצרפים לקורות חיים - מאוד חשוב לשים לב למספר פרטים קטנים שיכולים לקלקל את כל הרושם, במיוחד אם אתם באמת אנשים שיודעים על מה אתם מדברים. הנה שלושה טיפים שבלעדיהם כל פוסט טכני עלול לשקוע ולעשות יותר נזק מתועלת: