ToCode

# הבעיות במערכת החינוך לא קשורות לכסף קל לנסות להגן על מערכת החינוך - מורים ומורות תשושים עומדים מול כיתות גדולות מדי וצריכים ללמד חומר שלא תמיד מעניין את התלמידים. למה כבר ציפית? הם עושים כמיטב יכולתם. תשלמו יותר ותקבלו כיתות קטנות ומורים מאושרים שמרוויחים טוב. אם רק זה היה כל כך פשוט. הבעיות במערכת החינוך לא קשורות לכסף. ברור שיותר קל למורה להסתדר בכיתה של 10 תלמידים מאשר בכיתה של 30, וברור שכמה שמורה תרוויח יותר איכות החיים שלה מחוץ לעבודה תשתפר. מה שלא כל כך ברור הוא מה יקרה באותה כיתה בת 10 תלמידים בזמן הלימודים. כי הבעיות במערכת החינוך הן קודם כל הבעיות שלנו כחברה, והבעיות שלנו בשוק העבודה. סוף עידן הקפיטליזם התעשייתי אומר שאין יותר צורך או יכולת לבנות מפעל טוב יותר, לשפר באמצעות מדידות ולהגיע לשלמות בתאימות לתקן. טלפון שנראה כמו אייפון אבל זול יותר? בעולם תעשייתי רגיל זה היה גורם לאפל לצאת מהשוק. בעולם הפוסט-תעשייתי שלנו, תודה אבל לא תודה. אנחנו (כצרכנים) לא מחפשים את המוצר הגנרי היעיל ביותר שפותר בעיה, אלא את המוצר המעניין, החדשני, עם הסיפור הטוב, שמתאים לנו אישית. ובתוך זה מערכת החינוך לא יודעת מה ואיך ללמד, בדיוק כמו שארגונים רבים לא יודעים איך להתיחס לעובדים שלהם ואיך לייצר את אותה חדשנות שאנחנו צריכים. אנחנו יודעים שהשיטות הישנות לא עובדות. אנחנו יודעים שמעקב אחר עובדים, נהלי עבודה קשיחים, עובדים שאפשר להחליף אותם ברגע ואיומים כל הזמן בפיטורים לא משיגים תוצאות טובות. יש לנו גם תחושה לגבי שיטת העבודה בארגונים שכן מצליחים, אבל אין לנו מספיק ניסיון בעבודה לא תעשייתית. איך בכלל בית ספר לא תעשייתי יכול להתנהל? את מה ימדדו? מה ילמדו בו? מה יהיו מטרותיו? הקפיטליסט התעשייתי אלוף בבניית מערכות במקום אנשים, אבל מה קורה כשמה שאנחנו צריכים הוא אנשים? וכן אנחנו יודעים מה היינו רוצים ללמד: נשמח לקבל בוגרים עצמאיים, שיודעים למצוא בעיות מעניינות ולפתור אותן בצורה יצירתית, שיודעים להתגבר על מכשולים בדרך ולבחור לעצמם אתגרים שמתאימים להם. שיוכלו ללמוד לבד דברים חדשים ויתאימו את עצמם לעולם משתנה. אנחנו פשוט לא יודעים איך ללמד את זה. הדרך קדימה לא קשורה לתוספת תקציב או אפילו לבחירת שיטת עבודה אחרת. אין שיטת לימוד שעובדת שאנחנו יודעים עליה. יש המון השערות וניסיונות ורעיונות שאולי עובדים לחלק מהאנשים ולא עובדים לאחרים. והמחקר הזה צריך להימשך. הדרך קדימה תחייב אותנו להיפרד משיטת הלימוד המוכרת (שלא עובדת), ולהיפתח לרעיונות חדשים שכנראה גם רובם לא יעבדו. הדרך קדימה תחייב אותנו להכיר בזה שחלק מהילדים שלנו יהיו שפני ניסויים באותו מסע, ומחייבת אותנו לתת להורים הרבה יותר אפשרויות בחירה לגבי המסע הספציפי של כל ילד. בתקופה הקרובה אנחנו צריכים חדשנות ולא יציבות. וכן זה מפחיד, מסוכן ועלול לא לעבוד. הבעיה שהאלטרנטיבה הנוכחית גם לא עובדת.

