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

ממשקי משתמש – יצירתיות מול שימושיות

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

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

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

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

נלקחת מ: https://commons.wikimedia.org/wiki/File:Mission_Accomplished_-ALS_Ice_Bucket_Challenge(14848289439).jpg

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

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

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

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

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

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

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

עלייתן ונפילתן של רשתות חברתיות – דעה

ב2007 קיבלתי הזמנה לקחת חלק מאנשים מובחרים באמת ברשת חברתית חדשה ואנונימית בשם פייסבוק.

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

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

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

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

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

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

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

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

להמשיך לקרוא

לצטט ברשת

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

ממשק ציטוטים

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

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

כל שורה (למעט קישור ווב) לא תעבור את עמודה 80, ותהיה ירידת שורה במידה וכן.

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

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

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

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

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

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

תהנו 🙂

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

חשיבה מופשטת

לפני כ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, אשר מן הסתם הוא רעיון ממש לא רע.

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

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

הקדמה

אנחנו חיים בעולם שיש בו המון מילות באזז, כדוגמת 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 !

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

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

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

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

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

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

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

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

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

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

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

מוזילה, לאן ? (2014)

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

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

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

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

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

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

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

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

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

אז השאלות המתבקשות הן:

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

או בריכוז לשאלה בודדת, מוזילה, לאן ?

רובי לאן ?

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

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

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

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

בשל כך, אני שומע הרבה מאוד אנשים שמספידים את השפה. למעשה אני כל הזמן שומע על חוסר ההפרדה בין רובי לבי Rails, אבל כפי ש Metasploit כתוב בשפה, כך גם עוד הרבה מאוד כלים אחרים (כדוגמת fog, puppet, chef, capistrano ועוד).
כפי שכבר כתבתי בעבר, אפילו אצלי, היא מחליפה כבר מזמן את פרל (שגם את השפה הזו אני מאוד אוהב). אפילו YaST – הכלי הכי מזוהה עם סוזה, שוכתב לרובי.

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

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

אנטגוניזם מקצועי

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

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

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

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

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

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

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

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

מראה מראה שעל הקיר – planet foss il

הרבה זמן שיש בעיות עם האגריגיטור של planet.foss.org.il. לפעמים הוא למעלה ולפעמים הוא למטה.
אז החלטתי לקום ולעשות מעשה – ליצור אתר מראה עבורו בכתובת: planet.linesip.co.il.

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

הדרך שביצעתי את המראה פעל ב3 שלבים:

  1. הלכתי ל cache האחרון של גוגל והורדתי את קובץ ה index.
  2. מחקתי את כל התוכן של הbody פרט לרשימת החברים בplanet‏
  3. יצרתי סקריפט רובי קצר שיצר את קובץ הini עבור מערכת ה planet

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

תרבות החשיפה

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

יש בעיה, בפייסבוק ובכלל הרשתות החברתיות, אנשים נחשפים יותר מידי. פייסבוק כבר מוגדרת בהרבה מקומות כאמצעי ריגול. אם תחפשו, תמצאו הרבה מאמרים (1, 2, 3, 4, 5, 6) איך חברות ביטוח מרגלות אחרי משתמשי פייסבוק לדעת עליהם מידע וככה לדרוש תשלום או לא לשלם להם בעקבות הדברים, סתם לקחתי 6 קישורים ראשונים שמצאתי בגוגל …
אבל יותר מזה, אם את/ה בוגדים בבן/ת הזוג, אפשר לאתר אתכם דרך הפייסבוק. כן גם אם יש לך עוד חשבון ועוד בשם בדוי.

אפילו לא התאמצתי לגלות את המאמרים האלו, פשוט כתבתי בגוגל ומייד מצאתי.

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

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

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

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

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

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

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

מוקדש כחומר למחשבה

חוק הנגישות סיבוב 2

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

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

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

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

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

אל תתנו להם לחוקק חוקים – חוק הנגשת אתרים

"The more corrupt the state, the more numerous the laws." — Tacitus

הקדמה

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

רק כאשר מספר מקומות הבינו כי למרות שדפדפנים כדוגמת Firefox מהווים פחות מ5% מהתעבורה, אבל מהווים 90% מכוח הקנייה, שראינו שינוי מגמה.
פתאום אתרים התחילו להיות מונגשים לFirefox תחילה, היות והוא זה שהכניס כסף. אבל בשביל להיות תואם Firefox, כל מה שצריך זה לפתח לפי תקנים (תודה מוזילה), ולכן למעט באגים של הדפדפן, אם אתה כותב לפי התקן, תיאורטית זה אמור לעבוד עבור כולם.
בנתיים גם השימוש ב data עבור הסלולר גדל, ודפדפן Opera Mini תפס, וגם החברה הזו בחרה לעבוד עם תקנים, וראו איזה פלא, לא צריך לשכתב דברים (למעט התאמה לסוג תצוגה).

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

