טיפים קצרים וחדשות למתכנתים
בשעור הראשון בקורס בדיקות יחידה אני כבר מגלה לכולם את הסוד לבדיקות טובות: כשהקוד טוב קל מאוד לכתוב עבורו בדיקות.
אבל מה אם צריך לבדוק קוד שיכול להיות גרוע? או שממש לא נועד לרוץ תחת המיקרוסקופ של בדיקות? קחו לדוגמא פתרונות תרגילים בקורסים.
השבוע הוספתי בדיקות אוטומטיות לפתרונות שתלמידים מגישים בקורס Python, ואלה שני הטריקים שעזרו לי בדרך.
ללמוד טכנולוגיה חדשה? מה הבעיה? פותחים גוגל, קוראים מה שצריך ומתחילים לכתוב קוד. מה, אתה לא יודע לחפש בגוגל?
לו רק החיים היו כל כך פשוטים.
כשהתחלתי להקליט את מדריכי הוידאו לאתר הזה חיפשתי כמה שיותר חומר על איך להקליט מדריכי וידאו באיכות גבוהה. ניסיתי ללמוד כמה שיכולתי על סאונד, תסריט, אפקטים וכל מה שצריך בשביל שהקורסים יצאו מעניינים. אפילו קניתי מיקרופון ותוכנות יקרות. ועדיין התחושה היתה שמשהו לא עובד, אבל לא הצלחתי להבין מה בדיוק. עד שפגשתי את רוב.
לפרל יש 3 ספריות פיתוח ווב: הראשונה נקראת Catalyst והיא ממש מסובכת ומהונדסת יתר על המידה. השניה נקראת Dancer והיא דוקא מאוד פשוטה אבל עדיין לא ממש יציבה, והשלישית נקראת מוג'ולישס, ולמרות השם המוזר היא דוקא די פשוטה. בואו נראה כמה דרך דוגמא קצרה.
חיפוש קצר ברשת יביא אתכם לעשרות מאמרים שיעזרו לכם לכתוב תוכנית ריאקט ראשונה בשבוע, שעה ואפילו בעשר דקות. אבל כמובן שאחרי שלמדתם עשר דקות או אפילו שבוע, זה עדיין רחוק מהידע הנדרש לכתיבת יישום מלא בעצמכם, וגרוע מכך, בנסיון לכתוב יישום מלא לפני שיש לכם את הידע אתם עלולים לעשות טעויות שייקח הרבה זמן לתקן.
בואו ננסה הפעם משהו אחר, במקום ללמוד ריאקט בעשר דקות קבלו תוכנית איך ללמוד ריאקט בחודש וחצי (או אפילו קצת יותר). אזהרה: הפוסט לרציניים בלבד.
תחום פיתוח Front End הוא היום אחד החמים בתעשיה והדרישה לעובדים בשמים. יחד עם זאת, מתכנתים רבים שנכנסים לתחום מתוך תקוה למצוא עבודה חדשה מגלים שהחיפוש קשה ולמרות המחסור המגייסים בררנים.
אנסה להסביר כאן את המניעים לבררנות, ולתת טיפים איך להתבלט וכן להשתלב בעבודה.
יש בעיה עם דוגמאות Hello World כשמדברים על ספריות קוד- הן פשוטות מדי ולא מצליחות להציג את היתרונות של ספריות מורכבות. ריאקט למשל כמעט תמיד תראה מסובכת יותר מ jQuery בדוגמאות פשוטות. לשמחתנו מדי פעם עולה דוגמא קצת פחות פשוטה אבל שעדיין נכנסת ב 50 שורות קוד שמראה את היתרונות.
טרנד חדש במקומות עבודה הוא לחייב את המועמד לכתוב ולהגיש מיני-פרויקט (יומיים-שלושה עבודה) כדי לראות שהבן אדם יודע לכתוב קוד. בעיניי זה מוזר לבקש מאנשים לעבוד בחינם כחלק מתהליך הראיון, אבל נשים את זה בצד רגע. יותר מעניין לחשוב איפה לשים דגש כדי שהקוד שלכם יעבור את הסינון.
בעוד שאת התחביר של JavaScript יחסית קל ללמוד, פיתוח ארכיטקטורה ליישומי צד-לקוח היא משימה יותר מורכבת. הסביבה אינה מגדירה ארכיטקטורה סטנדרטית ל״אפליקציית ווב״ (ובכלל, מהי אפליקציית ווב), והפיתוחים ביכולות הדפדפנים ובשפה עצמה יצרו דרכים שונות לכתוב קוד צד-לקוח לאורך השנים.
אני חושב שזו אחת הסיבות לפופולריות של Frameworks ולחיפוש אחר ספריה אחת שתתן תשובה לכל השאלות. החיפוש אחר הדרך הנכונה לפתור בעיה ב Angular, React, Redux או Durandal הוא בעצם חיפוש אחר ארכיטקטורה לאפליקציה שלנו. לכן ולפני שמתחילים לכתוב יישום צד-לקוח גדול, כדאי להתעמק קצת יותר ברעיונות ובארכיטקטורה שאותן Frameworks מתבססות עליה.
מחיר זה נקודה קשה לכולם- הצעה נמוכה מדי תשלח אתכם לעבוד בשביל פרוטות והצעה גבוהה מדי עלולה לחסל את העסקה ולהחזיר אתכם ללשכת התעסוקה. אבל יש מיתוס אחד שחוזר כמעט אצל כל פרילאנסר שאני מדבר אתו על הנושא שפשוט מפריע לכם למכור.
ראש השנה הוא הזדמנות טובה להסתכל קדימה ולדמיין איך נראה בשנה הבאה, במקרה של ToCode איזה קורסים יהיו כאן עוד שנה. אלה התוכניות שלי, אשמח לשמוע מה דעתכם ואם יש קורסים נוספים שהייתם רוצים לראות שאינם ברשימה.