Its the last night of 2015, I have a drink of the alcoholic type origin and its time for me to write my annual post reminiscing about this past year. And quite the year it has been. I’ve said in past years that odd-numbered years have had quite significant changes for me. Last year was an exception, with a change in employer, but that only barely squeaked in toward the end of the year. This year set the pattern back on track, though.

In the last year, I think the most significant change in my life was the purchase of my first home. After just over 5 years, we moved out of our first apartment. Though it took me a while to get used to driving to a new place, I was (and still am) very excited to make our new place our home.

However, I should mention that it was not the only thing that happened this year. It was also a year where I felt I made a significant impact on things at work. This past year I have worked hard to find ways to improve the Interface Engine that I work on at work, and felt that I have made some pretty sizable contributions on that front. I’ve also been working hard with my colleagues to improve customer relations in regards to the Interface, and feel that we have made very big improvements there.

Most of this year was filled with work. But for the first time in a very long time, I don’t feel exhausted. In fact, I actually feel empowered and excited to work at PatientSafe. Working with people who are truly talented, who truly care, I feel like I’m doing what I’ve wanted to do - help people through code. But I have also tried to balance my dedication at work with significant quality time with my family, as it finally has made sense that without the balance, my life is difficult and depressing.

Well, at this point, the alcohol is being overly effective in relaxing me on this eve to 2016, and it is now making it difficult to think clearly into this past year. With 2 hours left in the year, I think its time to git commit this and enjoy the remaining time with family. Maybe next year I’ll actually post more technical stuff, like I said I would. Until then, Happy New Year!

Since I purchased my first Android device, the much-loved Nexus One, I have had a desire to build and distribute my first app for the Android platform. Unfortunately, with each attempt on starting an app, I ran four of the most difficult roadblocks for a hobbyist developer: getting an idea for an app, finding the time to work on an app once an idea was found, not getting into paralyzing infinite loop of restarting the project each time the platform changed, and feature creep.

Finding good app ideas was never a hard thing for me, but finding one that I could work on in a short period of time and had a small scope that a single hobbyist developer could work on was another. Though I am certainly an experienced Java developer, working with the Android platform in itself has a small learning curve. Moreover, the ideas I had usually involved some sort of webservice as well, complicating the project in many ways. Questions like “What framework should I build it with?” and “What sync mechanism should I use?” to “How much is it going to cost to host this service?” and “What should I do about securing user data?” swam through my mind. The complications made the walls steep, and the first lines of code had not even been written yet. These questions usually discouraged progress, even though most of the answers to the questions were “Who cares? Deal with it later.”

However, there were other times when I came across ideas for self-contained apps that were fairly simple. I’ve repeatedly had one such idea, which essentially was a way for me to stop using Google Forms to track some information and use an app instead. It had a well-defined scope, and allowed me to explore some of the most important parts of the Android platform. But after starting the project, making some progress, and pausing to spend time on the other things that my life demanded my attention on, I found it difficult to go back to the project and continue where I left off, mainly for my third roadblock.

Whenever I had time to return to my app projects, Google released a new version of the Android platform. In earlier versions (pre-Honeycomb), this usually wasn’t a big deal since a lot of the changes were enhancements to the platform. However, after Honeycomb, there were a lot of UI-related changes: Fragments, Holo, then Material. I wanted the UI of my app to look-and-feel like it belonged on the platform. Rather than try to refactor the current code (which wasn’t much), I figured I’d restart the project, using the new paradigms from the beginning. This caused me to restart the project quite a few times.

Then, with each platform update, I got more ideas that could be put into the project. And with each idea, I’d stop what I was doing and start on the new idea. Sometimes, the new ideas were changes to things that I had already done, causing me to rewrite pieces over and over again. Feature creep and refactoring hell were my enemies at this point and my projects were caught in a state of perpetual “IN PROGRESS”.

It actually became a joke for me. I had been a part of the San Diego Android Developers Group for many years, practically from its start, but I hadn’t finished a single app. Long-time members of the group knew me and knew the problem I had. It was’t a technical problem, just a PEBCAK one. However, this past November, an app idea was sparked in me, with a small scope and with such limited UI (read: almost none) that it was nearly impossible for me to get caught up in the vicious stagnation cycles that paralyzed me in the past.