# איך זה ירגיש? איך זה ירגיש להשתמש בשפה אחרת, אולי שפה פונקציונאלית בשביל הפיצ'ר הבא? איך זה ירגיש לבנות סרביס במקום להרחיב את המונולית? איך מרגיש לעבוד עם מנגנון Deployment אוטומטי? או ידני? ומה אם הפעם נכתוב את הבדיקות לפני שנכתוב את הקוד? או שנוותר לגמרי על הבדיקות? ומה יקרה אם בפיצ'ר הבא ננסה לפתח רק על ה Trunk בלי Branch-ים ב git? שיגרת פיתוח טובה היא כזאת שמאפשרת גם לקחת אוויר ולגוון. וכן הסטטוס קוו הוא כח חזק, גם אנחנו, גם המנהלים שלנו וגם חברינו לצוות יודעים למצוא מיליון סיבות למה צריך להמשיך לעשות דברים כמו שאנחנו כבר עושים. הרבה פעמים אלה סיבות טובות אבל אני שם לב שהרבה פעמים הן מתבססות על דברים שקרו בעבודות קודמות או הרגלים שכבר שכחנו מה המקור שלהם "אני לא בטוח למה אנחנו לא משתמשים ב Micro Services. בואו ננסה לכתוב פיצ'ר אחד בגישה זו ולראות מה יקרה" יכול להיות כיף ומלמד, בלי קשר אם בסוף נעבור לגישת Micro Services או שנמשיך בשיגרה שעובדת לנו.

# הדרך לפעם ביום העצה שאני הכי אוהב לתת לאנשים שמתחילים קורס היא להשקיע שעה ביום בלימוד. עם שעה ביום של לימוד Python, אחרי חודש יהיה לכם בסיס טוב בפייתון ותוכלו להמשיך בקצב שלכם, ואותו דבר עם רוב הנושאים הטכנולוגיים שאני מלמד פה. אבל זו עצה מאוד תמימה. הבעיה בעצה הזאת היא הקושי ביישום. כן שעה ביום בימים הראשונים עוד מצליחים למצוא, אבל זה יש את הלחץ בעבודה ואת הבאג בפרודקשן ואת המסיבה לילדים ולפני ששמת לב הצלחת למצוא שעתיים בכל השבוע, וגם זה במקרה הטוב. בשבוע שאחרי אפילו את השעתיים האלה יהיה קשה למצוא. מצד שני מי שכן מצליחים לבנות את ההרגל של ללמוד שעה ביום טכנולוגיות חדשות, יכולים אחרי לימוד פייתון להמשיך ללמוד Front End ואחרי זה AI ואחרי זה פיתוח אפליקציות והשמים הם הגבול. אנשים שיש להם את ההרגל הזה מצליחים יותר בקורסים וגם מתקדמים מהר יותר בתור מפתחים. לכן לפני שנרצה לדבר על איך ללמוד פייתון בצורה יעילה, אולי שווה לדבר על איך ללמוד בצורה יעילה, או איך לבנות הרגל של לימוד שעה ביום. הנה כמה טיפים שעזרו לי: 1. הרגלים נבנים לאט. במקום להתחיל עם שעה ביום ולהתייאש, עדיף להתחיל עם שעה בשבוע, אחרי זה לעלות לשעתיים בשבוע ולהמשיך להעלות לאט. גם אם ייקח חצי שנה לייצר הרגל של לימוד שנה ביום, זה עדיין שווה את ההשקעה. 2. גיימיפיקציה עוזרת. אפשר ליצור טבלא שבועית ולתכנן מראש באיזה ימים תלמדו, אפשר להשתמש באפליקציות כדי לשמור על "רצפים" ולאסוף מטבעות וירטואליים. שחקו עם זה לראות מה עובד לכם. 3. חברים עוזרים. אם אני בעבודה מתחייב להעביר סשן פעם בשבוע על נושא אז יהיה לי יותר קל למצוא שעתיים באותו שבוע ללמוד את הנושא. אם אחרי זה אני מוסיף על זה Meetup פעם בחודש אז יהיה לי יותר קל למצוא זמן במהלך החודש. 4. גיוון עוזר. לא צריך כל יום לכתוב קוד או לקרוא פוסט מקצועי. אפשר שעה אחת בשבוע לשמוע פודקסט, שעתיים לכתוב קוד, עוד שעה לראות הרצאה ביוטיוב וכך כל פעם להוסיף עוד פעילות שתוסיף עוד זמן לימוד. יש לכם הרגלים יומיים שאתם מצליחים להתמיד בהם? נסו להיזכר איך יצרתם אותם ומה מדרבן אתכם להמשיך. רעיונות שלא חשבתי עליהם כאן יתקבלו בברכה בתגובות.

