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

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

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

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

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

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

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

<img src="cat.png" />

והופך אותה לשורה שנראית כך:

<img src="cat-1.png" />

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

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

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

/\V\[0-9]\[0-9]

עדיין אפשר להשתמש בקיצור \d כך שגם החיפוש הזה יעבוד:

/\V\d\d

למצב קצת קסום אנחנו נכנסים עם \M בתחילת הביטוי ומצב זה ממש דומה ל"לא קסום בכלל" מלבד התווים ^ ו $ שלא צריכים שתכתבו \\ לפניהם.

למצב קסום אנחנו נכנסים עם \m בתחילת הביטוי. מצב זה מזכיר מאוד את grep ובו רוב הסימנים המיוחדים יעבדו בלי \\ אבל עדיין יהיו מספר סימנים מיוחדים שכן יצטרכו \\ לפניהם לדוגמא +, ? ו {}.

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

בחזרה לדוגמא מתחילת הפוסט הביטוי הראשון שניסיתי לכתוב בוובינר היה:

:s/\vsrc="(\w+)\.(\w+)"/src="\1-1.\2"/

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

התיקון הכי פשוט יהיה להוסיף \\ לפני סימן השווה ואז נקבל את הביטוי הבא שעובד:

:s/\vsrc\="(\w+)\.(\w+)"/src="\1-1.\2"/

אגב עכשיו שזה מאחורינו בואו נראה את הגירסאות המתאימות של הביטוי גם במצבי הקסם האחרים:

:s/\Vsrc="\(\w\+\).\(\w\+\)"/src="\1-1.\2"/
:s/\msrc="\(\w\+\).\(\w\+\)"/src="\1-1.\2"/
:s/\Msrc="\(\w\+\).\(\w\+\)"/src="\1-1.\2"/

למידע נוסף על כל הסימנים וההשפעות של מצבי הקסם ב vim מוזמנים לקרוא בתיעוד כאן:

http://vimdoc.sourceforge.net/htmldoc/pattern.html#pattern

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

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

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

   https://www.tocode.co.il/blog/2015-05-vim-html-image-gallery

3. עוד כלי שתומך בביטויים רגולאריים הוא גיט ובפרט הפקודה git log שמקבלת פרמטר בשם grep. החיפוש הזה ייתן את כל הקומיטים שההודעה שלהם מתקנת Issue בן שלוש ספרות או יותר.

   $ git log -i -E --grep='(fix|close).*[0-9]{3}'
   

4. ביטויים רגולאריים יכולים לעשות קסמים כשאתם צריכים החלפה מהירה של מילים בסקריפט. נכון של Bash ולכל סביבה יש את הכלים המיוחדים שלה להחלפות, אבל הייתרון בביטויים רגולאריים שתחביר אחד עובד תמיד: אנחנו נמצא אותם ב awk, sed וכמובן ב grep.

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

   text = 'hello.txt'
   puts text.chomp('.txt') # prints hello
   

   אבל אז אתם עוברים לפייתון ופתאום צריכים לכתוב קוד כזה:

   text = 'hello.txt'
   if url.endswith('.txt'):
       print(text[:len('.txt') + 1])
   

   בעוד שבאמצעות ביטוי רגולארי הייתם פותרים את הבעיה בשתי השפות עם אותו קוד בדיוק.

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

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

https://www.tocode.co.il/workshops/59

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

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

קרה לכם? ברור. בואו נרשום לקחים:

1. לא להילחץ. המטרה הראשונה שלנו היא לגרום לבעיה להופיע גם על שרת הבדיקות, שם אפשר לשבור דברים ויש לנו יותר מקום למשחק.

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

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

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

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

6. לפעמים יש לנו תוספים או תוכנות שהתקנו בסביבה אחת ושכחנו מהם. אפשר להשתמש ב:

   apt list --installed
   

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

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

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

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

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

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

2. מוסיף מלא הדפסות Debug ומקווה שחלק מהמידע ייתן לי השראה.

3. עושה הפסקה.

4. חוזר ומגלה שהבעיה עדיין שם, ולי עדיין אין רעיונות.

5. כותב בדיקות אוטומטיות.

6. מוסיף עוד הדפסות ומנסה לחפש חוקיות.

7. מחפש שינויים בין הקוד שלי לגירסא ישנה בה הכל עבד (לפחות לפי מה שאני זוכר).

8. מתייעץ עם חבר.

9. מתרגל לחיים עם הבאג.

רעיונות נוספים? מוזמנים לשתף בתגובות.

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

1. אנחנו שואלים פחות שאלות, כדי שלא יחשבו שלא הבנו.

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

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

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

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

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

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

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

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

https://www.akimbo.me/blog/s-2-e-6-origin-stories

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

https://soundcloud.com/einatnathan/ep17

האזנה מהנה, ינון

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

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

רק בבקשה אל תעצרו ב"לא יודע". זה לא בריא לכם וזה לא בריא לקוד שלכם.