קטגוריה: אתרי אינטרנט

חשיבה מופשטת

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

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

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

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

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

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

אבל זה לא הכל. גם לעיצוב בhtml יש תיאור, למשל בשביל להגיד שcss הוא עבור המסך. זה נקרא media types.

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

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

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

וזה הכיוון שאני חשבתי עליו כאשר דיברתי על מה אני הייתי רוצה ש HTML יבצע.

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

מה זה מאפשר לנו להשיג אם זה בhtml (ולא, זה לא דומה אפילו לתכנות)?
דבר ראשון, זה אומר שאנחנו טוענים פחות מידע. למשל יש עכשיו את פרוטוקול HTTP/2. הפרטוקול אומר כי בגלל שיש המון מידע שצריך להטען, במקום לחכות לכל המידע הזה, אני אכניס הכל בבקשה אחת ואצור multiplexing.
טעינה של המון לוגיקה ב Javascript, טעינה של המון CSS שלא לדבר על תוכן שאולי רק לא יוצג ב HTML, כולם יוצרים בעיות ביצועים. אך במידה ואנחנו נוכל לטעון רק את המידע הרלוונטי כאשר הוא רלוונטי בלבד, אז למעשה כמות המידע ירד, ולמרות ש HTTP/2 הוא נחמד, עדיין אשיג אופטימיזציה מצויינת רק מעצם זה שאני לא טוען מידע שאני לא זקוק לו.

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

<div src="/foo.html" alt="no content" media="(max-wdith: 640px and max-height: 480px)">

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

הנה הדגמה גם לזה:

<link href="/styles/bootstrap.min.css" rel="stylesheet" provides="bootstrap" ver="3.3.4">

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

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

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

מעניין איך תפתרו את ה"תרגיל" למעלה …

buzz words

הבעיות שיש לי עם תכנות ריספונסיבי

הקדמה

אנחנו חיים בעולם שיש בו המון מילות באזז, כדוגמת big data, responsive design, cloud computing, סייבר וכיוב' …
כל המילים האלו מגיעות מעולם השיווק, אבל לאדם טכני לא באמת אומרות הרבה.

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

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

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

מונחי יסוד

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

CSS – הם קבוצה של חוקים אשר יכולים לכסות אחד את השני (מכאן השם: Cascading Style Sheet) בצורה שתספק עיצוב למסמך.

הסבר

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

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

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

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

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

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

הפרוטוקולים המהירים של גוגל

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

עם המהלך הזה של גוגל יצאו 2 פרוטוקולים מאוד מעניינים:

  1. SPDY – אשר כרגע עובר להית HTTP/2
  2. QUIC – היכולת לקחת את UDP ולתת לו רק חלק מהתכונות של TCP

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

העניין הוא, שבSPDY, יש שימוש בפרוטוקול TCP, והוא, כאשר יש משהו שנמשך הרבה זמן הופך להיות סוג של blocking עד שהבקשה הארוכה הזו מסתיימת.
אז איך מאיצים את זה?
אפשר לחשוב על UDP. הבעיה היא שהוא חסר state. כלומר או שעבר לי מידע או שלא, אבל אני לא יכול לדעת מעבר לזה, וזה אומר שבשביל לדעת אם משהו ביצע, אני יוצר עוד סוג של over-head וזה ליצור בתוך המידע שלי יכולת לדעת אם משהו הצליח או לא.

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

כרגע יש שמועות שבנוסף לHTTP שעבורו תוכנן QUIC, הפרוטוקול יהיה בשימוש בעוד מקומות, כמו למשל webrtc, אך זה רק שמועות כרגע, ונראה שהולך להיות מאוד מעניין 🙂

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

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

knockout.js

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

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

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

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

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

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

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

הכלי נקרא knockout.js. הכלי הזה בנוי בגישה של "תשאיר לי את ה data binding, השאר שלך לעשות מה שתרצה".

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

הגישה של konockout.js קיבלה את השם Model-View-ViewModel אשר מאוד מוכרת לי מעולם הדלפי, רק בצורה שונה.

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

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

זה נעשה בצורה די פשוטה בג'אווהסקריפט נקי:

function observable() {
   if (arguments.length > 0) {
      //write stuff
   } else {
      // read stuff
   }
}

למעשה arguments זה המקביל ל var_args של C או open array של פסקל, רק שהוא מכיל בתוכו אוביקטים כי זו שפת javascript.

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

הנה קוד מאוד פשוט ב knockout:

<p>First name: <input data-bind="value: firstName" /></p>
<p>Last name: <input data-bind="value: lastName" /></p>
function ViewModel() {
    this.firstName = ko.observable("Joe");
    this.lastName = ko.observable("Bloggs");
 
    this.fullName = ko.computed(function() {
        return this.firstName() + " " + this.lastName();
    }, this);
}
 
ko.applyBindings(new ViewModel());

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

זהו, זה כל מה שהיה צריך. אין צורך בשיריון של namespace, איזורים וכיוב' … בלי לבחור סוג של template וכיוב'.
במקום שבו משתמשים בשדות, אז נכנסים לתוך ה namespace של אותו אובייקט, ואז במידה ורוצים לצאת החוצה משתמשים ב ‎$parent ובמידה ורוצים להתחיל מההתחלה, משתמשים ב ‎$root כלומר בנקודה שבה קראנו ל applyBindings.
אם אתם רוצים את האובייקט עצמו שאנחנו משתמשים בשדה מסוים (למשל כאשר משתמשים במערך), משתמשים ב‎$data וישנם עוד סוגי משתנים. הנה הסבר פשוט בנושא.

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