# איך לבנות אוטומטית Docker Image מכל קומיט גיטהאב מספקים שני משאבים מופלאים ובחינם - אחד נקרא Actions והשני Packages. יחד הם מאפשרים לנו ליצור Docker Image במאגר פרטי מכל קומיט ובצורה אוטומטית. בואו נראה את זה בפעולה. ## היתרון של אימג' מכל קומיט אבל לפני שנגיע להסבר הטכני בואו נדבר על הערך של בניית אימג' אוטומטית מכל קומיט - הוא היכולת לבנות מהר ובצורה מדויקת סביבת פיתוח לכל קומיט. אם מפתחים צריכים להפעיל build אחרי שמושכים את המאגר, אז כל מפתח שמפעיל build עשוי לקבל תוצאה קצת שונה (בגלל סקריפטים שרצים בזמן בניית האימג'), ועשויים להיתקל בבאגים מוזרים שנובעים מבעיות בבניה. לעומת זאת אם יש לנו בילד אוטומטי בכל קומיט, אז מאוד קל למפתחים להיות בטוחים שאנחנו עובדים בדיוק על אותה גירסה וקל להרים מהר שרת עם גירסה של אימג' לפי קומיט בשביל לשתף עם אנשי מוצר או QA. את הקמת השרת אפשר יהיה אפילו לעשות אוטומטית. בפוסט זה נראה איך להשתמש ב Github Action כדי לבנות אימג' מ Dockerfile, ואיך להשתמש במאגר אימג'ים (Registry) של Github Packages כדי לאחסן בו כל אימג' שאנחנו בונים מתויג לפי מזהה הקומיט. ## דרישות קדם - אסימון גישה לפני שאפשר יהיה לדחוף אימג' אוטומטית ל Registry עלינו לקבל אסימון גישה עם הרשאות דחיפה. בשביל זה ניכנס למסך הזה: https://github.com/settings/tokens/new נבחר את ההרשאות write:packages ו read:packages, נשמור ונעתיק הצידה את אסימון הגישה שיצרנו. לאחר מכן ניצור פרויקט גיטהאב וניכנס למסך ההגדרות שלו ושם ל Secrets, וניצור סוד חדש בשם PAT ונדביק את האסימון שיצרנו בתור ערך של הסוד הזה. ## מבנה הפרויקט הפרויקט שאני עובד עליו נקרא express-app ואפשר למצוא אותו בקישור: https://github.com/ynonp/express-app בתוך תיקיית .github/workflows נמצא קובץ האקשן:

name: 'build'

on:
  push:
    branches:
    - main
  pull_request:

jobs:
  build:
    name: 'Build'
    runs-on: ubuntu-latest
    steps:
      - name: "Build:checkout"
        uses: actions/checkout@v2
      - name: 'Build:dockerimage'
        uses: docker/build-push-action@v1
        with:
          registry: ghcr.io
          username: "ynonp"
          password: ${{ secrets.PAT }}
          repository: ynonp/express-app
          tags: latest,${{github.sha}}

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

FROM node:18-alpine
ENV NODE_ENV=production

WORKDIR /app

COPY ["package.json", "package-lock.json*", "./"]

RUN npm install --production

COPY . .

CMD ["node", "./bin/www"]

עבור פרויקט Node.JS. ## תוצאה - בניה וזה הכל. מכאן כל פעם שאני דוחף קוד לפרויקט באופן אוטומטי נבנה Image המתויג לפי ה SHA של הקומיט ועולה לריפוזיטורי פרטי שלי על Github Packages. ה URL של הריפוזיטורי לדוגמה שיצרתי הוא: https://github.com/users/ynonp/packages/container/package/express-app ומה שהכי טוב עכשיו זה שאפשר לחשב אוטומטית את שם האימג' לפי ה Hash של הקומיט לדוגמה:

ghcr.io/ynonp/express-app:588d27d0e9640323d6b2554581305cef4100c44f

ולכן פקודה כזאת תפעיל את האימג' שמתאים ל SHA מסוים בדוקר על המכונה שלי:

$ docker run -p 3001:3000 --rm ghcr.io/ynonp/express-app:588d27d0e9640323d6b2554581305cef4100c44f

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

