רשומות

שרת FastApi על דוקר ב10 דקות

תמונה
דרישות: היכרות עם פייתון, עם web frameworks (כקונספט) והיכרות בסיסית עם דוקר. שתי השחקניות החזקות ביותר כיום בתחום ה web frameworks לפייתון הן django ו flask . הפוסט של היום מתעסק בשחקנית החדשה והסקסית בתחום שנכתבה על ידי tiangolo  ובעיני מסמלת את כל מה שטוב ויפה ב open source software. FastApi הוא web framework פייתוני מודרני וחדשני אשר נועד ליצירת APIs. הוא נבנה בעיקרו על הענקיות starlette (לניהול העבודה ב web) ועל pydantic (לולידציית data). הפיצ׳רים העיקריים בהם הכלי מתגאה הם - מהירות (ביצועים), מהירות קידוד , הפחתת באגים (כתוצאה מהפיכת תהליכים שהיו נכתבים ידנית לאוטומטיים), אינטואיטיביות , פשטות , רובסטיות , וסטנדרטיות (עבודה עם JSON schemas ו OpenApi). לכלי קיימות יכולות רבות אותן אני ממליץ לכם לקרוא בעיון בדוקונטציה הרשמית   (דרך אגב, אחת הדוקומנטציות הטובות שיצא לי לראות). בפוסט הזה אתמקד ביצירת API פשוט באמצעות הכלי (מעין hello-world) ובהמשך אגע באיזורים קצת יותר מתקדמים כמו חיבור DB, בדיקות, א-סינכרוניות, authorization ועוד טיפים ויכולות מגניבות בהן יצא לי להתקל. יצירת AP

Azure Functions עם פייתון בקלות

תמונה
יכולת מאוד חזקה ומגניבה שקיימת ב Azure (ובשאר ספקי הענן) היא functions. בפוסט הזה נדבר על מה זה functions, למה זה טוב, מתי נרצה להשתמש בזה, ובנוסף נראה דוגמה פשוטה של functions ב Azure. יש כל מיני דרכים ליצור function ב azure, היום אני אסביר על הקלה והגנרית בעיני - ה CLI. azure cli הוא כלי עוצמתי מאוד שנותן לעשות עם api די אחיד ונוח כמעט כל פעולה שאנחנו רוצים לעשות על סביבת הענן שלנו. מה זה Azure Functions? Azure functions זה שירות ענן שמאפשר לנו הרצה on demand של קטע קוד שנבחר (פונקציה) בעוד שהוא מתחזק עבורנו את כל מה שנדרש על מנת להריץ את הפונקציה הזו. כלומר, איננו צריכים לדאוג לתשתית או לגרסאות מעודכנות של התלויות שלנו. כל שעלינו צריכים לעשות זה לספק את הקונפיגורציה הנדרשת לנו ואת הקוד אותו אנחנו רוצים שירוץ, ו Azure דואג לכל השאר עבורנו.  באמצעות functions ניתן לבנות web APIs, להריץ קוד בעת שינויים בבסיס נתונים, להרשם תורי הודעות ועוד... יתרון נוסף שיש לפונקציות ענן הוא auto-scaling. באופן מובנה, כאשר יגיעו פניות רבות לפונקציה שלנו, מופעים נוספים של הפונקציה יקומו וכשירד הצורך המו

חוקים לדיזיין פשוט

