קטגוריה: תקשורת

מתכנת IT

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

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

עכשיו אשאל אתכם שאלה: האם איש DBA שייך לקבוצה הזו? התשובה היא כן. האם הוא איש DevOps? התשובה היא לא.

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

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

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

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

להמשיך לקרוא

מימוש RDP טבעי בשפת רובי

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

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

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

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

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

כתובת הפרויקט: https://github.com/Safe-T/rdp-rb

סיכום שנה – 2015

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

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

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

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

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

פרויקט של גוף ממשלתי שהשורשים שלו נטעו בסוף 2012, הגיע למצב של פיילוט ב2015, שעכשיו ב2016 כנראה שיכנס להיות בכל הארץ אצל אותו גוף ממשלתי.

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

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

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

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

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

הכירו את SCTP

זהירות, פוסט ארוך

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

עד עכשיו היה שימוש רק ב E1, אז החיבור הוא קווי באמצעות קו רגיל של ISDN, אבל יש לזה מגבלה של 30 ערוצי תקשורת פר חיבור (אם אין דחיסה).
אנחנו כמובן מעוניינים לספק כמה שיותר תעבורה, אז התחלנו לברר על משהו הנקרא SIGTRAN אשר הוא בעצם SS7 על גבי IP, אך הוא אינו משתמש ב TCP או UDP בשביל זה, אלא על גבי פרוטוקול (יחסית חדש) בשם  SCTP.

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

מהו SCTP?

הקדמה

ישנם שני פרוטוקולים מעל רמת IP אשר מאוד מוכרים בעולם – TCP ו UDP.

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

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

אז מה הוא SCTP או Stream Control Transmission Protocol בשמו המלא?

הסבר הרעיון (TL;DR)

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

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

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

כלומר יש לנו כאן סוג של פרוטוקול multiplexing .

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

מוכר לכם ממשהו? למשל מגישה בשם HTTP/2?
אבל כאן זה פרוטוקול ברמה נמוכה יותר, ולא מימוש בשכבה 7.

אבל העניין הוא שזה ממש לא הכל. יש לפרוטוקול תמיכה בmultihoming – כלומר האפשרות להתחבר למספר שרתים במקביל, וכך להבטיח שרידות בקבלה ושליחה של המידע.
הפרוטוקול אפילו מאפשר תמיכה במציאות הנתיב עם האיכות הכי טובה שהגדרנו, כמו ש MPLS, DiffServ וכיוב' מספקים.
עוד פיטצ'ר נחמד, הוא תמיכה ב jumbo frames, אשר מאפשרים לשלוח עם MTU גדול יותר מ1500 בתים.

אז כיצד זה בעצם עובד?

להמשיך לקרוא

אנדרואיד, mms ובעיית אבטחה עם פתרון ישים

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

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

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

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

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

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

כיצד עובד ה MMS? אני שולח הודעת SMS במבנה מסוים שאומר כי יש לי משהו כדוגמת תמונה בשרת שניתן להוריד באמצעות WAP.

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

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

ניסויים בתורי הודעות

יש מערכת שאחרי load test הבנתי כי אני חייב לבזר את המערכות שבה. אז התחלתי לבצע מחקר על סוגים שונים של message queue בשביל לבזר את המערכת. עשיתי ניסויים עם המון מערכות שונות, כולל התייעצות עם אנשים שממשים כבר מערכות המשתמשות בהם, והגעתי להבנה כי כנראה ש RabbitMQ מתאים לצרכים שלי.

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

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

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

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

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

כך שלי חסר מאוד מידע איך ומה בוצע בפוסט, אבל אני לא מצליח לשחזר את מה שהם כן מזכירים.
העניין הוא, שאני לא בוטח ברדיס לפעולות ה mq שאני צריך, כי אני צריך מחסנית יציבה של worker..
אם חלילה וחס הוא נפל, אסור שהמידע יאבד, ויותר מזה, במידה ואני צריך להוסיף workers, אני צריך מצב של ביזור המידע, בלי שworker אחד ידרוך על השני, ואני מקבל את זה בצורה טבעית ב Rabbit, (ועוד מספר סוגים של MQ שבדקתי), אבל רדיס מעולם לא תוכנן לזה. הוא נמצא בזיכרון, אני כמובן שיכול להכריח אותו לכתוב לדיסק (איטי מאוד, אבל זה מה שקורה עם persistence queue בRabbit), אבל בשביל לעשות תורים בגישה של Round Robin, ובכן, בלי לכתוב משהו ב lua, אני לא מכיר תמיכה לזה ברדיס, למרות שאשמח לגלות שיש.

ככול שאני עובד כרגע (אמנם עדיין בפיתוח) עם MQ, ככה אני אוהב יותר את הרעיון של השימוש ב Rabbit.
במערכת שאני בונה, יש לי מערכת חיצונית שהיא של ספק אחר שמדברת עם HorentQ, דרך הפרוטוקול שנקרא STOMP (בניגוד לRabbit שברירת המחדל שלו היא AMQP אך תומך גם ב STOMP), והיתרונות של מערכת כזו שהיא robust מאוד, מאפשרת להתמודד עם בעיות שונות, כדוגמת קריסת מערכת, ניתוק התקשורת, התנהלות של load balance של מספר שרתים וכיוב'…

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

 

 

חשיבה מופשטת

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

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

buzz words

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

הקדמה

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

סינטרה מודולרית

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

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

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

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

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

אנחנו משתמשים בRack בעצם, היות וכמעט וכל הframeworks עבור בניית מערכות web ברובי משתמשים בו, אנו זקוקים לקובץ קבוע בשם config.ru.

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

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

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

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

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

את המערכת של יצירת המסכים, ושליחת ה REST, יצרתי בקובץ rest.rb, והכל מאוגד שם.
יש שם משהו שהולך לעבור למקום אחר בקרוב, וזה מספר מתודות לסיוע בפעולות.

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

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

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

במקרה הזה, הגדרתי כי במצב של ‎:development משתמשים ב Sinatra::Reloader, אשר מגיע עם Sinatra-Contrib – תת פרוייקט המספק הרבה כלי עזר לדברים שונים.
הסיבה לשימוש ב Reloader הוא לא לאתחל את השרת בכל שינוי שעושים למחלקה של סינטרה, כאשר Reloader מגלה כי התוכן של הקובץ השתנה, הוא גורם ל rack לטעון אותו שוב, וככה אנחנו לא זקוקים לטעינה מחודשת של השרת עצמו.

המערכת שכתבתי, משתמשת ב template בשם haml, למעשה פעם ראשונה אשר אני משתמש בה מרצון. תוכלו למצוא את ה layout.haml שהוא המסגרת הרגילה וכן כרגע קובץ בשם index.haml תחת ספריית view.
ועבור העיצוב, אני משתמש ב Foundation 5, אשר אני אוהב אותה יותר מאשר bootstrap.
עבור Javascript יש גם את jQuery וגם את knockout.js, כאשר אני נעזר גם ב lodash.js למספר דברים פשוטים, והיא מספקת בעצם גרסה שעברה אופטימיזציה ל underscore.

את הקבצים של Foundation, וכל ה Javascript ניתן למצוא תחת public.

דבר אחרון שנשאר לספר עליו הוא שאני משתמש במשהו אשר נקרא puma.
מה זה ?
puma הוא משהו שלוקח את rack וגורם לו להיות שרת לכל דבר ועניין, אשר ניתן לבצע עליו חיבור לשרתי HTTP שונים, כדוגמץ apache או nginx.
החיבור נעשה על ידי הגדרת proxy בשרתים.

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

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