Beyond saying that it was not a government contract and involved writing a distributed message processing system in Java, I don’t really have anything interesting to say about the job itself. It was better than many jobs that I have had (except for the commute).

I was surprised by how easily I switched back into the work routine. It made me notice some of the things that are “hard” about being retired. Not that I am complaining about being retired – it is truly a luxury.

One thing that makes working easier than being retired is having a weekly schedule where someone else decides how I fill my time. It takes more energy to sit down and write this blog entry than it did to go into work every morning and do the tasks assigned by my boss. Part of the difference is that I don’t have to make a decision about whether to go into work each day, and another part is that I didn’t have to resist the desire to browse the internet or otherwise waste time.

It is also much easier to explain my “job” to people when I am employed. Having a job is easy to understand, and when I say that I am a software engineer it lets people make a bunch of (generally correct) assumptions about me. When I try to explain early retirement and game development, it takes a lot more time to reach the same level of understanding about what I am doing. It is also kind of interesting that it generally takes a lot longer for people to wonder if I am happy with a job, than with not working.

Finally, and most importantly, work provides me with a sense of self worth and accomplishment that is much harder to achieve when I am not working. Even if the job isn’t producing something that I would consider worthwhile, the fact that I am getting paid is enough of an accomplishment for the day to feel like a success. The bar is much higher when I am working on my own projects; just putting in time isn’t enough. I need to make real progress on something that I think is worth doing.

I have a feeling this sounds like I am complaining about being retired (the ultimate first world problem), so I want to say again that I love being retired and only took this job to buy some luxuries that I couldn’t afford on my retirement budget. But I was surprised by some of the advantages of working and wanted to share that experience.

One of the first board games that we played over and over was Settlers of Catan. We got a lot of enjoyment out of that game, but the more we played it, the more frustrated we got with how random the game could be. We almost always played with the random board, but the initial city spots could vary so much in quality that picking first could be enough to win the game. But even more frustrating than the randomness of the board was the randomness of the dice. It seemed like some games we would roll three sixes for every eight. In others we would have long streaks of fours or tens that could win the game for the player on those tiles.

To solve this problem with a game that we otherwise still enjoyed, we created a fair board builder and fair die roller. The board builder would try to make a board that was balanced for all the players and the fair die roller would try to even out the distribution of rolls within a single game. The first version of this program was in Java and Java Web Start. As Java and especially Java Web Start fell out of favor and I learned C#, I re-wrote the application in C#. The C# app was great, but could be a pain to install at friends houses before a game. At my last job I learned Flash, so I re-wrote the fair die roller and board builder in Flash. Now that Flash is falling out of favor, I have re-written the fair die roller again in javascript.

Like the other re-writes before it, this version has been a learning experience. I have programmed in javascript before, but for this application I decided to learn and use jQuery. jQuery has some great features and there is a lot to like, but I would have to say that this version of the fair die roller has taken me longer to build than any of the others except the original in Java. I am not an expert at HTML or CSS and I spent a lot of time fighting with the layout of the page.

You can check out my latest fair die roller here. You can also compare it to the previous versions in flash, c#, and java.

I’d like to eventually add the fair board builder. But for that I will probably try to learn the HTML5 canvas. We also don’t play Settlers as much as we used to, so that isn’t a very high priority right now.

1. The list of pieces that I am practicing. This would be nice to keep up to date, but even with the “Same as Yesterday” button, I just don’t have the motivation to keep entering the data.
2. The stopwatch and countdown. I haven’t been practicing in the same room as the computer, so it is not handy to have to turn on the computer both before and after practice time. Instead I have been using a stopwatch on my phone, or just my watch to time the practice and then separately enter the time.

I would like to use my Android phone, which I usually have on me, to record the practice time. To do that, I am going to create a web database and php accessors so that I can load and update practice time from the phone or computer. While doing this conversion, I am going to make a few changes:

1. Remove the list of pieces practiced per day. It would make the database more complex and I never use the feature.
2. Make the database multi-user. This will allow me to publish the application and Android app. I am not sure if that will ever happen, but the software has been useful for me, so it might be appreciated by others too.

This will be the first time I have made a multi-user web database, so I am debating how to handle security. I want each user to only have access to their own data, but don’t want the overhead of encrypting all the data.

After my experience with the DurationAlarm application, I suspect that the Android app will take most of the time. But all of the GUI elements that I will need are built in.

The app is a duration based alarm. This is a common way to set an alarm for a nap, but I would like to use the same system for an over-night alarm. Since I don’t have a day job, I don’t have to get up at any particular time, but I’d like to limit my sleep to the amount of time I need.

The application is simple enough to be a good problem to learn Android development with.

I have had bad experiences with Java and eclipse in the past, so I’ve decided to do all my Android development in a virtual machine. I used Oracle’s Virtual Box and an old copy of windows XP. While the Virtual Box software is nice (especially since it is free), this took a lot longer than I had expected. I had forgotten how old windows XP is and I spent hours installing updates. Installing eclipse and the android SDK went fairly smoothly and once installed, I was able to hook up my phone and run a sample app through the VM.

The Android SDK documentation is good, and the sample apps provide a lot of examples to follow and I was able to make quick progress on my program. The GUI builder is not bad, but I spent half the time editing the XML directly anyway. The hardest part was the lifecycle. It takes a while to get used to the idea that your program can be killed and re-started with very little notification.

The app took about three days of me working on and off. I was impressed by the Intent system which allowed me to easily use the built in alarm software to handle the alarm part while my app just does alarm scheduling. I was least impressed with the resource ID system and java in general. I have always disliked java and this project reminded me of all the ways that java makes my code ugly and my coding sloppy. There may be a better way to do this, but the default mode for the resource ID system makes all the GUI elements into global variables.

I used the local database to save off the user’s last alarm duration. Once I got used to it, that is a very convenient system. Much like what is built into C#.

I have no plans to put the completed app on the Android Market. It works fine, but I have no desire to test it on other phone models.