# הגנה על קורסים דיגיטליים החברים ברב מסר הזמינו אותי לראיון בנושא הגנה על קורסים דיגיטליים. אני מסכם גם כאן את עיקרי הדברים עליהם נדבר. וכן כשיפרסמו את ההקלטה אשים פה גם קישור. ## מפת איומים בואו נתחיל בשאלה - כמה זמן לוקח להכין קורס דיגיטלי? אם לא הכנתם אחד אני בטוח שיש לכם איזה מספר בראש. אני יודע שלי היה. וכמו בפיתוח תוכנה גם כאן לא היה קשר בין ההערכה שלי לכמות העבודה בפועל. ואחרי שהשקעת את השלושה, חמישה או עשרה חודשים בבניית קורס, לא תעשה הכל כדי להגן עליו? לא מגיע לך להרוויח מכל העבודה הקשה? מה פתאום שמישהו יהנה מהקורס בלי לשלם עליו?! בהגנה על קורס דיגיטלי האינטואיציה ברורה אבל המציאות יותר מורכבת. בשביל להגן על קורס דיגיטלי עלינו להבין מה האיומים איתם עלינו להתמודד, ומי השחקנים המרכזיים במגרש. הנה הרשימה שלי: 1. הורדה והפצה ב Torrent או לחברים. 2. הורדה והעלאה לאתר קורסים מתחרה (לפעמים תוך הוספה או מחיקה של Watermark). 3. שיתוף לינק לצפיה ישירה בתוכן ברשת חברתית. 4. שיתוף פרטי גישה ברשת חברתית או עם חברים. ובסיכום המקרים אפשר להגיע לשלושה וקטורי תקיפה מרכזיים: אנשים שיורידו את התוכן, אנשים שיעקפו את מגבלות הגישה ויצפו בתוכן דרך קישור ישיר ואנשים שישיגו גישה לפרטי חשבון של משתמש חוקי. כנגד תקיפות אלה נוכל להשתמש במנגנוני ההגנה הבאים: 1. נוכל להגן על התוכן שלנו באמצעות DRM ולחסום צפיה לא מורשית ברמת הקובץ. 2. נוכל להגן על הלינקים הישירים לתוכן, למשל לדאוג שהתוכן ייפתח רק אם הדפדפן מגיע באמת מהדומיין שלנו. 3. נוכל להגן על החשבונות במערכת הקורסים שלנו ולזהות אם אותו חשבון מחובר ממכשירים שונים או מכתובות IP שונות. ## הצד השלילי של הגנה אבל הבעיה האמיתית בהגנה על תוכן היא שלעולם לא נצליח לעשות עבודה מספיק טובה, ולא משנה איזו הגנה נבחר זה תמיד יפגע בחווית המשתמש. דוגמה פשוטה מחוץ לעולם הקורסים היא ספרים. בגלל כל מיני חוקי זכויות יוצרים של האיחוד האירופי אי אפשר לקנות ספר בצרפתית במקור באמזון אם אתם מבצעים את הקניה מישראל. ויותר מזה, אם במקרה הצלחתם לרמות את אמזון עם VPN וכרטיס אשראי זר וכתובת זרה, עדיין לא תוכלו להפעיל את הספר על הקינדל שלכם כי הוא מגיע עם DRM. אבל, את אותו ספר תוכלו להשיג בחינם ללא DRM באינסוף אתרי ספרים פיראטיים ברשת. מרוב רצון להגן על התוכן נוצר מצב שאין ברירה אלא להוריד עותק פיראטי. בחזרה לקורסים דיגיטליים בואו נבחן מחדש את ההגנות שתיארתי- 1. הגנה באמצעות DRM על הקבצים עצמם היא מעולה, אבל היא מחייבת את הצופים החוקיים שלכם, ששילמו ממיטב כספם על הקורס, להשתמש בתוכנה ייעודית לצפיה. מעבר לזה, יש היום אינסוף כלים להסרת DRM מקבצים, כך שמי שיוריד את הקבצים וירצה להפיץ אותם בסך הכל יצטרך להפעיל עוד כלי אחד כדי למחוק את ההגנה. 2. ההגנה המקובלת על הלינק הישיר לצפיה היא באמצעות וידוא דומיין. זאת הגנה טיפשית כי כל אחד יכול לשנות את קובץ ה hosts במחשב ולהתחזות לאתר מדומיין אחר. הדבר היחיד שהגנה זו מגינה מפניו זה משתמשים שיפיצו ברשת חברתית או לחברים קישורים לסרטי הוידאו מהקורס שלכם. 3. הגנה באמצעות בדיקת גלישה ממספר מכשירים במקביל יכולה לעבוד, אבל לרוב בגלל באגים ואתגרים טכניים אחרים הנפגעים העיקריים מהגנה כזאת הם המשתמשים החוקיים, שלא יוכלו לגשת לתוכן או שיצטרכו להתחבר מחדש כל כמה ימים. ## לא כל "פיראטיות" היא רעה בסוף המטרה שלנו בתור יוצרי תוכן היא לעזור לאנשים. כן אנחנו רוצים למכור קורסים כי הכסף עוזר לנו לייצר עוד קורסים, כן אנחנו חושבים שמי שהשקיע חודשים ולפעמים יותר בבניית קורס צריך להיות מתוגמל על זה ובמיוחד אם הקורס הוא טוב, אבל לא כל פיראטיות היא רעה. לא לכולם יש כסף פנוי לקורס שלך, לא משנה כמה הוא מעניין או טוב. לא כולם מבינים את הערך של הקורס לפני שצופים בו. וכבר קרה לי לא מעט פעמים שאנשים נחשפו לתכנים פה באתר בכל מיני דרכים בלי לשלם וחזרו לומר תודה ולשלם אחרי הצפיה ואחרי שהקורס עזר להם למצוא עבודה. ## מה עושים בשורה התחתונה ההתמודדות עם גניבת קורסים היא לא טכנית. לא משנה כמה מנגנוני הגנה טכניים נשים, כשאנשים יצטרכו לעקוף אותם הם ימצאו את הדרך, ובמיוחד כשמדובר במוצר שכל כך קל לגנוב אותו כמו קורס דיגיטלי.

