SoSE2007^@VTC

Iteration 5 has Nick and Boomer cleaning-up details. Nick has modified the hacked RTWho server to function as he needs; Boomer is working the WoW Admin GUI, especially for local XML database functionality.

One of the SoSE project's assigned deliverables is to compile and make available a Subversion How-To document. It's our great hope that this will not only assist VTC students to learn how to use this great source code management tool, but also provide faculty a means to incorporate this skill into the appropriate classes.

Lastly, some great news! Nick and Boomer are approved to continue working 15 hours per week for the entire fall 2007 and spring 2008 semesters which will allow WoW development and design to continue. You can imagine that I'm pretty happy about that, and so are Nick and Boomer :)

The fourth iteration is now underway. Nick is working on the local server that will use an XML database, allowing users to enter their own personal, private information. Boomer is working on the GUI client that will "morph out" when a user decides they want to add local, personal records.

Peter's hacked RTWho server bought us a good deal of time and provided an opportunity to explore different options. So, rather than writing a remote Java server for the fifth (and probably final) iteration, we've decided to take two weeks to clean up and put finishing touches where they're needed.

I'd like to use this post to show some screen shots of the work in progress:

• A graphic representation of our iteration planning; iteration 5 has changed (as noted above).
• The current WoW GUI user client showing a search result.
• The current WoW GUI admin client showing a record being deleted.

