שלום אורח התחבר

הבלוג של ינון פרק

טיפים קצרים וחדשות למתכנתים

מעדיפים לקרוא מהטלגרם? בקרו אותנו ב:@tocodeil

או הזינו את כתובת המייל וקבלו את הפוסט היומי בכל בוקר אליכם לתיבה:

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

ואז התחילו הבעיות:

  1. הבוט החדש לא הצליח לפצל הודעות ארוכות כמו שצריך

  2. הבוט החדש לא שלח הודעות Markdown אלא טקסט רגיל, ולכן דוגמאות הקוד הופיעו שבורות בערוץ.

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

  1. את הקוד כתבתי ישירות על שרת ה Production ב vi.

  2. את הטוקן של טלגרם כתבתי Hard Coded בתוך הסקריפט.

  3. על Source Control או בדיקות לא היה מה לדבר.

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

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

  1. להעביר את הקוד לגיט מסודר.

  2. להוסיף בדיקות ל flows החשובים או לפחות לאלה שהיו שבורים.

  3. לבנות מנגנון Deploy מסודר שישתמש ב CI (במקום להעתיק קבצים עם rsync).

  4. להעביר החוצה סודות למשתני סביבה.

וזה בדיוק היה שלב 2 בפיתוח הבוט, שאולי חלקכם שמתם לב אליו בפירסומים והמחיקות שעשיתי במהלך אתמול. הקוד המעודכן של הבוט עלה לגיטהאב ואתם מוזמנים לקרוא אותו כאן: https://github.com/ynonp/blog-to-telegram

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

תוספת שניה לקוד היא הקובץ .github/workflows שמעלה מכונה שמתקינה את כל התלויות ומריצה את התוכנית פעם ביום בשעה שמונה בבוקר. אני מקווה שהמעבר ל Github Action יגרום לסקריפט להיות יותר יציב ולא להישבר גם אם השרת עמוס או שודרג. זה ה Workflow:

# This workflow will install Python dependencies, run tests and lint with a single version of Python
# For more information see: https://help.github.com/actions/language-and-framework-guides/using-python-with-github-actions

name: publish-daily-post-to-telegram

on: 
  workflow_dispatch:
  schedule:
    - cron:  "0 8 * * *" 


permissions:
  contents: read

jobs:
  publish:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Set up Python 3.10
      uses: actions/setup-python@v3
      with:
        python-version: "3.10"
    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
    - name: run
      env:
        TELEGRAM_TOKEN: ${{ secrets.TELEGRAM_TOKEN }}
      run: |
        python blog_to_telegram/publish_daily_post.py

המעבר לגיטהאב ול Workflow גם הכריח אותי להוציא את הסוד מהקובץ לתוך Secret של גיטהאב, וקידם אותי עוד צעד בדרך לקוד טוב יותר.

כמובן ששלב שני הוא לא סוף הדרך. נשאר עוד:

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

  2. להוסיף בדיקות (כרגע יש רק בדיקות למנגנון פיצול ההודעות).

  3. להוסיף קובץ Readme ותיעוד בתוך הקוד.

אבל זה יחכה לבאג הבא או ל Pull Request מכם. מה שיבוא קודם.

מתכנת ריילס, גם אם מאוד מוכשר, אבל שלא נגע בריילס 5 שנים, יתקשה למצוא בזה עבודה היום.

מתכנתת ווב, אפילו מאוד מוכשרת, שפעם אחרונה שכתבה קוד JavaScript היתה לפני חמש שנים ב jQuery, תתקשה למצוא עבודה היום.

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

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

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

  1. לכתוב סקריפטים קטנים בפייתון או ב bash, אפילו שאנחנו כותבים קוד ב Java.

  2. להמשיך לעבוד בלינוקס על הלפטופ, אפילו שבמקום החדש מותר לעבוד גם ב Windows.

  3. לבנות ממשקים או אפליקציות קטנות לדברים "שוליים" כמו ממשק שמראה למי בחברה יש יום הולדת החודש.

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

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

