I do love to write, and the personal musings I put out onto the web from time to time might be fun, but I want this blog to be about technical matters. I hope that I'll learn something, and perhaps the things that I post will help someone else.
I've written about my love of swimming in the past. Since 1994 I've kept an electronic journal. I create a new Word document every month and write as often as time and energy permit. Each one includes an embedded Excel spreadsheet where I keep track of the number of trips I make to the pool and the yardage for each workout. I used to only swim at noon, 1800 yards at a clip. In 2000 I worked up the courage to swim with a Masters group for the first time. These workouts tend to be longer and more intense, so after 2000 I started breaking out Masters and noon workouts. At the end of each year I roll up all my yardage to see how I did.
2007 turned out to be an average year, in spite of my C6 disk problem. I had three months (Mar, Apr, and May) where I didn't swim at all, and I was still limited in June. By August I was back swimming with my Masters group. The last four months of the year were my best ever. I think that seeing the yards pile up and having a chance to get back to "average" were great motivations for working hard and not skipping workouts.
There are only two problems with this system.
The entry into Excel every month is very manual. I copy & paste the embedded spreadsheet from one month to the next, which is a bit of a pain. I manually transcribe the data into a second Excel spreadsheet that I use to roll up results and display lovely plots of yardage versus time. This is error prone and time consuming.
I would love to be able to index all those journal files with a search engine like Lucene. I have fourteen years of my life stored in Word files, and sometimes I find myself wondering when a particular event happened. I'd love to be able to type some search terms into a UI and have it return a list of files and dates when those terms appear. Since Word is Microsoft-proprietary I have to rely on a library like Apache's POI to read and parse the documents for indexing. Alas, the embedded Excel spreadsheets gum up the works. I get an exception when I try to read my Word docs, and POI isn't a very active project these days. There's a bug reported, and a promised fix, but it's been years since it was first posted. I won't hold my breath waiting.
So I'm proposing to write a swim tracking application for myself. If done correctly, this will give me more capability. As a bonus, I'll be able to remove those embedded spreadsheets and index my electronic journal files. That'll be another fun application to write!
I'd like to use technologies that I love and am familiar with, but would like to know better: Java 5, Spring, Hibernate, and MySQL or PostgreSQL for the relational database. I'll deploy on either Tomcat or WebLogic.
Should I think about an embedded database like Hypersonic? It'd be great to have a SourceForge or Google project that would allow someone to be up and running with a minimum of effort. If I follow that thought to its logic conclusion, should I also bundle it with Jetty? I'd like to have the lightest weight app server possible. Spring makes it possible for me to do robust Java EE development without EJBs, so that helps.
The user interface will be either straight JSPs, using JFreeChart for graphics, or Jasper Reports.
I'll use IntelliJ as my IDE.
I'll set up a Subversion repository for my source code.
Like any good software project, I'll start with my requirements.
Are there any good commercial or open source alternatives worth looking at? A Google search on
"swim tracking software" tells me that there are some low-cost commercial programs available:
Swim Shark,
Jack Rabbit Swim, and
Swim Log. But there are no open source alternatives out there. Maybe this will be a good niche for me.
I wouldn't mind stealing a peek at what they've done to see if I could duplicate any neat features. UI design isn't my forte, so having a few thoughts about how to lay things out might help, too. But the journey is as important as the destination, so I'll still be writing this myself.
This is a swim tracking database, but I could see where it might be possible to extend this to all sorts of activities. What about cycling? Running? I'm doing yoga on my own now. What if I had a nice calendar control to show me how frequently I was keeping up with daily yoga? Wouldn't a goal of 3-4 days per week be helped along by seeing a calendar tracking success? There's nothing like a string of "no yoga" days staring you in the face to motivate better effort.
I'd like to write it for multiple users. My daughters are both athletes, so maybe they'd like to track progress on their workouts. Security will be an issue. I'll have to have roles for different users and administrators.
I had a choice when I started tracking. Would I keep book yards on a monthly or weekly basis? I decided to stick with a weekly basis. The week ends on Sunday, because most of the swimming was done during the work week. If Sunday fell within a given month, that week would count against that month's totals. So a given month might be credited with four or five weeks of swimming, depending on when the Sundays fell. Would I continue with that system? Or should I switch to a true month accounting? It makes a difference when determining personal best yardage totals for a given month. Having a real relational database might give me some flexibility there.
So I account for total number of visits and yards each week, with a special tracking for Masters workouts and yardage. I'd like to keep that breakdown.
I've hit a lot of pools in the state. Most of the time these are 25 yard pools, but there are happy days when we're allowed into the 50 meter pool at the University of Connecticut. Unfortunately, those opportunities are rare. We haven't had a Masters workout in the big pool in years now. Should I maintain units, too? Or just leave everything in yards and convert in the UI when necessary?
I only keep track of total yards, but swimmers know that a workout can consist of different sets. Masters swimmers usually do all four competitive strokes in a single workout - butterfly, back, breast, and freestyle. Should my database allow me to break workouts down by set? Keep individual times? This is what a real coach would probably want. Maybe a database of workouts would be worth having. I could associate a given day's swim with a particular workout that way. It could be useful.
The payoff comes with the plots and reporting. I like knowing what my best total yardage is for a given month. So far in 2008 every single month has been either my best or second-best for total yardage. Sometimes I might feel tired in the morning, but knowing that I'm close to a best monthly total is all the incentive I need to get out of bed. I have plots of yardage versus month for each year, along with an "average" year curve. I could supplement that with theoretical curves for best and worst years, keeping track of all my milestone monthly totals.
Should I use a relational model, or explore a data warehouse-like star or snowflake schema? I'll have to think about what the pertinent dimensions should be. Since this is mostly a reporting database, there might be some advantage to going that way. I'm not sure how objects and Hibernate work with data warehousing schemas.
That's enough to think about for now. I'll have to see if Blogger allows me to post UML diagrams. I'll flesh out the design a bit more soon. But this is a fine start.
Posts
