פרק מספר 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 יש הרבה יתרונות, אבל במקו…