טיפים קצרים וחדשות למתכנתים
אז החלטתם להתקין שרת לינוקס בענן שיהיה לכם לחבר. ברכותיי. בואו נראה איך מתחילים, איך מתקדמים וגם לאן ממשיכים אחרי. הפוסט הזה מלווה את הוובינר שאעביר מחר באותו נושא ואם אתם קוראים את זה בזמן מוזמנים להצטרף בקישור:
המרחק מכדור הארץ לירח הוא 384 אלף קילומטר, אבל עיקר האנרגיה שתצטרכו כדי לעבור אותו תבוזבז ב 100 ק"מ הראשונים עד שתצאו מהאטמוספירה. אחרי זה שאר ה 383,900 ק"מ עוברים חלק.
והסיפור דומה גם כשלומדים מיומנות חדשה או כשכותבים מערכת.
בהתחלה הכל נראה קשה ולא רואים התקדמות כלל. רק אחרי המון השקעה דברים מתחילים לרוץ ואז מתחיל המסע הארוך האמיתי - ה 384,900 ק"מ, שלושה ימים של לשבת בחללית ולתהות אם אתה בכיוון הנכון ואם נחיתה על הירח שווה את זה.
אז כן זה לוקח המון עבודה בהתחלה רק כדי להיכנס למסלול ואז עוד המון עבודה והמון זמן כדי להתקדם בו. אבל הי - זאת הדרך היחידה להגיע לירח (או לכל מקום אחר שאתם רוצים להגיע אליו).
הצעד הראשון בדרך להפוך למתכנת Full Stack הוא להבין איך להביא את התוכנה שלכם ממחשב הפיתוח למשתמשים. כשמדובר ביישום Web זה אומר לדעת איך להתקין שרת, לחבר אותו לדומיין, להתקין nginx או apache ולחבר את כל החוטים כדי שהיישום שלכם יעבוד מול העולם החיצון.
אחרי זה אפשר לשפר זה ברור: אפשר ללמוד Docker ולעבור להפיץ את היישום שלכם כ Container. אפשר ללמוד יותר לעומק איזה אינדקסים ליצור בבסיס הנתונים ואיך הם משפיעים על המערכת. אפשר ללמוד אבטחת מידע ולנסות לפרוץ לשרת של עצמכם. אבל אין ספק שהצעד הראשון הוא להיות מסוגלים להביא את התוכנית שלכם למשתמשים.
ואם עד עכשיו דחיתם את הצעד הזה מוזמנים להצטרף ביום חמישי לוובינר השבועי בו אציג איך לבנות מכונת Production ליישום Flask ולהתקין את כל הכלים על המכונה ולחבר לדומיין כך שבסוף יהיה לנו Web Application עובד באינטרנט. זה ייקח פחות משעה ובסוף יהיו לכם את כל הכלים והידע לעשות את זה לבד על המערכת שלכם.
רוצים לבוא? הרשמה בקישור:
גם אם אתה יודע לדקלם מתוך שינה את כל תרשימי ה UML של תבנית העיצוב Observer זה לא אומר שתדע להשתמש בה.
הסוד בלדעת Design Patterns (כמו גם הרבה מיומנויות אחרות) הוא לדעת איך ליישם אותם בעולם האמיתי: מתי להשתמש, מתי לא להשתמש ומתי לבנות משהו דומה על בסיס אותו עיקרון.
במקום לשנן תיאוריה הרבה יותר משתלם להשתמש ביכולת החדשה שלמדתם בהקשרים שונים ובמערכות שונות בעולם האמיתי. כן תוסיפו למערכת שלכם פיצ'ר חדש המבוסס על פיירבייס, או vue, או לא משנה מה. רק אחרי שתעשו את זה מספיק פעמים נוכל להגיד שלמדנו את זה.
נ.ב. ערבוב טכנולוגיות בפרויקט זה משהו שקורה די הרבה בחיים האמיתיים. לא תמיד זה טוב אבל זה כן נותן למתכנתים הזדמנות ללמוד הרבה טכנולוגיות. בקישור הבא מהנדס לשעבר בספוטיפיי מדבר על עירוב הטכנולוגיות המטורף שהיה אצלם:
זוכרים את הסצנה מהנסיכה הקסומה שאיניגו אומר לויזיני שהוא משתמש במילה בלי להבין אותה? אז ככה הרבה מתכנתים עם המילה פולימורפיזם. נשים את ההגדרות האקדמיות בצד ובואו נראה למה זה חשוב ומה המשמעות שלה בעולם האמיתי.
אבל שניה קודם איניגו
זה בסדר לא לדעת שאלה בראיון עבודה. באמת. אבל אם אתם ניגשים לראיון ושואלים אתכם שאלה שאתם לא יודעים תעשו לעצמכם ולמראיין טובה ואל תנסו למכור לוקשים:
זה לא בסדר להגיד שזו שאלה יותר ... אקדמית- גם אם היא היתה אקדמית אם שאלו אתכם משהו בראיון עבודה זה אומר שהמראיין חושב שהשאלה חשובה לתפקיד.
וזה לא הגיוני להגיד שככה כולם עושים- אנחנו יודעים את זה. בדיוק בגלל זה שאלנו למה.
מה שאני הייתי עונה: "אני לא יודע למה צריך XYZ. האמת שבכל הפרויקטים שהשתתפתי בהם כתבתי בשיטה הזו ועד עכשיו לא חשבתי על זה יותר מדי לעומק. מיד בתום הראיון אלך לקרוא על זה. רוצה לנסות עוד כמה שאלות שאותן כן אכיר?"
אף אחד לא יודע הכל וברור שאפשר למצוא דברים שאתם לא מכירים, וגם דברים שאתם משתמשים בהם ולא מבינים עד הסוף. לכל אחד יש כאלה. אבל אם נהיה הוגנים ופתוחים לגבי זה יהיה הרבה יותר קל לבחון אתכם לפי מה שאתם כן יודעים.
היא לשנות את החיים כך שהדבר החדש הזה הוא משהו שנשתמש בו כל יום.
בגלל זה אנשים מחפשים עבודה: כי המחשבה אומרת שאם רק אצליח להתקבל לעבודה כ Front End Developer אז ממילא אצטרך לכתוב קוד Front End כל היום וכך אדע את זה.
ובגלל זה אנשים שטסים למקומות רחוקים לומדים את השפה יותר טוב מאשר מי ששומע קלטת לפי השינה.
האתגר הוא להבין איך לשנות את החיים ולשלב את הדבר החדש בלי שנצטרך להחליף ארץ או עבודה.
מחר אעביר וובינר על שיפור ביצועים בריאקט. אלה הדברים ודוגמאות הקוד שאדבר עליהם. אם אתם פנויים מחר בעשר מוזמנים להצטרף ולצפות לייב. הרשמה בחינם בקישור:
אפליקציית האייפון הראשונה שכתבתי היתה די גרועה: לא רק מבחינת מה שהיא עשתה (זה לא היה הרבה) אלא גם מבחינת הקוד שלה ואיך היא עשתה דברים. 3 אפליקציות מאוחר יותר וכבר ידעתי לכתוב אפליקציות אייפון די טוב. ולא בטוח שזה היה לטובתי.
כי כשהגיע אנדרואיד במקום ללמוד Java ולכתוב אפליקציות נייטיב בסביבה זו התחלתי לחפש פיתרונות Cross Platform. המחשבה היתה שאני כבר יודע לכתוב לאייפון וחבל לזרוק את הידע הזה. חשבתי- אם רק היה אפשר לכתוב לאנדרואיד כמו שכותבים לאייפון הכל יהיה בסדר, כי את האייפון אני כבר מכיר.
כשאנחנו מכירים דרך מסוימת לפתור בעיות קשה לחפש דרכים אחרות להתמודד גם אם ברור שיש דרכים הרבה יותר טובות.
במובן מסוים למישהו שלא יודע כלום על פיתוח אפליקציות יהיה יותר קל ללמוד Android מאשר למישהו שיודע לפתח טוב לאייפון. כי כשאפשר להשתמש בכלים שאני כבר מכיר בשביל לפתור בעיות סיכוי טוב שזה מה שיקרה.
עכשיו השאלה: האם אני מוכן להיות שוב גרוע בזה? האם אני מוכן להתחיל מההתחלה? והתשובה חייבת להיות חיובית למי שרוצה להישאר בתחום הזה לאורך זמן.
הכי כיף לבקש מאנשים לכתוב תיעוד לקוד שלהם. אפשר לעשות עם זה המון משחקים ולמדוד לכמה אחוז מהפונקציות בקוד יש תיעוד ולהראות גרף יפה של איך אנחנו מתעדים.
ולדעתי זה עדיין לא יגרום לאנשים לכתוב תיעוד. בדיוק כמו שהשלט בתמונה לא גורם לאנשים לנקות אחרי הכלב שלהם.
אנחנו לא כותבים תיעוד כי בתרבות שלנו הרבה יותר חשוב לסיים פיצ'ר עובד ובלי באגים מאשר להשאיר קוד נקי ומתועד, וגם חמישים גרפים שיוקרנו על המסך במסדרון לא ישנו את זה. אנחנו יודעים שתיעוד זה חשוב פשוט מעדיפים להמשיך לבנות עוד פיצ'רים ולתקן עוד באגים בזמן הזה.
אם תיעוד הוא באמת חלק מהותי מה DNA של החברה שלכם כדאי להטמיע מדיניות הרבה יותר נוקשה בנושא. וכן זה אומר לדחות גירסאות אם הקוד לא מתועד טוב בדיוק כמו שהייתם מתנהגים אם היה באג קריטי בגירסא. או שאפשר להמשיך להדביק שלטים על העץ ולקוות.