קטגוריה: קהילה

מבחן שגוי

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

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

אבל במקום, מקבלים שאלות בנושא של TCP/IP, כיצד מסד נתונים עובדים, איך יוצרים מודולים לקרנל וכיוב'.
מה עכשיו? האם אתם מתאימים לתפקיד?

אז הגזמתי קצת, נכון? ובכן לא.

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

שאלות בנושא התפקיד להראות יכולת והבנה חשובים הרבה יותר מאשר היכולת אז אני מדבר על full stack עבור פיתוח web, הנה מבחנים טובים יותר מאשר שאלות מדמ"ח:

  1. יש לי צורך לאסוף את הנתונים הבאים – מה הסכמה למסד הנתונים שתתכנן ולמה?
  2. האם מסד נתונים מבוסס סכמה באמת מתאים לזה, או אולי מסד נתונים מסוג אחר?
  3. תן לי הדגמה מתי תבחר בdjango/rails ומתי ב sinatra/flask?
  4. מתי Go עדיפה על פיתון/רובי?
  5. מה ההבדלים בין Vue/React לבין Angular?

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

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

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

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

זו כמובן דעתי, בלבד, בהצלחה 🙂

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

פודקאסטים שאני מקשיב להם

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

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

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

אני מחלק אותם למספר סוגים (אין חשיבות לסדר):

פודקאסטים טכניים:

להמשיך לקרוא

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

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

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

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

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

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

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

 

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

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

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

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

 

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

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

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

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

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

הרצאה על systemd

הרצאה על systemd

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

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

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

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

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

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

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

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

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

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

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

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

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

Firebird 3.0

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

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

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

  • DSQL
  • ESQL
  • PSQL

DSQL – הם בעצם השאילתות שכותבים ומריצים בצורה דינאמית באמצעות API. המקדם D מייצג את המילה Dynamic.
ESQL – הם בעצם שאילתות עם preprocessor, כאלו שכותבים למשל דרך תוכנה שלנו. ההבדל בינה לבין DSQL היא שבשפה זו משתמשים בפקודה EXEC. הפירוש של המקדם E מייצג את המילה Embedded.
PSQL – השפה שבה כותבים stored procedure וטריגרים. המקדם של P מייצג את המילה Procedural.

בנוסף ישנה שפה בשם DDL – ‏Data Definition Language. זו השפה בה עושים פעולות כדוגמת create table או create database.

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

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

SQL – כלל השפות:

  • Merge Syntax
  • פונקציות window
  • תמיכה ב regex בביצוע SUBSTRING
  • נכנס סוג נתונים בשם Boolean
  • יכולת לשמור גרסאות עם RDB$RECORD_VERSION
  • cursor יציב

PSQL:

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

DDL‏:

  • תמיכה במצב null של עמודה ו domain
  • היכולת לשנות קידוד ברירת המחדל של מסד הנתונים
  • הוספה של Identity Column – המקביל ל serial בPG ו Auto Increment של SQLITE ו MySQL
  • תחביר עבור RECREATE SEQUENCE/GENERATOR
  • טריגרים עבור DDL
  • תמיכה ב DATABASE LINGER

אבטחה:

  • תמיכה database encryption
  • תמיכה מורחבת יותר בהרשאות Object
  • הרשאות לעבודה עם DDL
  • הרשאות ברמת מסד הנתונים
  • תוספות לעבודה עם Roles

פיקוח:

  • הוספת יכולות נוספות לסטטיסטיקה אודות שאילתות ומסד הנתונים בכלל

אז מה זה כל הסעיפים האלו ? להמשיך לקרוא

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), היות ולי אישית כבר יש מימושים בנושא.

הפילוסופיה של הקוד

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

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

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

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

כל זה נעשה בשפה העברית.

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

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

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

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

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

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

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

פוסט למחשבה.

NaCl, Sodium והצפנה

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

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

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

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

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

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