יום ראשון, 3 בנובמבר 2013

Heads up on Codeine!

Codeine is a tool for continuous deployment - as it's name implies. Codeine tries to ease automation tasks that are in the heart of the continuous deployment process, and provide sleek and simple web-based interface for proactive monitoring combined with deployment automation environment.
Codeine enables gradual deployment plan, with rollback capabilities and monitoring during an upgrade process.
Codeine, in many aspects, was inspired by jenkins, and tries to support continuous deployment in a similar manner to jenkins supporting continuous integration.
Codeine (previously known as 'yami') is also an open source project, so you can download it from github and use it.
In the future I plan to post some usage explanation and examples, as well as documentation. For the time being, please contact me directly if you wish to use it or to be an active participant in its development.


יום שישי, 8 ביוני 2012

Prefx - messaging redirection

I just recently had an idea. 
When I want to send text message with my galaxy device it is asking me if I want to send it with the built in messaging application, whatsapp, viber etc'. Of course you can configure a default way to send but this applies to all your friends. And what if someone don't have whatsapp but have skype/viber?
It happened after I had to meet my friend, I text him using whatsapp, but he didn't replied. I was busy and forgot about it, and got an answer 2 days later that whatsapp is not showing notification about new messages arrives and he prefer the usual text messages.
Of course the meeting didn't occur, but it left me with this idea. I don't want my phone to ask me how I want to send message to someone, I want it to know that and save me the thinking and mistaking. how can it be known? of course it is the preference of my friend. My first and most important when writing a message is that it will get to its destination.
That's how Prefx was born. Everybody will install that app and tell how they prefer to be contacted. When you want to send a message to someone, you will be redirected automatically to his/her preferred messaging system, assuring the message will arrive to its destination. This can be also applied to phone calls easily (although if someone is not answering you know it immediately), and also I have some other ideas on how to extend it.

My experience with writing android app

One of my ideas was to get the experience of writing an android application. Up until now it was a good experience and I would like to share that. Why in English? my previous posts were in hebrew, which is my tongue language? The answer will come in the post later.
So I started to write my first android application. I had a bit of experience before, but I never wrote a full app and never deployed anything to the android market.
It is quite nice and easy. Writing java with eclipse is my day 2 day work, so It was like swimming in a water I know. There are a lot of examples out there, Google's developer sites is very good and has a lot of documentation. The documentation is clear and there is also a big community to assist, in stackoverflow for example.
I started by writing a prototype, to make sure I sort of know how to do it. Here are some of the things I learned: How to start an activity that is not of your app, How to "normalize" a phone number to include country prefix, How to write to the android filesystem and how to save data in my app. I even created an icon using gimp!

Technologies I used

I saved my work at dropbox. I work alone, but on several different computers so it was pretty convenient. It also includes revision history, but I never used it because that requires to login to the website. So a friend advised me to use git. I know svn well, but when I got the principle of git that I don't need all the fuss of a remote server repository, it was pretty incredible. I just got revision history in eclipse for almost free.
After registering to the android market and deploying initial version, I started got exceptions from my few friends who install the application. Crashing the app was not nice, so I started using ACRA. This is an error reporting system. It behaves nice to the user - tell him/her an error occurred and suggest to send a message to developer, and when an error is reported, I get it to a google docs spread sheet include some data that is collected, and receives mail notification about new error. And this is a 5 minute install time monitoring tool.
Of course I have to test my application. Parts of the code I wrote by TDD, but I also wan't to get some unit tests for activity and flow coverage. It is still on my todo list. hope to get to it soon.
One more things on my "technology" todo list is google-analytics to collect usage data about the app.
I also started using Guice. When I decided to use it I also considered RoboGuice, but in the end I decided to go with pure Guice from few reasons: I a still consider myself as new to guice, so I want to get some experience on the regular usage of guice. I want to be able to apply my experience with it also to regular java applications and I didn't understand exactly what is the benefit of RoboGuice. 
This is how I use guice: I init guice in my application startup and create a base activity that inject guice to the activity itself. All my activities are inherited from this activity. pretty straight-forward.

