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

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

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

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

1. מתקינים אפליקציה בשם TextMe Up Second Phone Number ובתוכה קונים מספר טלפון שני. אפשר לבחור מדינה אז כדאי לבחור משהו לא מרכזי מדי כדי שלא תקבלו מספר שכבר אנשים נרשמו איתו. עלות הקו 15 ש"ח.

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

3. נכנסים עם הקוד שקיבלתם ויש לכם טלגרם.

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

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

6. בשביל שיהיה קל לצ'וטט משני החשבונות בלי שתצטרכו כל פעם להתנתק ולהתחבר (זכרו עוד מעט תאבדו את הקו ולא תוכלו להתחבר שוב לעולם לחשבון החדש), כדאי להתקין אפליקציית טלגרם נוספת על המכשיר. יש את Loopy על אייפון ועל אנדרואיד יש אפליקציה בשם Telegram X. התקינו אחת מהן, התחברו ממנה עם החשבון החדש והסיסמא והשאירו אותה מחוברת.

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

זה ממש לא תירוץ. גם אם זה עבד לכם בחמש השנים האחרונות.

לכו לחפש את ה Best Practices העדכניים בתחום שלכם. יש המון מקורות מידע (כולל כאן באתר על חלק מהנושאים). כי כשאתם ממשיכים לכתוב document.write בקוד שלכם אתם מוציאים את כל החשק להמשיך לקרוא.

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

1. איך מתקינים?

2. איך מגדירים נתיבים?

3. איך מגדירים לנתיב שיקבל רק HTTP Methods מסוימים?

4. איך מגדירים Templates? איך טוענים Template אחד מתוך Template ראשי? איך מגדירים Layout?

5. איך שולחים קבצים סטטיים?

6. איך משנים את שמות תיקיות ברירת המחדל?

7. איך מגדירים HTTP Headers חדשים?

8. איך מפעילים Debugger?

9. מה צריך לעשות כשרוצים לעבור ל Production?

10. איך מפצלים את היישום למספר קבצים? מה המבנה המומלץ לפרויקט?

11. איפה שומרים API Keys?

12. איך כותבים בדיקות?

13. איך מנהלים קונפיגורציה שונה לסביבות שונות? (פיתוח, ייצור בדיקה)

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

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

הצמיחה של פייתון בשנים האחרונות היא לא פחות ממדהימה. החברים ב Stack Overflow טוענים שב 2018 פייתון היא השפה ששאלות לגביה מקבלות יותר צפיות מכל שפה אחרת. גם כאן בארץ אני רואה יותר ויותר לקוחות שלי בתעשיה בוחרים ב Python לפרויקטים או ממירים קוד קיים אליה.

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

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

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

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

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

https://www.tocode.co.il/bundles/advanced-python3

דוד בהט סיפר בגיקטיים על אהבתו ל Code Reviews דרך סיפור על דיון בנושא Public Data Members מול Properties. בואו נראה את הפרטים הטכניים של התלבטות כזו ואולי זה יעזור גם לכם להחליט.

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

ואז ב 2008 נוסד גיטהאב ושנה אחרי ב 2009 פתחתי שם חשבון. אני אפילו לא זוכר בשביל מה ואם תכננתי לעשות עם זה משהו. בכל מקרה 2018 והחשבון עדיין פעיל. בזכות גיטהאב למדתי להשתמש בגיט, למדתי לתקשר עם מתכנתי קוד פתוח אחרים, למזלג ספריות ולשלוח Pull Requests.

גיטהאב הוא באמת מהסטארט-אפים האלה שיחד עם ההצלחה שלהם סחפו את כל הקהילה להשתפר איתם: החל מדרכי תקשורת טובות יותר (Issues, Pages) ועד שילוב כלי בדיקות (Travis) וכלי אבטחת מידע לכל פרויקט.

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

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

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

נ.ב.ב. מנכ"ל מיקרוסופט התפנה לכתוב בהתרגשות על הרכישה. לטייק אחר לגמרי על אותו הנושא שווה לקרוא אותו:

https://blogs.microsoft.com/blog/2018/06/04/microsoft-github-empowering-developers/

מה אתם עונים כששואלים אתכם כמה זמן ייקח לכם לפתח פיצ'ר מסוים? הנה כמה רעיונות:

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

2. תוך שבועיים, אבל לא בטוח שעם כל הפיצ'רים.

3. תוך שובעיים (אבל אם תשלם יותר אוכל לסיים גם תוך שבוע).

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

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

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

7. תוך שעתיים הכל באוויר (ולכו חפשו אותי אחרי שהכל יישבר).

זוכרים את הבדיקה האוטומטית ההיא שממש התאמצתם לכתוב? זאת שכוללת Mocking למלא מחלקות במערכת ועבדה ממש טוב פעם אבל האמת שאם נהיה כנים כבר כמה זמן שהיא מכשילה לכם את חבילת הבדיקות?

או הבדיקה ההיא שרצה מול שירות רשת חיצוני שעובד רוב הזמן חוץ מימי שלישי ואז צריך לזכור שכשבדיקה נכשלת ביום שלישי לא לשבור את הראש על זה כי זה נורמלי? (הי כתבנו את זה ב Wiki לא קראת?)

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

נראה לי שכדאי למחוק אותן.

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

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

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

"יש מתכנתים שחושבים- יש לי בעיה, אשתמש בביטוי רגולארי לפתור אותה. עכשיו יש להם שתי בעיות".

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