webrtc ORTC

הקדמה

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

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

היא תומכת ב OPUS, ו G711, ומחייבת אותנו לעבוד בצורה מאובטחת תחת DTLS,

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

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

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

הדגמה קלה (מה RFC):

v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=.
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0 8 97
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 51372 RTP/AVP 31 32
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000

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

הנה הסבר על מה שאתם רואים מול העיניים שלכם:
האות v, מייצגת version – גרסת הפרוטוקול, שלפחות כרגע היא תמיד 0.
האות o, מייצגת origin של הבקשה, ומכילה (לפי הסדר) – שם משתמש, session id, בנוסף session-version, סוג רשת (אינטרנט), סוג הכתובת, כתובת הרשת.
האות s מייצגת את session, כלומר השם שלו.
האות c מייצגת מידע על connection. זה אומר סוג הרשת, סוג כתובת הרשת, כתובת הרשת.
הכוונה היא לאן רוצים להתחבר בשביל המדיה.
האות t מייצגת זמנים.
האות m מייצגת מדיה, עם סוג מדיה, פורט דינאמי, פרוטוקול משלוח של המדיה, ומידע הקשור לפרוטוקול.
האות a מייצגת attribute, שזה תכונות שונות, למשל כאן, זה מייצג איזה קוקדים של אודיו ישלחו, כולל הקוד שלהם שמוגדר ב RFC עבור כל סוג קודק.

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

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

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

תוכן

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

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

ואז ישבו הרבה אנשים, אשר רובם יצרו את webrtc ואת Open Peer, והחליטו על גרסה 1.1 לwebrtc בכנס מסחרי מסוים, אם כי למרות ההכרזה על 1.1 ההכרזה מרגישה יותר כמו 2.0.
השם לפרוטוקול החדש באותו כנס, קיבל את השם ORTC או Object Real Time Communication, אשר ה draft הראשון (מבחינת יכולת מימוש) שלו שוחרר באוגוסט 2014.
היכולת לעקוב אחרי דברים, נעשת באתר ייעודי לכך בשם ortc.org.

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

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

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

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

ואכן, זה מה שORTC מבצע. הם יצרו אובייקט בשם RTCRtpCapabilities, אשר התפקיד שלו לדבר על "מה אני צריך" עם הצד השני וניתן אפילו לעשות החלפה בזמן ריצה של המידע (ב SIP זה נקרא re-Invite).

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

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

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

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

למי הפרופיל רשת חברתית קיים אחרי המוות ?

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

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

facebookעכשיו השאלה היא לא רק למי שייך המידע, אלא מה קורה עם פרופיל שכזה כאשר אדם מת ?

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

מה אנחנו כבני אדם בכלל רוצים שיהיה בחברה שלנו במצב שכזה ?

פוסט למחשבה.

אפצ'י מפסיק לפעמים להגיב לבקשות בצורה רנדומאלית

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

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

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

הפעלתי wireshark, וגיליתי כי three way handshake אינו מתבצע עד הסוף, ולמעשה ה ACK האחרון לא נשלח חזרה על ידי השרת (ה wireshark היה על השרת עצמו).
יש מספר נסיונות שליחה של לחיצת היד, ובסוף יש RST על הבקשה כי לא ניתן היה ליצור קשר, והבקשה התנתקה.

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

בנתיים דיברתי עם בוריס, והוא הצליח למצוא קישור מעניין שמדבר כי אפצ'י בברירת המחדל מגיע עם דגל של TCP_DEFER_ACCEPT. עד כמה שאני מבין, הדגל הזה אומר לשרת לא לחכות ל three way handshake, אלא במידה ונשלח מידע אחרי החיבור הראשוני, כשעוד אין ACK, אלא רק SYN-ACK, ניתן כבר לקבל את המידע, ולמעשה רק כשהוא יסתיים להישלח, ישלח גם ה ACK.

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

בשביל לכבות את הדגל בחיבור, צריך לשים ב httpd.conf הראשי, את הקוד הבא:

 AcceptFilter http none

במידה ויש הגדרה אחרת בנושא, למשל עם data, יש לשכתב אותה לnone.
וזה מכבה למעשה את הדגל של TCP_DEFER_ACCEPT ועכשיו אפצ'י חייב לחכות ללחיצת היד כמו שצריך לפני שיוכל לנתח את מה שנשלח.

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

 

מערכת פשוטה לשיתוף קבצים פנים ארגונית

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

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

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

אז החלטתי כי במקום להמשיך ולחפש תוכנה, אכתוב משהו פשוט שיעשה את זה, ותוך שעה וחצי, כולל דיבוג כתבתי את simple file sharing – גרסת mercurial וגרסת git.
זהו מנוע פשוט, הכתוב ברובי עם סינטרה ללא javascript שאני כתבתי, אלא cgi מול html/css פשוטים מאוד מבוססי foundation.

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

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

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

תם עידן הפרטיות, תחי הפרטיות

Le roi est mort, vive le roi !

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

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

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

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

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

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

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

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

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

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

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