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

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

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

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

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

ולמרות שביום רגיל אני תמיד בעד להקשיב לרגשות, בסיפור הזה הרגש לא עוזר. במקום זה, שווה לנסות להוסיף את המילה "עדיין":

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

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

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

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

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

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

מה שמפתה ב"איך" זה שאפשר לקבל תשובה קצרה ובסופה להרגיש שהתקדמנו: הוספנו מנגנון זיהוי משתמשים ליישום, סידרנו את הבראנצ'ים, קיבלנו תשובה מבסיס הנתונים. ל"מה" אין את הקסם הזה.

ועדיין קשה להתעלם מהחשיבות של "מה" - מה זה בעצם OAuth והאם אני בכלל צריך אותו? איזה Grant Types קיימים? ואיזה מהם אני צריך? מה זה בראנץ ומה זה בכלל אומר להעתיק קובץ מבראנץ אחד לשני? איזה בסיס נתונים יעבוד הכי טוב עם המערכת שלי ועם עולם התוכן שאני צריך לשמור?

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

לכלים יש השפעה דרמטית על הפרודוקטיביות שלנו. הם יכולים להפוך אותנו לפי 10 יותר מהירים או פי 10 יותר איטיים.

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

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

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

כלים כמו WSL ו Docker מאפשרים לנו להריץ Shell Scripts של יוניקס על מכונת ווינדוס, אבל הבדל אחד בין מערכות ההפעלה עלול לקלקל את המסיבה, וזהו תו סוף שורה.

ב Unix תו סוף שורה הוא \n. ב Windows זה \r\n. ולכן סקריפט שאני כותב למשל ב Notepad ואנסה להריץ ב WSL ייכשל עם הודעת שגיאה בסגנון הבא:

-bash: ./test.sh: /bin/bash^M: bad interpreter: no such file or directory

עם כל זה אנחנו יכולים לחיות בקלות ופשוט לא לכתוב Shell Scripts ב notepad, אבל מה קורה כשכלי שאנחנו כן צריכים מחליט לשנות את תווי סוף השורה בסקריפטים שמישהו אחר כתב?

הכלי שאני מדבר עליו הוא גיט.

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

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

*.sh        text eol=lf

אפשר לשנות את התבנית של הסקריפטים שתתאים לשמות הקבצים שלכם או להוסיף נתיב לסקריפטים ספציפיים, או לכתוב כמה שורות אם יש לכם כמה סוגים של קבצים שלא תרצו לשנות להם את הסיומת.

למידע נוסף על gitattributes וכל הדברים שתוכלו לכתוב בו שווה לבקר בספר בקישור: https://www.git-scm.com/docs/gitattributes

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

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

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

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

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

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

מצד אחד בשביל להיות מפתחי מובייל טובים צריך ללמוד המון: רצוי להכיר לעומק את כלי הפיתוח XCode ו Android Studio ואת השפות Kotlin ו Swift איתן כותבים קוד נייטיבי. ריאקט נייטיב מאפשר לדלג על כל זה ופשוט לכתוב אפליקציות, ואז ללמוד את הכלים היותר מתקדמים כשעולה הצורך.

תהליך העבודה מזכיר את מה שהיה פעם Phonegap, אבל התוצאה שונה לגמרי. במקום לבנות קוד וובי שרץ בתוך דפדפן מוטמע, ריאקט נייטיב ממש הופך את הקוד שאנחנו כותבים לאפליקציה טבעית בפלטפורמה המשתמשת בפקדים הטבעיים של מערכת ההפעלה. כלומר כשאני כותב Text או Button אני לא מקבל אלמנטי span או button מ HTML, אלא את רכיבי הטקסט והכפתור של הטלפון.

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

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

אם אתם כבר מנויים מוזמנים להיכנס לקורס ריאקט ולגלול לסוף הקורס בשביל הפרק החדש: https://www.tocode.co.il/bundles/react

אם אתם עדיין לא מנויים אז גם היום הוא יום טוב להירשם: https://www.tocode.co.il/quickjoin

ולינק אחרון לסיום - בתחילת ספטמבר אעביר כאן וובינר עם עיקרי הדברים על ריאקט נייטיב ואפשרות לשאול שאלות. הכניסה חינם וצריך רק להירשם בקישור: https://www.tocode.co.il/workshops/118

רשימה חלקית של דברים שמתיישנים במערכת שלנו, למרות שממש לא נגענו בהם:

1. בדיקות - רק נסו להריץ בדיקות אחרי כמה חודשים בלי הרצה.

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

3. קוד תשתית סופר גנרי - כי הדרישות מהמערכת השתנו בחמש שנים האחרונות, ואותו קוד תשתית גנרי עכשיו רק מעכב אתכם.

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

5. כלי עבודה - נו, חוץ מ vim.

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

לא צריך יותר מכמה דקות ביוטיוב כדי להיתקל בסרטים שמכילים את המילים Full Course: סרטים של שעתיים, שלוש ואפילו 8 שעות על טכנולוגיה מסוימת, בה מרצה בדרך כלל נחמד מספר ומספר על הטכנולוגיה, ואפילו בונה פרויקטים לדוגמה וכמובן הכל מצולם ומסודר. פה למשל יש מדריך פייתון של 4 שעות עם 35 מיליון צפיות: https://www.youtube.com/watch?v=rfscVS0vtbw

קשה להתווכח עם 35 מיליון אנשים, ובכל זאת אם אתם שוקלים ללמוד דרך וידאו הנה כמה טיפים שעוזרים לי להישאר מרוכז:

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

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

3. סכמו לעצמכם את הנקודות המרכזיות בוידאו תוך כדי צפיה, ברמה של כל 2-3 דקות לעצור ולכתוב מה קרה שם.

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

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

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

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

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

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

הנה שבעה פרויקטים שאתם יכולים להתאמן עליהם בכל אחת משתי השיטות:

1. משחק סנייק

2. משחק טטריס

3. בלוג

4. צ'ט מיידי מרובה משתמשים

5. שידור וידאו "חי" עם הערות מהצופים

6. ניהול כספים אישי

7. משגר משימות (בסנון הזה)

צוותים שעובדים ב Agile רגילים להשתמש בקוד בתור הדרך "לגלות" את הבעיה או מה הלקוח רוצה. בין שנים עשר העקרונות האג'יליים השניים האלה מעבירים את המסר:

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

2. תוכנה עובדת היא המדד העיקרי להתקדמות.

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

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

אבל הבעיה שאנחנו לא חיים בספרינט בודד.

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

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

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

2. תשומת לב מתמשכת למצויינות טכנית ועיצוב ותכנון נכון מגדילים את היכולת האג'ילית.

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