The idea stemmed from an annoyance I had with my fiancee’s sister’s (let’s call her A) use of Instagram. Since she had a tight-knit family and I was a part of it, I wanted to be involved in family (having known her sister since they were pretty young). The issue was that A wanted to keep some pictures she came across on Instagram. In order to do this, she would reshare the original post, open the image and screenshot it, then delete the post. However, because I had post notifications for her, I’d see a post notification pop up on my phone, but when I tried to open it, Instagram would complain that the post had been deleted. It was rather annoying.

I also felt it was pretty annoying that Instagram didn’t have a facility to save images to the device - but there were ways. I had had enough of the annoying notifications (she is a teenager, so you could imagine the volume of notifications I would receive), but didn’t want to sacrifice not receiving the notifications for her. So, after doing a little bit of research into the capabilities of the Android platform, I found a quick solution that almost required no UI. After one spending some time one Saturday coding it up, I had not only a working prototype, but a nearly-finished app (yes, the requirements of the app were that small).

I finished the app, and knowing that in order to distribute updates to the app I needed to use the Play Store, I published my app (at the time of writing this, the app is in public beta) so that when I fixed problems or added features, she would automatically get them on her device. Unfortunately, the original name of the my app was already taken (ironically enough by another app that did pretty the same thing mine did), so the first submission was rejected by Google. However, after renaming it and retrying, it was accepted as Keepagram and published.

So, that’s the long story behind my first app, Keepagram. It is embarrassingly simple, and in no way a shining example of the depth and breadth of my skills as as software engineer, but as someone who has been paralyzed by making my pet projects overly-complicated, I am very proud that after so many years I have finally been able to get something done.

If you’d like to join the public beta for the app, click here. I am definitely looking for feedback on it, so feel free to let me know what you think.

Over six years ago I wrote a post on my old Blogger blog about what I believed the exact middle of the year was. When I had written it, I remember feeling that the computations that I did were faulty since there was just something odd about the numbers I was getting.

Today, I remembered about my old post, on this year’s “Middle of the Year Day,” and wanted to revisit the computations that I used. Re-reading the post, the computations made logical sense, but, again, the result just felt wrong. Especially when you introduce leap seconds into the logic, things became much more murky. But then I realized something simple that I had actually accounted for, but was subtle and forgotten as you continued to read the post: the calculations that the exact middle of the year was made by grouping 4 years together, and dividing the four into equal pieces. Therefore, the calculation of the time of July 2nd at 15:04:34 is not “the exact middle of the year”, but rather the “quarter marker of the current leap year cycle”. In other words, on July 2nd at 15:04:34, we would be crossing another 25% through the current leap year cycle (in my parlance, a “leap year cycle” is every 4 years).

However, we do not usually look at the calendar and think about time in 4-year cycles. We usually subdivide time based on our non-scientific concept of a year, which means 365 days on a non-leap year and 366 days on a leap year. Thus, given this, the middle of the year - to the hour - is July 2nd at noon on a 365 day year. According to Wikipedia, we keep July 2nd at noon as the middle of the year on leap years too.

But, then there are timezones, so July 2nd at noon occurs at different times for different timezones. If you remained in the same timezone throughout the year, then the exact middle of the year would be July 2nd at noon for you, but if you were in Los Angeles and talked to someone in New York, you would find that they had their exact middle of the year 3 hours before you. To alleviate this discrepency across timezones, we could use a common timezone, UTC (or GMT), and just change the time for everyone depending on where you are in the world. Thus, if the exact middle of the year is July 2nd at 12:00 UTC, for myself living in the Los Angeles timezone, the middle of the year is July 2nd at 5AM (UTC-7 during summer time; or 4AM if you don’t take into account Daylight Savings, which is UTC-8). So, depending on how you look at time, you could celebrate the middle of the year at either noon or whatever time noon in UTC is in your own timezone.

So, six years ago, I sought to find the exact middle of the year, and over the last half decade, the concept of the “middle of the year” became complicated by leap years and seconds and timezones, and just the general perception of time. Though I may have missed this year’s crossing into the last half of the year, I feel better in knowing that I was wrong, because being wrong gave me the opportunity to look back at the question, and gave me the opportunity to evaluate my findings in a broader context.