על ביצועים בריילס ובכלל

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

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

לאחרונה, למדתי על פונקציה מגניבה של ActiveRecord, שנקראת Eager Loading Association. אני חושב שהלינק מסביר הכל אבל בגדול, אם אני כותב את השורה הזו:
clients = Client.all(:include => :address, :limit => 10)
אז ריילס "חכם מספיק" להביא לי את עשרת Clients עם ה-Adress שלהם בשתי שאילתות בלבד, וכל זאת למרות שיש קשר של Association בין טבלת clients לטבלת adressees. קרי, שתי טבלאות נפרדות, שתי שאילתות ומקבלים את כל המידע הרלוונטי - חגיגה!

Open Source לעומת פיתרון של תוכנה כשירות

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

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

הנחת היסוד שלי היא כזו: או שאני מומחה \ מפתח מומחיות בתחום, או שכדאי לשלם עבור מוצר SaaS (בהנחה שמדובר בכמה עשרות דולרים בודדים עבור משתמש). הנה הסיבות:

1. בכדי שאבין אם פתרון מתאים לי או לא, בדרך כלל אני מתחיל לעבוד איתו קצת. במוצרי SaaS כמעט תמיד יש 30 יום חינם. מוצרי קוד פתוח, אני צריך שרת, להוריד, להתקין לקנפרג, וכבר ביזבזתי כחצי יום רק על התקשקשויות מיותרות. אם זה פיתרון מאוד פופולארי, זה יכול לקחת פחות זמן, אבל הרעיון ברור.
   
   
2. לעיתים כשאני עובד עם מוצר, יש לי שאלות, בקשות הערות. מוצר שאני משלם עבורו, יש לי בדרך כלל דוקיומנטציה טובה, וגם אם לא, תמיד יש אבא שאני יכול לשאול (קוראים לאבא הזה support ). מוצרי קוד פתוח טובים, באים עם מספיק דוקיומנטציה. בשביל אבא, צריך כבר לשלם.
   
   
3. מוצר שהוא כלי עבודה עבורי, ולא יותר מזה, אני לא רוצה להתעסק איתו, ולא לחשוב עליו:
   מה קורה אם נופל השרת? מה יש על השרת?
   מה צריך לגבות? איפה הקבצים שעשיתי להם attachments יושבים?
   מה קורה עם אני משדרג את ה-Apache? או את ה-JRE של המכונה?
   האם מישהו צריך להתחבר מרחוק? האם זה מאובטח? האם זה SSL? האם צריך לעדכן DNS?
   איפה יישב השרת?
   כל השאלות הללו, אלו מחשבות קטנות ומציקות שתמיד נמצאות ברקע. בשיטת תוכנה כשירות כל הנ"ל לא מעניין אותי.
   
   
4. עוד לא פגשתי מוצר מושלם, תמיד יש עוד דברים שהייתי רוצה וצריך. במוצר עם אבא אני תמיד יכול לבדוק מתי מוסיפים דברים, ואם יש באגים, אני יודע שצריכים לתקן. במוצר של קוד פתוח, אם הקהילה מספיק גדולה וטובה, כל זה קורה. אחרת....חבל.

אז מתי כן עדיף מוצר קוד פתוח?

1. אם הפונקציונאליות במוצר הקוד הפתוח עדיפה על המוצר שהוא תוכנה כשירות (כאמור אצלנו המקרה הוא הפוך לחלוטין).
   פוקציונאליות עדיפה, כוללת מבחינתי: נוחות שימוש, אפשרויות, התאמות וכו'
   
   
2. אם בסה"כ, ה-Total Cost of Ownership יוצא יותר זול. ישנם המון אקסלים וגרפים באינטרנט שמנסים לענות על השאלה, אבל מבחינתי השיקול החשוב הוא - אם אני מקצוען בתחום או רוצה לפתח מומחיות בתחום.
   למשל, בדוגמא של ה-CRM, אם אנחנו נגיע למצב שיהיו לנו כל כך הרבה משתמשי CRM, שתצדיק העסקה (עלות מעביד) של עובד שזוהי המומחיות שלו, אז יכול להיות שנעדיף את SugarCRM.
   עובד זה יצטרך לדאוג, כמובן, ל-customizations, לגיבויים, לשינוי בקוד אם צריך, לעדכונים, לשרת , לאבטחה וכו'. כמובן שצריך לקחת בחשבון את העלות של השרת והגיבויים והעזרה הטכנית הנוספת שהוא עלול להזדקק לה. אבל הרעיון צריך להיות ברור -> אם חשובה לי מומחיות בתחום ה-CRM, אז יכול להיות שאעדיף מישהו פנימי שיתעסק רק בזה. אם המומחיות ב-CRM אינה חלק מהליבה של העסק שלי, כנראה שאוותר, או שאקח חברה שזוהי הליבה של העסק שלה.
   

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

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