תמונה
בסוף שנות התשעים הגיחו לעולם מתודלוגיית הפיתוח והספר Extreme Programming שנוצרו (ברובם) על ידי Kent Beck  (האיש המגניב בתמונה למעלה).  בספר הוא הציג 4 עקרונות לעיצוב פשוט של תוכנה ואני מאמין שהעקרונות האלו נכונים היום יותר מאי פעם משום שאנחנו נמצאים בעידן בו יש כמויות עצומות של רעש בנושא דיזיין וארכיטקטורה, מאות ספרים והמון גישות. סביר להניח שהרבה מהדברים ישמעו טריוויאלים לרובנו אבל לא בהכרח באים לידי מימוש ביומיום. אפשר לשים לב שהדברים שאכתוב נכונים גם לכתיבת קוד ממש כמו לדיזיין. למה דיזיין פשוט? מפתח בשם Gergely Orosz שאני מאוד אוהב לקרוא תכנים שלו, כתב בבלוג משפט שמאוד התחברתי אליו - ״Software Architecture is Overrated, Clear and Simple Design is Underrated״. הוא כותב שארכיטקטורת תוכנה מוערכת יתר על המידה משום שרוב האנשים מסתכלים על תבניות של ארכיטקטורה (patterns) כעל פטיש ואז מחפשים מסמרים כדי לדפוק באמצעותו, במקום לשים בראש סדרי העדיפויות שלהם כללים פשוטים וחשובים של דיזיין נכון וללכת לפיהם. הטענה כאן היא שלרוב, אם נדבוק בעקרונות הדיזיין הפשוטים שלנו נשים לב בדיעבד שמימשנו patte

ליפול מהר עם Pylint

תמונה
אם יש downside שאני לא מפסיק לשמוע בנוגע לפייתון זה היעדר הקומפילציה. התלונה שאני שומע הכי הרבה זה - ״לא הגיוני שאני כותב קוד וצריך לחכות עד ההרצה שלו כדי להבין אם מה שעשיתי היה בסדר!״. בתור אחד שמגיע משפה סטטית עם קומפילציה, מהרגע הראשון בו התחלתי לכתוב בפייתון הרגשתי שחסר לי משהו שיעבור על הקוד שלי ויספר לי על בעיות שעלולות לצוץ בעת ההרצה. בפוסט הזה אציג בקצרה ואספר איך אני משתמש בכלי שאולי היודע ביותר בתחום ה code analysis עבור פייתון, שמתיימר לתת מענה לא רע לבעיה שהצגתי - pylint . מה זה pylint pylint הוא כלי שבודק שגיאות בקוד, מנסה לאכוף סטנדרטים של השפה, ומחפש 'smells' בקוד שלנו, בנוסף הכלי יודע לתת הצעות refactor לחלקים בקוד ומספק מידע על מורכבות הקוד שלנו. ובסוף, אחרי כל זה הוא נותן לקוד שלנו ציון לפי הפרמטרים שהוזכרו לעיל. איך משתמשים ב pylint pylint הוא cli tool פשוט מאוד לשימוש.  נתקין אותו באמצעות pip install pylint   בסביבה בה שאר החבילות שלנו מותקנות  (אחרת נקבל שגיאות רבות על כך שחבילות אינן מותקנות). לאחר ההתקנה ניתן לראות את יכולות הכלי באמצעות pylint --help בגד

קודם כל פייפליין

תמונה
מבוא לרגל הגעתו של הבלוג ל150,000 כניסות החלטתי לחזור לפוסט קצר ואולי קצת פילוסופי (שאולי יחזיר לי את המוטיבציה לחזור לכתוב) על החשיבות הכנסה של continuous integration (CI) בסיסי לקוד שלנו עוד לפני שבכלל יש לנו קוד שעובד. אני לא אתעקב הרבה על מה זה CI כי יש על זה טונות של מידע באינטרנט , הצחיק אותי לגלות שבעברית קראו לזה ״אינטרגציה רציפה״. אני רק אגיד במשפט, שכשאני אומר CI אני מתכוון לתהליך שמושך את הקוד, ומבצע עליו פעולות כדי לוודא שהוא לא שבור לחלוטין . לדוגמה - מריץ עליו כלים של static analysis, מקמפל אותו, מריץ עליו unit tests, מעלה אותו לסביבת בדיקות, בונה ממנו package, מריץ עליו integration tests ועוד מיליון דברים שאפשר לעשות - וכל זה על שרת מרוחק. בפוסט לא אדבר על איך נכון לבצע CI אלא רק על החשיבות של הכנסה שלו כמה שיותר מוקדם. למה CI כל כך חשוב בעיני סיבה 1 - fail fast כשאני מפתח תוכנה (וזה לא חשוב מה היא עושה) אני דואג שיהיה לי איזה שהוא סוג של ולידציה על הקוד שלי (כמו שתיארתי במבוא), לרוב אני דואג לבצע דחיפות תדירות ל source control ותוך כדי שאני מפתח, במסך השני שלי פתוח הדשב

