In February I was contacted by Mercury, a company that I worked for five years ago, about helping them with a project. The contract would last three months and offered good pay. They caught me at a good time and I agreed to take the job, starting right after we got back from PAX East.
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. Continue reading “Contracting Job at Mercury”
Continue reading “Fair Dice Roller”
I have been using the PracticeLog for a little over a year now and have found it to be very useful. However, there are several features that I never use:
- 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.
- 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:
- Remove the list of pieces practiced per day. It would make the database more complex and I never use the feature.
- 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.
I have had an Android phone for a while now, and one of the reasons that I picked that particular phone was so that I could create my own applications without going through a central marketplace. Until now, I have never actually done it. The Android marketplace has had all the utilities and apps that I have wanted. But I’ve decided that I want to learn how to write software for Android and there is an app that I have always vaguely wanted and haven’t found.
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.