ToCode

# כמה גבולות שיעזרו לכם להתקדם אחת הדרכים הכי טובות להשתפר במשהו היא להצר את הגבולות, וכשהמשהו שאנחנו רוצים להשתפר בו הוא כתיבת קוד יש כמה תבניות קלות שאפשר לאמץ: 1. הגבול הכי קל לאימוץ הוא מגבלת זמן. קחו לכם שעתיים בשבוע כדי ללמוד משהו חדש או לבנות משהו קטן לעצמכם, ושחקו את המשחק הבא - מחליטים מראש מה בונים, יושבים שעתיים ומנסים לבנות את מה שתכננו. אפשר לתת לעצמכם מדבקה אם הצלחתם. בהתחלה זה קשה אבל לאט לאט, שבוע אחרי שבוע, תגלו שאתם משתפרים בזה. 2. גבול נוסף ששווה לנסות הוא אימוץ שיטות עבודה טובות יותר. אני מוצא שאני כותב קוד טוב יותר אם אני מכריח את עצמי להוסיף בדיקה לכל באג שאני מתקן. בהתחלה לא ידעתי איפה להתחיל לכתוב את הבדיקות האלה, אבל לאט לאט תקלה אחרי תקלה זה נהיה יותר קל. 3. הצעה שלישית ואחרונה להיום היא ליצור לעצמכם מגבלה טכנולוגית או מגבלת ביצועים, מעבר למגבלות שהעולם כופה עליכם. דוגמא טובה היא תקציב ביצועים שאתרים רבים מאמצים, שאומר שאנחנו מחליטים שהאתר אמור להיטען ל-80% מהמשתמשים בשתי שניות או פחות. הניסיון להישאר בתוך הגבול הזה ילמד אתכם הרבה על זמני טעינת אתר, מה משפיע על זמן הטעינה ואיך לשפר אותו. השיטה עובדת כי העבודה בתוך מסגרת כללים נוקשה מכריחה אותנו להיות יצירתיים ולמצוא פיתרונות ושיטות עבודה שבאופן רגיל לא היינו מתאמצים למצוא. זה לא קורה ביום אחד, אבל אם אתם מוכנים לתת לניסוי הזה שלושה או ארבעה חודשים אני בטוח שתופתעו לטובה מהתוצאות.

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

# איפה החלק המתסכל? בכל טכנולוגיה חדשה שאת באה ללמוד יהיה קטע מתסכל. לפעמים זה יהיה בהתחלה, לפעמים באמצע ולפעמים צריך ממש להתאמץ בשביל להגיע אליו. ובשביל ללמוד טכנולוגיות חדשות מהר יותר מכל האחרים הטריק הכי טוב הוא לחפש כמו משוגעים את החלק המתסכל. מתכנתת שעוברת מ Python ל Go תצטרך לעבוד ממש קשה אפילו בשביל תוכנית Hello World פשוטה. בגו אין מנהל חבילות, אנחנו צריכים לקמפל את התוכניות שלנו, צריך לחשוב על Types בכל צעד ועוד לא אמרנו מילה על ה Class-ים שנעלמו. לעומתה מתכנת שעובר מ Java ל Python יוכל לקלוט את העניין ולהתחיל לפתור בעיות בפייתון תוך כמה שעות. הרבה מהמבנים המוכרים מ Java עובדים כמעט כמו שהם גם ב Python. החלק המתסכל של פייתון מגיע הרבה אחרי התוכניות הראשונות, כשאנחנו באים לבנות תוכניות גדולות ומגלים ששפה דינמית מכריחה אותנו לחשוב אחרת, שה Design Patterns שלמדנו כבר לא ממש רלוונטים וצריך שיטות עבודה ותבניות קידוד אחרות. הרבה פעמים אנחנו מתבלבלים וחושבים שמשהו הוא "קל ללמידה" אם החלק המתסכל שלו מגיע ממש מאוחר בתהליך הלימוד (אנגולר היתה דוגמא מושלמת לטכנולוגיה כזאת, אבל לדעתי גם גיט ופייתון נופלות בבור הזה). אבל האמת הכואבת היא שאם לא דפקתם את הראש בקיר כמה שבועות זה פשוט אומר שעוד לא עשיתם את הלמידה האמיתית.

