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

הצמיחה של פייתון בשנים האחרונות היא לא פחות ממדהימה. החברים ב 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 לא קראת?)

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

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

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

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

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

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

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

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

שתי נקודות ששווה להכיר אם אתם מתכוונים להכניס גולשים מאירופה בתקופה הקרובה:

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

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

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

הדבר השני הוא שספריות קוד שאינן ריילס, כולל בשפות אחרות, התחילו להעתיק את היכולות החדשניות שריילס הביאה לשולחן. ספריית Django של פייתון, הספריה sails.js של node וכמובן play ב Java. ריילס נהיה משעמם כי החדשנות שלו ניצחה והוא הפך מספריה לתפיסת עולם.

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