קטגוריה: חברה

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

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

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

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

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

על פניו קוד משוכפל זה גרוע, וזה מקום שאפשר ליפול בו, נכון?
אז זהו, שזה מורכב יותר. היה לי 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 לקחה שניה וחצי, כאשר לפני השינוי המקורי המערכת היתה קורסת אחרי למעלה מעשר דקות של עבודה, בגלל נושא הבאפרים וניהול הזיכרון.

סיכום

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

חשיבה ביקורתית

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

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

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

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

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

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

 

אז מה הקשר של כל זה לטכנולוגיה?

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

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

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

 

מוגש כחומר למחשבה.

מתכנת IT

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

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

עכשיו אשאל אתכם שאלה: האם איש DBA שייך לקבוצה הזו? התשובה היא כן. האם הוא איש DevOps? התשובה היא לא.

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

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

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

איש DBA יודע למשל המון על IO ועל דיסקים, וזיכרון, אבל זה לא אומר שהוא יודע מספיק בשביל להחליף ציוד, או לבחור חומרה בצורה נכונה. הוא רק יודע מה מסוגל לתת ביצועים טובים, אבל האם לוח מסוים עדיף? האם שרת מסוג מסוים? האם בקר מסוים? האם מעבד מדגם אחד טוב יותר וכיוב', הם פחות מהמומחיות שלו. זה לא אומר שהוא אינו יודע, זה אומר שהוא פחות חי את זה. זה יותר סוג של by-product של העבודה, מאשר המומחיות.

להמשיך לקרוא

סיכום אוגוסט פנגווין 2015

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

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

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

הרצאה על systemd

הרצאה על systemd

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

ואז התפזרנו לצילום קבוצתי (שכמו כמעט בכל כנס – לא השתתפתי בו) ומסלולים שונים.

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

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

לאחר מכן, הלכתי לשמוע על מערכות הפעלה, והמרצה ניסה לסמן מטרה גדולה מידי, ופספס אותה לגמרי תוך כדי הציור שלה.
הוא לקח את לינוקס והגזים עם המון דברים, כמו למשל הרעיון שיש לך הרבה tty פתוחים גם בשרת ווירטואלי. אבל אפשר לכבות את זה. במידה ואתה עם מערכת init של sysv יש לך את הקובץ Inittab ואם אתה משתמש ב systemd אז אפשר גם שם לסגור דברים.
העניין הוא, שהוא פספס לגמרי את השימוש ב tty ומה הם אומרים – שזו תקשורת סיריאלית אשר מסוגלת לעשות המון דברים, בהתאם לסוג המסוים, כמו למשל text terminal, או teleprinter וכיוב'… כן זה עולם ישן, אבל הפשטות שלו גורמת לו להיות מאוד יציב ואיכותי יחסית, שניתן לזרום איתו להרבה כיוונים שונים.

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

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

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

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

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

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

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

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

אנדרואיד, mms ובעיית אבטחה עם פתרון ישים

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

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

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

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

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

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

כיצד עובד ה MMS? אני שולח הודעת SMS במבנה מסוים שאומר כי יש לי משהו כדוגמת תמונה בשרת שניתן להוריד באמצעות WAP.

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

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

מזלגות נעוצים

בתקופה האחרונה, נעשו מספר פעולות fork לפרויקטים מוכרים, בהם node.js ודביאן.
בנוסף, פרויקט docker מקבל מתחרה, לאחר שחברת CoreOS הודיעה כי לא מקובל עליה הכיון של docker.

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

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

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

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

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

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

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

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

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

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

החברה של CoreOS, רוצים container ומשהו שזו כל ההתמחות שלו, אבל docker מתחיל להיות stack שלם של דברים, והם ממש לא אוהבים את זה, כי בסופו של דבר,זו סוג של תחרות, לא ?

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

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

יחידות בדיקה, כן, לא, אולי

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

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

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

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

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

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

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

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

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

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

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

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

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

האם בדקת באמצעות ‎ /dev/full האם המערכת שלך יודעת להתמודד עם מצב בו אין מקום יותר לשמור מידע ?
רק השבוע סידרתי את MySQL שהרס טבלה כי מערכת הקבצים הגיעה ל 100% ולא היה מקום לרשום את הרשומה, אז הטבלה נהרסה.

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

יותר מזה, אתה בודק את הקוד שלך על 10,000 רשומות, הלקוח קצה שלך אבל משתמש ב10,500 רשומות, ואז יש איטיות (ב10,499 עדיין אין), איך לא ידעת להוסיף עוד רק 500 רשומות לבדיקה ? זה מה שמנהל מסוים יצעק עליך, לא ?

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

האם בכלל יש פתרון למקרי קצה כאלו ?

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

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

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

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

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

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

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

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

מוגש כחומר למחשבה.

אריקסון ו webrtc

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

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

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

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

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

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

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

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

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

כרגע יש קרב גדול על בחירת קודקים לוידאו, כאשר הקרב הוא בין H.264 לבין VP8 ובעתיד גם VP9.

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

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

systemd

זהירות פוסט ארוך מאוד

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

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

מהפכה נוספת, היא החלפת הגישה של sysv כמעט לגמרי, עם מנהלי init שונים, כאשר זה שלוקח את הכי הרבה אש, וגם בשימוש הרב ביותר הוא systemd. זה השם שלו, כפי שהוא כתוב. והd בסוף מצייג כמובן את המילה daemon, כי הוא יושב ב pid 1, ומנהל את העליה של כל השאר, אחרי שמנהל האתחול (כדוגמת grub) מריץ אותו.

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

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

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