מעבר שרתים לא בשבת הזו

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

ההחלטה לעבור סופית נפלה ביום רביעי לפני כחודשיים, לאחר שהיה ניתוק נוסף, והפעם הוא לא היה במשך 5 דקות. להזכירכם, בשרת שלנו משתמשים לקוחות, ואין לנו פריבילגיה ל-down time אשר אינו ביום שישי או שבת ומתואם מראש.
אז ביום רביעי ההחלטה נפלה, ותוך 24 שעות כבר היה לנו שרת חדש אשר התחלנו לקנפרג במרתון.
ביום חמישי נשלח אימייל ללקוחותנו, מסביר על שדרוג הגירסה ביום שבת וגם על מעבר השרת. למרות שהמעבר לשרת החדש הוא עניין של כמה דקות, כיוון שאנחנו משנים גם DNS וגם MX Records, למעשה חלקים באפליקציה עלולים לא לעבוד עד 24 שעות מהשינוי. במידה וה-DNS מתעדכן בזמן (בדרך כלל עניין של עד שעה), אז האפליקציה המרכזית יכולה לעבוד.

באימייל הודענו, שאם מישהו חייב לעבוד באותה השבת, אז נוכל לפתור לו את הבעיה (בגדול, שינוי ב-/etc/hosts עד שה-DNSים מתעדכנים), ויום שישי בבוקר החלו הבדיקות של האפליקציה על השרת החדש.

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

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

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

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

Wordpress and Rails on the same Domain -> a much simplier configuration

About two weeks ago, I wrote a blog about how to make Wordpress and Ruby on Rails work on the same domain. That way still works but it might make problems if you use the non-default permalink options, and you have to change the .htaccess file. Also, this way is much simpler:

1. Same assumptions apply: you already have Apahce, mod_php, phusion(Passenger), and you know how to make it work. Your existing blog and website are working, but not on the same domain, or not concurrently. You are using Debian / Ubuntu.
   Make sure you use the Passenger Version 2.1.3 or above. This is key here.
   
   
2. I assume you've installed your blog under /var/www/blog, and let's say you've installed your rails website under /var/lib/www.myWebsite.com
   
   
3. Login to your blog as admin, goto Options -> General, and change your Wordpress Address URL, and your Blog Adress URL to www.myWebsite.com/blog (click update Options, and disregard whatever doesn't work right now)
   
   
4. Go to the /var/lib/www.myWebsite.com/public folder, and link to your blog folder :
   ln -s /var/www/blog blog
   
   
5. goto to the wordpress directory: cd /etc/wordpress/
   
   
6. make wordpress look at the configuration file (linking the mywebsite configuration file to the default config-blog.php file):
   sudo ln -s config-blog.php config-www.myWebsite.com.php
   
   
   Up to here everything was the same, the key here, that now Passenger supports the "PassengerEnabled off" command, as follows:
   
   
7. edit your /etc/apache2/sites-available/www.myWebsite.com. Add the following lines
   <VirtualHost *>
   ServerName www.myWebsite.com
   DocumentRoot /var/lib/www.myWebsite.com/public
   <location>
   PassengerEnabled off
   </location>
   </VirtualHost>
   
   
8. restart the apache (/etc/init.d/apache2 restart),
   
   
9. That's it.
   
   Now, you can also change the .htaccess in your blog directory, and the permalink will work. It will be probably something like:
   
   <ifmodule>
   RewriteEngine On
   RewriteBase /blog/
   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteCond %{REQUEST_FILENAME} !-d
   RewriteRule . /blog/index.php [L]
   </ifmodule>
   

A very similar configuration we did for our blog about test tools and testing methodologies in http://www.practitest.com. The website is a rails application, but the http://www.practitest.com/qablog is a wordpress blog.
Good luck.