טיפים קצרים וחדשות למתכנתים
ספריית unittest של Python כוללת Decorator בשם patch שתפקידו לעזור לנו לבדוק קוד שיש לו תלויות שקשה לבדוק. במדריך זה נראה מהן תלויות שקשה לבדוק וכמה דוגמאות לשימוש בפקודה patch כדי להתגבר על קושי זה.
לא מזמן חיפשתי בגוגל את הביטוי:
children teach themselves to read
אתם יכולים ללחוץ על הלינק כדי לראות את התוצאות בעצמכם. מסתבר שיש קטע כזה ויש הרבה אנשים שמוותרים על ללמד את הילדים שלהם לקרוא, כי הילדים ממילא חשופים כל כך לקריאה שהם ילמדו לבד. ומסתבר גם שכשילדים לומדים לבד לקרוא זה מצליח להם הרבה יותר מהר והרבה יותר בכיף מאשר הלמידה השיטטית של בית הספר.
אותי מה שיותר מעניין זה להבין מה גורם לילדים האלה להתאמץ כל כך כדי ללמוד לקרוא, והאם אנחנו יכולים לייצר את אותה מוטיבציה גם בכיתות שלנו או בתהליך הלימודי שאנחנו רוצים לעבור. הנה כמה דברים שאני חושב שעוזרים:
הפחד להישאר מאחור - אם כל החברים שלי יודעים לקרוא אני רוצה גם.
הרצון להצליח יותר - אם החברים שלי עדיין לא יודעים לקרוא אני יכול להבין מה שאחרים לא מבינים, אני יכול להיראות יותר חכם מהחברים.
כשאני צריך לדעת לקרוא בשביל להשיג משהו אחר - למשל כי לאח הגדול שלי נמאס להקריא לי את מה שכתוב במחשב ועכשיו בשביל להפעיל את המשחק אני צריך לגלות לבד איפה ללחוץ.
רעיונות נוספים? שתפו בשמחה בתגובות
הפקודה in של פייתון מאפשרת לחפש אלמנט בתוך מבנה נתונים. למעשה כל מה שהיא עושה זה להפעיל את הפונקציה __contains__ של מבנה הנתונים, או בקוד זה אומר ש:
5 in [10, 20, 30, 5, 9]
בעצם מפעיל את:
[10, 20, 30, 5, 9].__contains__(5)
בגלל שפייתון היא שפה מונחית עצמים, כל מבנה נתונים יכול לממש את __contains__ בצורה שמתאימה עבורו, ולכן הזמן שייקח ל in להחזיר תשובה תלוי קודם כל בסוג מבנה הנתונים בו אתם מחפשים.
שלושת המקרים הנפוצים לחיפוש אלמנט הם חיפוש במילון, חיפוש ברשימה וחיפוש במפתחות של מילון. בואו נמדוד זמנים לכל אחד מהם ונראה מה אפשר ללמוד מזה.
הבעיה הראשונה עם ״לעגל״ פינות היא שבסוף נגמרות הפינות לעגל. אז פעם אחת הצלחת לעשות Deploy לא דרך הסקריפט של הדיפלוימנט כדי לא להיתקע על לתקן את הסקריפט וככה הצלחת להעלות את הפיצ'ר חצי יום לפני הזמן. ופעם שניה הצלחת לדלג על איזה מקרה קצה שאף אחד לא יגיע אליו והעלית פיצ'ר נוסף חצי יום לפני הזמן. אבל מה הלאה? הרי כל פינה כזאת שמדלגים עליה רק הופכת את המערכת ליותר קשה לתחזוקה בטווח הרחוק.
ויותר חשובה הבעיה השניה עם ״לעגל״ פינות, והיא שאתה לא מקבל את ההזדמנות להפוך למתכנת טוב יותר.
כל האנשים שהמליצו לי לעשות ספורט תמיד אמרו שכדאי להתחיל לרוץ לאט והרבה. הקצב כבר יבוא עם הזמן. אני לא יודע לגבי זה כי אף פעם לא ממש הצלחתי להתמיד. בתכנות כן הצלחתי והעצה הזאת מצוינת - מתחילים לכתוב קוד טוב ולאט, ואז עם הזמן הופכים ליותר טובים בזה. עיגול פינות רק פוגע בך, כי הוא לא מאפשר לשפר את המטריקה הנכונה.
זה ממש לא סוף העולם לכתוב קוד לאט. אבל לכתוב קוד גרוע? מזה קשה מאוד להתאושש.
כולם מהמרים לפעמים על הטכנולוגיות הלא נכונות, ואז נתקעים עם מערכת שקשה לתחזק. וזה בסדר כל עוד הכל עובד לכם ולמשתמשים שלכם. השמועה אומרת שבנקים עדיין משתמשים בקובול ואף אחד לא מרגיש.
אבל אנחנו יודעים שהגיע הזמן לשדרג כשדברים מתחילים להרגיש מוזרים. למשל המשפט הבא שמצאתי בחוברת במטוס, כשהסבירו על מערכת הבידור החדשנית שלהם:
ב Windows 8/10 יש שני דפדפנים, שניהם מכונים Internet Explorer. את אחד הדפדפנים ניתן לפתוח דרך ממשק Metro בעוד את השני ניתן לפתוח רק מסביבת שולחן העבודה. דפדפן שולחן העבודה מאפשר שימוש ב Plug-Ins דוגמת Silverlight אך דפדפן Metro אינו מאפשר זאת. אם הנך משתמש ב Windows 8 יש לוודא שאתה משתמש בדפדפן Internet Explorer מתוך שולחן העבודה.
מייקרוסופט הפסיקה לעדכן את סילברלייט ב 2013 והחל מ 2015 כרום כבר לא מריץ יישומי סילברלייט. זאת הסיבה לדרישה להתקין את הפלאגין ולהשתמש רק בדפדפן מסוים בשבילו. המשך השימוש בסילברלייט רק ילך ויעשה יותר מסורבל עד שיהפוך לכמעט בלתי אפשרי. תאריך הסגירה הרשמי של סילברלייט הוא ספטמבר 2021, ואחרי זה גם עדכוני אבטחה ותיקוני באגים לא יסופקו.
כן ברור שהיה טוב להתחיל עם פיתרון מבוסס Web ללא פלאגינים, אבל בהינתן שזה לא קרה, היום הוא יום מעולה להתחיל לשדרג.
מילא לשלוח קורות חיים ושלא יחזרו אליך - שם אפשר לפחות להתנחם בהרגשה שזה לא אני, שפשוט אין לי את הניסיון הדרוש, שאני לא בדיוק מה שהם מחפשים, שאם רק הייתי עושה תואר הייתי מתקבל. זה לא אישי.
אבל להיכשל בראיון!? אותי אתם לא מקבלים!? עליי אתם מוותרים!? זה כבר ממש לא נעים.
אם נשים את האגו בצד האמת היא שגם כישלון בראיון לא קשור למי שאת או אתה, אלא בעיקר לתשובות שענית בראיון (שעה של שיחה), לשאלות ששאלת או לא שאלת ולתדמית הספציפית ששידרת. אנשים שמחפשים עובדים מחפשים תמיד תבנית מסוימת של העובד האידאלי, ובראיון הם מנסים לבדוק עד כמה אתם מתאימים לתבנית הזאת.
אחרי שהבנו את זה השלב הבא זה לנסות לקבל עוד מידע כדי ללמוד ולהשתפר לסיבוב הבא. שאלו את עצמכם: איזה תבנית ניסיתי לשדר? איזה תבנית שידרתי? מה היה הפער? אפילו תרשמו את זה.
לדוגמא לפני ראיון ארשום לעצמי שאני הולך להתראיין למשרת מפתח Junior שלימד את עצמו הכל ויודע לתקתק פרויקטים. אני כבר יודע שהאתגר המרכזי בתבנית כזאת זה השאלה אם אני מסוגל ללמד את עצמי את הדברים הנכונים. אז עכשיו במהלך הראיון אני הולך להיות מאוד רגיש לשאלות טכניות על נושאים שאני אמור לדעת ושאני בטוח שאני יודע את התשובה. בשאלות כאלה יש פוטנציאל גדול לענות מהר מדי תשובה לא מספיק מעמיקה. אז בסוף הראיון כדאי לרשום בצד את כל השאלות שידעתי את התשובה להן, ולחפש באינטרנט כל אחת לראות אם יש שם איזה טריק (או אפילו לשאול חבר שעובד כבר בתעשיה מה דעתו).
בשורה התחתונה הראיון זה פשוט משחק התאמה, ואתם יכולים לבחור מה אתם משדרים ולהמשיך לשפר עד שזה מצליח. כשמסתכלים על זה כמשחק אני חושב שיותר קל לזהות את הבעיות ולשפר לאט.
כל מערכת שאתם מפעילים עלולה להגיע למצבים מביכים כשהיא פוגשת את העולם האמיתי. לפעמים עומסים, לפעמים באגים ולרוב שילוב של שניהם יגרמו למערכת שלכם להיתקע או להתרסק. לדוקר יש מנגנון אוטומטי שמזהה נפילות מסוג זה וגם יפעיל מחדש את האפליקציה כשזה קורה כדי שאף אחד לא ישים לב לפאדיחה. זה נקרא Health Check ובוא נראה איך זה עובד.
למרות שאנחנו יכולים להרכיב את כל המערכת שלנו לתוך מיכל אחד, בדרך כלל זה לא יהיה הרעיון הכי טוב. כשהמערכת כולה במיכל אחד קשה יותר להעביר סרביס מסוים למכונה אחרת - זה הכל או כלום. בעיה נוספת היא שדרוגים: כשכל הרכיבים של המערכת שמורים באותו מיכל ואתם צריכים לשדרג רק רכיב אחד, תהיו חייבים להוציא גירסא חדשה של המיכל כולו.
ההמלצה בקהילת הדוקריסטים היא לכן להפריד את המערכת שלכם למספר מיכלים, כאשר כל מיכל אחראי על חלק אחר במערכת ויכול תיאורטית לרוץ על מכונה נפרדת. כך בסיס הנתונים ישב במיכל משלו, כל Micro Service יקבל מיכל, רדיס במיכל משלו וגם Memcached במיכל נפרד.
אבל כשאנחנו מפרידים את המערכת שלנו למיכלים אנחנו מייצרים סיבוך אחר: הצורך לארגן את המיכלים יחד לריצה בצורה מתואמת, ולהתמודד עם אילוצים של חלקים שונים במערכת.
ב Docker מיכל שאמור לרוץ בסביבת ייצור כחלק ממערכת גדולה יותר נקרא Service. כמו שהקובץ Dockerfile הגדיר מה יש לנו בתוך מיכל, כך יש קובץ מקביל בשם docker-compose.yml שאחראי על הגדרת הסרביסים במערכת. לכל סרביס נרצה להגדיר על איזה מכונות מותר לו לרוץ, מהם מיפויי הפורטים שלו ואילוצים שונים של הסרביס (למשל שסרביס מסוים חייב לרוץ על מכונה מסוימת, או לא יכול לתפוס יותר מכמות מסוימת של זיכרון).
אז אנחנו בטיול באיטליה השבוע וכשאתה תייר דברים שביום רגיל לא היו מפריעים לאף אחד נראים פתאום מוזרים. אפליקציית פנגו לדוגמא.
מקומי מחנה את הרכב, מפעיל פנגו ומתחיל לשלם על חניה. הכל טוב.
תייר מחנה את הרכב, מחפש להוריד את פנגו (שלהם נקרא איזיפארק), מגלה שזה מעל 80 מגה, שורף את החבילת גלישה ומחכה שעות כי הקליטה לא משהו בשביל אותו פינוק. ובשעות האלה אפשר לשאול - למה דווקא אפליקציה? הרי QR Code שמפנה לדף תשלום היה עובד הרבה יותר טוב. פשוט מדביקים את הקוד ליד השלט של איזיפארק, מזינים בטופס מספר רכב ומספר כרטיס אשראי ומשלמים.
ואנחנו הרי יודעים את התשובה- אפליקציה כי ככה כולם עושים, אפליקציה כי כבר יש לנו אחת, אפליקציה כי צריך לאסוף מידע על המשתמשים וזה יותר קל אחרי שהם נרשמים. אפליקציה, אפליקציה כי זה מה שאנחנו מכירים.
התפקיד שלנו כמפתחים הוא לחשוב מחוץ לקופסא. לחשוב על הבחירה הטכנולוגית השונה שיכולה להפוך את כל החוויה. לא קל אבל שווה את ההשקעה.
ילד קטן מנסה להרכיב פאזל שגדול עליו, מתעצבן וזורק את כל החלקים לכל הכיוונים. ואתה רואה את זה ולא מבין - למה רגש כל כך חשוב כמו תסכול צריך להיות משהו שגורם לנו להרגיש כל כך רע.
הדחף לזרוק את החלקים לכל כיוון לא עובר עם הגיל. גם מבוגרים מרגישים תסכול והרבה מאיתנו יתאמצו מאוד כדי להימנע ממנו.
ודווקא בגלל זה חשוב להגיד - התסכול הוא הרגש הכי חשוב של מי שרוצה ללמוד דברים חדשים. תסכול הוא מה שקורה לרצון ללמוד כשהוא פוגש את המציאות: אנחנו מתחילים עם איזה חלום גדול של איך העולם יראה אחרי שנדע לכתוב אפליקציות לטלפונים ואיזה אפליקציה מטורפת נכתוב, ואז כשהחלום הזה נשבר מול חופי המציאות התוצאה היא תסכול גדול. וזה מעולה, כי מהתסכול נולד חלום חדש, יותר מציאותי, שגם הוא יישבר וכך בסידרה של תסכולים ושיפורים אנחנו מצליחים ללמוד מיומנות חדשה.
אז כן תזרקו בשמחה את כל החלקים של הפאזל לכל הכיוונים, תשברו את הגיטרה (או את מסך המחשב). ואז תקחו אוויר, תאספו הכל ותנסו שוב. זאת בדיוק הדרך.