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

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

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

1. תוכלו לעשות ישיבה פעם בכמה זמן לעבור על קומיטים ולראות איזה מהם אתם אוהבים ואיזה לא.

2. תוכלו לזהות קומיטים שאתם לא אוהבים ולתקן אותם באמצעות ריבייס.

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

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

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

מישהו ברדיט שאל השבוע - "אם אני רוצה לכתוב פרויקט כדי להוסיף אותו לקורות חיים, האם אפשר להשתמש בכלים המובנים בפריימוורק גם לחלקים שאנשים רואים? לדוגמה אם אני משתמש ב Django כדי לבנות אפליקציית ווב, האם אפשר להשתמש ברכיב ה Login המובנה ב Django?"

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

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

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

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

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

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

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

בעבודה על פרויקט Node.JS לבחירה בטייפסקריפט יש גם יתרונות וגם חסרונות עליהם נדבר בשיעור זה.

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

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

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

3. אפשר לקבל תוצאות טובות ובזול עם VPS או שרתים פיזיים - לינוד עדיין משכירים שרת VPS זול ב 5 דולר בחודש, ומכונות טובות ב 40$ בחודש. כן, נצטרך לעבוד קשה בשביל לקבל High Availability במובן שאם Region שלם נופל המערכת אוטומטית תתחיל לעבוד מ Region אחר או מ VPS אחר, אבל גם זה אפשרי ובכל מקרה לעסקים קטנים לא בטוח כמה זה הכרחי.

4. בעזרת Kubernetes ו Docker (לא מכירים אותם עדיין? יש קורס) אפשר לקבל חוויה מאוד דומה ל Deployment האוטומטי של חברות הענן, אבל בשליטה שלכם ועם תמיכה טובה במצב פיתוח, ואפשרות לעבור מהר בין ספקי תשתית.

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

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

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

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

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

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

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

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

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

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

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

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