מפגש רובי #5 - רשמים

אתמול הייתי במפגש ה Israel Ruby User Group החמישי במספר. במפגש היו כעשרה אנשים, חלקם חדשים במפגשים וחלקם לא.
הלכתי למפגש עם יוני גרוס (שהוא אחד ממקימי הקבוצה) ועם ויטלי גורודצקי שהם הצוות שאני עובד איתו ב-Kontera - צוות Ruby!

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

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

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

פישוט = תשומת לב

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

Publisher.find(:all).each do |publisher|
articles = publisher.articles.find(:all, :condition=>”…” ).each {|a| do_something(a) }
# …
products = publisher.products.find(:all, :condition=>”…” ).each {|p| do_something_else(p) }
# …
end

האחראי עליי כשראה את הקוד, התחיל לדאוג לגבי איך שהסקריפט ירוץ בפרודקטשיין, טבלת Publisher אמורה להכיל כמה אלפי רשומות, מה שאומר שהסקריפט בעצם היה מריץ פי שניים שאילתות (נגיד 5000*2 = 10000 שאילתות) מה שהיה גורם למערכת עצמה לקרוס תחת העומס העצום על המסד הנתונים.

הדרך הנכונה לעשות את הנ”ל היה פשוט לעשות כך:

articles = Article.find(:all, :conditions=>”…” )
products = Product.find(:all, :conditions=>”…” )

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

 

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

 

 

——-
* שבוע שעבר התחלתי לעבוד בחברת הסטארטאפ Kontera ובינתיים נהנה מהעבודה, מהאנשים ומהתנאים המצוינים שקיימים שם.

MooTools/JQuery Selectors

לפני כ-3 שבועות valerio, מייסד הספרייה MooTools, הכריז בבלוג הפיתוח של הספרייה על כך שבגרסה הבאה תהיה תמיכה נרחבמת ב-CSS3 Selectors, ביניהם בכאלה שJQuery לא תמכה כמו nth-child וגרסאות יותר מסובכות של הסלקטור הנ”ל (2n+1 וכו’), לבסוף valerio החליט בכלל להפציץ, והרחיב את התמיכה בסלקטורים לתמיכה לא רק לפי הסטנדרט של CSS אלא לפי איך שלמפתח יהיה יותר נוח. הדובדבן שבקצפת, הוא פיתח אפשרות ליצור סלקטורים מותאמים אישית ועל המפתח פשוט לספק שני דרכים בשביל לבחור את מה שהוא רוצה, אחת ב-XPath ואחת ב-DOM בסיסי עבור דפדפנים שאין בהם תמיכה ב-XPath מתוך JavaScript.

בנוסף הוא פיתח את SlickSpeed, ערכת השוואות בין הספריות השונות שמודדת זמנים, תמיכה וטעויות מימוש של כל ספריה וספריה. תוצאות ההשוואה כפי שנערכה אצלי על מחשב  Intel Core2Duo, 2GB RAM על פיירפוקס 2.0.0.4 שרץ על לינוקס אובונטו 7.04 מעודכן, מראות כי prototype בסה”כ הכי מהירה אחריה mootools ואחריה dojo.query, אבל עם בודקים את התוצאות דווקא מגלים ש-dojo.query היא בעלת המימוש הכי טוב בחיפושים הפשוטים וש-prototype/MooTools הן בעלות המימוש הכי טוב ל-nth-child.

הסיפור לא נגמר כאן, היום צוות JQuery הכריזו על גרסה 1.1.3 שמכילה שיפור בממוצע בין דפדפנים בכ-800% במהירות של הסלקטורים שלהם כולל תמיכה בכמה חדשים ושיפור התמיכה בסלקטור nth-child וביוניקוד. בבדיקה בחבילת ההשוואות שהם הריצו, הממצאים מורים שעל IE6 הם נמצאו בתור הכי מהירים אבל מבדיקה שאני ערכתי כאן על מחשבי (פיירפוקס 2.0.0.4 על אובונטו 7.04 ושאר החומרה המפלצתית) נמצצ שככל שהחיפוש מכיל יותר חלקים כך jqeury נעשים פחות ופחות טובים ביחס לחבילות האחרות. לזכות JQuery ניתן לאמר כל הכבוד על השיפור (במבדק הראשון שערכתי התוצאה הכוללת שלהם הייתה: 4878 מילי שניות ואילו בבדיקה השנייה התוצאה הכוללת היא: 669 מילי שניות - פי 7 יותר מהיר!) ובנוסף, הם הצליחו לשמור על נפח החבילה שלהם - רק 20KB (גרסה מקומפרסת).

איך מתחילים לכתוב OOP עם MooTools?

אהרון ניוטון, אחד ממפתחי ספריית MooTools וגם אחד ממתכנתי צד הלקוח של האתר CNet.com  כתב מדריך/מצגת שמסבירה צעד אחר צעד את תהליך היצירה של מחלקה בשימוש עם ספריית MooTools. המדריך מציג את אופן בנייתה של מחלקה שתפקידה להוות בסיס ל-SlideShow כולל תמיכה ב-Events ועל השימוש בעקרון פרמטר ה-Options שקיים בכל מחלקה ומחלקה שקיימת ב-MooTools.

הוא לא מסביר על מה המתודות של MooTools שהוא משתמש בהן עושות אלא איך משתמשים בהם, וזאת נקודה חשובה מאוד כי כדי להבין את המדריך צריך להכיר את ה-API של MooTools. מי שעדיין לא מכיר אז אני ממליץ לעבור קודם על עמוד התיעוד של המחלקה Class ועל הפרק ב-MooTorial שמדבר על מחלקות.

—-

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