I know this won't be the first one out there but I think it will make a nice personal project. I've spent some time thinking about what technologies I want to use and have decided to leverage my Java and Spring MVC knowledge rather than learn something entirely new. I will still need to learn new technologies like jQuery (currently use Dojo) and MongoDB (currently use Oracle) among others.

My end-point goal is to deploy a mobile web application to the Cloud. I want to have full coverage testing of the codebase and want to keep the codebase in an online repository.


Here is the current technology plan:


Database: MongoDB
Framework: Spring Roo (Java)
Front End: jQuery for Mobile + HTML5
Cloud Deployment: Spring Cloud Foundry
Repository: GitHub


Major Milestones:

1) The first major milestone will be to deploy a RESTful Web Service which delivers up-to-date MLB starting lineups and rosters in JSON. Ultimately the scorekeeper application will consume this data.

2) The second major milestone will be to deploy the scorekeeper application.


I would like to use this thread to contemplate major design questions, technology questions, and to track/discuss progress.

So first off would like to hear if people think this is a good idea for a project to show to prospective employers, and also if I'm making any kind of major mistake in the technologies (i.e. - suitability for future employment).

Where are you going to get the data? Every sports data source I've found to be extremely expensive.

I was just planning on scraping starting lineups and rosters from a web site.

Do not base personal project selection based on impressing employers (or others). Pick a project you are passionate about and motivated to finish. Finishing a project and talking about it passionately will impress people more than the content/subject.

It sounds like that's exactly what he's doing. It still makes sense to pick the best technologies for the job.

To be honest, I'm not super passionate about the application itself.

If I was going to develop an application that I had a real passion for it would be a homebrewing recipe generator. I strongly considered doing this, but I believe it would be a lot more complicated and take a lot longer to develop. I would also need to secure permission from the American Homebrewers Association and/or BJCP to use their style guidelines in the app. (Although that's probably not much of an obstacle since so many different apps currently exist they must give permission fairly freely.) Another issue is tracking down a complete source of all the information for barley, hops, etc. for all the different suppliers. (The same basic ingredients can have different values which affect recipe formulation.)

Also, not sure I want potential employers to know I have such a passion for beer! Probably not much of an issue but you never know.

Anyway I still think the current app will be fun to develop and quicker. I have pretty strong reason to believe I'm going to be unemployed by the end of July so it would be nice to at least get the web service piece of it up fairly quickly.

I need to wipe my home system and rebuild my development environment before I get started so I'll consider this some more before starting development.

If your reasoning is to build some projects to show off when trying to get hired, then go for it!

Any app that you would think would be fun to make is worth making for your resume.

You can always save the Amazing app idea for a hobby project when you're working at a nice place.

So I've been doing just a few things so far and might change course slightly.

I wiped Vista off my home machine and installed Windows 7 but now I found out MongoDB doesn't work on Windows 7. I'm either going to switch to a relational DB or possibly partition my disc and put some flavor of Linux on it. That could slow me down though (never used it) so not entirely sure I want to go that route, although the learning would be valuable.

The current plan is to scrape lineups and rosters from a website with jsoup. I think what I will do is wait until I get a request for a lineup, check if it's persisted already, if not go out and parse it (if it's available), return it to the calling method and persist to the db. That seems better than having to parse it every time I get a request.

Will have to figure out how to handle double headers, and also bad calls like if someone wants the lineup for the Sox for a given day and they're not playing that day. Not sure what to pass back to the service consumer in that case when they are expecting a response (json or xml or html depending on what they ask for in the header) with a lineup.

Going to search and see if there are any conventions for web services to handle situations like that other than just sending back an HTTP error code.

I would expect that the message you send back would have a success value along with any data as a parameter. This will let you give information about what failed "Brown Sox not a valid Team" or "White Sox not playing this day", etc...

Anyway, I am interested in what you get going, I am going to try to do a distantly similar idea for a side project, I need to get a web service up and running and need to use Java on the back end, so I might be able to learn from what you do.

I do something similar with college football (I can give website if it's not considered spam) for parsing. I parse the pages, and store it locally in a db. This is much faster, especially when you need any kind of analysis. I don't do on-demand parsing or anything, but that's a good idea. I did run into issues with consistent data on external websites (I parse the NCAA's site and sometimes when you look at Team A and Team B's pages, they'll have completely different stats (and sometimes scores!) for games against each other. It's usually lower division teams, so MLB should likely not have this issue.

As for hiring, this can never hurt you. I've used my football site as proof of skills before, talked about interesting parts of it I did (mine has a ranking component that dynamically builds SQL so I can change the ranking algorithm easily and not have to manage tons of SQL changes).

Good luck!

Thanks Tom - good info.

I'll definitely keep this thread updated. My plan was to make a lot of progress last week (got laid off last Monday), but as it turns out I had a surprisingly large number of things to do due to the layoffs and I didn't get a chance to even look at this project.

Tom this video might be useful to you: Designing a REST-ful API using Spring 3