Marketing

My main concern now is advertising. When I told my friends about the app, they said it is nice idea. Its not that I am planning to make money out of it, but it will be nice to have many users. I have a friend "working" with me on marketing. He created a facebook page for the app.
Another friend wrote about it in his facebook page. He also suggested me a catchy description: "Pick your preferred messaging channel so friends contact U the way U choose!". Hopw it will catch.
Since the app is free, I don't see a reason for people not do download it. However, I still need to find a way to get to all those people. That is one of the reasons I wrote this post in English. I hope it will get some traction from  readers or bots. I am still looking for ideas how people will see my app in the market. If you have any, I will be glad to hear...
It is also a bit difficult to explain what the app is doing. A blog post is a great place to do so.
So here are some links:



להוסיף לביטורמה

יום ראשון, 22 בינואר 2012

תאימות לאחור

בתור מתכנת, תאימות לאחור היא עניין מעיק אשר מצריך מאמץ נוסף למימוש של פרוייקט תוכנה, ולעיתים סותר את הרצון להתקדם ולשפר את המוצר. האם זה שווה את המאמץ?
בתור משתמש הייתי מעדיף תאימות לאחור ברמה הגבוהה ביותר שניתן. בצורה שכל כפתור נמצא איפה שהיה בגרסא הקודמת וכל פונקציה ישנה קיימת במערכת.
אין ספק שיש מתח בין שני הצדדים. ננסה להגדיר קודם כל את סוגי הממשקים ואת התאימות לאחור שיכולה להיות בהם.
אבל קודם כל אני רוצה להגדיר מהי תאימות לאחור, או לפחות לצטט מוויקיפדיה: נאמר על רכיב שהוא תואם לאחור, אם הוא מספק את כל הפונקציונליות של גרסה קודמת של אותו רכיב. ואם להקצין ולהיות יותר פילוסופי, אז רכיב שהוא תואם לאחור בצורה מושלמת הוא בעצם אותו רכיב בדיוק, כי גם ההתנהגות שלא היתה קיימת בגרסה ישנה היא חלק מהפונקציונליות של הרכיב.
אז אלו סוגי הממשקים שאני רוצה להתייחס אליהם:
  • ממשק משתמש (HMI)- אמצעי קלט ופלט הפונים לחושים שלנו. תאימות לאחור בתחום זה יכולה להתבטא בעיצוב גראפי זהה או דומה, בכיוון הגלגלת של העכבר או בהשמעת מסויים צליל בתגובה לארוע מסויים.
  • ממשק או פרוטוקול בין מערכות (MMI)- אמצעי תקשורת בין רכיבים אשר תוכנתו לכך מראש, לעיתים אותו מוצר שאמור לתקשר עם גרסאות ישנות יותר שלו, או רכיבים שנוצרו ע"י אנשים או חברות שונות. תאימות לאחור אומרת שהרכיבים יצליחו לפעול בסביבה בה יש רכיבים מגרסאות ישנות יותר.
  • ממשק לכותב תוכנה (API)- בדרך כלל ההתייחסות דומה לפרוטוקול בין מערכות כמו שמתואר לעיל אך פה אני מתכוון באופן ספציפי למקרים בהם אין מערכות נפרדות, לדוגמא כאשר משתמשים בספריות צד-שלישי בכתיבת תוכנה. במקרה הזה אם תרצה להיות תואם לאחור (בתור כותב ספרייה) תוכל להוסיף פונקציונליות חדשה אבל תתקשה לגרוע או לשנות התנהגות קיימת.
  • מידע ונתונים - בהיבט הזה מתייסים לתאימות כך שהמידע שהמערכת השתמשה בו הגרסא ישנה יהיה שמיש בגרסאות חדשות יותר. הפשרה המקובלת בחלק מהמקרים בהם רוצים לשבור את התאימות לאחור בתחום זה היא לבצע "upgrade" בשדרוג לגרסה מתקדמת.