כיום למעט 2 דפדפנים עיקריים, מרבית הדפדפנים מבוססים על אותו בסיס (אשר משתנה לאט לאט שוב), בשם Webkit, אשר התחיל בכלל את דרכו כ KHTML עבור פרוייקט KDE כדפדפן בשם Konqueror.

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

העיקר להמשיך לקרוא

Beware of Amazon AWS

Last year I'ved tested AWS with small server that is "free" for a year (unless you exceed the usage).
When the testing was done, I removed the server, and on my account, there was not even one type of service to remove or delete anymore.

Recently I'ved discovered charges of AWS in my credit card, that I gave them last year, but I haven't used any of their services anymore.
So I'ved email them and now, after two weeks, I still have no answer from them, so I removed my account completely and left them feedback at the web site on this issue.
Furthermore, I've also added a complaint at the Facebook page of AWS.

Taking from you money without giving you any service is theft, and as such, it is a criminal act.
I don't know exactly why the company stole from me, but they did, it was in a very small amount, but still they took money without giving me anything in return, or me asking them for anything, and they took it without my knowledge.

So before you are going to open any cloud service with Amazon, please beware, you might find yourself paying them even after you long stopped using it.

מה נדרש בשביל אתר ?

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

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

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

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

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

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

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

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

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

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

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

My first ruby framework part 1

I'ved tested many static web page generators, and I found a very horrifying conclusion: They are either too big and overwhelming, or they are very small, compact, and written mostly for generating static blogs.

I'ved started to invest a day with a friend static generator, that he wrote for his blog, and even opened 11 bug reports for it, however, the generator he created is also very blog specific solution, and I want to create static web site, not a blog. The difference is in the way routing works, and the whole stat of mind when using such thing. And if I wish to make his generator do what I'm looking for, it will require from me a lot of work.

So, I'ved started yet another static web site generator (more like a framework for it imho 🙂 ), after I'ved tried not to go there in any possible way.

At the first day I'ved started planning how the skeleton of the static content will be, and started looking for libraries that can convert markup languages (markdown, reStracturedText etc…) to html, and I've chosen something that is written in Haskell, with a lot of power named Pandoc. It even has a Ruby wrapper for it, that I'm using for the project. So I jumped to the water of reinventing the wheel and creating yet another generator.

In the beginning, of writing my code, I'ved encountered several problems that needed to be solved. For example: How do I execute my executable without installing it as a Gem ? In default behaviour, if it's not installed, then Ruby does not know how to locate the files. But at the end I found an interesting solution for it:

$BASE_PATH = File.expand_path(File.dirname(__FILE__) + '/..')

I found additional problems to be solved. For example I needed to make Bundler find the Gemfile, but the executable is not part of the Gemfile path. After a lot of research and grep in the source code of Bundler, I found the answer:
It uses an environment variable named BUNDLER_GEMFILE, and it is needed to be set to the Gemfile path like so:

require 'bundler'
ENV["BUNDLE_GEMFILE"] = $BASE_PATH + '/Gemfile'
Bundler.require(:default)

Another problem that I found was in the way of parsing the cli parameters.
Ruby has it's own default library for it, but it was not built for what I was looking for.
So later on, I found a library named slop that is very nice, and works well, but not 100% of what I was looking for.
When I read the Bundler source code, I found Thor, and finally found the proper parser for me, but I will not use it in this version.

I find it very interesting how writing something like a framework takes different way of thinking then normal program.

It is very important to emphasize that at the time of writing this post, my code is still not ready, and many basic things are not implemented, and the core is constantly rewritten. But the next post will be about v0.1 that is ready 🙂

ליצור פריימוורק ברובי חלק ראשון

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

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

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

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

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

$BASE_PATH = File.expand_path(File.dirname(__FILE__) + '/..')

לאחר מכן, נתקלתי בעוד בעיות.
למשל היתה בעיה איך אני גורם לקובץ הריצה למצוא את Gemfile כאשר אני לא רץ בספרייה שהוא נמצא בה.
חיפוש וחפירה בהרבה מאוד קוד, גילה שיש רק דרך אחת לעשות זאת, וזה להשתמש ב environment variable של bundler בשם BUNDLE_GEMFILE :