# המיומנות הכי חשובה שחסרה ל Chat GPT למנועי בינה מלאכותית כמו Chat GPT וחבריו יש עדיין בעיה גדולה - הם לעולם לא יענו בשאלה. הם לא יודעים מתי צריך לבקש עוד מידע, ומתי השאלה מעידה על כך שאתה לא באמת מבין מה אתה צריך. כשאני אשאל אותו למה כואב לי הראש, הוא יסביר שהוא לא רופא ואז ינחש מה הבעיה. כשאני אשאל איך לכתוב אימייל שימכור אני אקבל תשובה מפורטת, אפילו שאין לו מושג למי אני מנסה למכור ומה. כשאני אשאל באיזו תדירות לשלוח הודעות למשתמשים שלי הבוט יכתוב אינסוף המלצות, אפילו שהוא לא יודע כלום על העסק שלי או המשתמשים שלי. וכמובן שהתנהגות זו תימשך גם בכל שאלה טכנית. בלי יכולת להבין את הבעיה האחריות נשארת בידיים שלי. בדיוק כמו עם מנוע חיפוש, עליי למצוא את ה Prompt הנכון שיתאר את הבעיה בצורה מספיק מדויקת כדי לקבל מהבוט את התשובה הנכונה. "אני לא יודע" ו"אני צריך עוד נתונים" הם משפטים קסומים והיכולת להגיד אותם ולהתקדם עם האי וודאות תישאר היתרון הגדול שלנו לתקופה הקרובה. היום הוא זמן טוב להתאמן על מיומנויות אלה.

# איך להתקין k3s יחד עם ה Dashboard על multipass מולטיפאס הוא כלי להרצת מכונות לינוקס וירטואליות קטנות במהירות על מכונות Mac ו Windows. בין השאר אפשר להיעזר בו כדי לשחק עם קלאסטרים, כי קלאסטרים צריכים הרבה מכונות ועם מולטיפאס מאוד קל ליצור מכונות חדשות. בואו נלך להתקין קלאסטר של שלוש מכונות, מנוהל על ידי k3s (שהוא סוג של קוברנטיס פחות שמן), נתקין עליו את לוח הבקרה של Kubernetes וניגש לממשק הניהול מהמחשב המארח. ## התקנת k3s על multipass אני מתחיל עם המדריך כאן: https://andreipope.github.io/tutorials/create-a-cluster-with-multipass-and-k3s.html. רק שבמקום להתקין את גירסה 18.04 אני מתקין את 22.04. כלומר נפעיל:

for f in {1..3}; do
    multipass launch -c 1 -m 1G -d 4G -n k3s-$f 22.04
done

לאחר מכן מתקין מכונה ראשית על המכונה הראשונה שנוצרה:

multipass exec k3s-1 -- bash -c "curl -sfL https://get.k3s.io | sh -"

מושך את הטוקן וכתובת ה IP ומחבר אליו את שתי המכונות האחרות:

IP=$(multipass info k3s-1 | grep IPv4 | awk '{print $2}')
TOKEN=$(multipass exec k3s-1 sudo cat /var/lib/rancher/k3s/server/node-token)

for f in {2..3}; do
     multipass exec k3s-$f -- bash -c "curl -sfL https://get.k3s.io | K3S_URL=\"https://$IP:6443\" K3S_TOKEN=\"$TOKEN\" sh -"
done

נוודא שהכל עובד:

$ multipass exec k3s-1 sudo kubectl get nodes
NAME    STATUS   ROLES                  AGE     VERSION
k3s-1   Ready    control-plane,master   2m48s   v1.26.5+k3s1
k3s-2   Ready    <none>                 56s     v1.26.5+k3s1
k3s-3   Ready    <none>                 46s     v1.26.5+k3s1

## התקנת לוח הבקרה השלב הבא הוא התקנת ה Kubernetes Dashboard על הקלאסטר החדש שלנו. אני הולך לפי המדריך כאן: https://gist.github.com/jannegpriv/06427e4ecc2a17f317a4bebc32b6445c קודם כל נכנס למכונה הראשונה:

multipass shell k3s-1

בתוך המכונה מריץ את הפקודות:

mkdir ~/k3s-dashboard
cd ~/k3s-dashboard
GITHUB_URL=https://github.com/kubernetes/dashboard/releases
VERSION_KUBE_DASHBOARD=$(curl -w '%{url_effective}' -I -L -s -S ${GITHUB_URL}/latest -o /dev/null | sed -e 's|.*/||')
sudo k3s kubectl create -f https://raw.githubusercontent.com/kubernetes/dashboard/${VERSION_KUBE_DASHBOARD}/aio/deploy/recommended.yaml

ממשיך ליצירת שני קבצי ה yaml מתוך אותו מדריך:

# service-account.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin-user
  namespace: kubernetes-dashboard

# cluster-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: admin-user
  namespace: kubernetes-dashboard

ובסוף נתקין את שני הקבצים:

sudo k3s kubectl apply -f service-account.yaml
sudo k3s kubectl apply -f cluster-role.yaml

הדרכים המרכזיות לחשוף את ממשק הניהול החוצה למחשב המארח הן שימוש ב Proxy, שימוש ב Port Forwarding והתקנת Ingress Controller. אנחנו נשתמש ב Port Forwarding כי זה הכי פשוט. נפעיל עדיין מתוך המכונה הוירטואלית:

sudo k3s kubectl port-forward -n kubernetes-dashboard service/kubernetes-dashboard 8443:443 --address 0.0.0.0

ולאחר מכן נוכל מתוך המחשב המארח לגלוש לכתובת ה IP של המכונה הוירטואלית בפורט 8443 כדי להגיע לממשק הניהול. שימו לב שהדפדפן יתלונן על Certificate לא תקין (כי זה Self Signed של הקלאסטר). פשוט נדלג על האזהרה. אחרי שיש לנו גישה נשאר לעבור את מסך החיבור. בשביל זה צריך לייצר טוקן עם הפקודה:

sudo k3s kubectl -n kubernetes-dashboard create token admin-user

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

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

