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

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

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

וככה אנחנו מקבלים אתרים שכתובים בריאקט, כש HTML פשוט עם קצת JavaScript היה מספיק טוב; מערכות ענן שהיו עובדות הרבה יותר טוב על VPS פשוט או קוד עם כל כך הרבה Design Patterns שאפשר היה לכתוב ממנו ספר.

הבעיה עם Over Engineering היא שהעלות ממשיכה ללוות אותנו בכל שלב בדרך. זה לא שפעם אחת בהתחלה השקעתי יותר מדי ובניתי פיתרון מתוחכם ועכשיו הרווחתי וכל פיתוח עתידי יהיה יותר קל, אלא ממש להיפך - השקעתי בהתחלה בבניית פיתרון יותר מדי מתוחכם, ועכשיו:

1. הרבה יותר קשה לי לשנות את הקוד, בלי לשבור את התבנית המתוחכמת שבניתי בהתחלה.

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

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

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

שתי דוגמאות כאן מטוקוד - כמו שאולי אתם יודעים האתר הזה בנוי בריאקט עם React Router כדי לתת חווית Single Page Application. זה היה נראה כמו רעיון טוב לפני 5 שנים כשלא ידעתי הרבה על בניית אתרים, אבל היום אני כבר יודע לראות שזו היתה הנדסת יתר. בימים אלה אני עובד על גירסה חדשה של האתר, פשוטה בהרבה ובלי פריימוורקים, שנותנת חוויה טובה יותר ותחזוקה הרבה יותר קלה.

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

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

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

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

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

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

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

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

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

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

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

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

כמתכנתים אנחנו תמיד ממהרים לבנות את הדבר הגדול הבא וכמעט תמיד מחפשים את ה"איך" - איך להוסיף 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 ולאיזה מטרות, וגם כאן לרשום הכל.

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