Pivotal Tracker רוצים 100$ מדי חודש עבור ניהול פרויקט של יותר מעשרה מפתחים באמצעות הכלי שלהם. החלטתי להשתחרר מהתלות, ובעקבות עשיית סקר כלים לניהול פרויקטים בשיטת SCRUM הגעתי אל ScrumDo החדש ופתוח-הקוד, שמבוסס על Django ו-Pinax.
אחרי התעסקות לא ממושכת הכלי התברר כשימושי ביותר והוחלט לכתוב סקריפט שמייעל את תהליך הייבוא מקובץ CSV שPivotal מייצר אל קבצי האקסל (ייאיקס) שסקראם-דו אוהב לייבא.
הרי התוצאה:
Pivotal2ScrumDo
עם כל עניני הענן, התרבו ההתקנות הסדרתיות במחוזותינו. אני משוכנע שישנן מערכות פריסה (deployment) רבות, טובות ומורכבות, אך לצרכים שלי (בדיקת scalability של מונגו-דיבי) העדפתי לתפור משהו פשוט.
הסקריפט הבא מקבל כפרמטר יחיד מחרוזת JSON שכוללת את שם המכונה, האיי.פי, המשתמש והסיסמה, ומצידה מבצעת שתי פעולות:
דוגמת הרצה:
/home/milez/Projects/remote_init.py '{"name":"mongo9","host":"50.x.x.x","user":"root","password":"secretpass"}'
קוד מקור:
https://gist.github.com/968351
מדובר בסקריפט פייתון שיודע להתיישב על הקצה של /var/log/auth.log של אובונטו, ולפרסס אותו ברמת עומק סבירה, שמאפשרת לבחור על אילו ארועים בדיוק לבצע פעולות, למשל כגון התרעה במייל על התחברות של משתמש מכתובת IP חשודה וכ"ו.
על מנת לוודא שה-parsing עובד באופן סביר והסקריפט אינו נתקל בבעיות, ביצעתי פרסוס של קרוב ל30,000 שורות ארועים מה auth.log, ותיקנתי את המקרים בהם הבנת השורה ע"י הסקריפט נכשלת.
הסקריפט קורא את ההגדרות מקובץ בשם /etc/authwatcher.json, שדוגמה שלו מצורפת בקישור לקוד המקור.
על מנת להריץ את הסקריפט במצב שיקרא את הלוג כולו, הוסיפו לו את הפרמטר parseall:
$ /usr/local/bin/authwatcher.py parseall
מבחינתי, הדבר המעניין בפיסת הקוד הקטנה הזו היא השימוש בRegular Expressions מורכבים שמכילים Named groups, המאפשרים לפרסס באופן קריא ופשוט שורות לוג מורכבות יחסית.
הגיסט מכיל גם כן קובץ Upstart שיודע להריץ את הסקריפט במערכת ברקע ולאתחל אותו מחדש בעת הצורך.
לאחר שהנחתם את קובץ הקינפוג של הUpstart בתיקיה המיודעת, ניתן להתחיל את השרות באמצעות
$ sudo initctl start auth_watcher
במידה ורוצים לבדוק את מצב הסקריפט, עושים את זה ככה:
$ sudo initctl status auth_watcher
מקווה שתמצאו את הסקריפט הנ"ל שימושי כאלמנט אבטחה נוסף למערכותיכם.
עם התבהרות העובדה של-Flash לא תהיה נוכחות על גבי iOS, מערכת ההפעלה של הניידים של אפל, נתבקשתי לבדוק את המעשיות שביצירת סביבת משחקים עשירה גרפית באמצעות טכנולוגיות דפדפן “טהורות”.
בכנות, Flash, עם אופיה הקנייני הסגור אינה נמנית עם הטכנולוגיות האהובות עלי, מה שהוסיף מוטיבציה להדגים שניתן לחיות גם בלעדיה..
עם זאת, Flash של אדובי היא פלטפורמה מפותחת וגדולה, שאיננה רק פלטפורמת הרצה אחידה שאינה תלויה בדפדפן ומערכת הפעלה, אך גם סביבת פיתוח עשירה - שמקשה מאוד על מציאת אלטרנטיבה ראויה.
כתוצאה, החיפוש הטכנולוגי היווה נסיון לפשר בין הצורך לתמוך במספר גדול ככל האפשר של פלטפורמות הרצה, לבין הרצון להרכיב אוסף כלים וסביבת פיתוח ראויה ונוחה לעבודה.
תחילה, עלי להגדיר את הפלטפורמות בהן אנו (אנוכי והלקוח) מעונינים לתמוך. זוהי רשימתנו ההתחלתית:
כמו כן, ישנו הצורך ליצור תהליך עבודה נח עם הגרפיקה שאנשי הקריאטיב יוצרים.
כרגע, אין אלטרנטיבות ראויות לסביבת האנימציה והתסרוט של פלאש, שמאפשרת להגדיר קוי זמן של אנימציה,לנהל מבנה אובייקטים, ונותנת אינטגרציה יפה עם Illustrator וכלי מעצבים אחרים. מרגע שהדרנו רגלינו משבילי המרת הפורמט הבדוקים והידועים שבין החבילות המסחריות, האחריות להגדיר את תהליכי יצוא הגרפיקה מן המעצב על התמכנת עוברת אלינו.
תחילה, בדקנו את SVG כשפה עילית. למראית עין, יש לה יתרונות רבים:
עם רשימת תכונות כזו, ניתן היה לחשוב שזאת טכנולוגיה פשוט אידאלית לצרכינו. עם זאת, החסרונות הבאים התגלו בעת בניית הבדיקה:
בשל כך, הוחלט לנסות גישה יותר נמוכה בצורת Canvas, ולהשתמש בספרייה כגון Processing.js:
בעת יישום סצינת הניסוי ההתחלתית ב-Canvas/Processing גיליתי שכלים רבים, שהיו נגישים מיידית בSVG היו חסרים ולפיכך נאלצתי לממש אותם בעצמי:
היתי מצליח לחיות עם כל החסרונות הנ"ל, אם בתמורה היתי מקבל חויה עקבית וזהה בכל הפלטפורמות, שניתן לשלוט בה עד הפיקסל הבודד. לכן, החלטתי להמשיך בכתיבת דוגמה מורכבת ומציאותית יותר. לרוע המזל, הדמו החדש חשף בעיה שהיוותה מעצור מוחלט לצמד הcanvas/Processing: מהירות ריצה נמוכה להחריד בעת שימוש בCanvas במוביילספארי של אפל.
ביצעתי נסיונות מספר לשפר את ביצועי הדמו ע"י מניעת ציור מחדש של הרקע בכל פריים, הורדת כמות האובייקטים שעל המסך, הסרה של טקסטורות מאובייקטים. נסיונות אלו לא הביאו לתוצאה הרצויה.
הפתרון
בנקודה זהו, לאחר שהשקעתי זמן ומאמצים לא מבוטלים בהשגת מטרה פשוטה כביכול, נאלצתי לבדוק אם הגישה בה אני נוקט נכונה. הרי בבירור, החוליה החלשה ברשימת פלטפורמות היעד היא MobileSafari של אפל, ומכשירים ניידים אחרים להם מעבד איטי והיעדר אפשרות בחירה של דפדפן.
במכשירים אלו, גרפיקה מהירה ניתן לממש רק באמצעות שימוש במאיץ הגרפי. ובMobileSafari , רק פעולות על מודל האובייקטים (DOM) של HTML עצמו מואצות ע"י החומרה.
כתוצאה מהבנה זו, דמו הבלאק-ג'ק שוכתב מחדש, והפעם באמצעות שימוש בHTML, CSS3, והתווספו לו תמיכה בצליל ואפקטים של שקיפות. לבסוף, ההצלחה האירה פנינו..
כתוצאה מיידית, רמת הביצועים ב MobileSafari השתפרה פלאים.
לאחר קריאה נוספת ואופטימיזציה נפרדת לכל דפדפן, האנימציה הפכה להיות חלקה מאוד. בiOS 4.x MobileSafari מואץ רק חלקית, ולכן חשובה בחירה זהירה של צורת הגישה ל-DOM על מנת להוציא את מיטב הביצועים מהדפדפן הזה.
אישית, הופתעתי מהצלחתי לממש את כל הדרישות של סצינה עשירה גרפית באמצעות טרנספורמציות CSS “בלבד". בעוד היתי עסוק בחיפוש "פתרון מושלם" בצורת שפה או טכנולוגיה חדשה ומתקדמת, לא שמתי לב אל השפה הבסיסית ביותר של הווב, עד שמיציתי את שאר האפשרויות.
אין ברצוני לומר שcanvas וSVG אינם טובים. אך למטרה הספציפית שלנו – כתיבת משחקים שעובדים על הפלטפורמות הנ"ל, SVG נופלת בהיותה מתאימה לתרשימים מסובכים אך סטטיים באופן יחסי. וcanvas פשוט לא עומדת מבחינת ביצועים בדור הנוכחי של מכשירי אפל. וכל זה משאיר אותנו עם טכנולוגיה אחת: CSS3.
באופן מקרי (או שלא) בחירתי, שמוכתבת ע"י הצורך למצוא מכנה משותף נמוך שיעבוד על הפלטפורמות הכריח אותנו גם לבנות תהליך המרה משלנו עבור גרפיקה וקריאטיב של המעצב. אך זה נושא למאמר אחר..
קישורים לקוד המקור
דוגמאות הקוד שבמאמר זה ניתנות להורדה מחשבון הגיטהאב של הכותב:
ברוכים הבאים לוורדפרס. זה הפוסט הראשון; אפשר למחוק או לערוך אותו, ולהתחיל לכתוב.