# פרק חדש בקורס Node.JS - עבודה עם ספריית Sequelize הדרך המרכזית היום לעבודה עם בסיסי נתונים מבוססי SQL מתוך קוד נקראת ORM, שזה קיצור ל Object Relational Mapping. בעברית זה אומר שבמקום לכתוב קוד SQL אנחנו הולכים לכתוב קוד רגיל לגמרי שמשתמש במחלקות ואוביקטים, וספרית ה ORM תתרגם את הקוד שכתבנו לשאילתות SQL יעילות יותר ממה שאנחנו היינו כותבים. הספריה Sequelize של Node.JS היא ספריית ORM ל Node, שבעצם מנהלת בשבילנו את כל העבודה עם בסיס הנתונים, כולל כמובן יצירת השאילתות, אבל גם יצירת מידע ראשוני בבסיס הנתונים, יצירת הטבלאות וניהול גירסאות עליהן, ניהול החיבור לבסיס הנתונים ותמיכה בבסיסי נתונים שונים למטרות שונות (פיתוח, ייצור ובדיקות). מה שאהבתי במיוחד בספריה זה השילוב בין גמישות להיקף: הספריה נותנת פיתרון מקצה לקצה למערכת Node שצריכה לעבוד עם בסיס נתונים מבוסס SQL, אבל אם כבר יש לכם בסיס נתונים שמנוהל בשיטה אחרת הכל טוב ותוכלו להשתמש רק בחלקים מתוך Sequelize ולהתאים אותם לעבוד עם כל בסיס נתונים. בקיצור אחרי שעפתי על הספריה הזאת חשבתי לשתף את מה שלמדתי גם אתכם וכך נוסף פרק חדש לקורס Node.JS שעוסק ב Sequelize ובעבודה איתו. הפרק כולל 8 שיעורים ודף תרגול באורך כולל של כמעט שעתיים וידאו, במהלכם אני מדגים בניה של שני פרויקטים, כולל כתיבת בדיקות יחידה עם Mocha וחיבור ל API עם Express. אם אתם כבר מנויים יכולים פשוט ללכת לצפות בסידרה החדשה מתוך דף הקורס כאן: https://www.tocode.co.il/bundles/nodejs ואם עדיין לא אז כמו שאומרים הקיץ הוא זמן מצוין לעשות מנוי, וקורס Node.JS הוא לדעתי אחד הקורסים הטובים באתר אז שווה להתחיל ממנו את הלימוד.

# אין מפה אחת האנלוגיות שאני אוהב לגבי למידה היא האנלוגיה בין קורס למסלול הליכה - בשני המקרים אנחנו מתחילים בנקודה מסוימת, מתקדמים לפי המסלול ומסיימים בנקודה אחרת. בן אדם לא יודע לשחות, הולך לחוג שחיה, לומד שם את התנועות ומתאמן עד שבסוף מצליח לשחות. מפה לשם. וכמו שאנחנו מדמיינים במסלול הליכה את נקודות העניין המרכזיות וכמה זמן כל קטע בדרך הולך לקחת, כך אפשר לדמיין בקורס את ההישגים הנדרשים וכמה זמן ייקח להגיע מאיפה שאתה נמצא להישג הבא, ומה צריך ללמד בשביל שזה יקרה. אבל יש שתי בעיות ברורות עם האנלוגיה הזאת: 1. מסלול הליכה רגלי מרגיש פחות או יותר אותו דבר לכל אחד שעובר בו. "מסלול הליכה" לימודי הוא משחק אחר לגמרי. מה שאחת מצליחה ללמוד בשבוע ייקח לאחרת חודש וחצי. 2. ויותר גרוע, אופן הלימוד עצמו שונה בין אנשים שונים. הסבר שיהיה הגיוני ויעזור לתלמידה אחת להתקדם לא ידבר בכלל לתלמידה אחרת, שתצטרך המחשות אחרות, דוגמאות אחרות והסברים אחרים בשביל לעבור את אותה הדרך. כן כדאי להכיר את נקודות העניין המרכזיות על המסלול: כדאי להבין שכשאתם באים ללמוד פיתוח Front End תצטרכו להיות מסוגלים לבנות דף נחיתה פשוט, להתאים אותו למובייל, לבנות אתר עם מספר דפים שרץ על שרת מקומי, להפוך אותו ל Single Page Application על השרת המקומי, להבין איך עובד Ajax ולהוסיף מידע דינמי שמגיע מצד השרת. זה מסלול. אבל אין מפה ספציפית שתביא אתכם מנקודה לנקודה. אנחנו יוצאים לדרך עם תרמיל והבנה בגדול של היעד הבא, ומבינים שכל אחד יגיע לשם בדרך קצת אחרת.

