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

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

אבל העולם לא מוכן לתת לנו את ההזדמנות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ספריית unittest של Python כוללת Decorator בשם patch שתפקידו לעזור לנו לבדוק קוד שיש לו תלויות שקשה לבדוק. במדריך זה נראה מהן תלויות שקשה לבדוק וכמה דוגמאות לשימוש בפקודה patch כדי להתגבר על קושי זה.

לא מזמן חיפשתי בגוגל את הביטוי:

children teach themselves to read

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

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

1. הפחד להישאר מאחור - אם כל החברים שלי יודעים לקרוא אני רוצה גם.

2. הרצון להצליח יותר - אם החברים שלי עדיין לא יודעים לקרוא אני יכול להבין מה שאחרים לא מבינים, אני יכול להיראות יותר חכם מהחברים.

3. כשאני צריך לדעת לקרוא בשביל להשיג משהו אחר - למשל כי לאח הגדול שלי נמאס להקריא לי את מה שכתוב במחשב ועכשיו בשביל להפעיל את המשחק אני צריך לגלות לבד איפה ללחוץ.

רעיונות נוספים? שתפו בשמחה בתגובות

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