אתר נקודה ישראל

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

חברת דומיין דה נט מספקת שמות מתחם בעברית כבר במשך שנים למאות (אלפי?) לקוחות שלא הבינו שמדובר בפעולה על גבול ההונאה, שהרי שמות המתחם שלהם לא יהיו נגישים לא למנועי חיפוש, לא לשירותים ומערכות שלא מקושרים לשרת DNS שעבר "טיפול" כדי שיוכל לזהות את הסיומות הללו, ולמעשה אף־אחד לא ערב ללקוחות שמחר או מחרתיים הם לא יאבדו את הגישה לשמות המתחם שהם רכשו במיטב כספם, ואלו גם יקרים יותר משמות מתחם חוקיים; נכון לזמן כתיבת שורות אלו מחירו של שם מתחם חדש דרכם הוא 210₪, כאשר בפחות מ־100₪ ניתן לרכוש שם מתחם רגיל.

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

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

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

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

איגוד האינטרנט הישראלי הוא עמותה לקידום השימוש באינטרנט, שבין היתר שולט בשמות המתחם תחת הסיומת של ישראל, "‎.il". סיומת זו היא בין הראשונות שהופעלו, בדגש על סיומות של מדינות, וקיימת עוד משנת 1985, אם כי איגוד האינטרנט הוקם וקיבל את השליטה על סיומת זו רק כעשור מאוחר יותר. סיומות מדינה מטרתן העיקרית הייתה ליצור הבדלה בין אתרים עולמיים, אבל לאור כך שבימיה הראשונים של רשת האינטרנט רבים העדיפו שימוש בסיומות העולמיות com/net/org, נוצר מצב בו במקומות מסוימים בעולם לא היו מודעים כלל לקיומן של סיומות מקומיות דוגמת "‎.us".

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

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

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

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

רשימת סיומות שמות המתחם שאושרו על־ידי ICANN, המידע נאסף מויקיפדיה.
סיומת בשפה לאומית מדינה תעתיק
الجزائر. אלג'יריה al-jaza'ir
.বাংলা בנגלדש bangla
.中国 סין zhōngguó
.中國 סין zhōngguó
مصر. מצרים masr
.გე גיאורגיה ge
.香港 הונג קונג hoeng1 gong2
.भारत הודו bhārat
بھارت. הודו bhārat
.భారత్ הודו bhārat
.ભારત הודו bhārat
.ਭਾਰਤ הודו bhārat
.இந்தியா הודו inthiyaa
.ভারত הודו bhārat
ایران. אירן īrān
الاردن. ירדן al'urdun
.қаз קזחסטן qaz
مليسيا. מלזיה Malaysia
.мон מונגוליה mon
المغرب. מרוקו al-maghrib
عمان. עומאן Oman
پاکستان. פקיסטן Pakistan
فلسطين. האוטונומיה הפלסטינית filastīn
قطر. קטאר Qatar
.рф רוסיה RF
السعودية. ערב הסעודית as-saʢūdiyyah
.срб סרביה srb
.新加坡 סינגפור Xīnjiāpō/Sin-ka-po
.சிங்கப்பூர் סינגפור cinkappūr
.한국 דרום קוריאה hangūk̚
.ලංකා סרי לנקה lanka
.இலங்கை סרי לנקה ilangai
سودان. סודן Sudan
سوريا. סוריה sūryā
.台湾 טאיוואן táiwān/tâi-oân
.台灣 טאיוואן táiwān/tâi-oân
.ไทย תאילנד thai
تونس. תוניסיה tūnis
.укр אוקראינה ukr
امارات. איחוד האמירויות imārāt
اليمن. תימן alyemen

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

 

 

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

Mozilla Summit 2013

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

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

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

במהלך הכנס אני אנסה לקדם חלק מהנושאים שמעניינים אותי, כגון הפעלת הממשק העברי בגרסאות הרשימות של Firefox OS ו־Firefox for Android, ללמוד מלקחים של אזורים אחרים בעולם מה כרוך בייבוא רשמי ומכירת מכשירי Firefox OS בארץ, ואם יתאפשר גם לנסות לקדם מספר נושאים נוספים שמתעכבים הרבה יותר מידי זמן, כמו ההקמה של האתר החדש של מוזילה ישראל והוצאת האתר הנוכחי לגמלאות.

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

מבוא לתסריטאות

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

אחרי שהסטודנטים לומדים מספר שפות מחשב שימושיות, דוגמת C,‏ CPP,‏ Java ו־C#‎, מתקבל הרושם שהסטודנט שולט בכול השפות והידע שברשותו ישמש אותו שנים רבות. בפועל, קיימות שפות תכנות רבות נוספות אותם נדרשים מרבית עובדי התעשייה ללמוד על־מנת להתקבל למקומות עבודה מסוימים או כדי להטמיע בארגון טכנולוגיות חדשות. למעשה, בתחומים מסוימים שימוש בשפות שהזכרתי קודם כמעט לא מורגש בהשוואה לשפות אחרות; למשל מעטים הם אתרי האינטרנט שנכתבו בשפות כגון CPP ו־Java, לעומת שפות אחרות דוגמת PHP,‏ Perl,‏ Python ו־Ruby.

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

בהרצאה שהוצע לי להעביר התבקשתי לדבר על אופן כתיבת התסריטים והיתרונות שיש בכתיבת תסריטים על־פני שפות תכנות "רגילות", שזה קצת טעות להציג כך את התחום, שהרי הכתיבה ושימוש בשפות תסריט התחילה בסמוך להופעתם של המחשבים הראשונים בשנות החמישים של המאה הקודמת, והתפתחה יחד עם שפות התכנות האחרות. התבקשתי להתמקד בשפת תכנות אחת בלבד, ולצערי אאלץ להימנע מהדגמות על לינוקס עקב הידע המינימלי של הסטודנטים במערכת הפעלה זו, ומאותה סיבה גם אאלץ להימנע מהצגת דוגמאות Bash וגם לדבר על יכולות ייעודיות ל־Shell Scripting כגון Pipes, Redirections והעברת מידע בפרמטרים בין יישומי שורת פקודה.

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

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

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