אז נחזור לנקודת המבט של המשתמש. כדי להישאר באזור הנוחות שלנו, נרצה לשמר כמה שיותר מההתנהגות הקיימת כאשר נהיה מוכנים "להתפשר" בתמורה ליכולות חדשות שאנו מקבלים. כדי לשמר את המשתמשים שלי אני ארצה לשמר את ההתנהגות - אלא אם הם אוהבים הפתעות. בקיצון השני אם המשתמש הוא שבוי ויהיה חייב לשדרג ללא אפשרות לנטוש את המוצר למתכנת יש חופש לשינויים מרחיקי לכת.
בעוד שבעבר חברות כמו אינטל ומיקרוסופט צברו פופולריות בזכות רמה גבוהה של תאימות לאחור, היום רואים דוגמאות רבות יותר בהם מחליטים בחברות מחשוב גדולות כמו פייסבוק גוגל ואפל לא לשמור על תאימות לאחור.
גם אני מאמין שהכיוון הזה הוא יותר מאוזן ומאפשר לבצע שינויים, לתקן טעויות הסטוריות, לתת חופש יצירתי, גמישות ולהמנע מריבוי אילוצים שעלול להוות עול בהמשך. אם הכל היה מושלם מההתחלה, לא היינו צריכים לעשות שינויים. מכיוון שמערכות תוכנה הם מוצר דינמי ומתפתח אנו נדרשים לעשות שינויים. השינויים האלה עלולים לשבור את התאימות לאחור. אך אם הכיוון משתנה, אני מעדיף את האפשרות הזאת על פני האפשרות להשאר עם דבשת. תאימות לאחור אינה מקודשת וצריכה להיבחן בראי התועלת שהיא מביאה.

יום ראשון, 18 בספטמבר 2011

LiftMe - day 1.

