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

טיפים קצרים וחדשות למתכנתים

עבודה מיותרת / עבודה גרועה

15/10/2021

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

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

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

ה Power Shell הראשון שלי

14/10/2021

החדשות הגדולות הן שהחלטתי לתת צ'אנס ל Windows אחרי שהתייאשתי מלמצוא פיתרון גיבוי טוב ללינוקס על הלפטופ. החדשות היותר קטנות הן שניצלתי את ההזדמנות ללמוד Power Shell - ואת המעט שהבנתי רציתי לשתף כאן בפוסט.

המשך קריאה

אזהרת טריגר

13/10/2021

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

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

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

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

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

סקיצה לפיתוח משחק Snake ב React

12/10/2021

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

המשך קריאה

הוראות מדויקות

11/10/2021

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

$ \curl -sSL https://get.rvm.io | bash

שכולל מצד אחד את ה \ בהתחלה כדי להגיע לגירסה האמיתית של curl בלי alias-ים, אבל מצד שני מתעלם מזה שבמחשבים ישנים או כאלה שמאחורי proxy, עלולה להיות בעיה עם התעודות שתכשיל את כל המהלך.

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

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

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

חמישה טיפים לניקיון בין המשימות

10/10/2021

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

אז מה עושים? הנה 5 טיפים קצרים שיעזרו לשמור את הקוד שלכם נקי:

המשך קריאה

קודם בא הפחד

09/10/2021

לא לפני ה Tutorial הראשון, אלה לא מפחידים, אבל לפני שמתחיל תהליך לימוד אמיתי מגיע הפחד עם הספקות שלו -

"אולי זה לא יצליח",

"אולי אני לא מספיק חכם בשביל להבין את זה",

"אולי יחשבו שאני מתחזה",

"בטח אף אחד לא ירצה להשתמש בתוכנה הזאת",

"אני בטוח כותב את זה לא נכון",

"חייבת להיות דרך יותר יעילה",

"אין מצב שאני חייב לקרוא את כל זה בשביל ללמוד את מה שרציתי"

"בעצם הטכנולוגיה הזאת ממילא לא תהיה פופולרית",

"בעצם הטכנולוגיה הזאת תכף תפסיק להיות פופולרית"

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

זהירות: מאפייני CSS שעוברים בירושה

08/10/2021

מתוך וובינר די מוצלח על 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 הבאים עוברים בירושה ולכן יכולים להגיע לקומפוננטה שלכם גם בלי שהתכוונתם:

  • border-collapse
  • border-spacing
  • caption-side
  • color
  • cursor
  • direction
  • empty-cells
  • font-family
  • font-size
  • font-style
  • font-variant
  • font-weight
  • font-size-adjust
  • font-stretch
  • font
  • letter-spacing
  • line-height
  • list-style-image
  • list-style-position
  • list-style-type
  • list-style
  • orphans
  • quotes
  • tab-size
  • text-align
  • text-align-last
  • text-decoration-color
  • text-indent
  • text-justify
  • text-shadow
  • text-transform
  • visibility
  • white-space
  • widows
  • word-break
  • word-spacing
  • word-wrap

אני עובד על הפרויקט הזה כדי-

07/10/2021

אני עובד על הפרויקט -הזה- כדי לשלם את החשבונות

כדי להישאר בחזית הטכנולוגיה

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

כדי לכתוב "גוגל" בקורות חיים

כדי שיהיה לי משהו מלהיב לספר במסיבות

כדי ללמוד טכנולוגיה ספציפית שאני חושב שתהיה מאוד מצליחה

כדי להציל את כדור הארץ

כדי לקדם אג'נדה שחשובה לי

כדי להתעשר

כדי לטייל בעולם

כדי לרשום פטנטים

כדי להתפרסם

כדי ללמוד איך עובד סטארטאפ ובעתיד לפתוח אחד משלי

כדי ליצור קשרים איכותיים בתעשיה


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

לדעת איך להתרסק

06/10/2021

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

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