שנה: 2013

אבני הבניין של האינטרנט: URL

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

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

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

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

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

פוסט זה הוא חלק מהסדרה: אבני הבניין של האינטרנט.

מבנה ה Universal Resource Locator

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

להלן מבנה ה URL הרשמי:

(1) סכמה
לרוב זהו שם הפרוטוקול כגון http או https[א], או אפילו ftp, git, gg או אחד מני רבים אחרים.
הסכמה יכולה לכלול Psuedo-Protocol שאלו בעצם שמות שנשמרו ע"י הדפדפן בכדי לגשת לפונקציונליות פנימית מבלי לבצע קריאת HTTP. לדוגמה:

  • about:blank טוען דף HTML ריק. משמש לבדיקות ולאיתור זליגות זיכרון ע"י מתכנתי ג'אווהסקריפט. רשימת פקודות about בדפדפנים השונים.
  • :javascript – בכדי להריץ פקודת ג'אווהסקריפט
  • :data – בכדי לקודד מסמך (קצר) inline בתוך ה URL כגון:
data:text/plain, hello%20world!
השימוש העקרי של סכמה זו היא הטמעה של תמונות קטנות בתוך המסמך בכדי לחסוך roundtrips לשרת.

(2) //
המבטאים שמדובר ב URL בעל חלק היררכי.
למשל: mailto:name@example.com?a=b הוא URL תקני ללא חלק היררכי.

(3) פרטי החיבור
משמש לפרוטוקולים ספציפיים כגון ftp או Https.

(4) כתובת
הכתובת יכולה להיות מתוארת באחת מ 3 סכמות:

Hostname
כתובת ה hostname היא כתובת טקסטואלית שמשמשת כ alias ל IP Address. כתובות IP הן דינמיות ועשויות להשתנות לאורך הזמן. תהליך ההפיכה של הכתובת הטקסטואלית (hostname) לכתובת IP היא תהליך שנקרא DNS Lookup. שרת ה (Domain Name Servers (DNS שאליו פנינו כעת יקרא לשורה של DNS אחרים בכדי ללמוד על הכתובות, כל שרת DNS אחד בתורו יודע לפרש חלק מהכתובת.
לדוגמה, עבור הכתובת http://ynet.co.il תחילה קוראים לשרת ה ROOT כדי ללמוד על כתובת ה IP של שרת ה "il" (מפרשים את כתובת ה hostname מהסוף להתחלה). בשלב הבא תהיה פנייה ל DNS של "il" וללמוד ממנו את כתובת ה IP של שרת ה "co" ורק אז מקבלים את הכתובת ה IP של השרת של YNET בכבודו ובעצמו. כמובן ששרתי DNS שומרים cache, כך שסביר ששמות נפוצים יחזרו מה cache ולא יהיה צורך לפנות לשרתי DNS אחרים.

אתר יכול להוסיף לעצמו תחיליות ל hostname לצורך חלוקה פנימית. לדוגמה, לאחר שהדומיין ynet.co.il נמצא, ynet יכולים להפנות ל"תתי אתרים / אפליקציה" שלהם בשם mail.ynet.co.il או en.ynet.co.il.

התחילית www היא תחילית לכל דבר ממש כמו mail או en שכל שרת יכול לבחור אם להשתמש בה או לא. www הוא קיצור של world-wide-web ובשנות ה-90 זו הייתה קונבנציה מאוד מקובלת. אם אתם נגשים לאתר ללא תחילית www הוא לרוב פשוט יפנה אתכם לכתובת האתר עם התחילית. או שלא.
יש דיון ארוך שנים העוסק בשאלה האם נכון להמשיך בקונבנציה דיון1 דיון2, ללא שום מסקנה ברורה באופק.

כתובת IPv4
כתובת ה IP שמוזנת ידנית ע"י המשתמש, כך שניתן לדלג על ה DNS Lookup (בהנחה שכתובת ה IP לא השתנתה).
כתובת ה IPv4 מורכבת בעיקרה מ4 octets של 0-255, כגון 10.3.0.163. URL הכולל כתובת IPv4 יכולה להראות כך: http://10.3.0.163/yo#hey.

כתובת IPv6
פרוטוקול IP גרסה 6 נוצר בכדי להתמודד עם המחסור שנוצר בכתובות ה IPv4 הזמינות. בערך לפני כחצי שנה היו אמורות להיגמר כל כתובת ה IPv4 בעולם וכדי למנוע זאת היה מעבר מסיבי לכתובות ארוכות יותר שיספיקו לעוד מספר רב של שנים.
כתובת IPv6 מכילה 8 קבוצות של מספרים hexdecimal ארבע-ספרתיים כגון 2001:0db8:85a3:0000:0000:8a2e:0370:7334. על מנת לחסוך באורך הכתובת ניתן לכתוב את אותה הכתובת כ 2001:db8:85a3:0:0:8a2e:370:7334 או אפילו כ 2001:db8:85a3::8a2e:370:7334.

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

(5) Port
מספר בין 1-65536. הטווח 0-1023 שמור לרוב עבור מערכת ההפעלה ואין להשתמש בו כשאתם פותחים server socket. אם לא הוקלד ערך ב http – הערך יקבע על 80, וב https – יקבע על 443. כאשר יש שירות שנענה גם ל http וגם ל https, מקובל שמספרי הפורט יהיו עוקבים, למשל 5000 ו 5001.

(6) רשימה היררכית של Resources.
רוב הדפדפנים יקבלו גם "\\" בתור ה Separator.
סטייה מהתקן על מנת "להקל" על המשתמש  – היא התנהגות נפוצה בקרב דפדפנים.

(7) Query String
אנשים נוטים להניח שהפורמט של Query Sting נדרש להיות key1=value1&key2=value2 – אבל זו סתם קונבנציה שהשתרשה במשך השנים והיא איננה מחייבת. לדוגמה: מותר להשתמש ב ? בתוך ה Query String בכדי לבצע separation בין ערכים.
פעם כתבתי קוד שהניח שיש רק ? אחד ב URL – וכך נכשל. שיחה קצרה עם המפתח שכתב את הקוד שגרם לכשלון למדה אותי על החוקיות של מבנה ה Query String.

בפועל Query String הוא BLOB ש:

  • מיוצג בתווי ASCII. אם אתם רוצים באמת להעביר מידע בינארי (מותר) עליכם להשתמש ב Encoding שנקרא Base64.
  • נתחם ע"י סימן ה # הראשון שמופיע.
Query String משמש לרוב על מנת להעביר פרמטרים לשרת. Query String הוא חלק לכל דבר ועניין מה URL כך ששינוי בתו יחיד בתוך ה Query String משמעו – URL אחר.
(8) Fragment ID
בניגוד ל Query String שמיועד לצד-השרת, ה FID מיועד לצריכה ע"י קוד צד-לקוח. קונבנציה מקובלת היא שה Fragment מתאר מיקום במסמך. לדוגמה: אם תבצעו inspect למסמך ותמצאו id של אלמנט ב DOM, תוכלו להוסיף אותו ל URL כ FID כך שמעתה הדפדפן יציג את הדף כאשר בראש המסך הוא יציג את האלמנט עם ה ID שצוין.
באפליקציות מודרניות משתמשים ב FID על מנת לתאר את ה State של האפליקציה, לדוגמה: איזה טאב נבחר ואיזה Panels הם פתוחים. אין מניעה לקודד state מורכב כ BLOB על ה FID. שינוי ה FID-בלבד ב URL לא יגרום לטעינה מחודשת של הדף אלא יזרוק event מסוג hashChange. ה FID לא אמור להישלח לשרת.
ע"פ התקן, אגב, לא אמורה להיות מגבלה על אורך ה URL אולם IE8 ו IE9 מוגבלים ל 2048 תווים, ודפדפנים אחרים מתירים פי 2 או 3 מכך (בזה אני מעודכן כמה שנים אחורה, אולי דברים השתנו…).

Relative URL

עוד נקודה אחרונה ורלוונטית היא היכולת להתייחס ל "URL יחסי", כלומר URL יחסית ל URL של ה Document (דף ה HTML) הנוכחי. URL יחסי אמור לעבוד מכל הבחינות בדיוק כמו URL מלא.

נניח שאני כרגע בכתובת

 

URL יחסי שאינו מתחיל ב "/", למשל "gogo/a/b" שקול ל:

URL יחסי שמתחיל ב "/" למשל "gogo/a/b/" שקול ל:

כללי ה path הבסיסיים של unix תקפים כך שה URL היחסי "a/b/.." שקול ל

בהגדרה, URL יחסי הוא כזה שלא מתחיל בפרוטוקול (למשל http) וגם לא מכיל את האינדיקטור ל URL היררכי "//".

URL יחסי תקני הוא "http://www.walla.co.il//" – שמצביע לאתר וואלה עם הפרוטוקול שכרגע בשימוש בדפדפן (למשל ftp).
דוגמה אחרת היא ה URL היחסי "details#" – שהוא URL יחסי לכתובת הדפדפן הנוכחית עם FID בשם details. שימוש ב details# לא תגרום לדף להיטען מחדש (מכיוון שה FID הוא חלק ה URL הרלוונטי לצד-הלקוח בלבד).

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

שיהיה בהצלחה!

—

[א] Https הוא Http שמוצפן על גבי פרוטוקול שנקרא SSL (או בגרסה היותר חדשה: TLS). השימוש ב Http יעשה באתרים שמכילים מידע פרטי או מסווג (למשל קופת חולים או בנק). במערכות ארגוניות נהוג להשתמש בעיקר ב https משיקולי אבטחה.

פוסט רלוונטי (כולל כמה נקודות על Encoding של URL): http://blog.lunatech.com/2009/02/03/what-every-web-developer-must-know-about-url-encoding

מה חדש באופיס 2013?

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

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

כללי

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

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

  • כרגע SkyDrive מספק 7GB אחסון בחינם, שזה יותר מכל מתחרה אחר – ככל הידוע לי. 
  • האפליקציה של SkyDrive למובייל ולדפדפן מציגה היטב קובצי אופיס מכל הסוגים – שזה ייתרון לא קטן. 
  • האפליקציה ל iOS, לפחות ע\"פ Battery Doctor, צורכת כמעט חצי מתצרוכת החשמל של Google Drive: עוד בונוס קטן.
    Touch Mode
    מכיוון שמייקרוסופט מכוונת כיום לטאבלטים ומחשבים ניידים עם מסכי-מגע, חבילת אופיס 2013 עברה התאמה לטאצ\'. בשימוש בעכבר – נוחים יותר ריווחים קטנים מכיוון שהעכבר הוא מדוייק ואנו רוצים לגלול אותו כמה שפחות. מצד שני לאצבע אנושית עדיפים ריווחים גדולים יותר כדי לא ללחוץ בטעות על כפתור אחר מזה שהתכוונו. המרחק הגדול יותר שיש לעבור בין הכפתורים אינו מפריע, מכיוון שהאצבע נעה מהר ללא מאמץ.

    באופיס 2013 ניתן לעבור בין \"מצב עכבר\" (ריווחים קטנים) ו\"מצב טאצ\'\" (ריווחים מוגדלים):

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

    פ\'יצרים שהוסרו
    לחבילת אופיס 2013 יש מספר תכונות שהוסרו, הבולטות שבהן הן:

    • Clip Art Organazier 
    • SharePoint Workspace (לשעבר Groove) – אפליקציה לשיתוף קבצים.
    • Office Picture Manager (אפליקציה עצמאית לעריכת תמונות) 

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

    אופיס RT
    עבור חלונות 8 RT (המבוססת מעבדי ARM) יש גרסה מצומצמת של אופיס הכוללת: וורד, אקסל, פאוורפוינט ו OneNote (בולט בהעדרו: אאוטלוק). אופיס 2013 RT מסופקת ביחד עם מערכת ההפעלה Windows 8 RT, כלומר – כלולה במחיר. על פניה חבילת אופיס RT נראית אותו הדבר, אך בפועל יש מספר פיצ\'רים קטנים שלא זמינים בה. ע\"פ מה שהבנתי, לאופיס RT לא תהיה אפשרות להוסיף Plug-Ins.

    וורד 

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

    בנוסף יש מצב Review שנקרא \"Simple Markup\" (במקום ה \"Final: show Markup\") בו במקום לראות את כל תיקוני העריכה והערות בתוך המסמך – רואים פשוט סימון קטן אדום בשוליים לכל פסקה שהיה בה שינוי. לחיצה קטנה על הסימן האדום מחליפה מצבים עבור הפסקה: הצגת כל השינויים או הצגת המצב הסופי (מצב ברירת-מחדל). יכולת זו שימושית למדי לתהליכי Review של מסמכים!

    וורד ו PowerPoint

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

    תוך כדי שאנו גוררים אובייקטים (תיבת טקסט, תמונה כו\') יציעו לנו לעמד אותם לאובייקטים אחרים במסמך, או לשוליים ע\"י הצוות קווים מנחים, מה שנקרא alignment guides. כפי שאתם זוכרים יכולת זו קיימת עוד באופיס 2010 (אולי אפילו 2007?), אבל בגרסה 2013 היא השתפרה מאוד ומזכירה קצת את הרמה של הפיצ\'ר ב Visual Studio כאשר מסדרים פקדים ב WPF או Windows Forms. מאוד אפקטיבי.

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

    Visio

    אני צרכן כבד למדי של Visio בצורך יצירת תרשימי \"Light UML\" ו Marchitecture.
    אני כ\"כ רגיל לעבוד איתו שלפעמם אני משתמש בו, תוך כדי ישיבה, בכדי לסכם את תוכנה בצורת תרשים וטקסט. מכיוון שאני לא משתמש ב Templates המובנים (הם מסורבלים מדי לשימוש. יש לי סט צורות משלי) –  מאז גרסה 2003 לא היה שום שיפור שהיה משמעותי עבורי.

    Visio 2010 (משמאל) מול 2013 (מימין). שימו לב לאיכות הצל והרקע ההדרגתי.

    ממש שמחתי לראות שב Visio 2013, סופסופ, הטמיעו את מנוע הרינדור התלת-מימדי של Office 2007 לתוך Visio. התוצאות –  ניכרות.

    Visio 2013 הוסיפה גם לצורות מרקם Gradient כתכונה טבעית, כך ששינוי הרקע שומר על ה Gradient. יש גם Themes משופרים ועוד כמה צעצועים ל\"עיצוב אוטומטי\" – אבל לא נראה לי שהייתי באמת משתמש בהם.

    במשך השנים נוכחתי שתרשים יפה מסייע לשכנע אנשים לא פחות יותר מתרשים מדוייק או בעל UML-תקני יותר. היכולת \"ליפיף\" את התרשימים באמת הייתה חסרה לי, במיוחד עבור תרשימי \"Markitechture\". עבור השיפורים בתוכנת Visio – אני מחכה לגרסת 2013 בציפיה.

    אאוטלוק

    למרות שאני עובד בחברה גדולה בה יש מערכת סליחה: מספר מערכות עם פרטי העובדים, מערכות אלו לרוב אינן מעודכנות באופן תדיר. בנוסף, לעתים עלי לבצע מספר רב של לחיצות על מנת להגיע לפרטי איש-הקשר אשר בפרטיו אני מעוניין. כשמישהו שאני לא מכיר כותב לי מייל ואני מנסה להבין מי הוא, גיליתי שהדרך הכי קצרה היא לחפש אותו ב LinkedIn בכדי להבין במי מדובר.
    ב Outlook 2013 הוסיפו פי\'צר שנראה מאוד שימושי: חיבוריות לרשתות חברתיות (לינק-אין, פייסבוק ועוד) כך שאקבל בתוך האאוטלוק תקציר על האדם מהרשתיות החברתיות. ניתן גם לראות גם את ה Activities אחרונים ברשתות – דבר שיכול להיות שימושי עבור אנשים שאני בקשר עבודה קרוב איתם (אני כנראה צריך להיות חבר שלהם ברשתות החברתיות על מנת לראות מידע זה).
    לא יכולתי לנסות את הפ\'יצר מול המיילים של העבודה (ביצעתי התקנה בבית) בכדי להבין עד כמה יכולת זו עובדת טוב בפועל – אבל זה משהו שבהחלט היה יכול להיות שימושי עבורי.

    אקסל

    לאקסל יש פיצ\'ר מגניב חדש: אלגוריתם השלמה אוטומטית משופר שמזהה תבניות מתוכחמות יותר.
    בדוגמה למטה: אקסל מזהה שעמודה D (שם מלא) מורכבת מעמודה A (שם משפחה) ו B (שם פרטי). כשערך שני מתאים לתבנית מוקלד לעמודה D – אקסל מציע להחיל את התבנית (בלחיצה על Enter) על כל הערכים בטבלה.

    עד כמה משוכללות התבניות שאקסל מזהה? האם זה כולל גם Formatting משוכלל יותר? – אינני יודע לענות. בכל מקרה פיצ\'ר זה יכול לחסוך עבודת copy-paste מייגעת במקרים מסוימים. נחמד.

    סיכום

    שאלת השאלות: האם שווה לשלם x דולרים עבור עדכון גרסת אופיס? יש לי הרגשה שגרסה 2013, לפחות עבורי, משפרת יותר מגרסאות קודמות.

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

    עדכון (6/6/2013): לאחר ניסיון ממושך יותר באופיס 2013 יש לי שתי תלונות:

    • קביעת SkyDrive כ Default הייתה נוחה לי בזמן נתון, כי אני באמת מנהל את רוב המסמכים שם. כאשר רציתי לעבוד עם דיסק מקומי בעיקר – זה נהיה דיי מטרד. בנוסף: כששומרים מסמך ב SkyDrive אופיס מחכה שהטעינה ל SkyDrive תסתיים. אני מעדיף לשמור מהר ושהסנכרון ייעשה ברקע.
    • משהו ב selections של Visio 2013 דיי מרגיז: הוא לא מאפשר למתוח קו (או רץ) לתוך צורה – רק לתוך ההיקף שלה. לעתים רבות אני יוצר תרשימים \"free style\" ו\"התיקון\" הזה מאוד מפריע. עד כדי לחזור ל Visio 2007.

    פיתוח למובייל: Native או Web? (חלק ב')

    בפוסט הקודם, פיתוח למובייל: Native או Web (חלק א'), סקרנו כוחות המשפיעים על מספר הפלטפורמות עבורן נדרש לפתח אפליקציית מובייל. ריבוי הפלטפורמות הוא גורם מרכזי המעודד פיתוח אפליקציות ווב, אך בשל שיקולי UX והתאמה לחווית המשתמש – נוהגים פעמים רבות לכתוב גם אפליקציות ווב בוריאציות שונות ע"פ גודל המכשיר / מערכת ההפעלה.בחלק זה, אני רוצה להתבונן על האופציות העומדות לרשותנו לפיתוח אפליקציות Multi-Device וה Tradeoff הטכנולוגי בניהן.

    Native או Web: הדילמה

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

    יתרונות עיקריים של פיתוח Native הם:

    • Best User Experience בפיתוח ב Native קל יותר להגיע לשימושיות גבוהה. הרבה יותר קל להשיג אנימציה חלקה ותגובה מהירה, ולעתים יש דברים שפשוט לא עובדים בווב. מכיוון ששימושיות גבוהה היא ערך חשוב באפליקציות מובייל – זהו יתרון חשוב.חברות המושקעות בפיתוח לווב, מנסות להוכיח ש HTML5 "יכול הכל". סיפור משעשע הוא הסיפור של FastBook בו הציגה חברת Sencha אפליקציית מובייל עדיפה על אפליקציית הנייטיב של פייסבוק (לטענתם), על רקע טענות של צוקרברג על כך ש HTML5 עדיין אינה מספיק טובה.
      Sencha גם עורכת תחרות בשם HTML5isReady ברוח דומה.

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

    • Full Access to OS APIs אמנם ניתן לגשת כיום בחלק מהמכשירים ל GPS או אפילו למצלמה מקוד JavaScript של אפליקציית ווב, אך עדיין יש סט גדול של יכולות הזמינות רק מקוד native על המכשיר: גישה לאנשי הקשר, חיבור לרשתות חברתיות עם פרטי בעל המכשיר, ניהול קבצים ועוד.
    • App Store Distribution. הדרך הסטנדרטית לחפש אפליקציה למובייל היא כמובן דרך ה App Store של המכשיר – הזמינה רק לאפליקציית נייטיב. עבור חברה קטנה שמוכרת אפליקציות – גישה ל App Store היא הכרחית על מנת להפיץ את האפליקציה. עוד בנושא ניתן לקרוא בלינק לפוסט על חנויות אפליקציה.

    לפיתוח אפליקציות Web יש כמה יתרונות חשובים משלהן:

    • Easiest Multi-Platform Development קלות בפיתוח למספר מכשירים. שימו לב שאני אומר קלות ולא "פיתוח יחיד". זאת בשל קושי לבצע Full User Experience Reuse ובשל שכיחות הבאגים בדפדפנים מוביילים (בולט במיוחד: Android Browser על גרסאות אנדרואיד 2.3 ומטה).
    • Full control on updates באפליקציות נייטיב אינני יכול לשלוט מתי/האם משתמשים מעדכנים את גרסת האפליקציה – כך שה Backend שלי צריך לתמוך בגרסאות שונות. אם יש לי עדכון קריטי (אולי עדכון אבטחה?) – בווב אשחרר אותו לכל המשתמשים מיידית. בנייטיב: תהליך האישור של חנות האפליקציות יכול לעכב אותי בכשבוע או יותר בשחרור השינוי הקטן ביותר. תכונה זו חשובה יותר לארגונים.
    • Interoperability & Extendibility נקודה זו היא חסרת חשיבות כמעט ל Consumer אך חשובה מאוד ל Enterprises ועושה לעתים רבות את ההבדל: מכיוון שאפליקציות נייטיב רצות ב Sandbox – אין מודל קיים של Plug-in שארגון יכול להשתמש בו על מנת לבצע התאמות של אפליקציית נייטיב לצרכיו הספציפיים. מאידך גיסא הרחבות בווב (ב JavaScript) הן קלות מתמיד – ויש הרבה ידע ותשתיות קיימות. אלמנט נוסף שחשוב למחלקות ה IT הוא Branding: היכולת לצבוע את האפליקציה בצבעים והלוגו של החברה (כדי שיהיה ברור מעורבותה של מחלקת ה IT). לקוחות רבים דחו אפליקציות בגלל יכולת זו בלבד, סיבה שנראית כחסרת-חשיבות למי שלא מבין את הפוליטיקה הפנימית של ארגוני IT בארגונים גדולים.

    פתרון הביניים: Hybrid

    הפלא ופלא, אנשים יצירתיים חשבו על פתרון לשלב בין גישות ה Web וה Native במכשירי המובייל. בכלי הפתוח למערכות ההפעלה השונות ישנו פקד (פקד = control. ממש כמו כפתור או רשימה) שנקרא WebView ומהותו הוא הצגת תוכן וובי בתוך אפליקציית native.

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

    • בתור התחלה: ניתן להפיץ את האפליקציה ב App Store, מכיוון שמעתה זו אפליקציית נייטיב לכל דבר.
    • ניתן לשמור את קבצי ה HTML מקומית מבלי "לחלוק" Cache עם אפליקציות אחרות ולהבטיח טעינה מהירה יותר של האפליקציה.
    • ניתן, ופה אולי היתרון יוצא-הדופן, לחשוף פונקציות של האפליקציה הנייטיב כ javaScript API כך שאפליקציית הווב תוכל להשתמש בהן – וכל להעשיר את אפליקציית הווב ביכולות ״נייטיב״. לדוגמה: חישובים שדורשים יעילות גבוהה (כמו פענוח הצפנה), גישה ל OS API כגון שליפת אנשי הקשר, הפעלת רטט, או גישה לתמונות שצולמו לאחרונה בעזרת המכשיר.

    ישנם פתרונות סטנדרטיים, לדוגמה PhoneGap או MoSync, של Containers מוכנים-מראש לאפליקציות ווב הנקראים Hybrid Container או Hybrid Web Container. ע"י שימוש בפתרונות אלו, אתם יכולים להתמקד בפיתוח אפליקציות ווב (עם התכונות הנלוות של הווב) ורק "לארוז אותן" כאפליקציית נייטיב. PhoneGap מספקת Containers מותאמים למספר רב של מערכות הפעלה מוביליות, וחושפת JavaScript API אחיד ממערכות ההפעלה כך שתוכלו לכתוב אפליקציית ווב פעם אחת, ולגשת לשירותים של מערכת ההפעלה השונות מבלי להיות מודעים למערכת ההפעלה שמריצה את ה Container.

    רשימת הנייטיב API ש PhoneGap חושפת עבור אפליקציות ווב, על פלטפורמות שונות. מקור: וויקיפדיה. (לחצו על התמונה להגדלה).

    בואו נשווה את תכונות ההייבריד לאלו של אפליקציות נייטיב או ווב:

    פיתוח בעזרת Framework הכולל Hybrid Container מספק יתרונות משני העולמות, הווב והנייטיב:

    • גישה מלאה ל API של מערכת ההפעלה. אם זה לא API שמסופק Out of the Box ע"פ ה Framework, אני יכול להוסיף wrapper של קוד נייטיב החושף javaScript API בעצמי.
    • הפצה של האפליקציה ב App Store.
    • קלות בפיתוח Cross Platform (באופן חלקי: ייתכן ועלי לתחזק wrappers משלי)
    • שליטה מלאה על עדכונים (חלקי: עבור חלק הקוד הוובי באפליקציה. עבור שינויים בקוד הנייטיב עלי לעדכן גרסה של ה container / native app).
    • Interoperability / Extendibility (חלקי: רק עבור חלקי הקוד הוובי).
    • ה User Experience יהיה עדיין נתון רובו ככולו ליכולות הווב, קרי HTML5/CSS3.

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

    • את ההבדל מעל מערכות הפעלה שונות קשה להחביא, ו"ה javaScript API האחיד" מעל מערכות ההפעלה השונות לא מתנהג כ"כ יפה.
    • ישנו פער זמנים בין הזמן בו משתחררת גרסת מערכת הפעלה (למשל iOS 6) לזמן בו משתחררת גרסת ה Container שתומכת בה. מדובר בחודשים. במקרי הקצה, פונקציונליות יכולה להישבר (תמיכה לאחור איננה הצד החזק של אפל, למשל) ולדרוש מכם לכתוב wrappers משלכם, ללא תלות ב Frameworks.
    • ה Hybrid Frameworks מוסיפים Layer נוסף של תלות גם ברמת הבאגים והבעיות השונות. שוב סיבה לעקוף את ה Framework בכדי ליצור workarounds. איתור תקלה (האם היא באפליקציה שלכם, ב Hybrid Container או במערכת ההפעלה?) הופכת למשימה קצת יותר מורכבת. באג רציני דורש הבנה ב Internals של מערכת ההפעלה – כך שהניתוק ממערכת ההפעלה אינו מוחלט.
    • עליכם להקים ולתחזק סביבת Build לכל הפלטפורמות שאתן רוצים לתמוך בהן, משימה שאיננה פשוטה למפתח הבודד. את ה custom native code שאתם מפתחים עליכם לתחזק לכל פלטפורמה (ואולי אף גרסאות שונות של מערכת ההפעלה) – כך שיש אלמנט של קוד כפול.

    אינני רוצה ליצור את התחושה ש Hybrid Framework הוא פתרון לא-מוצלח. לפתרון Hybrid יש הרבה ערך ופוטנציאל והם יכולים להיות בסיס לפתרונות מצויינים – בעיקר כשמבינים את ה Tradeoffs שבאים איתם. הדבר העקרי לו כדאי להיות מודעים הוא פער גדול בין ציפיות גבוהות למדי ומציאות שאיננה כולה דבש. אחוז לא מבוטל של מפתחים מתחיל לעבוד עם Hybrid Container בציפייה ל Silver Bullet רק כדי לגלות שיש גם מורכבויות – ואז נוטש אותו.

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

    Native Transformers

    קטגוריה נוספת ואחרונה של כלי פיתוח מובייל עבור Multi-Device נקראת Native Transformers. נניח שהחלטתם ששימושיות וגישה למערכת ההפעלה חשובה מספיק עבורכם, והתחלתם לפתח נייטיב 6 גרסאות של האפליקציה עבור 3 מערכות הפעלה שונות (+ טאבלט / סמארטפון).

    עבור iOS עליכם לפתח בשפת Objective-C ב XCode על גבי מחשב מק.
    עבור Android אתם מפתחים בג'אווה על איזו סביבה שמתחשק לכם, וב Eclipse.
    עבור Windows Phone / 8 אתם מפתחים בשפת #C על גבי VS2012 שרץ רק על גבי Windows 8.

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

    כתבו הרבה קוד משותף, ומעט קוד ספציפי – ההבטחה של ה Native Transformers.
    Native Transformers מבטיחים לעזור בנושא זה. הם מציעים לכם לכתוב פעם אחת את הקוד שיכול להיות משותף, בשפת ביניים (לרוב javaScript או וריאציות שלה), בעוד ה Native Transformer יקמפל קוד זה לקוד נייטב עבור מערכות ההפעלה השונות, וייצור לכם שלד של פרויקט בסביבה המתאימה ממנו תוכלו להמשיך. יתרה מכך, חלק מהפתרונות בנויים כך שתוכלו לבצע שינויים בקוד המשותף ולהעביר את התוצר לסביבות הפיתוח הספציפית (לדוגמה: iOS, Windows 8) מבלי למחוק / לפגוע בפיתוחים הספציפיים שכבר עשיתם. מבנה שדומה להורשה בו רק מחלקת האב משתנה ברגע שמקמפלים את הקוד המשותף.

    מכיוון שמספר גדול של Native Transformers מתבסס על javaScript כשפת ביניים, לא נדיר למצוא פתרונות שיכולים גם "לקפמל" גרסאות HTML5, כלומר ווב.
    תכונה נוספת מקובלת היא Designer מסוג WYSIWYG בו אתם יכולים להרכיב בשפת הביניים את ה UI הכללי ולקבל שלד מוכן של UI בפקדים של מערכת ההפעלה הספציפית.

    בואו נשווה את ה Native Transformers לפתרונות שקרובים אליו ביותר, הרי הם פיתוח נייטיב על הרבה פלטפורמות מצד אחד, ופתרונות ה Hybrid מהצד השני:

    ישנו מספר רב למדי (אני שמעתי על כ 10 ויותר) של Native Transformers, בעיקר בעולם ה Enterprise. השלושה הנפוצים ביותר הם כנראה:

    • Appcellerator Titanium – הפלטפורמה המוכרת ביותר בקטגוריה זו.
    • Adobe Air – בעיקר עבור תוכנות גרפיות / משחקים. מספר לא מבוטל של משחקים שאתם משחקים בסאמרטפון שלכם ונראים נייטיב לחלוטין נכתבו בעצם ב Air.
    • Antenna – שחקן מרכזי בשוק האנטרפרייז.

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

    ל Native Transformers יש כמה חסרונות:

    • בדומה לפתרונות Hybrid – יש כאן תלות בשחקן צד שלישי, בקצב העדכונים שלו, האיכות שלו, היציבות הפיננסית שלו וכו'. התלות בספק ה Native Transformers גדולה משמעותית מהתלות בספק ה Hybrid Container, אותו קל יחסית "לעקוף".
    • שפת הביניים, הספריות שלה ובעיקר כלי העיצוב הגרפי הם סביבה חדשה (ולא כ"כ סטנדרטית) שיש ללמוד – מה שהופך את ה Learning curver לגבוה, למרות ש Native Containers ממוצבים ככלי Productivity לפיתוח מהיר על מספר פלטפורמות. בכל מקרה עליכם לדעת לפתח נייטיב בכל הפלטפורמות ולהכיר מספיק טוב את מערכות ההפעלה – הרי ה Native Transformers יוצרים בסה"כ שלד דיי גס של אפליקציה שיש עוד לעבוד עליו.
    • גודל ה binaries של האפליקציה גדל בצורה משמעותית. פי 10 הוא לא מספר חריג במיוחד. זה לא נשמע מעניין כ"כ בימנו, שהרשתות מאוד מהירות, אולם מערכות הפעלה מוביליות לא מרשות (משיקולי שמירה על סוללה) להוריד ב 3G אפליקציות מעל גודל מסוים (בימנו הגבול הוא 20-50MB, תלוי במערכת / גרסה). כלומר: ייתכן והאפליקציה שתיווצר, גם אם היא נראית פשוטה – לא תוכל להיות מותקנת ללא חיבור WiFi.
    • פתרונות אלו הם לרוב מסחריים, ובעלי רישיונות יקרים מהממוצע.

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

    הרבה אופציות. כיצד בוחרים?

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

    לו הדילמה הייתה פשוטה, קרוב לוודאי שהפוסט לא היה מתארך כ"כ J.
    סה"כ הקו המנחה הוא כזה: ארבעת הקטגוריות נמצאות על סקאלה: בצד אחד פתרונות ה Web (הכי זול לפתח Cross-Device, אבל חווית המשתמש הכי פחות אינטגרטיבית) ובצד השני האופציה לפתח נייטיב בנפרד על כל פלטפורמה.
     
    עליכם לבחון את המוצר שלכם ולראות היכן הוא הכי מתאים. מה יותר חשוב לכם: עלות-פיתוח נמוכה או חווית שימוש עליונה?
    אם אתם סטארט-אפ קטן, עובדים Lean או רק מתחילים – כנראה שעדיף לכם ללכת בגישה של Web-First (אולי רק עם Container לצורך הפצה – אם מדובר באפליקציה לצרכן הפרטי).
    אם אתם עסק שמגלגל מיליונים, והאפליקציה היא ה Main business שלכם (למשל פייסבוק) – שווה לפתח נייטיב. לחברה גדולה שזה הביזנס שלה אין מה לנסות ולחסוך צוות או שניים של מפתחים.
     
    שיקול נוסף הוא הארגון מול הצרכן הפרטי: למרות תהליכי ה Consumerization בארגון המדוברים כל-כך היום, הצרכן הארגוני הוא עדיין סלחן יותר לחווית המשתמש: יש לו הרבה מוטיבציה לעשות את העבודה. בנוסף, לשיקולי אבטחה (עדכונים מהירים) ויכולת ההתאמה האישית לארגון – יש משקל רב אצל הלקוח הארגוני.
    לא מזמן נכתבו אצלנו מספר אפליקציות נייטיב מ Scratch בטכנולוגיות ווב, מכיוון שלקוחות לא הסכימו לרכוש אותן ללא יכולות customization שאינן אפשריות בנייטיב. הכוונה הייתה להשקיע בלקוחות ולייצר חווית שימוש נהדרת ומרשימה – אבל הם הבהירו מה סדרי העדיפויות שלהם.

    לסיכום

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

    שיהיה בהצלחה!

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

    —-

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

    פיתוח למובייל: Native או Web? (חלק א')

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

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

    יש לנו כאן דילמה מהותית וכמעט חדשה:
    עבור אפליקצייה שולחנית הבחירה בין אפליקצייה native לאפליקציית ווב היא ברורה וקלה יותר: הצידוק לאפליציית native הוא בעיקר צורכי גרפיקה / זמן אמת (משחקים / תוכנות גרפיות / כלי productivity) או כלים ספציפיים למערכת ההפעלה (למשל אנטי-וירוס). כל השאר – הלך לווב. מכיוון שמערכת ההפעלה "חלונות" הייתה מונופול בצד ה Client – הפיתוח נעשה בכלים מתאימים (Windows Forms/WPF) עם נישה קטנה של UI בג'אווה (או שפות VM אחרות) – בעיקר לכלי אדמיניסטרציה.

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

    אנו נראה שהדילמה בפיתוח למובייל דומה – אך שונה ומורכבת יותר.

    באיזה מכשירים לתמוך? הרבה מכשירים, הרבה יצרנים.

    BYOD

    לפני שנה שוחחנו עם לקוח גדול שבחר להשתמש במערכת שלנו.
    "באיזה מכשירים אתם מתכוונים להשתמש?" – שאלנו. "משיקולי אבטחה, תהיה לנו מדיניות נוקשה של iOS[ב] בלבד! לא נרשה חיבור מכשירים אחרים למערכת".
    "כמה נוח", חשבנו לעצמנו, "הנה לקוח שסגור על עצמו".
    לאחר כשישה חודשים התקשר אותו הלקוח וחקר על תמיכה באנדרואיד.
    "חשבנו שאתם עובדים רק עם iOS…", תהינו בקול. "נכון", הוא ענה, "אבל… להרבה מאוד עובדים יש מכשירים שלהם שהם הביאו מהבית, רובם מכשירי אנדרואיד, והם לוחצים שנחבר אותם למערכת. אלו עובדים שלא קיבלו מאתנו מכשירים באופן רשמי, אבל עדיין רוצים להתחבר למערכת לצורכי עבודה. קשה לסרב לזה".תופעה נפוצה מאוד בארגונים היום היא תהליך שנקרא Bring Your Own Device (או בקיצור BYOD) – בה לעובדים יש מכשירים בעלי יכולות שהם רכשו והם רוצים להשתמש בהם לצורך העבודה.

    נכון לשנת 2013, BYOD הוא מיינסטרים

    מ BYOD נהנים שני הצדדים: הארגון מפחית עלויות (מכשירים, הכשרה, חידוש מכשירים) בעוד העובדים יכולים לעשות יותר עבודה ובדרך שהם בוחרים. ניתן למצוא כיום גם מדיניות של Buy Your Own Device – בה הארגון מספק לעובדים תקציב בכדי שיקנו לעצמם מכשיר בעצמם וע"פ בחירתם (תחת מגבלות מסוימות) – סימן לחשיבות שיש לבחירת המכשיר ע"י העובד.

    למורת-רוחם של גופי IT רבים, מדיניות BYOD היא לרוב איננה יוזמה של גוף ה IT אלא תגובה ללחץ ו"קביעת עובדות" מצד היחידות העסקיות (Line Of Business) בשטח.

    המשמעות המעשית של BYOD היא הצורך לתמוך במגוון רחב של מכשירים, ללא יכולת של גוף ה IT להכתיב או לבחור את המכשירים, כפי שיכול היה במשך שנים להכתיב את חומרת ה PC או את הדפדפנים שבשימוש[ג]. דיי נדיר היה לראות עובד מחסן שמביא PC מהבית לעבודה ודורש לחבר אותו למערכות הארגוניות.

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

    רוב מפתחי האפליקציות מתכננים לתמוך ב2 פלטפורמות או יותר

    דיי ברור שפיתוח Native (ל iOS, אנדרואיד, בלאקברי, Windows 8, וכו') מספק את מירב האפשרויות לפיתוח האפליקציה – ביצועים טובים יותר ויכולת לגשת ליכולות ספציפיות של המכשיר וכו' – ממש כפי שאפליציית Windows Native יכולה לעשות יותר מאפליקציית ווב הרצה על חלונות. בניגוד למחשב השולחני, אם נכתוב אפליקציה native למובייל בטכנולוגיה מסוימת – נגיע לפחות מ50% מהמשתמשים. כדי להגיע לאחוז דומה של משתמשי "חלונות" (כ 90%), עלינו לפתח עבור 3 מערכות הפעלה שונות ובסביבות פיתוח שונות, מה שמכעט משלש את כמות ההשקעה – מכיוון שאלו מערכות הפעלה שונות.

    לא דיברנו עדיין על עוד 2 מכפילים נוספים המשפיעים על "מספר הפלטפורמות בפועל":

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

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

    • סמארטפון: iPhone (ו iPod Touch)
    • סמארטפון: Anroid של סאמסונג (סדרות Note, Ace, Galaxy וכו')
    • טאבלט: iPad
    • סמארטפון: Windows Phone
    • טאבלט: Windows 8 (הערה: Windows 8 ו Windows Phone הן מערכות הפעלה דומות, אך שונות).
    • טאבלט: Amazon Kindle Fire (נפוץ בקרב משתמשים פרטיים).
    • ? טאבלט אנדרואיד* – אולי Galaxy או Nexus
    • ? סמארטפונים של יצרן אנדרואיד* נוסף. HTC, ZTE או מוטורולה הן המועמדות המובילות.
    • ? מכשירים של מערכת הפעלה רביעית. מתמודדות עיקריות: Tizen אולי BlackBerry 10 או FireFox OS.
    • ? מסכים (כבר לא נכון לקרוא להם "טלויזיות" או "טלויזיות חכמות") המריצים מערכות הפעלה מוביליות לינק1 לינק2.
    * בעולם האנדרואיד, יש משמעות מיוחדת ליצרנים השונים. אשתדל לכסות עניין זה בפוסט המשך.
    תחזית לפילוח מערכות ההפעלה המוביליות בשנים הקרובות

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

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

    UX Reusability

    עוד אלמנט שמשפיע על השיקול בין Native ל Web הוא הקושי לבצע UX Reusability בעולם המובייל. בגלל מוגבלות מכשירי המובייל (מסך קטן, מקלדת לא-נוחה), האינטגרציה בחווית השימוש בין מערכת ההפעלה לאפליקציות היא גבוהה ממה שנהוג ב Desktop.

    לדוגמה: ה UX Guidelines של חלונות 8 אוסרות על אפליקציה להוסיף אלמנט חיפוש בשטח האפליקציה. החיפוש נעשה מתוך SideBar של מערכת ההפעלה (נקרא "Charm") גם כאשר מדובר בחיפוש בתוך-האפליקציה. למכשירי ה Windows Phone יש כפתור חיפוש פיסי בתחתית המכשיר.

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

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

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

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

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

    הנה דוגמה לאפליקציית הווב של Financial Times, והדרך בה היא מציגה חיפוש על טאבלטים במערכות הפעלה שונות. בסקאלה שבין "UI כמו של מערכת ההפעלה" עד ל "UI עצמאי", FT בחרו גישת ביניים של "אזרחות טובה". האפליקציה בסה"כ נראית אותו הדבר על כל הפלטפורמות, מלבד אלמנטים שסותרים בצורה משמעותית את ה UX Guidelines של הפלטפורמות השונות[ד].

    —

    [א] Phablet – יציר הכלאיים בין טאבלט לאייפון. לרוב בעל מסכי "5 עד "7, שניתן לבצע מהם שיחות. דוגמה בולטת: סדרת ה Galaxy Note של סמסונג.

    [ב] מערכת ההפעלה של מכשירי אפל: iPad, iPhone ו iPod Touch.

    [ג] בארגונים רבים, IE הוא הדפדפן היחידי שנתמך לשימושים ארגוניים. Chrome יכול לשמש רק לגלישה אישית באינטרנט או שלעתים אף מונעים / אוסרים התקנה של כל דפדפן מלבד זה שהוחלט ע"י ה IT (שזה לרוב IE).

    [ד] כדאי להכיר:

    עשה זאת בעצמך: NoSQL

    מעוניינים לשדרג משהו? לעתים זול יותר ופשוט יותר לבצע שיפוץ קטן בעצמכם, במקום להשתמש בבעל מקצוע. ייתכן והתוצאה תהיה מוצלחת לא-פחות.
    בפוסט זה אני רוצה לשתף במימוש מוצלח של "טכניקת NoSQL BIG DATA" שביצענו על גבי מערכת קיימת, מבלי לשנות אותה באופן מהותי ומבלי להחליף את בסיס הנתונים הרלציוני הקיים.המסר המעניין מבחינתי, הוא שניתן ליישם ״בקטנה״ רעיונות של בסיסי הנתונים NoSql בעצמכם – ולהשיג תוצאות יפות.

    הבעיה

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

    בדיקות שעשינו למערכת הראו שבסביבות 30-אלף פרויקטים, המערכת מתחילה להראות סימנים של שבירת הלינאריות ב scalability. כלומר: עד נקודה זו – אם רצו לנהל עוד פרויקטים היה ניתן להוסיף עוד חומרה ביחס ישר לגדילה בכמות הפרויקטים / הפעילות. מעבר לנקודה זו היה צריך להוסיף x וקצת חומרה ל x פעילות נוספת, וככל שהמספר גדל – העלות השולית הלכה וגדלה.
    הבנו שהמערכת תוכל לטפל במשהו כמו 50 אלף עד 100 אלף פרויקטים, תלוי בכמות החומרה שהלקוח יסכים להקצות. באופן מעשי זהו בערך גבול ה Scalability שלנו ולכן ההמלצה ללקוחות הייתה לא ליצור מעל 50 אלף פרויקטים.חשוב להבהיר שמדובר במערכת בת כ3 שנים – שעברה לאורך חייה לא מעט שיפורי performance ו scalability. בשלבים הראשונים של המערכת הצלחנו לבצע שיפור יחיד שהגדיל את ה Scalability ב 30% – אך ככל שהזמן עבר שיפרנו אלמנטים פחות משמעותיים (כיוון שהמשמעותיים כבר שופרו) והבנו שאנו מגיעים לקצה ה Scalability של הארכיטקטורה הקיימת.

    פתרון אפשרי אחד היה לנסות לעבור לבסיס נתונים NoSQL, נוסח MongoDB או CouchDB – המתאימים יותר לשימוש הספציפי של המערכת, והיו יכולים בהחלט לשפר את המצב. הבעיה: שאר האלמנטים במערכת (מלבד הפרויקטים) התנהלו בצורה משביעת-רצון בבסיס הנתונים הרלציוני. מה עושים? עושים הסבה לכל הקוד לעבוד מול בסיס נתונים NoSql או דורשים מלקוחות לנהל 2 בסיסי-נתונים שונים במקביל?!

    התוצאות

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

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

    מקור הבעיה

    ישנן סיבות שונות המצדיקות מעהר לNoSql Databases:

    • הרצון בסכמה גמישה, שלא דורשת migration בין גרסאות.
    • כמות נתונים (ב TB) שדורשת מעבר משרת אחת לכמה שרתים – מה שנקרא Scale Out.
    • בעיית Scalability מקומית. כלומר: מעל כמות נתונים מסוימת, זמן התגובה למשתמש הקצה הופך ללא-סביר.
      זו הבעיה איתה התמודדנו במערכת שלנו.

    איך נוצרת בעיית Scalability?
    בואו נביט על (הפשטה של) סכמת הנתונים של מערכת הפרויקטים:

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

    אני רוצה להתמקד לרגע באובייקט קצת פחות טריוויאלי במודל הנתונים: Comment Attribute.
    תכונה-של-תגובה (Comment Attribute) יכולה להיות דבר כמו: תאריך, שם המגיב, קישור לתמונה וכו'

    בבסיס נתונים רלציוני ניתן לשמור תכונות כאלו ב-2 אופנים:

    • סכמה קשיחה: כעמודה (column) בטבלה. על כל תכונה אפשרית יוצרים עמודה חדשה.
      יתרונות: פשטות
      חסרונות: יש תכונות (כגון "deleted by admin") שמתרחשות לעתים נדירות – אך עדיין יש לשמור עבורן מקום בכל רשומה, הוספת שורה = הוספת סכמה.
    • סכמה גמישה: כטבלה נוספת, בתצורת master-detail, בה כל מפתח וערך של תכונה היא שורה נוספת.
      יתרונות: גמישות רבה ללא שינויי סכמה
      חסרונות: עוד טבלה לנהל, עוד קצת סיבוך.

    המערכת הנ"ל השתמשה בסכמה גמישה.

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

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

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

    חזרה לתיאוריה

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

    הנה טבלה חשובה למדי:

    מקור: גוגל

    שתי נקודות שהייתי רוצה להדגיש:

    • קריאה מדיסק היא הפעולה היקרה ביותר ברשימה (נו, טוב – מלבד WAN בין-יבשתי), והיא יקרה משמעותית מפעולות מבוססות זיכרון (פי 100 עד פי 100-אלף, תלוי בתסריט).
      אם אנו מתבוננים על שכבת ה Persistence כקופסה שחורה, אזי כדאי לנו מאוד להפחית קריאות לדיסק, גם על חשבון הרבה פעולות בזיכרון. כלומר: להבין מתי בסיס הנתונים או שכבת ה ORM גורמות לקריאות לדיסק להתרחש – ולגרום לקריאות אלו לפחות ככל האפשר.
    • בניגוד לזיכרון, בו יש פער גדול בין גישה כלשהי (100ns) לקריאת 1MB של נתונים (250K ns, פי 2500), בקריאה מדיסק הפער הוא רק פי – 2. כלומר: להביא 1MB של נתונים רציפים לוקח כמו הבאה של 2 חתיכות של 4k.
      הסיבה לפער זה הוא שזמן גישה (seek time) בדיסק כוללת תנועה של זרועה מכנית וסיבוב הדיסק לנקודה הנכונה, משם קריאה רציפה היא כבר "לא סיפור".
      הערה: מגבלה זו השתפרה מאוד עם הצגת כונני ה SSD המודרניים. ניתן לקרוא עוד בנושא בפוסט מבט מפוכח על מהפכת ה SSD. עדיין, קריאה מדיסק ובמיוחד קריאה בלתי-רציפה, היא יקרה למדי. בפוסט הנ"ל ניתן לראות כונן SSD שקורא 180MB בשנייה באופן רציף, אך רק 18MB בשנייה כאשר המידע מפוזר. יחס קצב העברת-נתונים של פי 10-15 בין קריאה רציפה לקריאה אקראית הוא מאפיין שכיח בכונני SSD מודרניים. יחס זה הוא בערך פי 100-200 בכוננים קלאסיים – כך שמדובר בשיפור גדול.
    כיצד נגרום לבסיס הנתונים לבצע משמעותית פחות קריאות לדיסק, מבלי לגעת בקוד של ה ORM או של בסיס הנתונים? כיצד נוכל לעשות זאת מבלי לשנות דרמטית את כל המערכת שלנו? התשובה בפסקה הבאה.

    Aggregate-Based Data Storage

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

    כשטוענים פרויקט:

    • נטענת רשומה מטבלת הפרויקטים
    • נטענת רשומה אחת מטבלת ה Topic (נושא אחד נפתח ב default)
    • נטענות כל רשומות הדיון מאותו ה topic (כדי להציג רשימת שמות) וכל הרשומות מהדיון הראשון, כולל כל ה comments וה attributes שלהם.

    זה המידע שנדרש על מנת לספק את חווית השימוש הרצויה.

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

    • לפחות קריאה אחת עבור כל טבלה.
    • בעצם, יש אינדקסים שבהם ייתכן ויש להיעזר – כך שבפועל ייתכנו מספר קריאות לכל טבלה.
    • המידע מגיע מהדיסק בבלוקים של 4k או 16k. אם הרשומות בטבלה אינן "קרובות דיין" על מנת להיכנס לבלוק של 16k נתונים – ניאלץ "לדלג" (seek) שוב בתוך הטבלה.
      רשומות מסוג ה Comment יכולות להיכתב בהפרש זמנים ניכר אחת מהשנייה, שכן תגובות יכולות להגיע לאחר שבוע או חודש.
      רשומות מסוג ה Comment Attribute יכולות להיכתב בהפרש (כלומר, פיזור) נוסף, מאחר והן נוספות "רק ע"פ הצורך". לדוגמה: תכונת ה likesCount תיווצר רק בעת שנעשה ה Like הראשון ולא עם יצירת ה comment.
    אין לי חישוב של מספר הפעולות בדיסק, אך יש לי בסיס להאמין שהוא יכול להסתיים בעשרות קריאות מהדיסק לכל discussion. השימוש ב ORM יכול להסתיר את העובדה שיצירת אובייקט "discussion" בזיכרון, רק בכדי לקחת את ה title ו lastUpdateDate – יכולה לגרום ליצירת אובייקטי ה comment והקריאה גם שלהן מהדיסק.
    נקודה מעניינת, שמעצימה את הבעיה, היא שבמערכת עם הרבה מאוד פרויקטים ודיונים, הכמות הגבוהה של ה comments שמתווספים למערכת בשעה, יכולה לגרום לכך ש 2 תגובות במרחק של 5 דקות אחת מהשנייה – לא יהיו במרחק 16k בדיסק (מכיוון שנכתבו מאז הרבה comments אחרים ב discussions אחרים).
    המצב הזה, בו המידע בדיסק מאורגן בניתוק מאופו השימוש בנתונים (קרי – ארצה לראות את כל ה comments מאותו דיון ביחד – ולא את כל ה comments שנכתבו בדקה מסוימת), הוא שורש הבעיה.

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

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

    במקרים כאלו יש ייתרון ברור לאיגוד הנתונים ע"פ נקודת הייחוס המתאימה לשימוש הנפוץ במערכת, מה שנקרא document-based database או aggregate-database.

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

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

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

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

    • יש לממש לבד לוגיקה של קריאה / כתיבה של אובייקטים לתוך ה BLOB (מה שציינו למעלה).
    • אנו מאבדים את היכולת לעשות שאילתת SELECT על כל האובייקטים במערכת. למשל, למצוא את כל ה Comments שנכתבו בין 2 ל 4 בבוקר.
      אם אנו רוצים לבצע שאילתה שכזו – יהיה עלינו לקרוא את כל ה Topics מהדיסק, אחד אחרי השני, ולסרוק בעצמנו את המידע בתוך ה BLOB.
      אם אנו רוצים מהירות בסריקה (ויש לנו use-case ספציפי) אנו יכולים להשתמש במנועי indexing כגון Lucne.
    • השימוש בסכמה של "טקסט חופשי", כגון פורמט JSON, מאפשרת לנו לבצע שינויים לסכמת הנתונים בין הגרסאות של המוצר מבלי לבצע שינויים לסכמת בסיס הנתונים.
    • השימוש בסכמה של "טקסט חופשי" מאפשרת לנו לשלם על שדות "נדירים" רק כאשר משתמשים בהם (לדוגמה: isDeletedByAdmin) ועדיין להינות מביצועים נהדרים.

    עדכון ספטמבר 2015:
    הנה שני סיפורים דומים של חברות שבחרו ב"התאמה אישית" של בסיס נתונים רלציוני על פני מעבר ל NoSQL DB:

    סיכום

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

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

    שיהיה בהצלחה!

    אם אתם מעוניינים ללמוד קצת יותר על BIG DATA, אתם מוזמנים לקרוא את הפוסט מה הביג-דיל ב BIG DATA?