~ryanlowe/blog: Project

Project

I don't really need an excuse for a project now, I have to do one to graduate. It looks like we'll be three people. Having a group that small has its own set of problems - development software is usually designed for teams or projects that are bigger, and you don't want to bog down your project with process. Process is for teams that are so large its hard to watch people to make sure they don't get off track. With three people, you can see that easily.

I like the idea of an agile method, not XP or RUP per se, but somewhere in the neighborhood. Small iterations (one to two weeks), unit testing (maybe test-driven design), stories. Let the project grow into something it wants to be (or the customer wants it to be) instead of dictating that completely at the beginning. Not committing to too much UFD (up-front design).

These agile methods are all about managing risk. On a project like this the risk isn't lost money, it's lost time. Having short iterations means you only have to plan an iteration or two ahead. Hopefully we can find some good customers, but that will depend on the project we choose.

Tools I'd Be Interested in Using

Bugzilla on a limited basis. I don't want to get too bogged down with it, however. If it's too big, forget it. We need a simple feature request (story) and bug tracking system.

XUL looks interesting. If we made an application, wouldn't it be nice if it looked exactly the same on 17 platforms? What is up with Mozilla as an application platform?

CVS or some other open/free CMS. We could run this on the same box as Bugzilla so it is available to us anywhere. Tack on a backup plan for good measure.

As for platform and language - well, that will have to be decided with the project itself. Factors might include:

- Familiarity with languages used
- Familiarity with platform API
- Complexity/scope of platform API
- Software tools required (and possible costs) for the language and platform
- Ability to work on the project anywhere
- The language and platform's suitability for solving the problem!

I'm leaning towards Java. We weren't trained well in C++ or the .NET platform languages (C#, VB.NET). Performance may take a hit, but not much. As a side bonus the application may actually compile and run on more than one operating system.

Project Ideas

1. An instant messaging client that implements a published protocol (ie. MSN)
2. A digital music (mp3, ogg) management system
3. An ftp server with user/permissions management

Posted at October 22, 2002 at 07:57 PM EST
Last updated October 22, 2002 at 07:57 PM EST

Comments

I still don't know about group size, but we will find that out.

As for tools, I would say we should use Tortoise CVS [http://www.tortoisecvs.org/]. It is a Windows tool for CVS. I like it.

I don't really know about what feature / bug tracking sw we should use, but we NEED one. ;-)

As for languages, I would go with Java too... doing the GUI's suck A$$, but for how many problems C++ can give, I would go with it too. And I KNOW Karen will say we should use Eclipse [http://www.eclipse.org/] (since that is what she is working on right now and she loves it!)

As for project ideas, right now I am drawing a blank. But that'll clear up.

;-)

» Posted by: Jimbo Jones at October 22, 2002 09:27 PM

Well, we don't *have* to use eclipse ... although they do have decent CVS and debug support (in *my* opinion :P )... I sure understand how to work with it better than I ever will with JBuilder. Having said that, yes, I'd like to do it with eclipse :)

One idea I'll throw out: we may be able to do our project as a plug-in for eclipse. The GUI stuff would be handled with SWT and jface; plus I've been learning a lot about how write plug-ins.

If the plug-in idea doesn't fly, I understand that the UI team is working on support for ppl writing stand-alone apps with SWT and jface. That's the team that I'm working on, so I could find out more. I think the infrastucture may be in place now actually ... At least we wouldn't have to work with Swing or AWT, they very thought of which make me shudder.

» Posted by: Karen at October 23, 2002 08:55 AM

What kind of plugin do you have in mind? Personally, I find development software boring. :) Yes, I know where I work.

» Posted by: ryan at October 24, 2002 12:36 PM

Well, I don't have any spedific ideas for what kind of plugin, but the framework may work with some of the ideas you've presented (I'm thinking of the digital music management system)

We'd need some way of entering information, querying information and displaying query results. Many of the building blocks to do this sort of thing already exists in eclipse, such as editors, wizards and tables. Not to say we couldn't do these things without using Eclipse, but it may be a jumping point.

Plus, think of how convenient it could be ... you're plugging away at your code, and think of a song you want to listen to ... you don't even need to start up a new app or alt-tab over, just hit a few shortcut keys, search for the song and a player will be launched. All within the same app :)

» Posted by: Karen at October 24, 2002 02:32 PM

Just wondering, has anyone heard from Brad? I still don't know how this project thing works. Do we really have control over the project that we are doing, or do we have to choose between certian ones? I heard that at least two groups have to work on a project... that might sink us if we have an original idea *gasp!*

As a user, if I was using a dev. program, I would MUCH rather alt-tab to another program and use that (i.e. Winamp) rather than hitting a few shortcut keys. (Well, I'd be hitting shortcut keys, but ones that I already know and I could use to get to my music from any app, not just the dev. tool.) But, hey, that is me. ;-)

» Posted by: JimboJones at October 24, 2002 04:28 PM

Eclipse is a lot of overhead for something simple like a music application. Unless our application was used for development in conjunction with Eclipse I think we'd have a hard time justifying the plugin on the Eclipse platform, even though it is free. It would also limit our minimum system requirements. You have the right idea though -- I think we should use technologies that let us focus on more high-level software engineering parts and less on sticky details.

As for control, as far as I know the only requirement is that we need a customer. This is an important factor. If we make a COTS product, our customer base is potentially much larger. If we make a developer tool, our only pool is developers - who may not have time for regular meetings.

This project is starting to look complicated. It's a good thing we're getting a two month head start.

» Posted by: ryan at October 24, 2002 06:25 PM

Good point ryan, eclipse does have a lot of overhead and the link between developers and their music needs was a bit of a stretch :P ... I won't be heartbroken if we don't end up doing the plugin idea, I just wanted to throw the idea out there.

Do we have any other ideas of what other technologies we could use so we don't have to focus on icky details? I glanced at XUL but i'm not too clear on it yet, is there anything else out there?

» Posted by: Karen at October 25, 2002 12:15 PM

To tell you the truth, I'm not to clear on what it can do either, or what we need to use it. See Oct 27th post, I'll put up a few links I've found.

» Posted by: Ryan at October 25, 2002 12:48 PM