טיפים קצרים וחדשות למתכנתים
סייפרס הוא ספריית בדיקות ה End-to-end האהובה ביותר על מתכנתי Front End היום ו testing-library היא ספריית ה Unit Test המובילה. הנה סיכום קצר של ההבדלים בין שני הדברים ובסוף המלצה במה כדאי להשתמש.
ואם היית חושב שזה אפשרי, האם היית מוותר על שעה בפייסבוק כל יום בשביל להתקדם בפרויקט הזה?
ואם היית חושב שזה חשוב, היית מסכים לקום שעה קודם כל יום בשביל לעבוד על זה?
ואם היית מבין שזאת ההזדמנות האחרונה, האם היית מוצא דרך לפנות שעה ביום בשביל לבנות את זה?
כולנו עברנו שטיפת מוח קולקטיבית. לימדו אותנו שזה לא אפשרי, שזה לא חשוב ושתמיד יהיה זמן יותר טוב. שקודם כל צריך להתמקד במה שאפשר למדוד ושחלומות יכולים לחכות לזמן שבו הכל יהיה מסודר (כלומר לעולם לא). הדבר הזה שרצית לבנות או ללמוד? אתה יכול להצליח בו; ההצלחה שלו יותר חשובה מרוב הדברים שאתה עושה עכשיו וההזדמנות שיש לך עכשיו לא תחזור. עכשיו הזמן להתחיל.
מצב שינה הוא מהפיצ'רים הכי משעממים שיש במחשב. כל מה שאתה רוצה זה שהוא יעבוד כמו שצריך, כלומר שכשהמחשב לא מחובר לחשמל ואני לא עובד איתו שגם לא יבזבז סוללה. מפה מתכנתים מתחילים לגזור כל מיני תנאים כמו:
אם הלפטופ עובד על סוללה וסוגרים את הכיסוי יש להקפיא יישומים שלוקחים הרבה סוללה.
אם משתמש לא נגע בלפטופ כמה דקות והוא לא מחובר לחשמל כדאי לסגור את חיבורי הרשת.
אם המחשב לא בשימוש אפשר לסגור את התצוגה.
ועוד אינסוף דברים קטנים שיחד מרכיבים את הפיצ'ר שנקרא מצב שינה. ב Windows הפיצ'ר הזה עבד לי מספיק גרוע כדי שאצטרך לחקור אותו ולנסות לתקן, אלה הדברים שגיליתי:
עבודה מיותרת זה מה שקורה כשאת כותבת משהו שלא באמת היית צריכה. לדוגמה בכתיבת חנות דיגיטלית ללקוח, הלקוח יודע שהוא הולך לבצע עיסקאות רק דרך פייפאל אבל את מגדילה ראש וכותבת מנגנון גנרי כדי שיוכל מתי שהוא רוצה להחליף חברת סליקה.
עבודה גרועה קורית כשאת מתעקשת להשתמש בעבודה המיותרת שכתבת גם כשזה לא באינטרס של הלקוח. באותה חנות דיגיטלית, אם ללקוח יש מסך של רשימת עיסקאות שבוצעו הוא היה רוצה לראות ליד כל עיסקה את מזהה העיסקה כמו שמופיע בפייפאל כדי שאפשר יהיה לוודא פרטים של עיסקה מסוימת. לא להציג את המידע הזה רק בגלל שיש חברת סליקה אחרת (שלא משתמשים בה) שבעיסקאות דרכה המידע לא מתקבל זה להפוך עבודה מיותרת לעבודה גרועה.
רק בגלל שכתבת את המנגנון זה לא אומר שחייבים להשתמש בו.
החדשות הגדולות הן שהחלטתי לתת צ'אנס ל Windows אחרי שהתייאשתי מלמצוא פיתרון גיבוי טוב ללינוקס על הלפטופ. החדשות היותר קטנות הן שניצלתי את ההזדמנות ללמוד Power Shell - ואת המעט שהבנתי רציתי לשתף כאן בפוסט.
לכל תעשיה יש את הסודות המקצועיים שלה ואחד הסודות שהכי חשוב להכיר הוא הטריגרים. טריגר הוא דבר שאם תעשו אותו בחברה באופן אוטומטי אנשים יסתכלו עליכם מוזר או ירגישו שעשיתם משהו לא בסדר. פוליטיקאים יכולים להיות ממש גרועים בזה ואז מתחילה סערה ציבורית והפוליטיקאי לא מבין מה כולם רוצים ממנו. אבל הנקודה שטריגרים קיימים בכל חברה ובכל תרבות.
בתרבויות של מתכנתים יש המון טריגרים שיגרמו לאנשים להפסיק להקשיב לכם: לחלק מהאנשים זה שימוש בשפת תכנות מסוימת, עבור אחרים זה סגנון כתיבה או שימוש בספריה מסוימת, או הכי בולט הוא חוסר תשומת לב לפרט שכל האחרים מבינים שהוא חשוב.
אז לדוגמה אם אתם ניגשים למשרת תכנות PHP ואתם כותבים במשימת בית קוד עם בעיית אבטחה מסוג SQL Injection, יש הרבה מאוד אנשים שרק על השורה הזאת יפסלו אתכם מהמשרה - אפילו אם זו שורה בודדת בתרגיל של מאות שורות.
הטריגר הוא טעות שתמיד קל לתקן אותה ברגע שאנחנו מבינים שעשינו אותה, וזה בדיוק מה שהופך אותו לכל כך מרגיז.
בתהליך של ראיונות עבודה ובמיוחד בתקופה של ראיונות שלא מצליחים, חשוב לחפש את הדברים הקטנים שאתם אומרים או עושים שגורמים לאנשים להפסיק להקשיב לכם. את הטריגרים שאתם דורכים עליהם בלי לשים לב. כל אחד כזה שתצליחו לאסוף מראיון עבודה, גם אם נכשלתם בראיון, זה משהו ששווה לזכור ולשמור לכל החיים.
ריאקט הוא קודם כל פריימוורק לפיתוח ממשקים גרפיים, וידוע שאין ממשק גרפי יותר מעניין ממשחק סנייק. אם יש לכם חצי שעה פנויה מוזמנים לבנות איתי משחק סנייק בריאקט כדי ללמוד יותר לעומק על החיבור בין ריאקט לקוד חיצוני.
הצורך המאוד טבעי שלנו למצוא הוראות מדויקות מתחבר יפה לרצון של אתרים רבים להיות ידידותיים, וכך אנחנו מגיעים למשפט הבא בהוראות ההתקנה של rvm:
$ \curl -sSL https://get.rvm.io | bash
שכולל מצד אחד את ה \ בהתחלה כדי להגיע לגירסה האמיתית של curl בלי alias-ים, אבל מצד שני מתעלם מזה שבמחשבים ישנים או כאלה שמאחורי proxy, עלולה להיות בעיה עם התעודות שתכשיל את כל המהלך.
כמובן שהיינו כועסים עליהם באותה מידה אם הם היו מכניסים גם -k להוראות ההתקנה - מה פתאום שמישהו ימליץ לי להתעלם משגיאות אבטחה? ובמיוחד כשאני הולך להתקין כלי רגיש כמו rvm.
לא, מקור הבעיה אינו חוסר דיוק בהוראות. אין הוראות מדויקות מספיק שיתאימו לכולם. מקור הבעיה הוא הניסיון לעזור לאנשים שלא יודעים איך להוריד סקריפט bash ולהריץ אותו, להצליח לעשות את זה בלי להבין את מה שהם עושים.
ההוראות הכי טובות הן אלה שמתארות במילים "מה צריך לעשות" ונותנות לי לשבור את הראש על ה"איך". זה אולי ייקח יותר זמן אבל לפחות יחסוך טעויות ופאדיחות.
כמו שפעם בכמה זמן אתם עוצרים כדי לנקות את הבית, כך גם הקוד שלכם צריך מדי פעם שתיקחו עצירה ותעבירו עליו סמרטוט. וכמו בבית, גם קוד שלא מנקים אותו הרבה זמן מתחיל להראות סימנים של לכלוך וגורם לאנשים חדשים לרצות לברוח.
אז מה עושים? הנה 5 טיפים קצרים שיעזרו לשמור את הקוד שלכם נקי:
לא לפני ה Tutorial הראשון, אלה לא מפחידים, אבל לפני שמתחיל תהליך לימוד אמיתי מגיע הפחד עם הספקות שלו -
"אולי זה לא יצליח",
"אולי אני לא מספיק חכם בשביל להבין את זה",
"אולי יחשבו שאני מתחזה",
"בטח אף אחד לא ירצה להשתמש בתוכנה הזאת",
"אני בטוח כותב את זה לא נכון",
"חייבת להיות דרך יותר יעילה",
"אין מצב שאני חייב לקרוא את כל זה בשביל ללמוד את מה שרציתי"
"בעצם הטכנולוגיה הזאת ממילא לא תהיה פופולרית",
"בעצם הטכנולוגיה הזאת תכף תפסיק להיות פופולרית"
הפחד תמיד שם כדי לשבש את תהליך הלמידה, והכי גרוע שפחד לא נעלם כשמתעצבנים עליו והוא לא נעלם כשמתעלמים ממנו. זה רק מחמיר את המצב. הפחד מתמסמס כשמכירים בו, כשמבינים שהוא בא לאותת לנו משהו וכשמרגיעים אותו. כשאני מסתכל על הסבר מעמיק ומרגיש את כל הגוף שלי רוצה לברוח אני עוצר לקחת אוויר ומנסה להרגיע אותו - "הי פחד, ציפיתי לך. בוא, תראה מה יש לנו לקרוא היום, אולי זה יהיה מעניין."