# תיקונים פחות קריטיים הרבה פעמים בעבודה על מערכת אנחנו רואים משהו שבור אבל שאינו דחוף - סוג של שיפור קטן שאנחנו יודעים שיעזור למשתמשים, ובדיוק כשכמעט מתישבים לפתור את זה באותו רגע מתחילות המחשבות: 1. איך אני מבזבז זמן על תיקון כזה כשיש כל כך הרבה באגים קריטיים לפתור? 2. מה יגיד הראש צוות? המנהל מוצר? הבוס? 3. ומה אם התיקון שלי יכניס מלא באגים חדשים? 4. עדיף להכניס את המשימה לתוכנית עבודה ולהתמודד איתה בצורה מסודרת. וזה נכון הרבה פעמים כשיש לכם צוות גדול ומנגנון טוב. אבל בהרבה צוותים זה לא ממש המצב - תיקונים פחות קריטיים יכולים לשבת בתוכנית עבודה חודשים ואף אחד לא מגיע אליהם, כי תמיד יש משהו יותר גדול. כשדברים קטנים נקברים ונעלמים שווה לנסות לשנות גישה ולקחת יותר אחריות כמתכנתים. נתקלים במשהו קטן שיכולים לסדר בשעה? נסו לסדר את זה בשעה באותו רגע. לא הספקתם? אפשר להשאיר ענף פתוח בגיט ולהמשיך מחר. שעה ביום לתיקונים קטנים זה משהו שכמעט תמיד אפשר למצוא וכמעט תמיד יהיה שווה את המאמץ.