הקמת שרת PyPI ב-5 דקות

תמונה
לאחרונה יצא לי לדבר בבלוג לא מעט על הצד היותר ״devopsי״ של פיתוח תוכנה. דיברנו קצת על  סביבות וירטואליות , על  pip , על  יצירת חבילות , ואפילו על  git submodules . הפוסט הזה ממשיך את הפוסטים הקודמים לו ומדבר עלי איך אנחנו יוצרים שרת אליו ניתן להעלות חבילות פייתון, וכן, לצרוך אותן. בחברות רבות, גם בזו בה אני עובד כיום, ישנו איסור על העלאה של קוד לציבור הרחב על מנת שלא לחשוף את סודות החברה. אבל מה אם בכל זאת אנחנו רוצים לשתף חבילות pip בין צוותים בתוך הארגון? בפוסט הזה אראה את הדרך הפשוטה ביותר שמצאתי להקים שרת PyPI בסיסי, להעלות אליו חבילות לחלוק אותן עם שאר הארגון. דרישות - מחשב עם docker עליו (נכון, אפילו לא חייבים פייתון) ומכונת לינוקס שתאחסן את השרת. קובץ הסיסמאות תחילה ניצור את קובץ הסיסמאות על מנת שלא לשמור סיסמאות בטסקט על הדיסק, ניתן לעשות את זה באמצעות ה cli של htpasswd או פשוט באתר אינטרנט כלשהו שמייצר קבצי סיסמה מסוג htpasswd. בכדי לעשות זאת נתקין את הכלי שמייצר סיסמאות באופן הבא: sudo apt-get install apache2-utils # UBUNTU or sudo yum install httpd-tools # Red Hat וניצור א

מה ההבדל בין אוטומציה לפיתוח רגיל

תמונה
מבוא בתעשייה יש כיום שיח סוער מאוד על ההבדל בין אוטומציה לבין פיתוח. בעוד שיש אנשים שאומרים שאוטומציה זה פיתוח לכל דבר ומי שכותב אוטומציה צריך להסתכל על עצמו כעל מפתח, יש אנשים שרואים בפיתוח אוטומציה כתחום ששווה פחות, מתגמל פחות ודורש פחות הכשרה. הפוסט הזה אינו עוד שיחת מוטיבציה עם מסר של ״גם מפתחי אוטומציה הם מפתחים וצריך להתייחס אליהם ככה״. מטרת הפוסט היא להציג את נקודת מבטי האישית על תחום האוטומציה, על ההבדל בינו לבין תחום פיתוח התוכנה ה״רגיל״ לנסות לתת מענה לשאלה - מדוע אנשים רואים פער בין התחומים? קודם כל, מה זה פיתוח אוטומציה? יש הרבה הגדרות ל״מה זה אוטומציה״ ואני חושב שזו אחת הסיבות המרכזיות לדיון הבלתי נגמר על ההבדלים. כשאני מדבר על אוטומציה אני מדבר על כל קוד שנכתב כדי לעזור לנו לקדם את התהליכים שאחרת היו נעשים באופן ידני. כללי, נכון? זו בדיוק המטרה (בהמשך הפוסט נראה בדיוק למה ההגדרה כללית כל כך וכלל לא משנה). לפי ההגדרה הזו, כתיבת הספרייה selenium היא כתיבת אוטומציה, אם ניקח את זה קצת יותר רחוק, גם כתיבת המערכת jenkins היא אוטומציה. האם Jason Huggins ו Simon Stewart, שניים