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

מה החלק הכי אפקטיבי של היום שלכם? ואיך אתם מנצלים אותו?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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