פרק מספר 64 של באמפרס (383 למניין רברס עם פלטפורמה) - רן, אלון ודותן בבוקר גשום של תחילת ינואר (זהירות בשטפונות!) עם סקירה של טכנולוגיות ודברים מעניינים מהזמן האחרון.
רן -
- שפה חדשה (לפחות לרן) בשם CUE
- שפת קונפיגורציה עם כמה פיצ’רים מעניינים, מימוש ב - Go ע”י מישהו ב - Google איפשהו באירופה.
- נניח שיש לכם תוכנית שמקבלת קובץ קוניפיגורציה (כקלט), או שאתם עובדים עם Kubernetes שצריך לקבל עשרות (או מאות) קבצי yml. - כנראה שיש לכם כמה בעיות בסיפור הזה:
- קודם כל - יש הרבה חזרות ואתם רוצים לעשות re-use לאיזשהו “אי של קונפיגורציה” במקום אחר, או אולי לקבע משתנים מסויימים שרלוונטיים בכמה מקומות/
- חוץ מזה - ולידציה: גם Data Types (אם אתם מצפים ל String כדאי שלא תקבלו Integer וכו’) וגם מבחינה לוגית (המינימום קטן או שווה למקסימום; גיל של אדם הוא לא 500 וכו’)
- את הבעיה הראשונה (יכולות re-use) שפת CUE לא כל כך פותרת . . . בשביל זה יש שפות אחרות (כמו Dhall למשל)
- שפת CUE כן פותרת יפה את הבעיה השנייה - היכולת להגדיר סכמה ולעשות ולידציה לסכמה הזו.
- לדוגמא - אפשר לקחת בנאדם ולהגדיר שיש לו שם פרטי, שם משפחה וגיל, ועל כל אחד מהם אפשר להגדיר גם Data Types וגם ולידציות סכמטיות (הגיל לא גדול מ-120 ולא מתחת ל-0, שם פרטי חייב להיות קיים אבל שם אמצעי לא חובה וכו’), הכל ניתן להגדרה בקבצים שונים.
- החלק המעניין בכל הסיפור - בסופו של דבר CUE לוקחת הכל ועושה איחוד, במובן של Graph unification:
- אתם למעשה מגדירים סדרה של אילוצים (הגיל לא קטן מ-0 וכו’) והתוכנית בסופו של דבר צריכה לקבל איזשהו ערך ממשי - ועושה ולידציה על הערכים הללו, ע”י איחוד של של כל האילוצים בקבצים השונים.
- אם יש סתירה - צועק . . .
- מאוד מזכיר תכנות לוגי - מי שכתב פעם ל - ProLog או שפות לוגיות אחרות ימצא המון דימיון בין זה לבין הגישה של CUE לקונפיגורציה - יש אוסף של Constraints ושל עובדות ובסופו של דבר נעשה איחוד על כל הגרף הזה, והתוצאה היא איזשהו ערך מעשי לכל אחד מהמשתנים והאם הוא עומד בכל אחד מהאילוצים הללו.
- (אלון) חייב להגיד שזה מעצבן ברמות קיצוניות - שונא Text-based configurations, כי בסוף אתה צריך לפתח כלי כדי לתחזק את זה . . . אני בגישה של Configuration as Code תמיד, וכל ה - “.yml-י ענק” האלה, שמצריכים כלי לניהול ה - .yml ועוד שפת תכנות לנהל את הכלי שמנהל את ה - .yml ועוד שפה לשפה . . . חזרנו לקוד מההתחלה, אז למה?
- (דותן) אתה רומז ל - Kubernetes? לא רק . . .
- לכאורה ה - use case הראשון הוא Kubernetes, אבל יכולים להיות אחרים.
- בחלק מהמקרים אתה אכן בונה את ה - Service ואתה מגדיר את הקונפיגורציה אז אתה לא חייב לסבול; מצד שני - אם אתה משתמש בכלים אחרים (כן, לדוגמא Kubernetes), האם באמת יש לך ברירה?
- אתה יכול להשתמש בשפות אחרות שמייצרות .yml או .json, אבל גם שם תצטרך לפתור את אותן בעיות . . .
- (אלון) ברור, אבל אני כועס על כל מי שמפתח לי משהו שה - Interface שלו הוא .yml, כי בסוף זה ניהיה מפלצת - ה”קונפיגורצית פח” הזו שאי אפשר לשלוט עליה ולוקח שבועיים לעדכן משהו ומצריכה “100 ולידציות”, במקום Configuration as Code שכבר היה מתקמפל ויש את כל מה שכבר קיים בשפות תכנות והיית יכול גם להוסיף טסטים על הקונפיגורציה, Canary ומה שבא לך - במקום זה אנחנו ממציאים טקסט, ועליו שפת תכנות, והיא לא מספיק טובה אז ממציאים עוד שפת תכנות - ובסוף תנהל הכל ב - Go. אז מה עשינו בזה?
- (דותן) קצת מזכיר את התקופה של ה - .xml - לפני 15-20 שנה - הייתה XSD כסכמה של ה-xml . . ראיתי גם משהו מאוד דומה ל-XSD בעולם של Kubernetes, משהו שמוסיפים על ה-yml-ים ומייצר עוד yml-ים, עם Rules וכו’ - לגמרי אותו הדבר, רק ש-yml יותר “קליל” מבחינת ה-syntax אבל זה לא אומר שבמהות זה לא אותו הדבר בסוף.
- (אלון) חזרנו לאותה בעיה . . אני מוכרח להודות שה-Plug-in של VScode ל-Kubernetes הוא להיט - מוצא ועושה מלא ולידציות וכו’.
- לא ברמה של CUE כנראה ועדיין -אם אני מרים Service של Configuration as Code וזה משהו מורכב של יותר מ-4 שורות - עזוב אותך . . בוא ניהיה ריאליים: ברוב המקרים שינויים כאלה מגיעים עם גרסא.
- לפעמים רוצים לשנות משהו קטן, אבל אני מעדיף Code על פני Text Configuration ברוב המקרים.
- (רן) אתה לא בהכרח בדעת מיעוט - אני חושב שיש מקרים שבהם זה לגמרי ולידי, אבל לא בכל המקרים אפשר להכיל את זה.
- לתחזוקה של Configuration as a code יש הרבה יתרונות, אבל במקומות שבהם יש ממשק עם “פחות-מתכנתים” (אנשי Ops? . . .) לפעמים צריך לספק קונפיגורציה שלא כקוד, ולפעמים יש מערכות שלא אתה כתבת (Kubernetes) שאתה צריך להתממשק אליהן, ואתה לא בעל הבית.
- פרויקט מעניין אחר שהוכרז באחד הכנסים האחרונים של GitHub, שמטרתו לשמר פרויקטי קוד פתוח לדורות הבאים - GitHub Archive Program
- כמה מאות או אלפי הדורות באים (או כמה שהקורונה ייתן) . . .
- התחילו עם פרויקטים שלהם ואחר כך אפשר היה גם להגיש נוספים -
- העבירו לכמה מדיות שונות (כולל הדפסה על נייר) - והצפינו בבונקר אי שם ליד גרינלנד בקרבת הקוטב הצפוני, בשרשת איים בשם Svalbard archipelago
- הארכיון לא מיועד אך ורק עבור GitHub (למשל, יש מצב שהארכיון עם דגימות זרעים של כמעט כל היבולים בעולם תופס שם מקום קצת יותר משמעותי), אבל עכשיו בין השאר יש שם גם פרויקטים בקוד פתוח שמגיעים לשם ונשמרים עבור הדורות הבאים, מתוך הנחה ששם זה ישמר יותר טוב.
- קצת מלחיץ שלא סומכים על הגיבויים של Azure, לא?
- מיועד כנראה עבור החייזרים שיגיעו מתישהו וינסו לקרוא את האימוג’ים.
- וכיוון שלא דיברנו עדיין על Kubernetes היום - הנה בלוג של מישהו שעובד בגוגל (כן, על Kubernetes) וכתב על מה שהוא חושב שהולך להיות מעניין באיזור של Kubernetes ב-2020
- אנחנו רק בתחילת השנה, יהיו תחזיות נוספות . . .
- יש 5-6 תחזיות, מעניינת במיוחד זו של CRD explosion (הכוונה ל Common Resource Definitions)
- מדובר ב-Data Type שמגדירים ב Kubernetes (כן אלון - ב YAML) - ומאפשר לתאר Entities “שלך” (מה - Business domain שלך) עבור Kubernetes, ואז לעשות איתם כל מיני דברים מעניינים.
- למשל - אפשר להגדיר Services מיוחדים, כך שעבור כל Service כזה צריך לפחות שלושה Pods וה-Monitoring עם Prometheus, או משהו בסגנון.
- אז גם אפשר לקחת את ה-CRD שלך ולתרגם אותו באמצעות כלי נוסף (Operator)
- ה-CRD זו ההגדרה (Syntax), וה-Operator זה מה שמתגרם אותו למשהו שהוא יותר Actionable - ולשניהם יחד יש כוח מאוד גדול.
- כותב הבלוג צופה CRD explosion - שזה הולך להיות מאוד פופלארי ונראה הרבה כאלה, עד כדי “CRD Hubs” שיכילו את הנפוצים והשימושיים יותר (רוצים להתקין Redis? או Kafka? כאלה)
- נכון, יש גם פתרונות אחרים ב - Kubernetes (החל מהגדרה “בידיים” דרך מנהלי חבילות למיניהם), אבל הוא צופה שכולם בסוף “יתנקזו” לכיוון של CRD.
- (אלון) זה מחבר אותי למשהו מהתקופה האחרונה - תהיות בטוויטר לגבי ההייפ סביב Kubernetes: הרי בסוף אפשר לקבל הכל ב-Cloud, גם אם קצת (?) יותר קשה לניהול לבד עם ה-APIs של כל ספק.
- כאן מדובר על אפליקציות שהן לא Kubernetes אבל עם הקונפיגורציה של Kubernetes, וזו נקודה מאוד מעניינת
- נשמע הגיוני שניהול של ה-Cloud יהיה ניהול של AWS או GCP או Azure וכו’, עם ממשק אחיד, כך שתוכל לייתר את Kubernetes בעוד כמה שנים, כי יהיה אפשר לעשות הכל ישירות על ה-Cloud
- אולי לא ב-2020, אבל אם התחזית היא שנראה אפליקציות על בסיס אותה הקונפיגורציה השנה אז כנראה שבסוף נגיע לשם - ו-Kubernetes ישאר נקודת מעבר לעולם אבסטרקציה אחר.
- (רן) אגב - CRDs כאלה קיימים לא מעט כבר היום - יש CRD שמנהל עבורך S3 (ליצור Bucket או לקבוע הרשאות למשל) - מפעיל אופרטור שמבצע את הפעולה, קצת כמו שכלים כמו Chef או Puppet עובדים.
- ובהמשך למה שאלון אמר - ברגע שהחלפנו את ה-API הזה, אפשר להחליף את Kubernetes בכלי אחר מלמטה, עם אותו API רק במימוש אחר.
אלון -
- אז נמשיך עם Kubernetes . . . כלי שפותח ב-Google בשם SKAFFOLD - ומאפשר Local K8s development
- עושה Init ,מכין את כל ה-YAML, כותב Dokcer, עושה את ה-Deploy . . .
- נראה חמוד, לא יצא לי (אלון) לעבוד איתו עדיין, אבל נראה מבטיח, גם אם עדיין שונא YAML.
- (דותן) מרגיש בנוח עם זה שיש עוד מישהו בסירה…
- שאלה למי שכן אוהב Kubernetes - כמה פעמים אתם מעדכנים Kubernetes בגלל בעיות Security?
- (רן) קשה להגיד . . . לא בהכרח כמי שאוהב ולא כמי שמריץ ב-Production.
- (אלון) אוהב, לא סגור על קצב העדכון, רץ יפה, יש דברים שאני אוהב ודברים שלא. עד רמה מסויימת של Scale זה מאוד נוח, אחר כך צריך ממש להתעסק עם הקונפיגורציות וצריך “להרים את מכסה המנוע” וזה מתחיל להיות מעצבן.
- (דותן) יש אתגר במקרה למשל בו יש לך לקוח ואתה מחוייב מולו חוזית לתקן בעיה תוך למשל שבועיים - בסביבה עם כל כך הרבה חלקים נעים, איך אפשר להגיע למצב שבו אתה משדרג כל הזמן? זו שאלה קשה, ולא קיבלתי בינתיים תשובה טובה.
- (אלון) אנחנו רצים על GCP עם ה-Managed Kubernetes שלהם, אז דווקא בנושא של העדכונים זה יותר קל וזה קורה (לפחות בתיאוריה) בלי Down-time.
- (דותן) יש SLA?
- כן, לא זוכר מה בדיוק
- וזה מעניין - כי אתה מבטיח SLA ללקוח שלך - ואתה תלוי בתגובה שלהם ואין לך ממש מה לעשות עם זה
- זה נכון גם עבור למשל VM שרץ על AWS ויש בו בעיית אבטחה.
- השאלה מה הסבירות שזה יקרה …
- אני (אלון) מאמין שדווקא בהקשר של בעיות אבטחה של Kubernetes הענן של Google יהיה מהיר יותר, אבל זו רק הנחה.
- (דותן) יש מסמך על Penetration tests שהזכרנו בעבר - ויש דברים כאלה (אולי לא קריטיים, אבל יש), כך שכבר עכשיו אם יש לך לקוחות עם דרישות גבוהות עלול להיות לך ניגוד אינטרסים (או לפחות אי התאמה)
- (אלון) יש להם מסמך על נושא ה-Security, שמדבר על ה-zones ומאיפה הם מתחילים בכל יום, מניח שעבור רמת Critical הם עושים את זה מהר, אבל צריך לקרוא יותר לעומק כדי להבין.
- קשה לי להאמין שכאן תיהיה הבעיה שלך, כי אפשר להגיד את זה על המון דברים - מוצאים בעיות אבטחה כל יום, כמו לדוגמא מה שהיה עם המעבדים של אינטל (ולוקח זמן להחליף את כל המעבדים…).
- פה מדובר במטרה נעה . . . בכל מקרה, בשתי חברות שעבדתי בהן הריצו בדיקה על Kubernetes, ופעמיים זה נפל על ענייני Security.
- אלון יחזור עם יותר פרטים . . .
- ועוד אתר (שלפעמים לא עובד, תמחקו cookies וזה עוזר) - Graphviz.it - שמאפשר ליצור גרפים בsyntax פשוט וחמוד
- שפה טקסטואלית שמאפשרת לתאר גרף - ואז זה יוצר את הגרף המתואר
- צורות שונות, קשתות בצבעים שונים
- אפשר ליצור עצים וכל מיני צורות שונות ומשונות - וזה מאוד קל ופשוט לייצג עם זה דברים
- תומך בכל מיני שפות מוזרות כמו יפנית וכאלה, קל וחביב - שווה לנסות
- מה יש מתחת? SVG מסתבר.
- וכן - יש גם כלי CLI מקביל - וזה ממשק Web מגניב ואינטראקטיבי
- ועוד אחד - אתר שמרכז Python anti patterns
- 3,2,1 . . .
- כן, כל השפה היא Anti-Pattern אחד גדול
- ועדיין - למי שכותב ב-Python זה באמת מעניין - קריאות לא נכונות, סדר לא נכון, Default dictionary, התנהגויות מוזרות . . . למי שכותב קוד ל-Production זה חובה לדעתי.
- ומי שלא כותב ב-Python? עזבו . . .
- מדובר גם על Python 2 וגם 3 - עם דוגמאות לכל אחד (Python 2 כבר ב-EOL בתיאוריה, אבל עוד רצים עליו דברים)
- לא ארוך , אפשר לעבור על הכל בשעה בקלות, שווה.
דותן -
- מאמר בשם Seven Ways to Think Like a Programmer
- יש לזה היסטוריה עם מאמר בשם Seven Ways to Think Like the Web
- כמה עקרונות לזכור - הראשון הוא It’s all just data, ויש גם Data doesn’t mean anything on its own ו - Programming is about creating and composing abstractions . . .
- אחלה דברים להחזיק בראש, וההמשך הוא ניתוח של כותב המאמר
- הסיכום - The tool shapes the hand: ככל שאתה יוצר לעצמך ארגז כלים יותר טוב, ככה אתה יודע ליצור יותר טוב, שזה עיקרון שאני (דותן) אימצתי לפני 10-15 שנים, בעקבות עצה שמישהו נתן לי.
- תבנה את ארגז הכלים שלך בצורה הכי טובה, וזה מה שיגרום לך להיות הכי פרודוקטיבי.
- (אלון) הנקודה הראשונה מאוד מעניינת (It’s all just data) - שמעתי (צפיתי) בשבוע שעבר הרצאה על Rust, ודיברו שם על שיטת חשיבה שונה: ברוב שפות התכנות את חושב קודם כל על ביצועים (Performance) במובן של CPU, בעוד Rust מכריחה אותך לשוב על זה במונחים של Data, בגלל ה Data ownership שלהם, וזה משנה לך את התפיסה.
- מעניין שהעיקרון הראשון הוא It’s all just data, כי בדרך כלל מסתכלים קודם כל מכיוון אחר, על מה התוכנה עושה.
- זה מתחבר לעצה הותיקה של “תחשוב קודם כל על מבנה הנתונים” - אם מבנה הנתונים נכון אז הבעיה תיפטר בצורה קלה.
- כתיבת הקוד ב-Rust היא מעט שונה - אם בדרך כלל אני “רץ קדימה”, מנסה כל מיני דברים ושומר לעצמי בראש כל מיני דברים תוך כדי הכתיבה שאני אצטרך לתקן אח”כ ובמה אני לא בטוח, ויודע “לרוץ אינטואיטיבית” עם החשיבה, כי לפעמים צריך לנסות קצת עד שמתגבש הרעיון בראש
- אז ב-Rust זה לא ממש עובד ככה - אתה יכול להתקדם ולכתוב קוד ולמצוא את עצמך במצב שאתה רוצה לשנות חלק מהאבסטרקציות ובסוף משכתב את כל הקוד.
- תכנות ב-Rust זה קצת “לחזור לפעם” - צריך “נייר מנטלי”: למדל את ה - Entities שלך ואת היחסים ביניהם, במיוחד את יחסי ה - Ownership, וזה בסוף הכל חוזר ל - Data.
- מצאתי שאם אני ממדל מאוד טוב את עולם ה - data שלי, אז נוצרת לי “חווית Rust קלה”
- אם לא - נוצרת חוויית Rust שאפשר לקרוא עליה ברשת כל מיני זוועות עולם.
- לסיכום - המאמר עובד, אני חושב. שווה לקרוא.
- המאמר הבא - חצי דרמה! לפחות עבור מי שאוהב את Linus Torvalds (ומי לא?)
- פרסומות?
- למי שמכיר - מדובר באדם מאוד שליו ורגוע שנוטה לעיתים לצעוק, לקלל, לזרוק דברים, קצת Shaming פומבי לאנשים, כאלה. סלחנו? לא ברור, אם כי הוא בהחלט עשה הרבה כנגד זה.
- בכל אופן - לא מאוד פופולארי, אבל יודע להתנסח בצורה טובה, וכשחופרים לעומק במה שהוא אומר בדרך כלל מוצאים שיש סיבה לזה שהוא התעצבן (כי מישהו שוב הכניס איזו שטות ל-Kernel ומדובר במערכות שנפרשות בכל העולם, במערכות הכי קריטיות וכו’).
- מאוד מלחיץ, ולא ברור כמה אנשים בעולם מתמודדים עם תפקיד כזה
- בקיצור - דרמה חדשה, שמגיעה מאיזשהו סטודיו (או לפחות משם זה התפתח), שניסה לעשות Port של משחק בשם Rage 2 (כבר התחילו בלהרגיע . . .) ל - Stadia, פלטפורמת ה-Gaming החדשה של Google.
- תוך כדי ה - Porting הם הבינו שיש בעיה עם Spin-locks של Linux - האופן בו מערכת ההפעלה מאפשרת לייצר Mutex (לפחות זו אחת הדרכים).
- מפה לשם - הבינו שיש משהו מאוד לא יעיל, ואז Linus התחיל לשחרר “הרצאות Twitter” על למה אסור להשתמש ב Spinlocks (זה - Spinlocks Considered Harmful), כי זה בעצם סוג של While-Loop . . .
- למי שמתעסק ב-Low Level ובכלל אוהב את Linus, שווה לעקוב - כאן יש קצת הסבר על כל הדרמה
- שווה לעקוב - בדרך כלל לומדים מזה לא מעט, במיוחד אם Linus מעורב בכל הסיפור.
- ולאייטם הבא -
- קצת מפתיע, אבל לשפת C אין (Read–Eval–Print Loop (REPL. ככה יצא.
- יש שפות (Python, Ruby, Java, Node …) שבהן פשוט נפתחת סביבת הרצה Real-time שבה אפשר לכתוב קוד ולראות מה יוצא. ל - C אין.
- יש לזה סיבה טובה - זו שפה מאוד ישנה, שגם מתקמפלת.
- מישהו מצא שאם מריצים Swift REPL, אפשר לכתוב שם קוד C וזה עובד - Swift as a C language REPL . . .
- כשעוברים על הפוסט והתמונות זה נראה די מגניב - אפשר לכתוב קוד C בסביבה די מודרנית.
- למה שנרצה לעשות את זה? ובכן, תמיד יש אנשים שמחפשים עוד כלי על מנת לייעל את העבודה שלהם...
- לא בטוח שהמאמר הבא רציני ויש מצב שזה רלוונטי לחלק המצחיקים או לפרק 1 באפריל - ועדיין: איך הצבא הקנדי הגיב לשחקני Pokemon Go שהשיגו גבול ופלשו לבסיסים שלו. כזה.
- העניין הזה של Pokemon Go זה משהו שעדיין קורה? נראה שכן.
- (אלון) בקיץ עוד ראיתי ילדים רצים ורודפים אחרי פוקימונים . . .
- (דותן) השאלה האם נשאר מישהו מספיק רציני לרמת חדירה לבסיס צבאי . . .
- בכל מקרה - זה נראה נחמד, ואז יש תמונה של דו”ח צבאי תחת הכותרת של Pokemon criminal intelligence advisory
- אנשים שעלו על טנקים ושטויות בסגנון.
- אמיתי או לא - אחלה סיפור, עם סטטיסטיקות על גילוי, טיפול וזמן תגובה (60 יום?!)
- עוד אייטם על סף ה-1 באפריל - מישהו העלה ב-Redit של Go (השפה, לא פוקימון שוב) Screen-shot של מסך מחשב שנראה די ישן, ומראה Edit.com (לא האתר - זה של Dos), והוא על Drive A (זוכרים את הפלופי-דיסק?) . . .הכל נראה כמו קריצה לרטרו.
- זה גם לא צילום מסך אלא צילום של המסך (עם טלפון . . .) - וזה מסך CRT.
- השאלה - “האם אני הראשון שכותב Go ב-Dos?”
- אנשים התעלמו מהשאלה - והוסיפו הערות על הקוד עצמו, וזה הפך להיות די מצחיק.
- מי אמר שאין Compiler ל-Dos? בכל מקרה עושה רושם שזו חייבת להיות בדיחה.
- זה נחמד, כי יש דברים שכבר הספקתי לשכוח וזה קטע נוסטלגי די חזק.
- (אלון) זה מזכיר את פסקל (טורבו פסקל!) - איפה ה - Editor הכחול עם הטקסט הצהוב?
- (רן) מה - אתה לא משתמש ב Color skin של כחול-תכלת ב-VI?!
- (דותן) אגב - אתם יודעים ש-IntelliJ (או שזה היה Visual Studio?) לקח הרבה מקיצורי המקשים של Turbo Pascal? וככה הגענו למצב שאנחנו לא מבינים מאיפה הגיעו כל הקיצורים המוזרים . . .
- פעם היה עניין כזה של “איך נשיג מפתחים? בואו ניקח את הסכמה שהם היו רגילים אליה ב-Editor הישן ונעשה קיצורים דומים ואז הם יעברו ל-Editor החדש”, הברקה שיווקית.
- פנינה נוספת - מי שעובד עם Rails בטוח מכיר את Devise: כנראה ה Go-to של כל מי שרוצה לעשות Authentication, וזו ספריה שאפשר ללמוד ממנה המון ולקחת גם לשפות אחרות.
- למשל - Passport זו הגרסא של Devise עבור Node.js, והרבה ספריות התחילו ככה.
- בכל אופן - יש כאן הסבר למשהו שאולי הספקנו לשכוח: כשעושים Log-in או User registration form, ברגע שמישהו מכניס שם וסיסמא לא נכונים ומקבל בתגובה “אין כזה משתמש” וכו’, נוצר פתח ל user enumeration attack - מישהו שיוצר database ענק ומחכה לראות מתי תגיע תגובה שהססמא נכשלה, וברגע שזה קורה מתווסף user חדש ל - Database . . .
- כאן יש Flag בשם Paranoid, וב-Devise כל מה שצריך זה להפעיל אותו ואז הוא לא מדווח החוצה האם יש או אין User או Password וכו’.
- בספריות של היום זה לא תמיד כל כך קל, ויפה לראות שזה כן קל בעולם של Rails.
- אם כבר דיברנו על .yml ו-.xml וכאלה, נראה ש-Rails עדיין מוביל בתחום הזה.
- (אלון) מסתבר שהרבה מה - Core Team של Rust בנוי ממפתחי Rails…
- (דותן) כן - מפתחי Ruby עשו כמה מעברים, בהתחלה לכיוון Clojure ואח”כ ל-Go - והיום הרבה מהם אכן בתוך Rust, מה שדי משמח אותי.
- (אלון) ל- Rust יש הרצאה על האופן בו ה - Core Team שלהם בנוי, והם אומרים שהם הוסיפו אנשי Python כי הם ראו שהרבה מהמצטרפים החדשים ל - Rust באים משם.
- (דותן) ואני חושב שזה גם עזר בחזרה - יש ספרייה של Serialization של JSON, שמה שקרה הוא שהם לקחו ספרייה כזו מ- Rust (עם ביצועים פסיכיים), עטפו אותה - והיום זו הספרייה הכי טובה ל Serializing / De-serializing ב-Python.
- לא בטוח שהרבה יודעים שכשהם משתמשים בזה, הם בעצם משתמשים ב-Rust.
- האייטם הבא - מצחיק אבל אולי יש לזה שימוש: ספרייה של p-ranav, שלי (דותן) זה נראה בהתחלה כ ran-tav וחשבתי שרן בנה ספרייה של Table Maker עבור ++C בשם tabulate
- קודם כל - כל הכבוד על החזרה למקורות!
- ולגבי הספרייה - יחסית לפרויקט ++C יש לה לא מעט Stars וזה נראה די מגניב - מייצר גרפים וטבלאות ועוד דברים די מודרניים . . .
- למי שעובד עם ++C, ואוהב ++C מודרני (שזה בערך 17 לפי מה שרשום) - יכול לשקול להשתמש בזה.
- ולא לפנות לרן - הוא לא באמת זה שכתב את הספרייה . . .
- וקצת סגירת / פתיחת שנה לרגל 2020 - רשימה של המלצות על ספרים מ-2019
- הרוב הם Non-Fiction, חלק הם סוג-של-טכניים אבל הרוב לא.
- אחד שדותן קרא ועומד מאחורי ההמלצה - Thinking in Systems, by Donella Meadows
- ספר שמדבר על חשיבה מערכתית, ומצאתי שם המון חשיבה הנדסית בנוסף.
- מומלץ.
- עוד ספרייה / כלי מצחיק בשם BusKill - מבירים Dead-man Switch? אז מישהו לקח ובנה כזה עבור ה-Laptop שלו …
- מחובר ל-USB, וברגע שמושכים ומנתקים אותו זה משבית את המחשב.
- אם אתם בורחים מהחוק (אנחנו לא שופטים), יש מצב שזה יהיה לכם שימושי.
- כולל גם תמונה של מתכנת עם כובע גרב שבורח . . .
- ומכאן ל - Apache Pulsar
- חייב להגיד שאני כבר מתחיל להתבלבל עם כל השמות של פרויקטי Apache… יש עוד פרוייקט עם שם דומה של מישהו ישראלי שכתב ב - Clojure ספרייה שקשורה ל-data עם שם דומה
- הכוונה לRon Pressler, כתב גם את quasar.
- זה מעיין Kafka-Killer - מי שרוצה להרוג את Kafka יכול לקחת את Pulsar - אותו דבר, ממומש ב-Production ע”י Yahoo (זה עוד דבר?) וגם ע”י Tencent - לא פראיירים.
- נראה שיש לזה נתוני Performance ו-Latency יותר טובים וכו’.
- למה Java ב-2020? למה Scala ב-2020? ככה . . .
- ב-Kafka אין הרבה Scala, בעיקר Java, אבל בWikipedia כתוב “written in Scala and Java”, אז זה בטוח נכון.
- אז רוצים לעזוב את Kafka? יש מתחרה, מסתבר.
- ואחרון - Things we (finally) know about network queues - apenwarr
- למי שלא מכיר - כל “Stack הרשת” שלנו מורכב מכל מיני תורים (Queues), עד רמת ה-Low-level של ציוד Ethernet, ה-TCP/IP stack וכאלה - כאן יש איזשהו ניתוח מ-2017 על כל מיני דברים שאנחנו סוף כל סוף יודעים על זה.
- נקודה אחת לדוגמא - There are two ways to deal with a full queue: drop packets, or throttle incoming packets (backpressure).
- מה שאהבתי כאן זה שזה מדבר על Network Queues, אבל מי שמבין יכול לחבר 1+1 ולהבין שזה נכון לכל תור, כמו Kafka או Rabbitmq או כל תור שאתם משתמשים בו.
- אני (דותן) חובב של עקרונות Queues, ואם יש Design Patterns של queue systems אני רץ לחפש
- נראה שיש כאן רשימה נחמדה של רעיונות עבור כל מי שמשתמש במערכות מבוססות-תורים (כל אחד בערך) ויש לו בעיות Performance (גם כל אחד בערך)
- עוד עקרון - “Queues exist only to handle burstiness” - אם יש Traffic קבוע בלי Bursts, כנראה שאתה לא צריך Queues אלא constants.
- (אלון) כנראה שזה לא נכון אף פעם . . . העולם לא באמת יציב, בטח לא על ענן של גוגל.
- פותח את הראש למחשבה.
ולחלק המצחיקול (או לפחות הכי מצחיק שהיה לנו) -
- טבלה נחמדה שמציגה 18 שפות תכנות - ולמה נבחר השם שלהן . . .
- למשל: Go נקראת כך כיוון שזה קצר וקל להקליד, Rust כי זה יציב כמו פטריה וכו’
- ל-Java בכלל היה בהתחלה שם אחר ואז החליטו לעבור ל-Java על כוס קפה . . .
- הסיפור הכי מוכר הוא של JavaScript (כי זה הכי דומה ל-Java, וצריך לדחוף את ה-Marketing . . . )
- (דותן) אגב חדשות מהשבוע (של תחילת ינואר 2020) - Plataformatec, החברה שמאחורי Elixir, נקנתה ע”י חברה אחרת (Nubank), ועכשיו נשאלת השאלה מה קורה אם Jose Valim “יוצא לחופשה”, ואם זה נכון להיכנס ל-Elixir כשברור שזה יקרה מתישהו.
הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול
אין תגובות:
הוסף רשומת תגובה