הבעיה עם תיעוד היא פער הזמנים בין הרגע שמישהי כותבת אותו לרגע שמישהי צריכה אותו. זה גורם לאנשים לכתוב תיעוד גרוע (כי "מי בכלל יקרא את זה") ולאנשים אחרים לעשות טעויות כי דברים בסיסיים לא כתובים בתיעוד. כמובן שיש גם יוצאים מן הכלל - ולכן בשביל לקבל השראה הנה שלוש דוגמאות לתיעוד מוצלח מפרויקטי קוד פתוח ב Python ו JavaScript.

המשך קריאה...

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

המשך קריאה...

בוובינר WSL שהתקיים אתמול רציתי להראות שכתובת ה IP של מכונת הלינוקס הוירטואלית שונה מכתובת ה IP של מכונת החלונות שמארחת אותה. הופתעתי לראות שה Ubuntu הוירטואלי לא ממש שמח להריץ ifconfig. וזה לא בגלל שהיה וירטואלי.

הפקודה ifconfig היא מיושנת ויש לה כמה מגבלות שלעולם לא יתוקנו, ולכן הפקודה המודרנית והמומלצת לשימוש היא ip. בשביל למצוא כתובת ip של מכונה אני יכול להפעיל:

$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp0s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:1f:e8:4c brd ff:ff:ff:ff:ff:ff
    inet 192.168.64.4/24 brd 192.168.64.255 scope global dynamic enp0s1
       valid_lft 56632sec preferred_lft 56632sec
    inet6 fd5e:dcce:7fd0:a7fb:5054:ff:fe1f:e84c/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 2591997sec preferred_lft 604797sec
    inet6 fe80::5054:ff:fe1f:e84c/64 scope link
       valid_lft forever preferred_lft forever
3: br-20cce5ed46b0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:2a:b6:7a:9c brd ff:ff:ff:ff:ff:ff
    inet 172.20.0.1/16 brd 172.20.255.255 scope global br-20cce5ed46b0
       valid_lft forever preferred_lft forever
4: br-9946704f08d6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:c3:91:58:ec brd ff:ff:ff:ff:ff:ff
    inet 172.18.0.1/16 brd 172.18.255.255 scope global br-9946704f08d6
       valid_lft forever preferred_lft forever
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:4d:37:b0:5c brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

וכמו עם ifconfig גם פה אני יכול לסנן את כל הבלאגן:

$ ip addr show | grep -w inet
    inet 127.0.0.1/8 scope host lo
    inet 192.168.64.4/24 brd 192.168.64.255 scope global dynamic enp0s1
    inet 172.20.0.1/16 brd 172.20.255.255 scope global br-20cce5ed46b0
    inet 172.18.0.1/16 brd 172.18.255.255 scope global br-9946704f08d6
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0

אפשר גם להפעיל ולכבות איתה ממשקי רשת, אבל המתג שאני אהבתי הוא בכלל האות n, שמציגה את כל השכנים ברשת מפרוטוקול arp:

$ ip n
192.168.64.1 dev enp0s1 lladdr 52:ed:3c:d3:64:64 REACHABLE
fd5e:dcce:7fd0:a7fb:10c8:64d2:15b:ca05 dev enp0s1 lladdr 52:ed:3c:d3:64:64 router STALE
fe80::50ed:3cff:fed3:6464 dev enp0s1 lladdr 52:ed:3c:d3:64:64 router STALE

דף התיעוד הוא כאן: https://linux.die.net/man/8/ip

והיום הוא יום מצוין להתחיל להתרגל. ואם האצבעות שלכם ממש מתעקשות על התחביר הישן, תמיד אפשר להפעיל:

$ alias ifconfig="ip addr show"

ולהרגיש כאילו כלום לא השתנה.

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

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

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

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

מפה לשם ובמקום להמשיך לזרוק זמן על שידרוג ספריות באליקסיר הלכתי לשרבט איזה סקריפט פייתון שרק שולח הודעה על פוסטים חדשים לערוץ. זה מה שיצא:

import requests
import telepot
import re

