Technically an off day for the agile project however Paul and Martyn researched the residual nitrogen calculations and came to a rather disturbing truth that all of the data from the PADI tables is going to have to be computerised.

While the research was going on there were some more problems with the source control however most of it is due to the team having to pick up an entirely new concept, let alone a new system. All seems to have smoothed out however, just got to keep reminding people of the steps the need to take in order to check files in and out.

Scrum master for the week is Stacey.

As I pointed out yesterday we had a large HCI hand-in today and really the entire team needed to focus on collating all of our material together into the report.

To start our day off there were numerous problems with the source control and continuous integration server, documents were not checking out properly etc. But after a little bit of jiggling everything sorted itself out. As I have said before, it would have been great to have had source control right from the start but due to the nature of the module and the learning curve being so steep to begin with, there is just no way you could have students trying to understand everything at once.

On the subject of source control, I really have started to dislike Team Foundation Server. Huge, bloated over-powered behemoth of a system that when you only need a fraction of it’s features actually wastes more time than it saves. Doesn’t meant I won’t ever use it and it has been useful to get some hands on experience using another type of source control but it most definitely wont be my first choice.

Subversion is lightweight, portable and entirely cross-platform. It doesn’t need a huge hulking backend server or advanced configuration, all you need is a web server, the pre-compiled SVN modules and the Subversion command line client. There is even a free deployable server for windows that you can install and have a working SVN repository in minutes (Check out VisualSVN Server). There are GUI’s for Windows, Mac OSX and Linux and there are even plug-ins for many of the major IDEs (Visual Studio, Eclipse, NetBeans, etc.)

Why do I love Subversion (apart from the above)? It’s simplicity! You can make your repository as simple or as complicated as your project demands and changes can be made easily. I carry around the svn client on a pen drive and I keep the majority of my projects (university, business and personal) stored in online SVN repositories I can access from almost any computer with an internet connection.

Anyway, I just needed to get that off my chest

As for the meeting with Janet today, not much to say on that, another paper to look at and report back on, we just have to get the finger out next week on the agile.

With another major hand-in tomorrow (HCI) we didn’t actually get much done today beyond a short scrum meeting. This is something that has really begun to bother me this semester and there is no real solution to it. We have so much coursework that overlaps despite having spaced out hand-in deadlines that it gets very hard to balance them all.

Group work is a very hard thing to manage on it’s own, however when you have multiple projects all vying for attention it makes the tasks even harder. I would like nothing more to devote 6 whole weeks to nothing but Agile however we have no such luxury in university. A shame, but such is life.

I wasn’t in today simply because I put off a meeting with a business contact for 3 weeks in order to do group work and yes I know I am supposed to be in University for group work and such, however we have 2 labs on a Wednesday and no lectures, during the labs we all work on group work anyway and I was not about to let my client down 4 weeks on the trot, not when there is business at stake.

As far as the project goes, well I managed to put everything into source control this evening, just got to hope everyone knows how it all works and doesn’t give the team hassle with Check Out/In locks (which are so much fun when the person who locked the code has gone home for the night).

Team seems to be getting on okay and to a point I am trying to take a little bit of a back seat from the programming tasks.

Yesterday was a long day, I had been up late working on a database assignment and had been on my feet since 7am working on more coursework including a trip to Dundee College to give a presentation for HCI and gather feedback. I was shattered by the time we were done so I decided just to come home. I knew that Agile was really on hold till today anyway since Monday is our “Sprint Planning” day despite doing that on Friday however we were yet to select the tasks as navigators.

The only thing that really took place (from what I have been told) was to organise our Sprint Backlog in excel and that was it. Two new tasks were added to the backlog however only one made it into the sprint and it was only really patching a problem with the first user story from sprint 1.

Scrum master for the week is Alan.

Paul and Alan worked on redesigning the view for the first user story and got on well, 2 out of the 3 tasks are now green. Great start!

Stacey and Rory made a start on the 2nd user story and I took a little bit of time to write up a Coding Standards document, nothing too long but something I hope will cut down on refactoring:

CODING STANDARDS

I advice the following standards be used on all source code developed on this project. They help increase the ability for other members of the team to read code and reduce the number of mistakes.

1 NAMESPACES

1.1 Namespaces should be of the format: DivePlanner.<project>.<folder>

Examples:
DivePlanner.UI
DivePlanner.UI.Controls
DivePlanner.Data.Validation

Be aware that creating a new folder inside a project in Visual Studio automatically tags the name of the folder on the end of any code files that are placed inside of it.
1.2 If you find that a collection of classes all perform a similar type of function (such as Validation), place them in their own folder and give them their own interface.

2 CLASSES & INTERFACES

2.1 Use CamelCase for class and interface names, that means the first letter of each word is a capital, eg. DivePlanner or IPlanner.
2.2 Exception: Uppercase abbreviations in class and interface names, such as IO, XML, etc.
2.3 Prefix interface names with I (capitol i).
2.4 Use meaningful and descriptive names for classes, for example DivePlannerIO implies that it performs IO handling for the DivePlanner.
2.5 Only put one class in a file
2.6 Exception: Structs, enumerations and internal classes are exempt from this rule. Place structs and enumerations at the top of the class file. Place internal classes at the top of the parent class definition.

3 COMMENTS

3.1 Avoid using inline comments to explain the function of a few lines of code
3.2 Use XML comments to describe classes, interfaces, structures , properties and methods

More information:
http://msdn.microsoft.com/msdnmag/issues/02/06/XMLC/ http://blogs.msdn.com/ansonh/archive/2006/09/11/750056.aspx