require 'bundler'
ENV["BUNDLE_GEMFILE"] = $BASE_PATH + '/Gemfile'
Bundler.require(:default)

ועכשיו הוא יכול לעבוד כמו שצריך.

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

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

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

הפצת לינוקס מול תוכנה

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

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

אז מה הן הבעיות ? הנה רשימה חלקית:

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

רמזור תנועה פשוט – עוד ניסוי בארדואינו

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

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

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

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

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

האם גוגל בצרות ?

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

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

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

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

הארץ סוגרת את התוכן, ללא מתן תמורה לקורא

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

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

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

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

  1. תן לי להרכיב את הידיעות והנושאים שמעניינים אותי בלבד
  2. עזור לי להסביר לך מה באמת חשוב ומעניין אותי, ותן לי תוכן בכיוון הזה (כלומר קהל היעד העיקרי שלך הם מתכנתים כמוני, אז תן להם תוכן שקשור בזה בעולם הטכנולוגיה)
  3. תן לי לנהל דיונים אמיתיים על כתבות, כולל עם הכתבים שלך על מה שנכתב – סגנון slashdot ולא טמקא …
  4. אפשר לי לשלם על ידיעה בודדת שאולי תעניין אותי, ולא על מנוי, כך שבמקום שאשלם על מנוי כאשר פעם בחודש אתה מפרסם ידיעה שמעניינת אותי, אוכל לשלם רק על מה שמעניין אותי באותו הזמן
  5. תן לי לנהל ידיעות – כלומר לשמור ידיעות שפרוסמו, לדעת למצוא אותן וכו'
  6. תן טעימות קטנות גם למי שאינו מנוי – תן לי לקרוא רבע מאמר מעניין ולהחליט מה הלאה (זוכר את הרכישה של מאמר ספציפי ?)
  7. צור קהילה סביבך, כזו שתרגיש שאתה הבית שלה, נגיד תקרא לה קפה דה מארקר ?

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

Planet Object Pascal

I'm glad to announce the creation of Planet Object Pascal.

I have created it in order to provide one place to have all known blog and knowledge of the Object Pascal developers (Virtual Pascal, Free Pascal, Delphi etc…)

If you have a blog that writes about Object Pascal, feel free to contact me, and I'll add you to the planet.

Having said that, I'm looking for a way to better design this, and at the long run, write something a newer system, then continue and using the unmaintained planetplanet system.

הממשל אינו זמין כעת, אנא נסה במועד מאוחר יותר

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

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

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

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

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

מדוע להגביל דפדפנים, ופשוט לא לעבוד לפי תקנים ?

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

מצגות בעולם הרחב של הרשת

מאז 2007, התחלתי להעביר הרצאות, חלקם ללקוחות בתשלום, ורובם קהילתיים לגמרי.

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

עד היום הייתי במידת הצורך יוצר שקפים באמצעות Impress של Libre/Open Office (בהתאם לקיומם בעולם), וכבר הרבה זמן שאני חושב להתחיל לעשות את זה קצת אחרת.

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

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

אז החלטתי ללכת על משהו בין מה שגוגל מציעים לבין impress.js, ומצאתי את reveal.js.
המערכת מציעה להעביר מצגות, עם תמיכה ב html5, css3 ו javascript. אבל אינה דורשת ממני לתכנת דברים, אלא להתמקד בתוכן, וכיצד אני רוצה שהוא יוצג. למעשה התכנות שלי זה html הכי מינימליסטי בעולם. המפתח שלה אפילו חשב על תמיכה בשפות כמו עברית, ולאפשר לנו להציג הרצאה מימין לשמאל לפי בחירה.

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

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

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

May the source be with you 🙂

where have all the music gone ?

I used to be a Pandora user, but due to issues with the Music labelling cartel, it was forced to close it's service outside of the U.S. Australia and New-Zealand.
So I moved to Last.fm that offered me to pay a fee and listen to music. Until I got the following Email: להמשיך לקרוא

Facebook do not understand their users

I've been using Facebook on and off since 2007, and have to say one thing:

Facebook do not understand their users, or how to make things right !

What does it mean, you probably ask yourself ?
Well here are some of the messages I keep on getting on Facebook in the past few months (Almost constantly): להמשיך לקרוא

Display Quote ההמשך

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

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

