פוסטים

ניהול חבילות וסביבות בפייתון - pipenv

תמונה
בפוסט הקודם  דיברתי על היתרון של סביבה וירטואלית בפייתון והצגתי את הכלי venv. בשנת 2018 נוצר הכלי pipenv שמטרתו לפתור בעיות נפוצות ב pip, ב venv ובעבודה עם קובץ ה requirements עליו דיברנו בפוסט הקודם. הפוסט הבא מדבר על הכלי pipenv, משווה בינו לבין venv ו pip, ומציג כיצד pipenv פותר לנו חלק מהבעיות שלנו. מה הבעיה עם requirements.txt ואיך pipenv פותר לנו אותה? אז דיברנו על היכולות המרשימות שנותן קובץ ה requirements ובאיזו קלות ניתן למלא אותו עם pip freeze. אבל לצערנו הוא דורש לא מעט התעסקות ידנית בפרוייקטים מתקדמים יותר. דמיינו את המקרה הבא: אנחנו מתקינים את הספריה requests בגרסתה האחרונה (2.24.0) וכשאנחנו מתקינים אותה מותקנת לנו באופן אוטומטי גם תת-תלות (sub-dependency) בשם urllib3 בגרסה 1.25.11. עכשיו בואו נניח שהתעדכנה גרסה של התגלתה פרצת אבטחה ב urllib3 והם שחררו את גרסה 1.25.12. כעת, הקוד שלנו בפרודקשן רץ מול הגרסה הישנה. עלינו לעדכן את הגרסה כמה שיותר מהר. הבעיה היא שאת זאת נצטרך לעשות באופן ידני משום שקובץ ה requirements כובל אותנו לגרסה ספציפית אם מילאנו אותו עם pip freeze. קיימת

סביבות מבודדות בפייתון - venv

תמונה
הקדמה כשאנחנו עובדים עם פייתון ורוצים להשתמש ביכולות הקהילה העצומות שלה, נרצה להשתמש בחבילות שאנשים אחרים כתבו. לשם שיתוף החבילות, מפתחי פייתון יצרו את pip package installer for python שמטרתו לאפשר התקנה ושדרוג פשוטים של חבילות פייתון אל מול מקור מסוים. מי שכותב חבילה מסוימת יכול להעלות אותה אל שרת החבילות של פייתון pypi - python package index. ואז על מנת להתקין את החבילה כל מה שהמשתמש יצטרך לעשות זה לכתוב pip install package_name. בפרויקט בוגר בפייתון נוכל לראות שימוש גם בעשרות של חבילות, ולכל חבילה יכולות תלויות משל עצמה. מטרת הפוסט לדבר על איך סביבה וירטואלית עוזרת לנו להישאר שפויים תוך שימוש בספריות פייתון חיצוניות בתוך הקוד שלנו. למה צריך סביבה וירטואלית? דמיינו את המקרה הבא - התחלתי לכתוב את הפרויקט שלי ובמהלך כתיבתו הבנתי שעליי להתשמש בספריה requests בגרסה 1.0.0. אני עובד עם הגרסה הזו ומשתמש ב requests ואז לאחר כמה חודשים אני פותח פרויקט נוסף שבו עליי להשתמש ב requests בגרסה עד 0.8 משום שהחל מגרסה זו כבר אין תמיכה בפיצ׳ר מסוים בו אני משתמש (אל תנסו את זה בבית). תחת התיקייה של פ

מחשבות על coupling ועל dependency injection

תמונה
אם הייתי צריך לבחור עקרון אחד לכתיבת קוד טוב וללכת איתו, זה היה לכתוב קוד שהוא loosely coupled. הפוסט הבא מדבר על החשיבות של כתיבת קוד בצימודיות נמוכה ועל איך הזרקת תלויות יכולה לעזור לנו עם הנושא. מה זה coupling משמעות המילה coupling בעברית היא צימודיות והכוונה כשמדברים על צימודיות היא על כמה חזקה התלות בין מימושים בקוד. במילים אחרות - ככל שכמות השינויים והתסבוכות שאכנס אליהם כשאצטרך לעשות שינוי או להוסיף שכבת אבסטרקציה תגדל - כך הצימודיות תהיה גבוהה יותר. coupled code vs decoupled code העיפו מבט בקטע הקוד הבא ונסו לחשוב אילו השפעות יכולות להיות לו על פיתוח התוכנה בעתיד עכשיו דמיינו את המקרה הבא (והניחו שבניית מחשבים היה דבר פשוט שמסתכם בכתיבת מספר מחלקות וחיבורן יחד): כתבתי את המחלקה Computer, הפצתי אותה למגוון גדול של משתמשים וכולם יכולים ליצור מופע של המחשב שלי ולהינות מיכולות העיבוד המופלאות של Intel. לאחר כמה חודשים הגיעה לאוזני השמועה שיש מעבד חדש בשם AMD. כעת אני רוצה שכל מי שירצה יוכל להחליף את המעבד שלו ולבחור אם ברצונו להשתמש ב AMD או ב Intel. אבל יצרתי בעיה. כשהכנסתי את היצ