Nick and Boomer have completed and delivered the planned product of the third iteration: a functioning WoW graphic user interface (GUI) client that queries (Peter's hacked RTWho) server. Here are some points you should consider if you try it out:

• This client will only execute queries from within the VTC LAN, however, the program itself will still run.
• The downloaded ZIP should be unpacked into one directory -- the WoW program should be run from this same directory.
• The ZIP file contains a .exe file that can be double-clicked to run on any Win32 machine, however, it too must be located in directory with all of the other WoW files.

Give it a go and let us know what you think! Send comments or questions to the SoSE mailing list at wow@sose.apt-projects.net. Thanks!

The WoW project's source code management server was reportedly experiencing hardware errors, so Nick installed Subversion on a PC in Williston (onyx) and transferred all of the ECET department's repositories to it. He spent good part of Tuesday and Wednesday on this, but now everything seems stable. Thanks Nick!

The same server used for Subversion, named morning, was also being used to run the WoW server on port 9130, but after the reports of hardware errors, Nick setup the WoW service on onyx. Nick is using Fedora 7 Linux but is having a heck of a time getting SELinux to let him open and use port 9130, so he's temporarily running the WoW server on port 80 instead.

Chris is experimenting with a web-based project management environment called Basecamp. The Basecamp philosophy is that "[p]rojects don't fail from a lack of charts, graphs, stats, or reports, they fail from a lack of clear communication. Basecamp solves this problem by providing tools tailored to improve the communication between people working together on a project." So far, Basecamp is living-up to its claim and may become the SoSE project collaboration tool of choice -- we'll see!

Although functionality is minor, we invite anyone interested to download our WoW command line .jar file and README, give it a try, and provide brutally honest feedback to our mailing list: sose@ecet.vtc.edu.

Please keep in mind, as Nick mentions in the README, the following: Each time [WoW] is run, the list of profiles is generated by a constructor with information hardcoded in, so any changes you make (add/update/delete) will not stay. Since WoW is run once for each command you will not be able to verify changes that you make, you will only receive an OK or an ERROR message before the program exits. The next iteration (2) is adding a server with storage, so when it is finished add/update/delete will actually change things.

This week the guys plan to articulate the details of the second iteration, then get on with coding it!

Lastly, I'll be sending a note to the SoSE distribution list asking anyone interested to join us at Majestic 10 Cinemas in Williston to see a matinee of the Fantastic Four movie! Details will be in the note -- please let us know if you plan to meet us there and we'll wait for you at the ticket counter.

Nick began coding (solo) last Friday; Boomer coded (solo) yesterday. A few short hours working together today and the guys have a working command line rendition of WoW that uses a mock data access object with canned data. In just two short days and a couple of hours, we have something that works! And both guys will attest to how good it has been to incorporate testing. Nick mentioned that his tests alone have saved him some wasted time already!

The guys are already gearing-up for the second iteration. If you'd like to get a general idea of their plan of attack, see Boomer's general progression diagram. Be sure to zoom-in for the best rendition of the graphic.

So, the command line WoW client will be made available to anyone who wants to give it a test drive. Let us know what you think!

Let the coding begin! The WoW project started exactly one month ago today, and 30 days later, Nick and Boomer are starting to write their first official pieces of WoW code.

On Tuesday, Professor Chapin stopped by, joined us for Martone's sandwiches, and listened to the guys explain their overall approach to the first iteration. He didn't notice any glaring problems, so we're off and running!

For those interested, you can see the UML diagram (which will simply be an image display in your browser). For reference, the CLI label in the diagram simply means command-line interface, which means WoW will have command-line functionality only (in this first iteration).

• Source Code Management (using Subversion)
• Unit Testing (using JUnit)
• Continuous Integration (using CruiseControl and Ant)

A good automated build environment integrated with sound source code management and continuous integration practices has been referred to as a three-legged stool. The WoW Team is now a proud parent its own! Each of our stool's legs are listed directly above (in that bulleted list). Adding to the fun, Nick and Boomer were able to build this server from pieces and parts that we ordered online.

Feel free to use a browser and access the CruiseControl build status page, but remember that you'll need to be on the campus intranet.

Sorry for all of the links in this post, Nick!

We know that coaching a customer to properly define the problem is an art; many projects flounder because they don't take the time or have the training and talent to understand the problem at hand. As a result, the requirements analysis suffers and projects struggle. If we have to spend two weeks on this task, we will. We really want to invest in thinking about the WoW Project problem, the solution, the system design, and system architecture. We'll be asking Professors Chapin and Damon for guidance along the way and tapping from the experiences of Mike Soulia.

There is a good amount of new material to cover this week, and for many of us, this will be the first time we go through the process. So it's time to slow down, be deliberate, and really *THINK* about what it is we're trying to accomplish.

This week will be a mix of fun, research, and attempting to bring to life some of the concepts that, up to now, we've only read about and discussed. Boomer created a Battleship game during the Java ForceFeed exercise and we see in this game a great opportunity to spread our wings; we'll put together our development environment infrastructure.

This is a great time to mention that the entire SoSE concept began last summer after Chris read a book entitled Ship It!. This simple, clearly written exposition outlines time-tested, successfully applied team software development practices -- here's a great PDF poster of key practices mentioned in Ship It!. So, this week, we'll have a go at putting it all together and making things actually work!

For all ForceFeed participants: does this image seem to you to be in esprit de Head First Java?

Before the SoSE/WoW project officially launched we had to decide on the technologies we'd use. Our decision: Java (version 5, update 11). We knew that most participants had limited Java programming experience & exposure to Java technologies. This realization gave way to the idea that we needed a level-set to get all participants up to speed and exposed to a common learning experience. The Java ForceFeed was born; the learning began!

Six copies of the O'Reilly Head First Java, 2nd Edition were given to the team. The book has 18 chapters, and at 2 chapters per day, they would finish in 9 days (or so). Nick & Boomer provided daily feedback and questions. Professors Damon & Chapin provided direction & cleared questions. It seems to us that the ForceFeed was a resounding success! We finished on 5/18/07.

Let the project begin! Oh, I should probably mention that SoSE = Summer of Software Engineering. It's pronounced saucy, which is fun :)

SoSE^@VTC is a group of people at Vermont Technical College striving to learn & implement best team software development practices so we can influence our students with this practical, applicable, knowledge from the beginning of their studies to the end.

SoSE2007^@VTC is a program. Programs continue -- they go on & on. Projects are short-term endeavors that drive programs, and our project this summer is an electronic rolodex that we call the Window-on-the-World, or simply, WoW. The WoW project will strengthen the SoSE program with the collective experiences we gather in, then apply.