מדוע לא בחרנו לפתח ב-Java או ב-.NET?

(ממליץ לקרוא לפני את הפוסט על רובי או רובי און ריילס (RoR), ואת הפוסט על שפת פיתוח ה-web הנפוצה ביותר)

הכי פשוט לנו היה לפתח ב-Java. הכרנו אותה הכי טוב. אך בעוד ש-Java מאוד מתאימה לכתיבת שרתים ואפליקציות אחרות, יש בה המון סירבול מיותר שמדובר באפליקציות ווב. הסרבול הוא למרות שאפשר לפתח ב-jsp , jsf וכו'

אגב, בעיה ב-Java שנתקלתי בה בעבר, כיוון שכל ארגון בוחר לעבוד עם מודולים שונים, יש להוריד עד עשרות מודולים מהאינטרנט, בגירסאות מדוייקות, כדי שהסביבה שלי תתאים לסביבת הפיתוח של הפרויקט.
כלומר, מפתח חדש, לא רק צריך ללמוד ולהכיר את כל הסטנדרטיים שעובדים איתם בחברה, גם צריך לקנפרג את המחשב עם כל המודולים השונים. ב-RoR יש רק את הגירסה של RoR (כיום 2.2). זהו. ברגע שיש את RoR 2.2, לא צריך יותר מזה כלום.
הדבר נכון גם כאשר עושים Deployment לאפליקציה בשרתי ה-Production. ב-Rails אני צריך את הגירסה האחרונה ומכסימום להריץ פקודה אחת של gems, אשר מביאה לי את כל המודולים החיצוניים ובזה נגמר הסיפור (גם להוסיף או לעדכן את מבנה הטבלאות שיתאימו לגירסה האחרונה בפקודה אחת - סעיף 7 כאן).

.Net היא לא אופציית OpenSource, ושכזאת, לא נרצה לשלם הרבה $$$ עבור רשיונות כאשר נגדיל את חוות השרתים, ו-Scale (קרי, איך לגדול) זה אחד הדברים היותר חשובים כאשר מפתחים תוכנה כשירות, או פיתוח לווב בכלל. כתבתי על Scale ו-how to scale כאן. מלבד עלות הרשיונות לשרתים, והרשיונות עבור המפתחים (MSDN), הפיתוח ב-.Net הוא פחות מהיר מאשר PHP או RoR. זאת למרות שה-IDE של מייקרוסופט בהחלט מצויין. גם ב-.Net כמו ב-Java, אם לא עושים סטנדרטים מלכתחילה, אפשר תוך זמן קצר מאוד להגיע לקוד שקשה מאוד לתחזקו. כבר ניהלתי בעברי כמה פרויקטים שפותחו ב-.Net שהיה צריך לפתח אותם מהתחלה. לא בגלל שהפלטפורמה כל כך גרועה, אלא בגלל שהמפתחים היו חסרי ניסיון.
פרויקטים שמלכתחילה אם היו מפתחים ב-RoR היה לוקח הרבה פחות זמן, ועולה הרבה פחות כסף. לא בהכרח כי המפתחים ב-RoR יותר מוכשרים, אלא כי פשוט הסביבה לכשעצמה גורמת להם לעבוד עם סטנדרטים מאוד מתקדמים ומותאמים לפיתוח ווב. כפי שכבר כתבתי, אפשר לעבוד עם סטנדטיים אלו בשפות אחרות, זה פשוט לא ברירת המחדל! לכן קוד "ספגטי" תמצאו הרבה יותר בפלטפורמות שהן לא RoR.


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

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

