ארגז כלי העבודה של מפתח צד-לקוח

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

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

 

מערכת הפעלה

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

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

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

סביבות פיתוח ועורכי קוד

למרות היותי מפתח צד-לקוח, אני חוטא גם בכתיבת קוד צד-שרת, כאשר השפה המועדפת עלי היא רובי. שתי סביבות הפיתוח (IDE) עימן אני עובד הן Aptana Studio 3 ו Netbeans כאשר האחרונה מתאימה יותר לפיתוח רובי וריילס והראשונה מתאימה יותר לפיתוח שפות צד לקוח.

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

למי שמוכן לשלם מעט ממון אוכל להמליץ על RubyMine כסביבת פיתוח מצויינת לרובי ועל PyCharm כסביבת פיתוח מצויינת לפייתון.

מנהלי קוד

רוב ניהול קוד המקור שלי נעשה באמצעות Git כאשר יש פרוייקט אחד שמנוהל ב Mercurial מסיבות היסטוריות שמקורן בתמיכה הטובה של Netbeans ב – Mercurial. ההעדפה האישית שלי היא Git בעיקר מתוך הרגל וקצת מתוך אהדה לתכונות ה Branching שלו שהן בעיני עדיפות על של Mercurial.

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

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

דפדפנים

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

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

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

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

כלי צד-שרת

ריילס

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

Padrino

מיקרו-תשתית הכתובה ברובי ומבוססת על מיקרו-תשתית בשם סינטרה. מצויינת לפרוייקטים קטנים בהם אין הצדקה להשתמש בריילס (הכבדה היותר). מגיעה עם מערכת Back-office מובנית, תמיכה מצויינת בשפות Templating שונות ושכבות ORM כמו ActiveRecord או DataMapper. קלה נוחה וזריזה.

Node.js

טכנולוגית פיתוח ג’אווהסקריפט בצד שרת המבוססת על מנוע V8 של כרום. נהדרת לפיתוח יישומים אסינכרוניים כמו מערכת העברת הודעות עם WebSockets או Faye וליישומים רזים וזריזים בצד-השרת. מכיוון של Node.js כותבים בג’אווהסקריפט, אך טבעי שמפתח צד-לקוח שכמותי יוכל להנות מיכולות השפה בצד השרת ולא רק בצד הלקוח.

Nginx ו Unicorn

שרתי ה-Production החביבים עלי, כאשר Nginx בחזית ו Unicorn מאחור. הבחירה ב Unicorn כשרת אחורי ליישומי רובי נובעת בעיקר מהיכולת לאתחל את היישום בצורה הדרגתית לאחר עדכון קוד ללא Down-time אך ישנם מקרים בהם Passenger יתאים יותר (בעיקר בשלבים מוקדמים בהם אין מקום להגדרת תצורות מסובכות).

כלים משלימים

טרמינל

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

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

Sequel Pro ו SQL Yog

Sequel Pro הוא כלי לניהול מסדי נתונים של MySQL עבור מקינטוש ו SQL Yog הוא כלי דומה (אם כי הרבה יותר מקצועי) לחלונות, שניתן להריץ ע”ג לינוקס באמצעות Wine. שני הכלים הללו מאפשרים ניהול של מסדי הנתונים באמצעות ממשק משתמש גרפי נוח ונותנים מענה הולם לכל צרכי העבודה מול מסד הנתונים לבני התמותה שבינינו שלא זוכרים את כל פקודות ה SQL בע”פ.

RVM

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

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

Git

כבר הזכרתי את Git ככלי לניהול קוד, אך בחלק מהפרוייקטים עליהם אני עובד יש לו שימוש נוסף ככלי לפריסת קוד. במצבים בהם אין צורך במערכת פריסת קוד מתוחכמת כמו Capistrano או Fabric, ניתן לפרוס קוד לשרתים ע”י תצורה של מאגר Git מרוחק עם hooks שיודעים לסנכרן את הקוד למקום הנכון בשרת ודחיפה של קוד מקומי למאגר הרצוי. היתרון בשיטה הזו הוא שהיא כמעט לא מצריכה מאמץ והגדרות מסובכות, אלא רק כמה שורות bash במאגר המרוחק לסינכרון הקוד, ושהיא נסמכת על מנהל קוד כך שיחסית קל לתקן ולדחוף שינויים אם משהו נשבר.

Redmine

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

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

כולם היו כלי

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

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

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

זהר ארד

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

הגב

23 תגובות על "ארגז כלי העבודה של מפתח צד-לקוח"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
גלעד
Guest

כדאי לך לנסות גם את http://www.activestate.com/komodo-edit במקום Aptana

זהר ארד
Guest

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

רפאל
Guest

כלי יחסית חדש שג’ון רסיג המליץ עליו – dynaTrace – http://ajax.dynatrace.com/ajax/en/
עושה טרייסינג כמו שצריך. מאוד מומלץ לניתוח ביצועים של אקספלורר ופייר-פוקס

