ספרית מפות חדשה לפיתוח אפליקציות web

לאחר חודשים של עבודה מפרכת שחררתי היום את ספרית המפות מבוססת ה-Google Web Toolkit שלי. הספריה מאפשרת פיתוח אפליקציות web עם מפות בשפת Java (החביבה עלי וכן על עמרי עד מאוד), כשם ש-Google Maps API מאפשר זאת למפתחי JavaScript.

לאחר נסיוני המר עם ה-GPL פרסמתי את ספרית המפות תחת ה-CC BY-NC-SA.

יום הולדת שמח, עמרי, ותהנה מהאוגרים!

hcoop.net, לא רק לקומוניסטים

אחרי תקופת מעבר ארוכה בה מאמצי מנהלי הרשת הופנו לבניית השרתים החדשים, hcoop.net פותחים את השערים למשתמשים חדשים.
hcoop הוא ארגון שלא למטרות רווח שמספק שרותי הוסטינג במחיר עלות לכמה מאות גיקים (העלות מתחלקת בין החברים בhcoop).
אני מאכסן בhcoop את הבלוג הזה, את firestats.cc ועוד כמה אתרים שונים ומשונים, והכל במשהו כמו 5$ לחודש.
מה שחשוב לי במיוחד, זה שאני מקבל גישת shell ואפשרות להריץ למעשה כל דבר שאני רוצה על השרת.
מנהלי הרשת מאוד גמישים ואם יש לכם בקשה מיוחדת יש סיכוי טוב שהיא תקבל מענה מספק.
בנוסף hcoop מאפשרים מספר בלתי מוגבל של הוסטים וירטואליים, שזה דבר נוח מאוד.
hcoop מומלץ רק למשתמשים שלא חוששים משורת הפקודה ומקריאת תיעוד.

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

IPv6

IPV6 היא הגרסא הבאה של פרוטוקול האינטרנט, שכבר מתבשלת כמה שנים טובות.
השינוי המרכזי ביותר, והמוטיבציה הגדולה של השינוי נובעת מהבעיה המחריפה והולכת של חוסר בכתובות IP פנויות. בIPV4 – הגרסא הנוכחית, כל כתובת תופסת 4 בתים שהם 32 ביט, מה שאומר שיש 2 בחזקת 32 כתובות אפשריות שזה קצת יותר מארבע מיליארד כתובות אפשריות.
התקן של IPV4 נקבע ב1981, ארבע מיליארד כתובות נראו אז כמו הגזמה פראית, ואף אחד לא דימיין שבתוך כמה עשרות שנים יהיה צורך ביותר כתובות.
השוק התמודד עם המגבלה במספר כתובות הIP במספר צורות:

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

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

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

IPV6
השינוי המרכזי בIPV6 הוא הרחבת טווח הכתובות האפשריות. במקום 4 בתים לכתובת IPV4, יש לא פחות מ16 בתים בכתובת IPV6.
קצת מתמטיקה:
4 בתים הם 32 סיביות. 2 בחזקת 32 זה 4,294,967,296,
4 מיליארד כתובות בIPV4.
16 בתים הם 128 סיביות, 2 בחזקת 128 זה:
340,282,366,920,938,463,463,374,607,431,770,000,000
340 מיליארד מיליארד מיליארד מיליארד כתובות בIPV6.
אז תחום הכתובות של IPV6 יספיק להרבה הרבה זמן.

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