# חודש לתיק עבודות... צא חודש זה זמן ממש קצר לבנות מערכת אבל אם כן מספיק לבנות חלקים ממנה, להתממשק עם מערכות קיימות או לחבר כמה דברים למשהו שנראה נחמד יחד. אז אם אין לכם עדיין תוכניות לקיץ הנה כמה רעיונות שתוכלו לבנות בחודש הקרוב: ## אפליקציית מובייל Cross Platform הטכנלוגיה הכי מדליקה היום נקראת Flutter והיא הדרך לבנות יישומי מובייל יפים וחוצים פלטפורמות. פלאטר מפותחת בגוגל, מציעה פיתרון ליישומי מובייל שעובדים גם בתור אפליקציות וגם מתוך דפדפן, וממה שמספרים היא הרבה יותר נוחה מ React Native. לי עדיין לא יצא לשחק איתה אבל אם היה לי סידור טוב לילדים החודש זו כנראה היתה האופציה המועדפת עליי כדי להעביר את החום. מה בונים? הטריק עם אפליקציות מובייל הוא שזה לא כזה משנה. אם מה שחשוב לכם זה חיזוק תיק העבודות, הכי קל זה לבחור אפליקציה שאתם אוהבים ולבנות גירסא שלכם. אם משתמשים ב API של האפליקציה המקורית החיים בכלל הופכים קלים. ## מערכת בדיקות אוטומטיות לאתר קיים מחפשים הזדמנות להשתפשף עם פייתון וסלניום? למה שלא תלכו לבנות 8-10 בדיקות אוטומטיות לאתר קיים? כל מה שצריך זה למצוא אתר שאתם אוהבים ולצאת לדרך. ## בוט לטלגרם שמוצא טיסות זולות בוטים לטלגרם הולכים לשנות את העולם יום אחד (או שאולי זה ממשקים קוליים, קשה לדעת). בכל מקרה ממילא חם וממילא יש לכם חודש פנוי אז אפשר לשחק עם הטכנולוגיה ואם במקרה כולם יתעוררו בספטמבר וירצו בוט לטלגרם לפחות יהיה לכם בוט להראות. אז כן לסקייסקאנר יש API ואתם יכולים בשתי לחיצות להתחבר אליו דרך בקשות HTTP רגילות מתוך הבוט שלכם. בוטים לטלגרם אפשר לכתוב היום כמעט בכל שפה ואתם יכולים לחפש פה בבלוג או סתם בגוגל דוגמאות קוד לבוטים בכל שפה שתרצו ללמוד. ## לפתור את Advent Of Code בשפה שאתם לא מכירים פיתרון של Advent Of Code אולי לא יחזק לכם את תיק העבודות אבל בהחלט יחזק את הידע שלכם בתכנות ויעזור לכם לעבור ראיונות עבודה בנושאי אלגוריתמים, מבני נתונים, רקורסיות ושאר פינוקים שמראיינים אוהבים. מאז 2015 אריק ווסטל מפרסם 24 חידות כל שנה. לנו יש חודש אז תוכלו לבחור שנה שעדיין לא עשיתם ולפתור חידה כל יום. ## ממשק קולי לאלקסה שיוכל להזכיר לילדים להכין שיעורי בית ממשקים קוליים הולכים לשנות את העולם (או שאולי זה בוטים לטלגרם, קשה לדעת). בכל מקרה ממילא חם וממילא יש לכם חודש פנוי אז אפשר לשחק עם הטכנולוגיה ואם במקרה כולם יתעוררו בספטמבר וירצו ממשק קולי לפחות יהיה לכם אחד להראות (או להשמיע). לאלקסה יש API והמון טוטוריאלס והכל מתחיל בקישור הזה: https://developer.amazon.com/en-US/alexa/alexa-skills-kit/tutorials הקוד הוא ב JavaScript ועם קצת מזל תספיקו לבנות ממשק קולי שיעזור להזכיר לילדים להכין שיעורי בית ויהיה מוכן בדיוק לתחילת שנת הלימודים. ## עכשיו אתם רעיונות נוספים? טכנולוגיות אחרות שהייתם רוצים לשחק איתן? מוזמנים לשתף בתגובות, וכמה שיותר מפורט יותר טוב.

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

# אתה לא הקוד שלך באחד הגלגולים הקודמים שלי כמתכנת מאוד אהבתי שפת תכנות שנקראת perl. חשבתי שיש לה קסם שלא ראיתי באף שפה לפני, כתבתי בפרל כל מה שרק יכלתי וכמובן שהלכתי למיטאפים להכיר את ה-9 מעריצי פרל האחרים בארץ. ללקוחות ששאלו אם אני יכול להציע קורס פייתון עניתי בזלזול שאין שום הגיון ללמוד פייתון כשהם יכולים לכתוב קוד הרבה יותר יפה ב perl, ושאני יכול להציע להם יופי של קורס פרל. נאחזתי בפרל כמו שלאונרדו די קפריו נאחז בדלת בסרט טיטאניק וכמעט שקעתי כמוהו יחד איתה, עד שבהתקף של היגיון התחלתי לקחת פרויקטים בפיתוח Python. מיותר לציין שלא הסתכלתי אחורה. הבחירה לעזוב את הקוד הישן, על כל הכלים שכבר כתבתם והידע שכבר צברתם היא אף פעם לא קלה. זה הבסיס לאינספור Flame Wars שאנחנו מכירים: ג'אווה או סי שארפ, וים או אימקס, אנגולר או ריאקט. מרגע שבחרת צד צריך משבר רציני בשביל להזיז אותך, ומשברים כמו שקרו לפרל לא מגיעים כל יום. ודווקא בגלל זה הבחירה להחליף היא חשובה. ככל שניפתח למערכות נוספות, לשיטות קידוד אחרות ולתרבויות אחרות כך לאורך השנים נוכל לאסוף את הטוב מכל העולמות ולכתוב את הקוד שבאמת הכי מתאים עבורנו.