תום ב
Guest

כרגיל, בנזונה של סקירה :)

אני מנחש שהרבה מפתחי פרונט אנד יגידו לך שחסרה פה המלצה על Sass/Less/Compass לכתיבת CSS

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

זהר ארד
Guest

לא ממש. Less / Sass / Compass לא ממש חסרים לי. אני משתמש בג’ם שנקרא Jammit לכל נושא המיזוג ומזעור ואת הכתיבה עצמה אני עושה ב CSS טהור.

אני כן משתמש הרבה ב HAML

oc666
Guest

אם אתה משתמש בלינוקס אולי כדאי לנסות את Quanta או KDevelop שאינם מבוססות Java.

אלעד
Guest

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

זהר ארד
Guest

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

יבגני
Guest

צודק ב -100%.

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

יש לי רק שאלה אחת… לא היה עדיף להשתמש ב”חלונות” בלבד בשביל זה ???

אלון פאר
Guest

את התוסף של RedMine ל-Eclipse לא הכרתי, הוא נשמע כמו אחלה רעיון!

תודה על הסקירה הטובה.

אלי
Guest

סקירה ברמה גבוה, תודה רבה :)
כבר הרבה זמן שאני שוקל ‘מעבר’ מסביבת הnotepad++/windows7 שלי לטובת משהו קצת יותר רציני, אבל עד עכשיו מצאתי את רוב הכלים טיפה מסובכים מדי לצרכים שלי.

אגב, למיטב הבנתע למפתחים מומלץ להשתמש בהוצאת דיאספורה, יש לך דעה בנושא?

זהר ארד
Guest

אלי, שמח שאהבת את הסקירה. אני לא מכיר את הוצאת דיאספורה (חוץ מפרוייקט הרשת החברתית המאובטחת והפתוחה). אתה יכול להרחיב בבקשה?

אלי
Guest

ואגב, לניהול פנים ארגוני אני יכול לציין שopentrium המבוסס דרופל נראה טוב.

אבי צוראל
Guest

אם אתה משתמש בHaml, לא נראה לך יותר הגיוני השתמש בSass ובקומפס? אם אתה מקונן תגים של HTML לא נראה לך הרבה יותר הגיוני לקונן את אותו הדבר גם בCss.

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

http://he.kensodev.com/?p=542

זהר ארד
Guest

אבי, אני בטוח ש Saas ו Compass מצויינים וגם קראתי עליהם וראיתי הרצאות. זה ממש עניין של הרגל שלא ראיתי צורך לשנות, לא מעבר לזה

עינב
Guest

למרות שאנחנו עובדים עם web stack מבוסס LAMP, רוב הפיתוח נעשה בחלונות (7).
בין היתר אנחנו משתמשים ב Netbeans, SQLyog, Git, Bugzilla, Mantis והרבה Putty.
הסיבה העיקרית להשארות בחלונות היא האינטגרציה עם Exchange וגם איזה פרויקט עם MS SQL Server (והאמת שאנחנו לא סובלים).

רן
Guest

תודה על הפוסט – למדתי רבות (בתור אולד-סקולר ששוקל עדיין את המעבר מ Java ל Rb)

כלי הניהול הגרפיים של MySql Workbench בגירסתם האחרונה והמאוחדת אמנם פחות יציבים מהגרסאות הקודמות, אבל עדיין מהווים פתרון ניהול DB גרפי חביב ושימושי – והעיקר – חינם ופועל על כל הפלטפורמות, בניגוד לכלי ה DB שהזכרת.
לגבי ניהול הפרוייקטים – זה המוצר המסחרי ממש היחיד שאני עובד איתו, Jira של Atlassian. היתרון הממשי שלו על פני כל מערכת אחרת שבדקתי הינו ממשק המתשתמש שלו שלא ירתיע גם לא-מתכנתים.

משה
Guest

מצורף להמלצה. הגירסא האחרונה שלו אכן פחות יציבה אבל בהחלט מדובר בכלי שכיף להשתמש בו.

בעז”ה גם תהיה פה פעם השלמה אוטומטית כמו ב-SQL Server Management Studio ואז זה בכלל יהיה מושלם.

רן
Guest

לכל משתמשי חלונות – הכלי שאני מתשמש בו הכי הרבה למעשה הוא Cygwin והכלים שתחתיו – ssh, svn, vi, Perl. סביבת CLI יוניקסית מלאה למי שמתכנת לפעמים בין סשנים של Crysis 2.

זהר ארד
Guest

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

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

אלי
Guest

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

יוני
Guest

ארגזי הכלים של הום סנטר הכי טובים

יוני
Guest

ארגז כלים של הום סנטר הכי טוב שיש

wpDiscuz

תגיות לכתבה: