מדע בזיוני

הפוסט הזה לא ממש מיועד למי שאין להם יד ורגל בתכנות ובאדמיניסטרציה הכרוכה בו, כך שאתם יכולים לחסוך לעצמכם את הזמן. מאידך, אולי תלמדו משהו. בשביל המתמידים יהיה בסוף גם טיפ קטן לכותבים (כותבים ממש – סיפור/תזה/מאמר… לא רק קוד). בתפריט היום – האם אפשר להשתמש בגוגל-דוקס (google docs) לניהול גירסאות קוד (version control, revision control). עוד מילות מפתח : eclipse, subversion.

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

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

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

פיתרון 1 – אימייל (פרהיסטורי):

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

פיתרון 2 – לעבוד מרחוק על השרתים של האוניברסיטה (לא טוב):

אפשר כמובן לעבוד מרחוק על השרתים של האוניברסיטה שם עושים סנאפ-שוט כל עשר דקות וכך הדטא שמור וניתן להשוואה (זה קצת מלאכותי לניהול גירסאות אמיתי).
החסרונות:
- עבודה מרחוק (בעיקר בסביבת X) היא מאוד איטית.
- הסיסטם של מדעי המחשב באוניברסיטה העברית פרנואידים במיוחד ולכן עבודה צריך להתחבר עם OTP (One Time Password) שמותקן על הסלולרי וזה מ-ע-צ-ב-ן ומסורבל (הבהרה: אני דווקא מעריך אותם על האבטחה הקפדנית ובמחשבים פרנואידיות זה בד"כ טוב).
- חייבים להיות אונליין כדי לעבוד מרחוק וזו כבר יכולה להיות בעיה אמיתית, בעיקר בחו"ל.
- אני עובד עם כל מני כלים שהאוניברסיטה לא רוצה להתקין או שאין לי את הסבלנות לבקש אישורים ולחכות שיסגר מעגל, למשל Oracle XE ו-Oracle SQL Developer (יש סיבות היסטוריות למה אני לא עובד עם Postgres או MySQL).
- ושוב בעניין הפרנואידיות – האוניברסיטה חוסמת מני סקריפטים שיוצאים לרשת כך שזה מטיל מגבלות קשות על העבודה שלי.

פיתרון 3 – לעבוד לוקאלית ולגבות על שרת (מעצבן):

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

פיתרון 4 – google docs (חלקי) :

להשתמש ב-google docs. אפשר לשמור כל גירסת קוד כמסמכי גוגל. גוגל-דוקס מציעים גם ניהול גירסאות וגם השוואה שלהם. אפשר להשתמש בגוגל-דוקס עם גוגל גירס (google gears) וכך לשמור גרסאות גם בעבודה אופליין (אם כי אולי זה ישמור רק את גרסת האופליין האחרונה. צריך לבדוק). כמובן שכשרות רשת הקוד על גרסאותיו השונות יהיו זמינים מכל תחנה ועל כל מערכת הפעלה (טוב, לפחות WIN, מק ולינוקס להפצות השונות).
ועכשיו אני מגיע לחסרונות.
בשביל להריץ את הקוד על המחשב צריך שהוא יהיה לוקאלי או נגיש עם הרשאות ריצה ולא שמור כמסמך בגוגל. אני למשל עובד עם אקליפס אז אני צריך את הקובץ פתוח באקלפס. זה כמובן מצריך לעשות קופי+פייסט (ק+פ) הלוך ושוב. הק+פ לא בעייתי בפני עצמו (אם כי מערכות ניהול גירסאות יעודיות חוסכות את זה), אבל הבעיה היא בהשוואת הגירסאות. לגוגל דוקס מערכת מצויינת להשוואת גרסאות שנכתבו בגוגל דוקס. כשעושים ק+פ דורסים את הגרסה הקודמת כולה וכך כשמנסים למצל את מנגנון השוואת הגרסאות מקבלים השוואה שמראה שהמסמך כולו שונה. איך אומרים בלעז – kind of defeats the purpose.
בעיה נוספת היא שגוגל דוקס לא מאפשרים לשמור תגים על הריוויזיות של המסמכים. חבל. זו לא נראה לי מסובך להוסיף פיצ'ר שמאפשר לכתוב כמה שורות שמתארות את הגרסה החדשה (כרגע אני עושה את זה כהערה בראש הקובץ. כלומר, אם יש לי כח ואני זוכר).

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

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

פיתרון 5 שימוש בניהול גירסאות לוקאלי וגיבוי בגוגל-דוקס (הכי טוב שיש?):

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

פיתרון 6 – subversion מקושר לגוגל-דוקס (קיים?):

צריך איזה גיק עם אחריות חברתית שיכתוב את הפלאגין הזה שיקשר את האקליפס וה-subversion עם גוגל דוקס.
או שאולי זה כבר קיים ברמה כזו או אחרת בגוגל-קוד (google code) עם google project hosting. עוד לא היה לי זמן לנסות את זה ולא ברור לי מה בדיוק התנאים, המגבלות והדרישות מקוד שמאוכסן בגוגל, אבל הנה עוד כמה רפרנסים.

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