ארכיון רשומות מאת: ik_5

כניסה לפרויקט קיים

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

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

התחלה

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

טעויות בכניסה לקוד/פרויקט קיים

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

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

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

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

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

הדרך שלי ללמוד

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

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

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

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

רכיבים קטנים

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

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

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

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

עבור מה השיטה לא מתאימה?

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

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

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

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

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

הגדרות שגויות לnvim

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

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

איזה סופ"ש אחד החלטתי לפתוח קוד Go שלי ולהמשיך ולעבוד עליו.
פתאום קיבלתי המון שגיאות לא קשורות לקוד שלי, אלא לvim-go.
אמנם עברו 3 חודשים מאז שהתחלתי לכתוב את הקוד בזמני הפרטי, אבל מה השתנה?!
הלכתי לפי הודעות השגיאה (בvim/nvim זה ‎:messages), וגיליתי שפונקציה לא קיימת עבור nvim. הלכתי לספריה ש vim-plug מתקין לי תוספים עבור nvim, ועם rg‏ (ripgrep) חיפשתי את הפונקציה ומצאתי אותה. מסתבר שקובץ חדש בשם config.vim לא נטען. אמממ, אבל הוא קיים בספריה.

פתחתי באג בנושא, כמו כל איש קוד פתוח טוב 🙂 הוצע לי לבדוק אם הקובץ קיים, דבר שהוא כן.
ואז החלטתי להתחיל בבדיקה של nvim וונילי, בעקבות תגובה של faith (הכותב העיקרי של התוסף).

התשובה היא שבהגדרות נקיות, הכל עובד גם עבורי. אז זה לא התוסף עצמו.
הלכתי לקובץ init.vim של neovim, שהוא ההתחלה ששם הוא טוען את כל הסקריפטים (הvimrc של neovim), ומקריאה ראשונית מצאתי משהו שיכול לשמש כבעיה:

set runtimepath+=~/.vim,~/.vim/after
set packpath+=~/.vim
source ~/.vimrc

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

החלטתי לעשות מהלך שעד עכשיו נמנעתי ממנו. לשים את ה"הפצת" vim שלי תחת nvim, ולעשות שינוי ל init.vim שלי. הוא כבר לא מתעניין ב vim בכלל. הכל נעשה דרכו, כולל הצבעה נכונה לספריות שונות.

לאחר ביצוע פעולה כזו, הכל עבד חלק 🙂

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

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

גילוי פורטים פתוחים בצורה נאיבית

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

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

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

  1. התעבורה עברה, אבל לא קיבלנו אישור – הפורט פתוח אבל מפולטר (מלווה ב Connection Refused).
  2. אין פורט פתוח – אולי מפולטר, ואם כן מקבל drop כאילו אין פורט פתוח.

פעולה זו של SYNchronize היא הדרך עבורינו לגלות האם TCP פתוח.

ההצעה הפשוטה ביותר להתמודד עם זה, זה לנסות לפתוח חיבור TCP בפורט המבוקש לכתובת, במידה ונפתח, החיבור פתוח. במידה והחיבור נכשל (אם timeout או connection refused), אנחנו יודעים שהוא לא פתוח. כאשר האחרון אומר כי הוא מפולטר.

זו לא הדרך היחידה לעשות את זה, אבל זו הדרך הפשוטה ביותר.

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

מתודולוגיות – חשיבה מחודשת

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

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

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

כיצד זה התחיל?

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

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

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

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

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

שאלה אחת שווה אלפי שורות קוד

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

  • באיזה שלב הוא לא מוצג?
  • האם הוא היה מוצג בעבר?
  • האם הוא צריך להיות מוצג?
  • מתי הוא אמור להיות מוסתר?
  • האם יש שימוש בשדה הזה בכלל?

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

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

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

ספר לי סיפור

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

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

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

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

מתכנת ❤ קוד

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

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

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

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

משחק סכום אפס

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

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

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

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

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

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