def daily_post_url():
    response = requests.get(
        'https://www.tocode.co.il/blog',
        headers={'Accept': 'application/json'},
    )
    json_response = response.json()

    return json_response['blog']['posts'][0]['href']

def post_content(url):
    response = requests.get("https://www.tocode.co.il" + url + '/md')
    return response.text

def split_body_to_messages(body):
    output = re.findall(r"(.{1,4096}\b)", body, re.S)
    return output

url = daily_post_url()
body = post_content(url)

chat_id = "@tocodeil"
bot = telepot.Bot('my-secret-token')
bot.sendMessage(chat_id, "https://www.tocode.co.il" + url, disable_web_page_preview=None)

for msg in split_body_to_messages(body):
    bot.sendMessage(chat_id, body)

וכן ברור שגירסת האליקסיר יותר יפה ויכולה לעשות הרבה יותר דברים (כמו לענות להודעות), ובטח גם הביטוי הרגולארי שמפצל הודעה להודעות קצרות יותר יצטרך שידרוג אחרי שננסה אותו על כמה הודעות, אבל יש גם יתרונות:

  1. קוד פשוט וקצר בהרבה (31 שורות לעומת מעל 700 בבוט הישן).

  2. רץ בתור סקריפט מ cron ולא צריך להישאר כל הזמן באוויר.

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

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

נ.ב.ב. היום בעשר בבוקר וובינר על WSL. שווה לקפוץ להגיד שלום.

"תיקון לצבעים"

"תיקון שגיאת כתיב"

"תיקוני UI"

"התחלתי לכתוב CSS"

"הוספתי בדיקות"

"שיפורים"

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

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

"תיקנתי את צבע הכותרת הראשית לפי ההערות מהמעצב. כרטיס ג'ירה עם העיצוב #121"

"תיקון מספר שגיאות כתיב בעמוד אודות"

"עדכנתי את קרוסלת התמונות בעמוד הבית כך שתאפשר ניווט מקלדת והקפאת האנימציה".

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

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

במודול itertools של פייתון יש פונקציה בשם pairwise שמקבלת איטרטור ומחלקת אותו לזוגות. זה נראה ככה:

>>> list(itertools.pairwise(range(100)))
[(0, 1), (1, 2), (2, 3), (3, 4), (4, 5), (5, 6), (6, 7), (7, 8), (8, 9), (9, 10), (10, 11), (11, 12), (12, 13), (13, 14), (14, 15), (15, 16), (16, 17), (17, 18), (18, 19), (19, 20), (20, 21), (21, 22), (22, 23), (23, 24), (24, 25), (25, 26), (26, 27), (27, 28), (28, 29), (29, 30), (30, 31), (31, 32), (32, 33), (33, 34), (34, 35), (35, 36), (36, 37), (37, 38), (38, 39), (39, 40), (40, 41), (41, 42), (42, 43), (43, 44), (44, 45), (45, 46), (46, 47), (47, 48), (48, 49), (49, 50), (50, 51), (51, 52), (52, 53), (53, 54), (54, 55), (55, 56), (56, 57), (57, 58), (58, 59), (59, 60), (60, 61), (61, 62), (62, 63), (63, 64), (64, 65), (65, 66), (66, 67), (67, 68), (68, 69), (69, 70), (70, 71), (71, 72), (72, 73), (73, 74), (74, 75), (75, 76), (76, 77), (77, 78), (78, 79), (79, 80), (80, 81), (81, 82), (82, 83), (83, 84), (84, 85), (85, 86), (86, 87), (87, 88), (88, 89), (89, 90), (90, 91), (91, 92), (92, 93), (93, 94), (94, 95), (95, 96), (96, 97), (97, 98), (98, 99)]

בשביל לחלק לקבוצות יותר גדולות אין פיתרון מובנה, אבל אנחנו יכולים לבנות אחד יחסית בקלות. בואו ננסה ניסיון ראשון:

def nwise(iterable, n):
    while True:
        yield [next(iterable) for i in range(n)]

אבל כשאני מנסה להפעיל את הפונקציה באותה צורה כמו pairwise אני נכשל:

>>> list(nwise(range(100), 2))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in nwise
  File "<stdin>", line 3, in <listcomp>
TypeError: 'range' object is not an iterator

וזה ברור - range אינו איטרטור. הפונקציות המובנות של itertools יודעות לעבוד עם iterable, כלומר משהו שאפשר לבנות ממנו איטרטור. הטעות הראשונה היא שלא יצרתי איטרטור מה iterable שהעבירו לי. תיקון ראשון ועוד ניסיון הרצה:

def nwise(iterable, n):
    it = iter(iterable)
    while True:
        yield [next(it) for i in range(n)]


>>> list(nwise(range(100), 2))
Traceback (most recent call last):
  File "<stdin>", line 4, in nwise
  File "<stdin>", line 4, in <listcomp>
StopIteration

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: generator raised StopIteration

הפעם הודעת שגיאה חדשה - בתוך לולאת ה while של nwise קראתי ל next עם פרמטר אחד. בהנחה שאין כלום באיטרטור, הקריאה תזרוק Exception וזה מה שאנחנו רואים בפלט.

תיקון אחד קל כאן הוא לתפוס את ה Exception בתוך הגנרטור ופשוט לסיים את הלולאה:

def nwise(iterable, n):
    it = iter(iterable)
    while True:
        try:
            yield [next(it) for i in range(n)]
        except StopIteration:
            break

תיקון שני קצת יותר מתוחכם אבל שיכול להפוך את הקוד הזה להרבה יותר פשוט הוא לוותר על הקריאה ל next ולהשתמש ב itertools כל הדרך:

def nwise(iterable, n):
    return zip(*[itertools.islice(iterable, i, None, n) for i in range(n)])

הרעיון הוא לקחת את ה iterable שלנו, לייצר ממנו n רצפים כשכל אחד מהם מתחיל ערך-אחד-קדימה ומתקדם בכפולות של n, ואז zip מחבר את כולם יחד.

ההתנהגות של git pull השתנתה בגירסה 2.27 של גיט, ואז שוב בגירסה 2.33, במטרה להפוך את הפקודה לקצת פחות הרפתקנית.

הפקודה git pull היא למעשה שילוב של שתי פקודות: היא קודם כל מושכת את כל הקומיטים מהענף המרוחק (fetch), ואחר כך היא משלבת אותם בענף שלנו - ברירת המחדל באמצעות merge.

הבעיה בשימוש ב merge כשמושכים קומיטים מענף מרוחק היא שלא כולם רוצים דווקא את ההתנהגות הזאת:

  1. אם היה ריבייס בענף המרוחק, merge עלול לפספס את זה ולהכניס קומיטים כפולים.

  2. אפילו אם לא היה ריבייס, merge יוצר במצבים מסוימים קומיט חדש עבור המיזוג ולפעמים מתכנתים נבהלים כי הם לא ציפו ש pull ייצור קומיט חדש.

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

ברירת המחדל הישנה, merge, אומרת ל git להפעיל merge כשהוא מזהה קומיטים חדשים בענף המרוחק. בשביל לבחור אותה בכל הפעלה של pull נפעיל פעם אחת:

$ git config pull.rebase false

ברירת מחדל שניה שאנחנו יכולים לבחור היא rebase, והיא אומרת שאם יש קומיטים חדשים בענף המרוחק וקומיטים חדשים אצלנו, אז אחרי fetch נעשה rebase לקוד שלנו על הענף המרוחק העדכני. גישה כזאת תעבוד טוב אם מתכנתים אחרים עשו push אחרי rebase אבל היא עלולה להיות מבלבלת כי זה אומר שאחרי pull מזהי הקומיטים שלכם ישתנו. בשביל לבחור בה נפעיל פעם אחת:

$ git config pull.rebase true

וברירת המחדל השלישית והמועדפת עליי נקראת Fast Forward Only והיא אומרת ש pull יסרב לרוץ אם יש קומיטים גם בענף המרוחק וגם בענף שלי, ואז במצב כזה אני צריך לבחור לבד מה לעשות. בשביל לבחור בהתנהגות זו אני כותב פעם אחת:

$ git config --global pull.ff only

בואו נראה איך זה עובד. יצרתי מאגר והוצאתי אותו מסינכרון עם הענף המרוחק. הענף main נראה אצלי ככה:

$ git log --oneline --graph
* 036277f (HEAD -> main) d4
* a82b7c8 d3
* b69d6c1 d2
* bb4f039 d1
* 244c3c2 c1
* 8a9cf3b first commit

והענף המרוחק נראה ככה:

$ git log --oneline --graph origin/main
* 6bf42ea (origin/main) c4
* 589e8f4 c3
* 955b0f3 c2
* 244c3c2 c1
* 8a9cf3b first commit

ההסתעפות היא בקומיט c1, כאשר הענף המקומי המשיך ממנו ל d1 והענף המרוחק המשיך ממנו ל c2.

ניסיון עכשיו להפעיל pull נותן את השגיאה:

$ git pull

hint: You have divergent branches and need to specify how to reconcile them.
hint: You can do so by running one of the following commands sometime before
hint: your next pull:
hint:
hint:   git config pull.rebase false  # merge
hint:   git config pull.rebase true   # rebase
hint:   git config pull.ff only       # fast-forward only
hint:
hint: You can replace "git config" with "git config --global" to set a default
hint: preference for all repositories. You can also pass --rebase, --no-rebase,
hint: or --ff-only on the command line to override the configured default per
hint: invocation.
fatal: Need to specify how to reconcile divergent branches.

נבחר את ברירת המחדל האהובה עליי:

$ git config pull.ff only

ועכשיו אני מנסה שוב להפעיל pull:

$ git pull

fatal: Not possible to fast-forward, aborting.

עדיין כישלון אבל לפחות הפעם פחות חופר. עכשיו אני יודע שאי אפשר לעשות fast-forward ונדרשת החלטה - האם אני רוצה לעשות merge רגיל או rebase. בשביל להחליט לבצע merge רגיל אני מפעיל:

$ git pull --ff

או בשביל להחליט שאני מעדיף rebase אני יכול להפעיל:

$ git pull --rebase

הבחירה בין שתי האופציות כבר תלויה במקרה הספציפי ובאיך אני רוצה שהשינויים שלי ישתלבו עם השינוי המרוחק.

הנה במאגר שלי התוצאה אחרי הפעלת merge:

$ git pull --ff
$ git log --oneline --graph

*   78831a1 (HEAD -> main) Merge branch 'main' of https://github.com/ynonp/divergent-branches
|\
| * 6bf42ea (origin/main) c4
| * 589e8f4 c3
| * 955b0f3 c2
* | 036277f d4
* | a82b7c8 d3
* | b69d6c1 d2
* | bb4f039 d1
|/
* 244c3c2 c1
* 8a9cf3b first commit

או אחרי הפעלת rebase:

$ git pull --rebase
$ git log --oneline --graph

* f0a0b30 (HEAD -> main) d4
* 07cd430 d3
* e95dcad d2
* 3f03f93 d1
* 6bf42ea (origin/main) c4
* 589e8f4 c3
* 955b0f3 c2
* 244c3c2 c1
* 8a9cf3b first commit

כשהבנתי שאני הולך לעבור ל Windows ידעתי שהולכים להיות קשיים: בתור בן אדם שבילה את רוב החיים בלינוקס ועוד כמה שנים עם מק, לא היתה לי שום יכולת התמצאות בעולם של Windows. הכלי הראשון שגיליתי אחרי המעבר היה WSL, והוא היה גם האחרון.

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

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

  1. פקודות WSL בסיסיות - התקנת הפצות, שידרוגים, גיבויים.

  2. הקמת סביבת פיתוח ב WSL.

  3. שילוב תוכניות גרפיות ב WSL.

  4. הגדרות המכונה wslconfig.

  5. הגדרות רשת.

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

כל הסיפור קורה ביום חמישי הקרוב בשעה עשר בבוקר. הרשמה בחינם בקישור: https://www.tocode.co.il/workshops/119