שיפורים נוספים הם תמיכה מובנית בתעדוף תעבורה מסויימת (QOS), הגדרה אוטומטית (Auto-configuration), חבילות נתונים גדולות לשיפור ביצועים ברשתות שמעבירות הרבה מאוד מידע (JumboGrams, חבילות נתונים בIPV4 מוגבלות לגודל של 65535 בתים, בIPV6 לעומת זאת החבילות יכולות להגיע לגודל 4 ג'יגה לחבילה)

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

ייצוג טקסטואלי של כתובות IPV6
אנשים רגילים לכך שכתובת IP הן מהצורה המקובל של a.b.c.d, כאשר כל מספר הוא בן 0 ל255.
בIPV6 התמונה משתנה, במקום 4 קבוצות בין 0 ל255, פתאום יש לנו 8 קבוצות של 0 עד 65535, שמיוצגות בבסיס 16, ומופרדות על ידי נקודותיים.
למשך:
[code]
2001:0db8:0000:0000:0000:0000:1428:57ab
[/code]
יהיה לא נעים להקריא את זה בטלפון.
כדי לעזור קצת, הוגדר הקיצור הבא:
סדרת אפסים אחת בכתובת יכולה להתכווץ לצמד נקודותיים, ואפשר גם להתעלם מאפסים שפותחים קבוצה – מה שאומר שאת הכתובת הזו אפשר לכתוב גם כך:
[code]
2001:db8::1428:57ab
[/code]
קצת יותר טוב.

FireStats וIPV6.
עד גרסא 1.4, פיירסטטס מאכסן כתובות IP בתוך מחרוזת תווים, ולכן תומך גם בIPV4 וגם בIPV6.
אחד הפיצ'רים המבוקשים ביותר הוא היכולת להתעלם מטווח של כתובות IP.
עד 1.4, ניתן להוסיף כתובות מסויימות לרשימת ההתעלמות, אבל זה לא מספיק כשרוצים להתעלם מטווח שלם, למשל כדי לסנן את הספאם של מייקרוסופט.
כדי לתמוך בסינון לפי טווח כתובות, הכי טוב לשמור את כתובת הIP כמספר ולא כמחרוזת – כי אז אפשר לבדוק אם המספר נמצא בטווח בקלות.
אבל באיזה כתובות IP לתמוך?
אומנם 99% מהמשתמשים עובדים עם IPV4 בלבד, אבל אם אני אסתמך על זה, זה בעצם אומר שאני מבטל את התמיכה בIPV6, צולעת ככל שתהיה.
לא ממש רציתי לעשות את זה, ולכן החלטתי לתמוך בIPV6 גם אחרי המעבר משמירת כתובות טקסטאלית לשמירה מספרית.

אבל איך שומרים כתובת IPV6 בMySQL כמספר? הטיפוס המספרי הגדול ביותר בMySQL הוא BIGINT, שרוחבו 8 בתים, וסיכמנו כבר שכתובת IPV6 היא ברוחב 16 בתים.
הפתרון הוא להשתמש בשתי עמודות של BIGINT, אחת לחצי הימני של כתבות הIP והשניה לחצי השמאלי.
קצת מכוער, אבל זה המצב.
בעיה נוספת שצריכה התייחסות מיוחדת היא בעיית ההצגה והקליטה של כתובות IP.
כשמגיעה כתובת IP טקסטואלית למערכת, צריך להבין מאיזה גרסא היא, ולתרגם אותה לייצוג מספרי.
כשרוצים להציג כתובת IP מספרית, צריך לעשות את הפעולה ההפוכה ולהציג אותה בצורה הידידותית ביותר (IPV4 אם הכתובת המקורית היא בIPV4, אחרת IPV6).
מכיוון שהתמיכה בIPV6 בPHP די צולעת – קיימות פונקציות, אבל רק מגרסאות חדשות של PHP וגם אז הן לא נתמכות בכל מערכות ההפעלה – כתבתי את פונקציות ההמרה והזיהוי בעצמי.
אפשר לראות בתמונה טווח IPV6 ליד כתובת IPV4 בודדת:
firestats ipv6

קריאה נוספת:

IPv6: The Promise, The Problems, The Protocol
ווקיפדיה

האינטרנט הוא הרשת החברתית

גוגל יוצאים עם OpenSocial, API חדש שבא לחבר בין רשתות חברתיות שהיו סגורות בעבר לאפשר כתיבת ישומים חברתיים שירוצו על מגוון רשתות חברתיות.
השאלה היא למה בכלל צריך רשתות חברתיות?
כבר היום האינטרנט הוא מעין רשת חברתית, הבעיה המרכזית היא המגוון בצורת השמירה והגישה אל המידע שטמון בו.
ליותר ויותר אנשים יש היום אתר אישי, והמגמה הזו מתגברת מהר מאוד.
לא טבעי מאוד שאתר האישי יכיל גם מידע על מי החברים שלי, יאפשר להשאיר לי הודעות, וכו'?
לכאורה, כבר היום כל הדברים האלו אפשרים, למשל:
* אני מריץ שרת דואר שמאפשר לשלוח לי דוא"ל
* אני מריץ שרת Jabber שמאפשר לצ'וטט איתי
* הגרגרן שלי מספר את מי אני קורא.
העניין הוא שמדובר בשרותים שונים, ואין סטנדרט אחיד שיאפשר למישהו שמכיר רק את האתר שלי לשלוח לי הודעה, או לצ'וטט איתי, או לבדוק מה אני קורא או האם יש לי חברה. (כמובן בהנחה שאני מעוניין לחשוף את המידע).
רשתות חברתיות באות לתת מעין סטנדרט כזה, כל רשת בתוך עצמה:
כשאני נמצא ברשת מסויימת, קל לי לחפש אנשים ברשת, קל לי לשלוח הודעות לאנשים או לצ'וטט איתם, קל לי לראות את פרטי הפרופיל שלהם וכו', אבל ברגע שאני עובר לרשת אחרת הכל משתנה.
הממשק של הרשת החברתית מכתיב לי את צורת העבודה, ובנוסף אנשים מופיעים בכמה רשתות עם פרטים ברמת עדכון שונה ואני צריך לזכור שFooBar ברשת אחת הוא בעצם JohnDoh מרשת שניה.
הנסיון של גוגל לפתור את הבעיה הוא להפוך את צורת הגישה למידע שנשמר ברשתות החברתיות לסטנדרטית, ובכך לאפשר לכל אחד לכתוב ישומים שרצים מעל המידע שנשמר ברשתות החברתיות האלו, אבל הוא בא לפתור בעיה אחרת: איך נכתוב ישומים שירוצו על יותר מרשת חברתית אחת.
מה שאני מציע לעומת זאת זה לפזר את המידע עצמו מחדש: במקום שכולו ישב בשרתי פייסבוק, או בשרתי לינקדאין, הוא ישב במאות אלפי שרתים, ששייכים למאות אלפי אנשים שונים.
אם ניקח דוגמא טריויאלית: אין ספק לאף אחד שנפח ההודעות שעוברות בכל יום בדואר אלקטרוני רגיל הוא משמעותי הרבה הרבה יותר מנפח ההודעות שעובר בכל הרשתות החברתיות יחד. הסיבה לכך היא שמדובר בפרוטוקול וותיק ומקובל, ושעובד למעשה בשיטת P2P, בלי ליצור צוואר בקבוק בצורת אתר אחד שמחזיק את כל הדואר בעולם או שמאפשר לחפש את האימייל של אנשים לפי השם שלהם. במילים אחרות: סך נפח השמוש באימייל לא מוגבל על ידי העומס המקסימלי ששרת מסויים מסוגל לשאת, ובנוסף השימוש באימייל הוא חופשי לגמרי במובן שלא צריך להרשם במקום מרכזי כדי לשלוח ולקבל אימייל. (ולפני שאתם אומרים שצריך לפתוח חשבון אימיל בשרת: זה נכון, אבל אתם יכולים להריץ את השרת בעצמכם, אתם לא צריכים טובות מאף אחד).
נניח שהמידע שהיום אני חושף על עצמי ברשתות חברתיות היה מרוכז רק באתר שלי, בצורה סטנדרטית שתאפשר לתוכנות לתשאל את השרת שלי לגבי:
* כבר לא צריך לתחזק 30 פרופילים שונים ברשתות חברתיות שונות, הכל יהיה במקום
* פתאום ברור איפה נמצא המידע עלי: בשרת שלי (שמייצג אותי ברשת)
* פתאום יש לי שליטה על המידע שלי, אם אני מחליט להפסיק לפרסם משהו, אני לא תלוי בחסדים של ספק מסויים כדי למחוק את המידע.

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

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

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

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

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

מצא את הכתבה

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

the-marker.png

ComCast, and so it begins

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

The great firewall of Comcast

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

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

מכונת הריגול הסודית של הממשלה

קידום של אימייל שקיבלתי מחבר בעל מודעות טכנולוגית לקויה:

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

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

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

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

בכדי שאדם יחשב כתומך בעצומה, עליו להעביר מכתב זה הלאה, ובכך הוא מצטרף ל"מונה האנשים" החתומים על העצומה.
נכון להיום, ה-1.9.07, חתומים על עצומה זו 300,764 איש. העצומה החלה לעבור לפני שבועיים וחצי בלבד!!!

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

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

IE7 לכל

לפני כשנה מייקרוסופט שחררו את IE7, ואיפשרו רק למשתמשי XP או וויסטה חוקיים להוריד אותו. (למעט אי אלו גרסאות מפוצחות).
IE7 דשדש אצלי בסטטיסטיקות, ושנה אחרי הוא עדיין לא הפך לגרסאת האקספלורר הדומיננטית :
בבלוג פה מהמשתמשים מריצים IE7 24% לעומת 41% שמריצים IE6.
באתר של פיירסטטס 9.2% מהמשתמשים מריצים IE7 לעומת 16.2% שמריצים IE6.
בכל מקרה, IE6 עדיין שולט אצל מריצי האקספלורר, עם קרוב לפי שניים משתמשים.

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

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