בשלב זה בדרך כלל עולות שתי אופציות - או לשכתב חלקים מהאפליקציה ולא להשתמש ב-sessions בשרת בצורה כזו שתפריע, או לקנות רכיבי חומרה יקרים להחריד, שידאגו שכל משתמש תמיד יגיע לשרת שאיתו הוא התחיל (ואז הבעיה לא אמורה להיווצר). אגב, אנשי טסטים מנוסים (כגון יואל) מכירים כבר את הבדיקות שצריך לעשות לוודא שהשרת עדיין "זוכר אותי", למרות שיכול להיות שהחלפנו שרת בדרך.
ב-PHP, ו-(RoR (Ruby on Rails, אין כמעט בעיה שכזו, כיוון שבברירת המחדל לא משתמשים ב-session שנשמר בשרת.

אגב, אם יש לכם את הבעיה הזו אני ממליץ לכם להסתכל על פתרון מדהים שנקרא memcache. זהו פיתרון כללי איך לעשות Caching לזיכרון. בין אם זה זיכרון של שרתי ווב, או שרתי database. אומרים שבפייסבוק (שכתובה אמנם ב-PHP) משתמשים בפיתרון זה להפחית עומסים.

על תגים ותגיות

עוד שהייתי סטודנט באוניברסיטה, תמיד התחבטתי איך לתייק את הקבצים של הלימודים:
בתוך ספריות של שנה-> סמסטר-> מקצוע
או בתוך ספריות של מקצוע -> שנה -> סמסטר

למשל קורס באלגברה לינארית ב' יכל להיות תחת: שנה א-> סמסטר ב-> אלגברה לינארית ב', אבל באותה מידה זה יכל להיות תחת אלגברה->שנה א->סמסטר ב.

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

הדבר נכון גם לתמונות - האם לסדר לפי שמות האנשים שבתמונה, או לפי תאריכים? איך אראה את כל התמונות של פורים מכל השנים?

עבור אנשים כמונו, אני מניח שהמציאו את התגיות (או באנגלית Tags, לעיתים זה גם נקרא Labels).
כל מה שאני צריך לעשות, זה לתת תגית או תגיות.

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

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

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

ממליץ בחום.

אגב, אם מעניין אתכם הפוסטים של בלוג אשר תויגו בתור טיפים, הקליקו על Label - "טיפים".

בטוח שאתה יודע מהי שפת פיתוח ה-Web הנפוצה ביותר?

אתם יודעים מהי שפת ה-Web הנפוצה ביותר בעולם?

בוודאי תגידו Java , או תחשבו ש-.Net של מייקרוסופט היא מספר אחד.
אבל האמת היא שאף אחת מהשתיים אינה המובילה כיום. רוב אתרי האינטרנט לא כתובים לא ב-Java ולא ב-.Net. אפילו לא ב-RoR - כי למרות שרוב אפליקציות האינטרנט החדשות כיום נכתבות ברובי און ריילס, ריילס עדיין לא מספר אחת. למעשה, יותר אתרים בעולם כיום כתובים ב-PHP מאשר כל שפה אחרת.

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

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

בפוסט הקודם פירטתי מדוע Ruby On Rails היא מצויינת. אנסה לפרט מדוע אנחנו בחרנו בה על פני PHP.

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

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

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

• בדיקות פנימיות Unit Testing - עם איזה מודול עובדים? ב-RoR זה מובנה. כל מי שלמד Rails יודע איך לעשות Unit Testing בפלטפורמה. אגב, ככל שהאפליקציה יותר מורכבת, צריך יותר Unit Testing.
  
  
• ORM - אם מפתח PHP מן השורה אינו מכיר ORM, אז ברור שמפתח RoR יכיר, כי כולם עובדים עם זה (אגב, Hibernate ב-Java מאוד פופולארית ורוב מפתחי ה-Java כן מכירים ORM, אך לא בטוח שיכירו MVC, למשל).
  
  
• שמות של טבלאות במסד הנתונים, אופן יצירתם, אופן תחזוקתם.
  
  
• מבנה הספריות ושמות של הקבצים - אפשר לזלזל בזה, אבל זה קריטי. כאשר אני נכנס לקוד של אפליקציה קיימת, אני יודע בדיוק איפה הגדירו את מבנה ה-DB, באילו מודולים חיצוניים משתמשים ואיפה הם מופיעים, איפה קבצי הקונפיגורציה, איפה ה-Controllers, איפה הדפים שמייצרים את ה-HTML, איפה קבצי ה-Unit Testing וכו'
  

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

בל נשכח שלעתים אנחנו, המפתחים המנוסים יכולים לעשות טעויות, והקביעה של הסטנדטים שלנו היא לא מושלמת. הסיכוי שזה יקרה לקהילה פתוחה של אלפי מתכנתים הוא נמוך מאוד. כיוון ש-RoR נועדה לפיתוח Web את כל הסטנדרטים הכי רלוונטים אנחנו מקבלים built in. זה מביא אותי לייתרון נוסף של RoR.

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

מה זה הרובי הזה?

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

למעשה Ruby on Rails כבר די פופולרית בארצות הברית, אבל משום מה, הכל לארץ מגיע באיחור. אנחנו כבר מודעים לכך שהמיתון מגיע לארץ לאחר כחצי שנה, אבל מי היה מאמין, שאפילו בטכנולוגיה אנחנו מפגרים כל כך הרבה זמן אחרי העולם?
כבר 5 שנים Ruby on Rails (או בקיצור RoR) קיימת, ולמעלה משנתיים היא הפלטפורמה החמה ביותר לפיתוח באינטרנט, חברת Apple מזמן החליטה להפוך את RoR כחלק אינטגרלי מערכת התוכנות שהיא מספקת עם כל מחשב Mac. בשנתיים האחרונות רוב הסטראטפים החדשים בעמק הסילקון בוחרים בה, ובארץ כמעט שאף אחד לא מכיר אותה!

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

יש הרבה סיבות מדוע RoR נהפכה לכל כך פופולארית. הנה רשימה חלקית:

1. סביבת ה-Rails נכתבה במיוחד עבוד פיתוח ווב, קרי, כל מי שעובד ב-RoR עובד לפי הסטנדרטים של פיתוח ה-Web. זהו ייתרון קריטי.
   
   
2. Convention Over Configuration - אפשר לקנפרג כמה שרוצים, אבל אם לא עושים כמעט כלום, הקונפיגורציה המובנית מתאימה ל-99% מהאפליקציות. ברוב המקרים הדבר הנכון ביותר הוא לא לשנות כלום. בשאר הפלטפורמות, כדאי להגדיר מראש את אופן העבודה.
   
   
3. MVC - Model View Controller - הפרדה מוחלטת בין ה-Model (קרי, המודולים שעוטפים את הנתונים), ה-View - הדפים שמייצרים את ה-html, וה-Controller, אשר מחבר בין השניים.
   
   
4. סדר בספריות - הספריות והקבצים של הקוד מסודרים באופן אוטומטי על פי סדר מסויים. כל מתכנת חדש שמגיע ומכיר RoR, ידע איפה לחפש כל דבר. כאשר המערכת גדולה ומורכבת, עצם הרעיון מוזיל את הפיתוח והרבה יותר חשוב, את התחזוקה. בנוסף, בתהליך הפיתוח אין צורך לחשוב איפה לשים כל קובץ. הכל לפי סטנדרטים של הפלטפורמה. סטנדרטיים אלו נכתבו לפי הצרכים של פיתוח ווב. במידה ורוצים לשנות - אפשר, אבל בדרך כלל אין סיבה לעשות זאת.
   
   
5. ORM מובנה (Object Relational Mapping) -חוסך מאיתנו את הצורך בלתקשר עם מסד הנתונים בשפת SQL וכל שורה בטבלה הופכת להיות אובייטק. הקוד יותר פשוט וקריא, וחוסך בעיות אם רוצים לעבור ממסד נתונים אחד לאחר. לא ארחיב על כך כאן- מי שלא מכיר שיקרא פה (חשוב אם הוא עוסק בתכנות). ב-RoR ה-ORM נקרא Active Record, ב-Java משתמשים ב-Hibernate, וב-.Net הרוב לא מכירים את הקונספט (גם כי שם מעדיפים כולם לעבוד רק עם מסד נתונים של מייקרוסופט). היו כמה מפתחי דוט נט שהיו מתוסכלים שלהם אין ORM . הם פיתחו את CastleProject .
   
   
6. plugins - בצורה זו כל אחד יכול בקלות להשתמש במודולים שכתבו אחרים. לא צריך לכתוב את הכל מאפס. אפשר להשתמש בקהילה (וגם לתרום לה כמובן)
   
   
7. קונפיגורציית DB - כל יצירת ה-DB, מבנה הטבלאות והקשרים בינהם נכתבים ב-RoR בצורה שכל מפתח חדש או מפתח אשר מעדכן קבצים, יכול בפקודה אחת "להשוות" את המבנה עם הקשרים. הדבר נכון גם אם מוחקים טבלאות או לוקחים אפילו גרסאות לאחור!
   
   
8. RoR מגיעה עם פלטפורמה של Unit Testing אשר מעודדת בדיקות אוטומטיות.
   
   
9. שפת הרובי חוסכת בשורות קוד והכתיבה מאוד ברורה והגיונית. עוד אפשר לקרוא כאן.
   
   
10. קוד פתוח -תנאי הכרחי - א. קהילה של אלפי מתכנתים כל הזמן גורמים לפלטפורמה לעבוד טוב יותר, ולמלא צרכים של מפתחים, ב. לא נצטרך להוציא עשרות עד מאות אלפי דולרים עבור רשיונות של שרתים.
    

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