טיפים קצרים וחדשות למתכנתים
הי חברים,
באיחור קל אני שמח להזמין אתכם להצטרף לאחד הוובינרים הקרובים שלנו. את הוובינרים אני מעביר כל יום חמישי בעשר בבוקר, והקלטות שלהם זמינות כאן באתר בדף הקלטות מוובינרים.
אני משתדל לבחור נושאים שקשורים לנושאי הקורסים ומרחיבים אותם. אם יש לכם רעיונות או חלומות על נושאים שהייתם רוצים ללמוד שלחו לי מייל ואנסה להוסיף אותם בחודשים הבאים. זאת הרשימה לשלושת החודשים הקרובים:
בהתמודדות עם אתגרים אנחנו שמים לב לשני רצונות מנוגדים ובעייתיים-
חלק מהזמן אנחנו מתעקשים לפתור הכל לבד, כאילו כדי להוכיח לעצמנו או לעולם שאנחנו יכולים.
חלק מהזמן אנחנו מיואשים לגמרי ורק רוצים להסתכל בפיתרון או שמישהו יסביר לנו מה עושים.
הבעיה בלפתור הכל לבד היא שכשאתם לא מצליחים זה יכול לייאש ולתקוע; ואם אתם מצליחים הכל זה אומר שלא בחרתם אתגרים קשים מספיק.
הבעיה בלהסתכל בפיתרונות של אחרים ולהעתיק היא שאתם לא מאמנים את השרירים הנכונים של פיתרון בעיות, ושרוב האתגרים בחיים האמיתיים לא דומים לשום דבר שכתוב בספר.
הפיתרון לאנשים שרוצים להשתפר וללמוד הוא להתרגל לחפש רמזים: לשאול איפה אפשר לקרוא יותר על XYZ, או לברר על איזה נושאים כדאי ללמוד כדי להתמודד טוב יותר עם הבעיה, או להסתכל על פיתרונות של בעיות דומות ולנסות להתאים אותם לאתגר שלנו, או כל חיפוש דומה.
רמז מאפשר לנו לשלב - גם ללמוד דברים חדשים, וגם ליישם אותם על האתגרים שעכשיו אנחנו מתמודדים איתם. שילוב כזה, לאורך זמן, מרחיב אופקים והופך אותנו לפותרי בעיות טובים יותר.
תרגילי Advent Of Code הם המקום המושלם להתאמן על שפת תכנות חדשה, ובמיוחד כזאת שיודעת להתמודד יפה עם נתונים ומניפולציות עליהם. קלוז'ר בהחלט מתאימה להגדרה. את יום 5 הצלחתי לפתור עם טריק פשוט אחד - ועוד קצת קוד מסביבו. הנה הסיפור המלא.
בגיטהאב אנחנו יכולים להסתכל בממשק הגרפי אחורה ולראות את כל הדיונים שהיו על Pull Request וגם מי אישר כל PR. אבל אם נחליט לקחת את הפרויקט החוצה מגיטהאב, או אם אנחנו עובדים בגיט משורת הפקודה, המידע הזה כבר לא זמין.
לא מזמן כתבתי כאן על מנגנון הפתקים בגיט. היום אני רוצה להראות דוגמה לשימוש בהם כדי שכל פעם שמישהו מאשר Pull Request השם שלו ייכתב בתוך הקומיט בתור Note, כך שנוכל להיזכר אחרי מכל מקום.
אחד השלבים המתסכלים בלימוד טכנולוגיה או שפה מגיע אחרי שאנחנו כבר מבינים את הבסיס, מצליחים לפתור תרגילים פשוטים ואפילו מצליחים להבין קוד שאנחנו רואים בפיתרון או תוכנית דוגמה.
אבל לא מצליחים לכתוב.
זה יכול להיות שאנחנו נתקעים ממש בהתחלה, פוחדים שנבחר את התבנית הלא נכונה או לא יודעים בדיוק איזו תבנית לבחור. חוששים שנעשה צעד שעוד שבוע נתחרט עליו, או הכי גרוע - מתחילים לכתוב והכל יוצא יותר מסובך בהרבה מכל דוגמה שראינו, עד לרמה שקשה להבין לאן נעלם כל הסיבוך הזה בתוכניות הדוגמה, ואם מישהו לא עשה עלינו איזה תרגיל.
אבל אין שום תרגיל.
הדרך היחידה ללמוד לכתוב היא לכתוב, ולכתוב כמה שיותר. לעבור את השלב הזה שדברים לא עובדים, ואז את השלב שהם מסובכים, ואז לאט לאט לשים לב לפיתרונות יותר פשוטים עד שדברים מתחילים להתחבר. המשך לימוד בקורס, המשך קריאה או אפילו שיעורים פרטיים לא יעזרו כאן. השרירים של הכתיבה צריכים להתרגל שגם הם צריכים לעבוד.
התחושה שאני לא יודע לכתוב היא הסימן הכי טוב לסיים את הקריאה ולהתחיל לעבוד.
בכתיבת מערכות תוכנה אנחנו יודעים (בדרך כלל) לאזן בין מהירות הפיתוח לביטחון. בקצה אחד של הסקאלה, מי שבונה קוצב לב צריך לעשות הכל כדי להגיע לאפס טעויות, ובקצה השני אם אתם בונים אתר משחקים אונליין אתם מוכנים לחיות עם העלאת גירסה שבה משחק מסוים לא עבד או עבד עם באג. תמיד אפשר להעלות גירסת תיקון.
את אותו הגיון אפשר לקחת גם לקריירה האישית או הלימודית שלנו-
האם אני מוכנה ללמוד טכנולוגיה גם אם היא בסוף לא תהיה "הדבר הגדול הבא"? או שהזמן שלי קצוב ואני צריכה אפס טעויות בבחירת נושאי הלימוד?
האם אני מוכנה להתפרץ בדיון גם אם אני לא בטוחה במה שיש לי להגיד, או שאני שואפת ל"אפס טעויות" ומוכנה לדבר פחות ובלבד שתמיד אגיד דברים שאני בטוחה בהם.
האם אני מוכנה להעביר הרצאה לצוות על נושא שאני לא מומחית בו, או שאני מעדיפה לא לקחת סיכונים ולכוון ל"אפס טעויות".
הטריק הוא שכמו במערכות, אי אפשר להחזיק במקל בשני הקצוות. אפס טעויות מכתיב התקדמות איטית יותר ומעט מאוד חדשנות. לרוב המתכנתים והמתכנתות שאני מכיר, מדיניות של אפס טעויות בקריירה לא שווה את המאמץ.
הדבר שאני הכי אוהב בעבודה עם לקוחות הוא כשמתקילים אותי בשאלה שלא חשבתי עליה לפני. כך היה כשעזרתי היום ללקוח עם גיט ובדרך למדתי על מתג סופר שימושי של rebase.
הכלי awk היה לאורך שנים ועודנו אחד הכלים המרכזיים לעיבוד טקסט בסביבת יוניקס. הוא פותח בשנות ה 70 בחברת Bell Labs על ידי שלושה מפתחים ששמותיהם נתנו לכלי את שמו: Alfred Aho, Peter Weinberger ו Brian Kernighan. הייחודיות של awk היא שמצד אחד הוא כולל אלמנטים מתקדמים משפות תכנות כמו משתנים, מערכים, מילונים ואפילו אפשרות להגדיר פונקציות; אבל מצד שני זה כלי סקריפטים שהשימוש בו מאוד ממוקד לפיענוח טקסטים.
היכרות עם awk תאפשר לנו להעלות את הרמה של הסקריפטים שאנחנו כותבים וגם לפתור בעיות הקשורות לטקסט במהירות ומשורת הפקודה.
לשים חגורה לפני שמתחילים לנסוע.
לצחצח שיניים לפני שהולכים לישון.
לבדוק מה מצב הזיכרון והדיסק כשמתחילים לחקור תקלה.
להסתכל בלוגים.
להוסיף הודעת הדפסה (או Breakpoint) במצב פיתוח.
לגבות את המחשב כל יום.
היום יום שלנו, ואיתו גם יום העבודה, מורכב מאינספור פעולות שאנחנו עושים "על אוטומט" פשוט כי ככה תמיד עשינו או כי מתישהו החלטנו שזה מועיל או כי מישהו החליט בשבילנו. וכן יש בנוסף גם קצת עבודה שדורשת חשיבה, קבלת החלטות וכל הדברים האלה.
דרך קלה לשפר פרודוקטיביות היא להתחיל לשים לב לפרוטוקולים האוטומטיים שלנו, לכתוב אותם ולתקן את אלה שכבר לא מתאימים לנו, או להוסיף אוטומציה לאלה שאנחנו יודעים שיישארו. אולי קשה יותר לראות אותם, אבל בסוף אלה הדברים שקובעים את התוצאה.
לפעמים יתרונות קטנים מתגלים לאט. ל zsh עברתי כבר לפני כמה שנים כי אפל החליטו שזה shell ברירת מחדל טוב יותר ואף פעם לא היה לי אכפת במיוחד כי כל הטריקים שהכרתי מ bash עבדו טוב גם בו. והשמחה האמיתית היא להתחיל לגלות טריקים חדשים.
אנחנו כבר יודעים להשתמש ב tee כדי לכתוב בפקודה אחת לכמה קבצים:
$ echo hello world | tee a b c d >& /dev/null
וזה עובד גם ב bash וגם ב zsh. אבל מסתבר שב zsh יש עוד טריק איתו אפשר לוותר על tee:
$ { echo hello world } > a > b > c > d
וזה יוצר ארבעה קבצים שנקראים a, b, c ו d בהתאמה ובתוך כל אחד מהם כותב את הטקסט hello world.
מיטיבי לכת יכולים לוותר גם על כל החצים ולהשתמש בשתי נקודות כששמות הקבצים מתאימים. במקרה שלנו:
$ { echo hello world } > {a..d}
נ.ב. את הפקודה המרכזית אני מקיף בסוגריים מסולסלים כי אחרת zsh לא תמיד יודע שהיא נגמרה. הסבר מדויק אפשר למצוא בתיעוד שלהם כאן: https://zsh.sourceforge.io/Doc/Release/Redirection.html#Multios