בקבוצה שלי אנו עושים מידי פעם שבוע טכנולוגיה. הרעיון הוא להתנתק מהעבודה השוטפת ולחשוב על רעיונות חדשים או טכנולוגיות בהן אנו רוצים להתנסות, ולממש אב טיפוס עובד. מסגרת הזמן היא שבוע, שבסופו נציג את התוצאות.
החלטתי להתנסות בכתיבה בשפת סקאלה. מכיוון שאנו כותבים בג'אווה, זה נראה כיוון מעניין להתנסות, לא יותר מידי רחוק ממה שאנחנו עושים, אבל עדיין תכנות פונקציונלי והתרעננות עם שפה חדשה.
על הפרוייקט שנבצע השבוע אנחנו עובדים בקבוצה של 3 אנשים. במהלך השבוע ניצור אפליקצייה שתעזור לאנשים לתפוס טרמפים עם חברים לעבודה. אני אנסה להסביר את הרעיון באופן כללי. אני עובד בחברה גדולה, ויש הרבה אנשים שמגיעים לעבודה עם רכבם הפרטי\ליסינג. אני מניח, שכשהם יוצאים מהעבודה לא תהיה להם בעיה לקחת מישהו טרמפ אם הוא לא מעכב אותם וזה במילא בדרך. הבעיה של אנשים שצריכים טרמפ (שאני במקרה גם לפעמים אחד מהם) היא שחוץ מלשלוח מייל לכל העובדים בחברה ולשאול אם מישהו יוצא בקרוב לעבר היעד שלי אין לי דרך טובה להשיג את המידע הזה. שליחת מייל כזה היא לא רעיון כל כך טוב, מכיוון שזה מציק, בעיקר עם כל מי שצריך טרמפ יישלח מייל כזה.
המערכת שאנחנו נכתוב, תהיה בעצם קישור בין האנשים. נניח שאני מעוניין לצאת בקרוב הביתה. אני נרשם במערכת (שנקראת liftme) עם מס' הטלפון שלי והיעד אליו אני מעוניין לנסוע. ליד הכניסה לבניין יוצב מסך מגע עליו תופיע רשימה של כל היעדים אליהם ביקשו אנשים טרמפ. כל מי שיעבור ליד הרשימה, יוכל בלחיצת פשוטה על אחד היעדים, להודיע שהוא יוצא לכיוון זה. בינתיים הוא יירד במעלית לחניה (יש אצלנו חניון). לאחר שבחר את היעד יישלח מסרון למי שהזמין את הטרמפ, עם מס' הטלפון של הנהג, הוא יוכל להתקשר אליו ולחכות לו בשער החברה.
זה הרעיון בגדול. אנחנו מתכננים לממש אותו עם scala/lift ומכאן גם משחק המילים של השם.
בהמשך אני אעדכן איך מתקדמת העבודה:
יום א: הכנו את סביבת העבודה שכוללת svn,eclipse,scala,lift וגם קצת maven. בסופו של דבר השתמשנו בעיקר בהוראות כאן. הדבר העיקרי שבילבל אותנו הוא הגרסאות השונות של סקאלה שלא תאימות לאחור. בנוסף חלק מהפעולות ארכו זמן בלתי סביר של כמה עשרות דקות בשל הורדת קבצים מהאינטרנט. נקווה שבהמשך ייתבצע caching ולא נאלץ להמתין. בינתיים החלטנו לעבוד על windows ולא על linux. ההתרשמות הראשונית מהממשק של סקאלה ב eclipse היא שהוא סביר אך לא נעדר באגים.
יום ב: הכנו שלד בסיסי של האפליקציה, מאמין שבעוד יום הוא כבר יהיה יותר סגור. כולל שני דפים עיקריים: בקשת טרמפ, ומסך טרמפים נוכחיים. עשינו קצת unit tests. אני עדיין לא מתחיל לעכל (ולהנות) מסגנון הכתיבה בסקאלה. בינתיים הוא מרגיש מאוד loose. התרשמתי מאוד לטובה מרכיב ה-comet. מה שהשתמשנו בו עד כה היה ממש כמו קסם, מעט קוד וביצוע קליל.
יום ג: סיימנו את השלד הבסיסי. כיף לראות שניתן לבצע דבר כזה, בתחושה שלי, בקצב מהיר ביותר גם ללא היכרות מוקדמת.
יום ד: המשך עבודה על עיצוב המסכים השונים ושפורים נוספים כגון טיפול בשגיאות וולידציה. ביטול של database שמגיע ביחד עם ה embedded jetty באפליקצייה השלד שלנו האיץ משמעותית את זמן עליית השרת, ועוזר ב-debug. ההרגשה שסביבת העבודה מאוד נוחה ל debug, למרות שלא הצלחנו עדיין לראות את כל הלוגים. בסביבת הפיתוח נתקלתי בקשיים לקרוא ולפענח את תאור שגיאות הקומפילציה. מכיוון שאני לא מכיר את השפה יש לי יחסית הרבה שגיאות תחביר, וחוסר היכולת לפענח אותן במהירות מוביל לתסכול. בנוסף, חבר לקבוצה הביא ipad2 עליו נציג את המערכת, אין ספק שזה משדרג את האפליקציה, ובכלל נראה מוצר מגניב.
יום ה: המשכתי את העבודה על העיצוב לבדי, והגענו לסוף השבוע עם אבטיפוס שלם. בהמשף, בנוסף לשיפורים נוספים שייעשו נתמקד בנסיון לבצע פיילוט של האפליקציה בבניין שלנו. נראה את השימוש האמיתי שנתבצע, ואני אוכל להבין האם ה use case עליו חשבתי מראש מעשי וישים.