# חמישה בוטים לטלגרם שתוכלו לכתוב כפרויקט צד אחרי שהתרגלנו לדבר בצ'ט בווטסאפ ועם Chat GPT אין דבר יותר טבעי מלהמשיך לתקשר עם בוטים גם במקומות אחרים. ברמה הטכנית בוטים מציעים דרך פשוטה לבנות ממשק לפרויקט שיהיה אינטואיטיבי למשתמשים ויחסית פשוט לפיתוח. אם אתם מחפשים רעיון לפרויקט צד, בוט לטלגרם יכול להיות משהו שכיף לבנות ולשחק איתו כשהוא באוויר. הנה חמישה רעיונות לבוטים שתוכלו לבנות בזמנכם הפנוי. ## בוט אקו את חווית פיתוח הבוטים תוכלו להתחיל עם בוט פשוט ששולח לכם בחזרה כל הודעה שתשלחו לו. בוט כזה ייתן לכם הזדמנות ללמוד איך לתקשר עם BotFather, איך לקבל טוקן ואיך להריץ בוט. מתכנתי פייתון יכולים להתחיל עם הספריה python-telegram-bot. מתכנתי Node.JS יכולים לנסות את node-telegram-bot-api. וכאן יש רשימה די ארוכה של ספריות בכל השפות לבניית בוטים לטלגרם: https://core.telegram.org/bots/samples את הבוט אפשר להריץ על כל שרת לינוד או אם אין לכם כח להתקנות להשתמש ב PaaS כמו code capsules. כאן יש מדריך להרצת בוט על השירות שלהם: https://codecapsules.io/docs/deployment/how-to-deploy-python-telegram-bot-to-production/ ## בוט שעוזר להגות מילים באנגלית אחרי שהעלינו בוט אקו והצלחנו לתקשר איתו, אפשר לעבור לבוטים מעניינים יותר. בדוגמה הבאה נשדרג את בוט האקו כך שיחזיר את הטקסט ששלחנו לו בהודעה קולית. תוכלו להשתמש ב AWS Polly כדי לתרגם טקסט לקובץ קול, ואחר כך חפשו ב API של הספריה שבחרתם איך שולחים הודעה קולית. ## בוט תזכורות בכתיבת בוט אנחנו מקבלים במתנה את הטיפול בהתחברות וזיהוי משתמשים - כי טלגרם מזהה אותם בשבילנו. המשימה הבאה תהיה לכתוב בוט שמייצר רשימת תזכורות למשתמשים. כל משתמש יוכל לשלוח לבוט הודעת "תזכיל לי" שתכיל את התאריך והשעה של התזכורת וטקסט התזכורת, והבוט ישלח חזרה הודעה בשעה שנבחרה. כדי לעשות את הפרויקט מעניין תוכלו לשמור את כל התזכורות בבסיס נתונים, ותוכלו לשחק עם פיענוח הפקודה ולתת גמישות בהבנת הפקודות - למשל "תזכיר לי לסגור את האש עוד 15 דקות" או "תזכיר לי להוציא את הכלב כל בוקר בשמונה". ## בוט קורא רסס אחרי שלמדתם מבוט התזכורות איך לשמור מידע למשתמשים ספציפיים ואיך לשלוח הודעה מתהליך רקע, נתקדם עוד צעד ונעקוב אחר פרסומים חדשים באינטרנט. כל משתמש בבוט יוכל לשלוח הודעת "הירשם ל" עם כתובת אתר והרישום יישמר בבסיס נתונים של הבוט. פעם ביום או כמה פעמים ביום הבוט יתעורר, יחפש כתבות חדשות בכל האתרים שאנשים רשומים אליהם וישלח לכל אחד את המאמרים החדשים מהאתרים שהוא רשום אליהם. בשביל לעשות את הפיתוח מעניין תוכלו להשתמש ב Airflow כדי לנהל את תהליכי הרקע, ושימו לב לא לשלוח לכולם הודעות באותה שעה כדי לא לעבור את מגבלת ההודעות לדקה של טלגרם (כן יום אחד יהיו לבוט שלכם אלפי משתמשים אז צריך להיערך בהתאם). אם גיליתם מאמר שאלף משתמשים רוצים לקבל תצטרכו לשלוח אותו בצורה מדורגת. ## בוט שמשחק איקס עיגול עכשיו שהשתלטנו על בוטים, בסיסי נתונים ועבודה ברקע עדיין נשארה עוד יכולת מדליקה של בוטים בטלגרם, והיא הטיפול במשתמשים ש"מזכירים" את הבוט שלכם בשיחה. למשימה האחרונה נכתוב בוט שכשמזכירים אותו בשיחה הוא מתפרץ ושולח לוח משחק של איקס עיגול. כל משתמש בתורו מודיע לבוט איפה רוצה לשחק, והבוט ישלח הודעה כשאחד המשתמשים בשיחה מנצח. שימו לב שהפעם לא צריך בסיס נתונים, ובמקום כדאי להשתמש במנגנוני ניהול ה Context של ספריית הבוטים שבחרתם. מיטיבי לכת כאן מוזמנים להחליף את המשחק או לאפשר לבוט לשחק מספר משחקים.