display_quote_navigation_mode

החלטתי עכשיו לשים לעצמי 2 מטרות לגרסה שאני יוצר:

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

הבעיה עם פייסבוק, היא שאסור לי לפרסם את הסיסמה שהפרוייקט קיבל, ובנוסף אני צריך ליצור או להתחבר למימוש של OAuth2, אשר שונה מ OAuth1 למשל …

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

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

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

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

display_quote_edit_mode

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

לאחר שאסיים את 2 השלבים האלו, כנראה שהשלבים הבאים יהיו:

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

עוד רעיונות ממכם יתקבלו בברכה.

הקוד עצמו, ד"א כרגיל נמצא ב github.

Zoho Mail vs Google Mail

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

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

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

חדשות Firebird

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

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

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

בנוסף, אפשר להתחיל להנות מהרצאות על Firebird ובכלל סרטונים על Firebird בערוץ SQLFirebird ב Youtube.

תהנו מהרצאה של Ann Harrison (אחת מהממציאים של מסד הנתונים המקורי):

האם לתרום ערכים לוויקיפדיה ישראל ?

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

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

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

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

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

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

זהירות מחנויות ישראליות ברשת

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

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

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

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

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

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

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

מהם הדגשים שצריך בעת תכנון סביבה גרפית ?

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

כיום יש מספר סביבות גרפיות שצריך לקחת בחשבון: אתרי ווב, שולחן עבודה, טלפון סלולרי ("חכם") ומחשבי לוח (למינהם). כל אחד מהם דורש גישה שונה. ואם זה לא מספיק חמור, אז כל סביבה גרפית מכילה הוראות עיצוביות משל עצמה, שלרוב אינם דומות למערכת אחרת. כלומר משהו שנכתב עבור גנום 3, לא זהה בהוראות העיצוביות לגנום 2, שלא דומה ל KDE או Windows וכו' … גם בWindows ההוראות האלו משתנות לפי כל גרסת מערכת (מאז 95, כבר נכתבו מספר מדריכים של מיקרוסופט בנושא, אחד לסביבות ה95, אחד לסביבות הXP אחד לvista ואחד ל7 ובקרוב גם ל8).

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

פרוייקט תחביב – ted.rb

התחלתי החודש ליצור פרוייקט תחביב חדש, בשם Ted-Parser המאפשר להוריד ממקור ה RSS של TED הרצאות שונות. כידוע, ההרצאות של TED מגיעות ברישיון CC כך, שההורדה שלהם חוקית, כל עוד אני לא אומר שההרצאות הם שלי.

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

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

שלום ולא להתראות גוגל+

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

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

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

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

אתר עם שפה

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

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

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

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

Playing with web frameworks

Foreword

I'm researching several web frameworks in order to create a web application that I need to, that also should work as a web site on the Internet, and will have API to integrate things into other web-sites, if clients does not want to use that site.

For the task I started with two frameworks:

  1. fpWeb – aka fcl-web
  2. django

I do not want to try Rails, because I find the logic behind it very disturbing. The Rails framework rewrite the language, rather then adding libraries to use. I think that it is not the proper way to write libraries. So I decided not to try it at all, even though I really love the Ruby language itself.

fpWeb

So I started testing fpWeb, and I must say that it takes a while to get used to it and the way it does things, but once I figured out the basics, I find it really enjoyable to write a CGI (I always hate to write html/css stuff though, and that's regardless of the language for the server side) application.

fpWeb works in very different mindset then most modern web frameworks I have ever worked with so far. On one hand it appears that everything chosen for you, that is the template engine, session engine etc.. But  on the other hand, you can actually use what ever you want, just decide on something and go for it. להמשיך לקרוא

תפוצה

קיבלתי הזמנה מגיא שפר להיכנס ל‎‏Diaspora* או תפוצה בעברית. אז אתם בטח שואלים את עצמכם מה זה בדיוק… ובכן תפוצה היא ניסיון של חבורת אנשים ליצור פייסבוק קוד פתוח שאמור להיות עם יותר פרטיות ועם שליטה טובה יותר של המשתמשים מאשר פייסבוק. אה והיא כתובה בRails, למרות שבמקור דיברו שהיא תהיה כתובה בPHP, אבל זה לא קושר 🙂

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

המערכת משתמשת בהרבה מאוד Javascript ו HTML5 בעוד שFacebook משתמשת המון בJavascript אבל אין בה תכונות של HTML5 שאני גיליתי.

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