למשל קרה במקום שעבדתי בו מצב אשר קראו מתוך מסד נתונים לתוך מערך מאוד גדול את כל הנתונים ואז היו שופכים את המידע לקובץ csv. יום אחד הגיע אותו המידע לגודל של 64 מגה, והbuffer נגמר. ראינו load על השרת והמון שימוש ב swap.

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

אין בעיה. אני סופר 65,000 רשומות ויוצר עוד קובץ וכיוב'. הנה מימוש pagination רק עם קבצים. כאשר יש את כל הקבצים, לוקחים את כל הקבצים ומאגדים אותם ב zip.
כמות הזמן של כל העיבוד הזה של מספר קבצים ואז zip לקחה שניה וחצי, כאשר לפני השינוי המקורי המערכת היתה קורסת אחרי למעלה מעשר דקות של עבודה, בגלל נושא הבאפרים וניהול הזיכרון.

סיכום

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

ואשמח לשמוע את דעתכם בנושא.

על שימוש ב VIM ו OCD

ב2003 החלטתי ללמוד vim כמו שצריך, אז עשיתי את כל מה שבן אדם שפוי עושה – יוצר מדריך בעברית המלמד עבודה בסיסית עם vim.

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

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

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

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

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

אבל הגישה של vi היא שונה כאן. אם כל משפט נגמר בנקודה, אפשר להתחיל בגישה הבאה:
בואו נלחץ על ‏ 2f.‎ (כלומר הספרה שתיים האות f ואז נקודה) ונגלה כי אנחנו מגיעים לנקודה השלישית הנמצאת בשורה שלנו. עכשיו ניתן להקיש 2w ו… הגענו למיקום הנכון. מכאן נלחץ על cw ונשנה את המילה הרצויה.

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

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

תנו לי לנסות את זה שוב. אולי אעשה את זה כך: ‎ 2‎)‎ ואז על w ואקנח ב cw.  טוב זה פחות הקלדות.
ועכשיו נשאלת השאלה – האם אני עדיין יכול לקצר את התהליך. אמנם במקום 7 תווים ירדתי ל5, עדיין זה הרבה בעיני.

אז מה השלב הבא? ובכן חשבתי להשתמש ב search and replace, אבל ב Neovim זה לא עבד כמצופה. אז עכשיו  האם אני ארים ידיים?
ובכן לא! אמשיך לחפש דרכים טובות לעשות את זה, אבל בשוטף, ולא בעבודה הנוכחית, כי כרגע זה מספיק טוב עד למציאת הדרך הקצרה יותר הבאה שכמעט תמיד מסתתרת בפינה חשוכה ומחכה לפנס שלי להאיר לה את הדרך.

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

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

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

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

שעתיים עם void-linux

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

לאחר דיון עם חבר על הפצות לינוקס, וזה שהוא אוהב ג'ינטו וסלאק, הוא הציע לי לנסות הפצה בשם void-linux.

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

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

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

אז אני ניתקתי את עצמי מכך, והלכתי לכיוון של ארץ' וחשבתי ש void-linux דומה בגישה שלה ל ארץ'. טעיתי.

ובכן, אין יחסית הרבה בחירה בהפצה הזו, היא מאוד דעתנית. אפשר לבחור סוג מימוש של libc שהוא glibc או musl.
אין למשל תמיכה ב systemd ובמקומה יש ruinit.

ההפצה בברירת מחדל מגיעה עם live cd, בטעמים של שולחנות עבודה Enlightenment, Cinnamon, LXDE, LXQT, MATE ואפילו Xfce.
מה חסר? ובכן גנום, kde4 ו plasma.

אני החלטתי ללכת לכיוון של musl ו live cd שהוא רק shell. רציתי להרגיש את ההפצה בברזל שלה.
והיא ממש מדהימה, קלה וזריזה מאוד.

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

