Podcatcher - Requirements

One of the goals I set for myself in the New Year was to gain experience with Lean/Agile software development. My test project will be a fairly simple podcatcher to manage the podcasts I listen to. Here is the initial set of requirements for this tool...
  • Subscribe to podcasts (obviously). All of my current subscriptions are RSS, so I'll focus on this first. Once I have something functioning, I'll add support for Atom feeds. It will also support importing OPML files. This is the format exported by iTunes.
  • I currently use iTunes to manage my podcasts and the default is to retrieve the latest podcasts on startup. This is OK if you generally listen to all episodes you subscribe to, but for some subscriptions, I like to pick and choose the shows I want to listen to. I know this behavior is generally configurable in iTunes, but I'm not sure this can be individually configured per show. The default behavior for my podcatcher will be to download only show descriptions, with the option to automatically grab the latest shows. This will be configurable by show.
  • Ability to set the genre (or other metadata) for the shows. This will provide a greater ability to automatically group shows I'd like to listen to.
  • Playlist creation - a manual way to group shows together for listening.
  • Allow the creation of a "favorites list" with user notes or labels about the show. This will offer a way to bookmark the URL of favorite episodes along with some notes and tag information. If you want to relisten to an episode at a later time, the episode can be easily downloaded again.
  • I'd like the podcather to "live" on the player (or any portable storage device). I've switched computers a lot lately and each time I import my OPML file into iTunes, I've needed to manually check for new episodes not downloaded by another iTunes installation. Also, since I've never had an iPod, syncing with the player has always been a manual process. By living directly on the mp3 player, these synchronization issues won't be an issue. Even when switching mp3 players, the podcatcher software can be simply copied between players. This requirement requires that the software footprint be as small as possible.
  • And finally, delete podcasts (including descriptions).

I guess that's it. On the surface this looks like fairly simple and straightforward project with a useful set of features. I think the next "Lean" thing to do is to prioritize these requirements and set the minimum criteria set needed to meet these requirements, but I'm going to start reading to verify this approach.

Comments

Post a Comment

Popular posts from this blog

I Believe...

A recent reorg at my company left me with a new manager - and a different approach to software development than my team had been previously following.  Our new approach is one that I don’t necessarily agree with, but it led me to think about - and reevaluate -  those tenets of software development that I think are important and that I believe lead to increased quality and productivity. This post will consist of fairly high level discussions about how to organize code, teams, and projects - but contain very little actual code. Many of these ideas will not be my own.  They are mostly ideas I’ve learned from others and their willingness to share their experiences with me.  They are, however, ideas that I’ve practiced and hardened as I’ve worked to build my own ideal environment for delivering value through software . Many of these ideas I now take for granted as commonplace (even though they aren’t).  I felt a need to document them anyway - so people can understand what to expect (a
Read more

Performance Tuning JCAPS - Part 2

It's been close to 2 months since my first Performance Tuning JCAPS post. Since then, we've noticed our servers running out of TCP connections under heavy load. Researching this problem, we learned that the JCAPS' JMS server makes heavy use of TCP in implementing Request/Reply queues . We approached Sun for guidance and they assured us that they've had success implementing high throughput applications using the JMS request reply solution... but how? It appears a multi-step solution is needed. First, running out of TCP connections in a scenario like ours is a JCAPS bug addressed in an ESR (110348) and rolled into JCAPS 5.1.3 Update Release 3 . We installed this update and noticed a marked improvement. Running my simple 75 user simulated test, transactions took 2521 ms to round trip (compared to the previous time of 20128ms). While this is great improvement, an average of 2.5 seconds is still really slow for this simple transaction. We reported our findings to Su
Read more

FRail :include

I really like developing with Rails, but I've been frustrated the last few days by some things Rails should do quite easily, yet doesn't. I've already written here and here about some of my struggles with Rails :include clause. Here's one more... Let's say you have a has-and-belongs-to-many relationship. If you :include this relationship in a find query, Rails will automatically create the join clause including the lookup table! That's cool. Unfortunately, it looks as if only the :include clause provides this piece of functionality. Why isn't the same functionality provided via the :join clause or through a general purpose module? This doesn't make any sense to me! I'm working on a database application where I don't need to display a lot of data, but the data displayed is heavily filtered by it's connections to other information in the database. I need to join a lot of tables to perform the filtering operation and using :include
Read more