מה זה singleton ולמה לא כדאי להשתמש בו?

תמונה
זהו פוסט קצר שמטרתו להציג את תבנית העיצוב singleton ומדוע אינני ממליץ להשתמש בה. הפוסט הינו חלק מסדרה שמטרתה לדבר על כתיבת קוד רע ו-anti-patterns בתחום עיצוב התוכנה. מה זה סינגלטון סינגלטון היא תבנית עיצוב ממשפחת ה creational, שמטרתה להגביל את יצירת המופעים של מחלקה מסוימת למופע יחיד, משתמשים בתבנית הזו על מנת שלא ליצור התנגשות בין אובייקטים בפעולות כמו כתיבה לזכרון, קובץ דאטאבייס וכו׳. אופן המימוש של סינגלטון הוא די פשוט. כל מה שצריך זה מחלקה עם field פרטי שמטרתו לשמור על האובייקט המאותחל. ופונקציית אתחול שמאתחלת את האובייקט במידה ולא אותחל כבר. באופן הזה נקרא כל פעם למופע המחלקה באמצעות הפונקציה get_instance ונקבל את אותו המופע. למה לא להשתמש בו סינגלטון היא תבנית פשוטה מאוד, אבל האמת היא שאין מתנות חינם. הנה 4 סיבות (מהקלה לחמורה) לכך שאני חושב שלא כדאי להשתמש בסינגלטון: בזבזנות בזיכרון שימוש בסינגלטון הוא אינו יעיל בהיבטי זיכרון כשמדובר על סביבות בהן יש  garbage collector . במקרים בהם משתמשים בסינגלטון בשפות כאלו (כמו java ופייתון), השפה מגדירה את האובייקט כחשוב (מכיוון שיש אליו רפ

מה חדש בפייתון 3.9

תמונה
בשבוע שעבר שוחררה גרסת פייתון 3.9 והיא כרגיל מביאה עמה כל מיני דברים מעניינים. כשמשתחררת גרסה של פייתון, בדרך כלל ה release notes מחולקים לנושאים כמו: syntax features,  built-in features, n ew features in the standard library,  Interpreter improvements, and  new library modules. מטרת הפוסט היא לכלול כמה מהדברים שאני מצאתי מעניינים ושיוכלו להעיל לי בחיי היומיום כמפתח. שימו לב: בגרסה 3.9 החבר׳ה של פייתון לקחו צעדים רציניים נוספים בהורדת התמיכה ובתאימות לאחור אל מול פייתון 2.7. בעבר פיצ׳רים פותחו עם תאימות מסוימת לאחור אבל מגרסה לגרסה הפיצ׳רים תואמים פחות ואף יורדת תאימות בפיצ׳רים ישנים. זאת ניתן לראות לפי Deprecation Warnings  על גבי ספריות ישנות. אם אינכם בטוחים באילו פיצ׳רים אתם משתמשים שאינם נתמכים עוד, השתמשו במדריך הזה  על מנת לבדוק זאת. הפיצ׳רים החדשים אופרטורים למיזוג ועדכון dictionaries אחד הדברים שאני הכי אוהב בגרסאות חדשות של שפה זה תוספות ל-syntax. באמצעות הפיצ׳ר החדש הזה נוכל בקלות לעדכן ולמזג מילונים. אם עד כה היינו משתמשים בפונקציה dict.update וב {d2,**d1**} על מנת לעדכן

הפרדה לתתי פרויקט באמצעות git submodules

תמונה
פעמים רבות כשאנחנו מתחילים פרויקט איננו יודעים מה יהיה גודלו הסופי, כמה מחלקות הוא יכיל, ואיך יראו התלויות. לפעמים, כמה שלא ננסה לתכנן את הכל מראש, נגיע למצב בו אנחנו רוצים להפריד חלק מה-codebase שלנו לפרויקט נפרד. הסיבות לכך יכולות להיות: 1. ניסיון לשמירה על single responsibility principle (כן, הוא לא נכון רק לפונקציות ומחלקות) 2. עובדים על הפרויקט כבר יותר מדי אנשים וביצוע פעולות גיט מרובות לאותו פרויקט על ידי הרבה אנשים יכול ליצור לא מעט צרות וקונפליקטים. 3. לפעמים, בתוך באותה חברה נרצה שמספר צוותים יעבדו על (או ישתמשו ב) אותו פרויקט. 4. במקרים מסוימים אפילו נרצה לקחת חלק קטן מהקוד שלנו (לדוגמה פעולות אוטומציה נפוצות) ולהוציא ל open source. מטרת הפוסט הזה הוא להציג שלושה נושאים: הראשון - הפרדת הפרויקט לתתי פרויקטים  השני - מתי נרצה להשתמש ב submodules? השלישי - צריכת תתי הפרויקטים באמצעות git submodules. הערת צד: אינני הולך לדבר על מימוש ההפרדה עצמה, הפוסט מניח שהקורא יודע לפתוח פרויקט, להזיז קבצים אל הפרויקט החדש ולדחוף אותו ל source control. איך מ