הגדרת המחיצות הלכה די פשוט, אבל בחירת מערכת הקבצים אילצה אותי לשנות את הבחירה שלי.
הסיבה היא שרציתי להתקין lvm, ושם שני מחיצות, אחת של root והשניה של home, אבל בבחירת מערכות קבצים, אי אפשר לבחור גם איך לעשות logical partitions שכל כך חשובים אם רוצים lvm. אז פשוט יצרתי את זה כ XFS וסגרתי עניין.

אוקי, עשיתי בוט להתקנה, ו… עכשיו הגיע הזמן להתקין דברים. אז להפצה יש מנהל חבילות משל עצמה בשם xbps שדווקא עניינה אותי, אבל המסך שלי נתקע פתאום כשהתקנתי neovim, אם כי ההפצה עצמה המשיכה לרוץ בהצלחה. מסתבר שהיה משהו בתוכנה עצמה שנעל עדכון מסך, שעד עכשיו לא הבנתי מה הוא ולמה. ד"א Ctrl+q לא עבד, ניסיתי 🙂

היכולת להשתמש במנהל חבילות בינארי הוא לא חדש, והפורמט הוא בס"כ הסוואה ל tar.xz.
התוכן שם קצת מוזר לי אבל, למשל רשימת החתימה של הקבצים משתמשת ב xml בקובץ בשם files.plist.
גם הקובץ props.plist הוא למעשה קובץ xml.

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

יש לכך שני סיבות עיקריות עבורי:

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

האם זה אומר שהיא גרועה? לא! רחוק מזה!
היא פשוט לא בשבילי, ואני אשאר בנתיים עם ארץ' 🙂

 

כיצד אני משווה טכנולוגיות

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

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

כיצד מתחילים?

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

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

נגיד הדגש הוא רינדור מידע סטטי שלא משתנה. או אולי זה משהו שיש לו observable, אשר מגלה שינוי במידע.
כל גישה כזו ממקדת אותך בדברים שונים.
למשל React יוצרת מצב סטטי תמידי, וכל שינוי מידע יוצר דינדור מחדש של כל הסביבה אשר מחזיקה במידע.
כמובן שיש מספר דרכים להתמודד שזה לא יקרה (למשל states).
לעומת זאת, יש את Vue.js שזו מחזיקה observable וכאשר מידע משתנה, רק מי שמשתמש במידע מרונדר מחדש על ידי שימוש ב shadow DOM, כאשר שאר המסך לא משתנה או מרונדר מחדש.

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

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

ניסויים

השלב השני הוא לקחת דוגמאות קיימות של אותה טכנולוגיה, ולהתחיל לסבך אותם.
זה דורש ממני להתחיל לקרוא תיעוד, וזה עוד משהו חשוב.
עד כמה התיעוד מסייע לי בנושא הטכנולוגיה, מול עד כמה הטכנולוגיה makes sense, וקל "לזרום" איתה.

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

עד כמה המידע שיש עדכני ומסייע לי להתעדכן?

אם אחזור לדגומא של React מול Vue.js. אז התיעוד של React מאוד מתפזר בתהחלה, ומנסה להסביר concept, בעוד שהתיעוד של Vue מאוד ממוקד מטרה – מה לצפות כאשר מתחילים לעבוד.
שימו לב, הדבר הראשון ש React עושים זה להציג Hello World. אנחנו לא מבינים כלום עוד, וכבר יש סוג של Tutorial כתיעוד, בלי קשר ל Tutorial.

זו הסיבה שקל למשל לזרום עם Vue ולהתחיל לבצע איתו משימות, בעוד שעם React עדיין עסוקים בלהבין את התמונה הכללית.

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

אב טיפוס

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

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

הבחינה היא יותר מה קורה כאשר סיימתי להגדיר את הסביבה שלי, מה אז?
האם אני יכול "להתחיל" או האם אני צריך ללמוד איך "להתחיל" לכתוב קוד?
למדתי עכשיו ללמוד את הקוד, האם עכשיו אחרי ההתחלה זה "זורם" או אני עדיין תקוע בהבנת ה concept?

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

דגשים שגויים

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

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

אבל מה זה משנה אם יש 10,000 כוכבים או 100,000,000 כוכבים בgithub?

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

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

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

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

עוד דגש בעייתי הוא "חברה X עובדת עם זה, אז זה חייב להיות טוב".
ובכן, זה טוב עבורם! לא בהכרח עבורכם.
תראו למשל את Gitlab, הם הסבירו מעבר שהם עשו לVue.js. אבל הם לא נשארו שם.
כלומר הם לא נשארו באמירה "הנה עברנו טבנולוגיה", אלא הם המשיכו לבדוק. ואפילו פרסמו ניתוח שנה אחרי, מה גורל המעבר.

סיכום

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

מחשבות על Github ומיקרוסופט

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

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

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

  1. מלחמה טובה לעסקים.
  2. שלום טוב לעסקים

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

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

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

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

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

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

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

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

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

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

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

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

התמודדות עם שגיאות תוכנה

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

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

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

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

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


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

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

חודש עם Tilix

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

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

הדבר הקרוב ביותר שמצאתי הוא תוכנה בשם Tilix, אשר קיבלתי עליה המלצה. התוכנה עצמה כתובה בשפה בשם D, והיא מספקת המון תכונות מדהימות, אשר חלקן לקוחות מכלים כדוגמת screen ו tmux, וחלקן מ iTerm2.

tilix

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

בנוסף לכך שיש לי split שקל לעבור בניהם עם המקלדת, אפשר גם ליצור משהו שנקרא session, ממש כמו virtual desktop. וגם אליהם ניתן לעבור בקלות עם המקלדת.
היא מאפשרת למשל לשתף מקלדת עם כל או חלק מהטרמינלים הפתוחים בסשן, כך שהקלדה במקום אחד תתקבל גם בשאר, חיפוש של תוכן שהודפס למסך (למשל לוג שאתם פתחתם עם tail -f, ואולי פספסתם משהו בו), ואפילו ניהול של clipboard, בנושא שאל העתקה והדבקה, ולא בניהול של היסוטוריה וכיוב' שלו, הוא יודע לספק הודעת מערכת כאשר פעולה הסתיימה, להגדיר מסוף כ readonly (לא מקבל מקלדת, בניגוד ל CTRL+S שפשוט משהה את הפעילות) ובנוסף, יש לו תמיכה בכלים שונים שלא ניסיתי עדיין.

אני יודע מה אתם חושבים, למה להשתמש בה ולא ב tmux?
ובכן, דבר ראשון, אני כמעט אף פעם לא עובד על שרתים מרוחקים בשנה האחרונה. כלומר כן לפעמים מתחבר, אבל עדיין לטרמינל שלי.

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

אבל זה לא הכל, אני יודע שכאן אני תלוי בטרמינל, ולא בתוכנה שרצה בטרמינל, אבל בסופו של דבר, האם זה משנה אם התוכנה נקראת tmux, screen או אולי Tilix?

ובכן, קצת 🙂

הייתי מאוד שמח לראות את Tilix משפרת מספר דברים אצלה:

  • יצירת שרת שיחזיק את הפעילות שלי ברקע (גם אם הממשק יתרסק, הפעילות שלי לא)
  • היכולת לשמור את כל ה"סשנים" של הטרמינלים שפתחתי ולאחזר אותם, ולא רק את הפעילים כרגע.
  • היכולת לבצע התאמה אישית של טמרינל פתוח on the fly ולא רק כמשהו שהוגדר מראש.

במידה והשניים הראשונים יהיו, לדעתי מדובר במתחרה ראוי ל tmux (למעשה הוא כזה כבר עכשיו, אבל עדיין).
כמובן שגם אפשר להריץ tmux בתוך tilix, ואז בכלל זכיתם המון גמישות 🙂

כמובן שיש עוד תכונות של iTerm2 שהייתי שמח לראות אצלי, אבל הדברים שבאמת חשובים לי נוצרו כבר.

 

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