I wrote this blog on my phone in January 2008 and there it sat until I remembered about it today, 13 months since my last blog. Okay, so I've also been lazy. :)

So the year has ended and I haven't yet written about either of my semesters in the Professional Software Development course. Where 2006 was enjoyable and fun, 2007 was... how do I put this? Bloody hard? Death on a stick?
Either way, it was no cakewalk like I'm realising first year was.

This isn't to say I didn't enjoy it. I did, but... in hindsight. I certainly did not at the time. Why? The answer is simple. Too much bloody work. More than could be handled. Now I'm no slacker, I've achieved an easy HD average so far, so when I say there was too much work I don't mean there was too much work that it disturbed my slacking and games playing. Those activities (for me anyway) went mostly out the window years ago. I mean I put all my time and effort into the work and it still couldn't be achieved.

Still, all is not pain and misery. When I wasn't being worked into the ground I thoroughly enjoyed myself. The content of the course is still (mostly) well taught and relevant. I chose to take the Games stream for my specialisation, and this year was the first year those subjects came into play.

In first semester I took four subjects: Object Oriented Programming in C++, Data Communications and Security, Data Structures and Patterns and Software Development Practices. OOP in C++ was good for me because I taught myself C++ in 2002 but never really understood some of the more quirky and less used features that the language offers. This subject wasn't hard for me, having already done C++ for years, but I know it was difficult for my peers.

Data Structures and Patterns was a really good subject. Although many people found it really dull, I found it fascinating. The labs really supported the content: one lab got us to write an algorithm with linked lists and then again with arrays to illustrate where linked links perform poorly compared to arrays.

Software Development Practices took us through the process of speccing, designing and spiking out software projects. They tried to make the subject as practical as possible but it still could be really boring. There was no exam (thank god) which is good because regurgitating tonnes of theory is no fun.

Data Communications and Security was a good subject except that it attempted too much in too little a time. For example, one of our labs was to make UDP reliable. That's pretty massive. An assignment was to create a whole P2P filesharing system which also included splitting a file and downloading it from multiple sources. That's pretty massive. I really enjoyed the content of the subject, but man, the amount of work ruined the semester for me.

There was a fifth subject called Careers in the Curriculum where we were taught about job interviews and how to write a resume. Although it was annoying to have to do it when I already had too much work, I recognise it's usefulness now as I've needed to do interviews and write a resume.

In second semester, my four subjects were Database Programming, Languages in Software Development, Software Project Practices and Management and Games Programming. Database was a good subject, although I found it taught very little actual content, preferring to flog the crap out of 'the three layered architecture'. It did skim over some of the details of different database technologies like being able to program custom types into SQL Server 2005, but mostly it was about the three layered architecture. The hardest part about that subject was that it made you learn ASP.NET without any help at all and a rather short deadline. The actual database content was easy; it was the ASP.NET stuff that was hard because we had to learn it from scratch.

Languages in Software Development was odd. It was both a boring and fascinating subject. It seemed both irrelevant and relevant. Languages taught us about the basis of programming: lambda calculus. It was rather esoteric but also fascinating as we got to build a lambda calculus interpreter in Java. It also taught us about induction which was rather brain twisting and I still struggle with it. Our lecturer, Marcus, was wonderfully helpful and was willing to spend hours with me outside of class helping with the lambda calculus and induction problems I encountered. This subject required constant and considerable work, but was worth it.

Software Project Practices and Management was a subject that continued on from Software Development Practices. It started off a little dull but got better once it started talking about Extreme Programming practices and Scrum. Unlike SDP, it had an exam, which was a chore. I didn't end up doing the HD assignment because I simply didn't have time.

Games Programming was the big disappointment for me. That's not to say it was terrible, it just didn't live up to my expectations. Unfortunately, the subject was focussed towards Games and Multimedia students rather than PSDs and as such didn't actually contain enough programming. We spent half the semester writing a game design and not actually programming. This subject was like data comms in first semester: way too much work that took time away from other subjects and made the semester a nightmare. The distinction assignment was nothing less than, oh, write a whole game. Want an HD? Do a research report as well. It was basically impossible to do when you factor in the other subjects we had to do.

So, basically the year was good, just back breakingly difficult, but only because there simply was not enough time to complete all the allocated work. I'm looking forward to next year when I move to Adelaide to do my IBL year at the DSTO. The fixed work hours will mean I can't overwork myself like I did this year trying to do all the work in my subjects.

They say that second year is the hardest and it gets easier from there. I really hope so. In either case, it's over a year away so hopefully I'll be ready to take it on again by then. Now? I just want to play games and fiddle with Visual Studio 2008, .NET 3.5 and Windows Presentation Foundation. And sleep.

This is the final blog I am doing for my Software Development Practices subject. It is on a game, so you probably will find it less dry than the previous four blogs.

Cellfactor Revolution is a computer game that, in my opinion, has some serious interaction design flaws. For those that don’t know, Cellfactor is a free first person shooter game released by Ageia as a marketing tool to attract people to buy their hardware physics processors. Cellfactor is a heavily physics-based game, which means that you use physics (aka being able to move objects realistically in game) to kill other players. For example, you might use your psychic powers and push a stack of boxes onto another player to kill them. You might fire a dart into an enemy player which causes all objects that are not tied down to be drawn to that player, crushing him. It is intensely physics based and needs an Ageia PhysX card to be played properly, hence why it has been released free to attract people into buying Ageia’s hardware.

From an interaction perspective, Cellfactor uses the standard first person shooter (FPS) controls: WASD for movement and the mouse to look around and fire weapons. But Cellfactor introduces new the new physics abilities that confuse the standard key-bindings that a seasoned FPS player would use. Obviously, in an attempt to make it easier to play, the developers set the default key bindings for the physics push and pull abilities to Ctrl and spacebar. This is where the problems start.

As any regular FPS player probably knows, Ctrl and spacebar are normally bound to crouch and jump. So by changing the default controls, Cellfactor’s developers have either forced you to relearn controls (a difficult and frustrating process: an exaggeration would be to imagine trying to relearn how to type on a Dvorak keyboard), or forced you to change them manually to something else. That doesn’t sound too bad until you figure out that there aren’t another good two keys you can bind physics push and pull to. See, in Cellfactor, you don’t just push and pull. You combine those abilities with other key-presses like Alt and right-click to perform special physics abilities like physics shockwaves. I tried to bind push and pull to mouse 4 (the thumb button on the mouse) and the F key and found it a real hand-bender to try and press mouse 4 + right-click + alt during an in-game fire-fight. Note that if you are able to change yourself to use Ctrl and spacebar as push and pull then you don’t get these finger contortions, which is probably why they are set to be the defaults.

In Cellfactor, you can play as different classes of player: a psychic, a soldier, and a mechanised robot. This introduces another problem: each class has different key bindings. For example, using default controls, pressing F will cause you to hyperjump if you are the robot, but pressing F when you are the soldier causes you to throw a proximity mine. Trying to remember what key does what when you are using a certain class at the same time as trying to bend your fingers unnaturally to press mouse 4 + right-click + F at the same time as using WASD is as difficult as trying to parse and read this sentence.

The solution requires a rethink as to how the player should interact with the physics abilities. What I would do is to bind the separate physics abilities such as push, pull and each of the special physics abilities to a number key. The player could then press the number key of the ability he wants, for example key 3 for physics push, and then use the standard FPS left and right-click to prepare and “fire” it. It is standard behaviour in FPS games to change binding of the number keys to different weapons or abilities in different classes, which reduces the player class / key-binding issue since people are used to it already.

I’m surprised that these problems weren’t encountered during play-testing. Either the developers didn’t do enough testing (a possibility because of the restricted budget this free game probably had), or they decided that relearning the controls was an acceptable thing they were willing to force players to do. It is possible they tried my idea that I discussed above and found that it prevented the player from using the physics abilities as quickly as the currently implemented design (after learning it).

In the end, the interaction design problem behind Cellfactor only affects those too stubborn or those that find it too hard to relearn their controls. It would also affect those who switch between games, since having to mentally switch between Cellfactor controls and Counter-Strike controls all the time would be annoying and frustrating.

This is the fourth blog I am doing for my Software Development Practices subject.

Eudora is an email client that I use to access my various email accounts via POP. It does the job admirably and I have been using it for years. Relatively recently, an update to Eudora added instant search functionality, presumably to combat all the other instant search products that have been hitting the market over the last few years. It was a good idea, as doing a normal search through your email tended to take a while.

The Eudora development team took the easy way out: they licensed a third party instant search product called X1 and integrated into Eudora. Unfortunately, this is where the good idea started to come apart. The fast search often does not find results, even though you know there are emails that would match your search parameters. This seems to happen mostly for newish messages, making me think that perhaps the X1 search engine is not having its search index updated in a timely manner. This is an annoying and misleading problem, since most users trust the output of their search request. If their result set is missing some emails, they probably won’t notice and will miss things.

I would probably blame this problem on a lack of testing. Eudora was late to the indexed-search party and perhaps the development team rushed the implementation and skimped on the testing just to get the product out of the door. Not a good move. My theory is lent credence by the fact that the Eudora team chose to integrate a third-party search solution rather than write their own, like every vendor seems to be doing currently. They needed a solution quickly, so instead of spending time writing their own, they used X1.

When specifying the requirements for the new indexed-search feature, the Eudora team probably forgot to define some clear quality requirements that should have specified the regularity at which the search index was to be updated, if indeed that is the problem. Of course, this is such a blatant problem that it really should have been picked up in the test phase. This indicates lax procedures behind the running of the software testing activities.

To fix these sorts of problems in the future, the Eudora team should be very careful and specify all quality requirements during the specification phase. This should be backed up by a more stringent test phase before the product goes live. The team should try not to rush the product out the door; in my opinion, its better late than critically broken.

Unfortunately, since Eudora is no longer being sold by Qualcomm (the company behind Eudora), this bug is probably not going to be fixed. Luckily, there is an option to turn off the indexed-search and use the old search. It may take a few seconds to return results, but at least it returns them all.

This is the third blog I am doing for my Software Development Practices subject.

Scintilla Text Editor, normally known as SciTE, is a light-weight text editor built for programmers and scripters. It supports syntax styling, bookmarks and some nice code editing tools such as block commenting (where you select an area of text and the editor will surround it with syntax-specific comment symbols such as /* and */).

The pain points that SciTE is probably trying to solve for its user base of programmers are:

• Other simple text editing solutions (eg Notepad) do not support syntax styling
• Other text editors that do have syntax styling do not allow the programmer to create a new style for a new syntax
• Other text editors do not have tools for fixing indentation, doing automatic block commenting and changing file line-ending types
• More comprehensive text editing solutions cost money and can suffer from feature bloat

SciTE’s main functions are:

• The display of syntax styled source code files
• Block commenting can be performed
• Ability to read multiple line-ending formats (eg CR, LF, CRLF)
• Able to fix incorrect indentation in source code files
• Able to search (and replace) using regular expressions
• Able to set bookmarks to certain lines

SciTE’s form is made up of the following:

• Syntax styling properties are read from configuration files that are user-configurable
• Syntax styling can be turned on and off or manually changed from one syntax to another
• Runs on Windows and Linux
• Displays multiple text files using tabs
• Multiple windows can be opened if preferred
• Code blocks can be “folded” (compacted into one line)
• Displays code tips (small text pop-ups that describe a method’s arguments)

SciTE mostly solves the pain points that its users have. It is lightweight and has the bare necessities and a few niceties that any programmer or scripter wants in a text editor. It also provides an extreme level of customisability via its configuration files which let you create new syntax styling rules for languages that, perhaps, SciTE does not support by default. However, SciTE’s configuration files are where its worst failing is. Although allowing the user to change everything down to the position that the SciTE window will open at on start up, it does so through a very hostile interface: its own text editor.

Configuring an entire program via a text configuration file is difficult: you must learn the format and search through it manually, looking for the setting you want to change. If I were the one to write SciTE, I would have put effort into putting a real GUI behind the program’s configuration, especially the syntax styling. A similar editor to the one that the IDE Eclipse provides would be appropriate, where you can change keyword colours and tab settings. It would obviously need to be extended to allow the definition of a new syntax: a UI would need to be created to allow the setting of syntax rules like keywords and block delimiters.

Overall, SciTE does solve the pain points of its users. It does provide a lightweight text editor that has syntax styling and some code specific features like indentation fixing. Its configuration methods, however, leave a lot to be desired in terms of usability. It can be difficult to configure new syntaxes or change existing ones using SciTE’s text file based configuration approach.

This is the second blog I am doing for my Software Development Practices subject.

Visions statements are used to broadly state the goals and objectives of a project. Vision statements are distinct from mission statements in that they describe a vision for the future rather than focusing on the immediate.

There is a simple template you can fill out to help you focus your ideas into a vision statement. You need to answer these six sections:

• For some audience...
  Who are the groups of people that your product is going to target?
  eg. PC gamers
• Who have a problem...
  What seems to be the problem that these groups are having?
  eg. They do not have a real-time strategy game that allows large-scale strategy
• Our product called x...
  What is the product's name and what category of solution does it lie in?
  eg. Supreme Commander is an RTS PC game
• That solves the problem by...
  What is the main reason that would persuade these groups to use your solution?
  eg. It allows large-scale strategy games over huge maps with hundreds of units
• Unlike...
  Who are your main competitors?
  eg. Company of Heroes
• Our product is different because...
  How is your product better than your competitor's product?
  eg. Supreme Commander allows the player to focus on strategy rather than tactics

Once you’ve answered those questions, you can string your answers together and use some English grammar skills to make it sound smooth. To continue the example I used:

Supreme Commander is a real-time strategy game for PC gamers who want to play large-scale strategy games over huge maps with hundreds of units. Unlike Company of Heroes, Supreme Commander allows the player to focus on strategy rather than tactics.

You might want to see what a real-world company uses for a vision statement. McDonalds uses this:

McDonald's vision is to be the world's best quick service restaurant experience. Being the best means providing outstanding quality, service, cleanliness and value, so that we make every customer in every restaurant smile.

All your projects should have a vision statement. When evaluating your solution you can always refer back to the vision statement and see if it matches your original vision.

This is a blog I have to do for my Software Development Practices subject. Its shorter than I'd like and hence not particularly comprehensive but I was forced to fit it on a single A4 page or lose marks.

Software Name: Opera
Version: 9.20
Date Released: April 11 2007
Developer: Opera Software ASA
URL: http://www.opera.com
Classification: Web browser

Opera is a little known and little used web browser. That doesn’t stop it from being a gem, however. It performs the same functions as the more popular browsers like Internet Explorer and Firefox: web browsing, downloads, favourites, history and so on. It supports tabbed browsing, which is the latest “rage” in the browser market, is quite compliant with web standards, and is very fast. In fact, according to howtocreate.co.uk, it beats Firefox and IE in almost every speed test (on Windows).

Obviously, I’m not going to bother telling you about the basics of the browser, since you’re probably viewing this blog using one. These days the main innovations with browsers are in the usability and speed area. I’ll instead highlight the main features and the strengths and weaknesses of Opera.

Opera takes great strides in making a browser more usable. Sure, it’s got all the standard features of today: tabbed browsing etc, but it innovates with new ways to interact with the browser. The main one is “mouse gestures”. Basically, you move your mouse in certain patterns while holding right-click and browser performs actions. For example, you can hold right-click and then move the mouse downwards then release the click, and you open a new tab. If you do that over a hyperlink on a webpage, you open it in a new tab. You can close a tab by moving the mouse down and then right. It takes a little time to learn the gestures, but once you’ve mastered them they becomes as essential as typing. It simply is a natural way to interact.

Another usability improvement Opera presents is the “Speed Dial” panel you view when you open a blank tab (see right). There are nine boxes you put your favourite websites into and the box will show a small preview of the specified website. When you click the box it opens the website in the tab. It sounds simple, but like all good usability features it’s so simple and easy to use it becomes transparent to the user.

There is one large feature that Opera lacks: a robust extension system like Firefox or, to an extent, Internet Explorer. If a feature is missing in Firefox, you can simply get an extension for it. For example, you can get mouse gestures in Firefox via an extension. Opera does not support extensions, which limits it a bit in the eyes of a power user.

As a result, I favour Firefox when developing webpages, because of its superb web developer tools via its extensions, and then I use Opera for everything else since it does it better. It is “Simply the Best Internet Experience”.

Advantages:

• Fast
• Mouse Gestures
• Speed Dial

Disadvantages:

• Doesn't support extensions

Overall Rating: Excellent

I have converted the RSS feeds on this site into FeedBurner feeds. Please unsubscribe from your current feeds and resubscribe to get the new URLs. This change should allow me to track the feeds' usage, which could be fun. I've gone a little statistics crazy since the bandwidth stealing episode, so now everything is all statted up. Sweet.

This will be a short blog this time, since I've got a ridiculous amount of Uni work to do. Swinburne has taken away the swat vac week that everyone uses for study before exams. So I get a grand two days to study for one of my subjects. Thanks Swinburne! [sarcasm].

One of our assignments is to write a P2P filesharing system (yes, you read that correctly) by the end of the semester. My team has spent the last 2 or so weeks planning; we haven't even written a line of code yet. We've written two documents describing the two protocols we're going to use and 23 whiteboards of object design. A lot of other groups have already begun coding but I think that's a bad idea. If there is one thing that the PSD course has taught me it is that starting a project by hacking some code is a good way to screw it up, especially in object oriented programs. Plan first, cut code later.

This seems to me to be especially important when you are working in a group. There are four people working in my group (including me). Without an OO design, everyone is going to do their own little thing and its just going to become a complete mess. Now that our design is done we can split the work between us and write the code knowing exactly what services someone else's part of the program will provide to my part.

The assignment's subject gives no guidance on how to code effectively in a group, which is crap since its a difficult thing to do effectively. Luckily, a few of us have some experience with source control before from a previous subject and I use source control at work. I've set up a Subversion repository for us all to work from on my home server. Hopefully, we won't make a mess when we use it.

We've named the program "LemonWire". This name has two tricks behind it. The first is obvious: a play on the common LimeWire P2P filesharing system. The second is less obvious: it works with the program's catchphrase: "its a lemon". Sounds random? Its not. Normally, when you say something's a lemon you mean that its not very good. The catchphrase basically reflects our cynicism with the assignment, since all of us reckon its way to big to be given to us to do in half a semester especially when we're missing swat vac. That and the fact that its a P2P filesharing system operated from a console! Also, a whole bunch of its architectural decisions are bad ones because we were forced to comply with the assignment spec. A good example is the fact that the network has a central server whose primary function is to bootstrap clients into the network. That ought to be done by another client, not a server. It would make sense if the server also indexed shared files and performed searches, but it doesn't.

I may have sounded a little too cynical about our ability to complete the assignment in the last paragraph. Its true that it is much too big for an assignment, but I think if we all work hard on it, we have a good chance of completing it in time, thanks to our time spent planning. Wish us luck!

The next few blogs are going to be blogs that I have to write for my Software Development Practices subject. One of the requirements is that I put the blogs online, so I'm putting them here. They may be a little dry, but hey, maybe you'll learn something!

So much for a short blog.

Time flies when you're having fun; its already almost half-way through 2007 and I haven't reviewed Year 1 Semester 2 of my university course, Professional Software Development. I will use the Atomic method of rating: a real 0-10 score where 0 is absolutely shocking, 5 is average, and 10 is brilliant. This rating is opposed to the typical ratings you see on the internet, ranging from 5 at the lowest to mostly 7s and 8s and maximums of 10.

Computer Systems

Computer Systems was supposed to be a lead on from Computer and Logic Essentials and it started out that way, but then deviated. This subject was a bit of a mess this semester, starting out with some theory about operating systems (quite interesting stuff), moving quickly into a little Linux and a lot of Bash scripting, sliding into a tiny bit of boolean algebra and logic gates, then diving into writing assembler (not x86 assembler).

Although, I came out of this subject unscathed and with good marks, a lot of people had a lot of trouble with this subject. The first assignment was writing four or five scripts in Bash. This doesn't sound too bad until you realise that the subject doesn't actually teach any Bash. We were referenced the quite terrible Advanced Bash Guide and given a lab or two and that's it. With Bash and Linux being quite different to Windows and Pascal (the language we learnt last semester), and almost no help from the subject itself, it was no surprise that many people had a lot of trouble with this assignment.

The other main assignment was a rather complex program written entirely in assembler. Again, a lot of people had a lot of trouble with this assignment. Assembler is particular complex (even for the simple chip that we were writing it for) and very different from normal programming (no branching, loops have to be written manually, etc). It also didn't help that the subject moved too quickly through the assembler and left everyone behind once they got lost at the beginning. A review meeting was held with the staff and the PSDs present and it was agreed that the assignment was to be made easier and the subject slowed a little. Once we had gone back over the basics and got them grounded better, most people started getting a grip on assembler. However, it was too little too late. I had a good grip on assembler from right at the beginning (I was able to follow the lectures better than most), but even I had to do the cut down assignment because there simply wasn't enough time to do the original assignment (this meant I lost marks automatically, which was nasty).

The subject was mostly taught by Rob Allen, with Raj Vasa jumping in at the beginning for some operating systems and Linux stuff. Although Rob is a really nice guy, his explanations were often hard to understand, and he moved too quickly through the subject without making sure people actually understood what he was talking about. Once he realised that people were failing the subject, he went back to the basics and taught them more slowly and most people responded well to that.

All-in-all, I quite enjoyed most of Computer Systems, although I'd probably be the only one in the course who'd say that. I found all the topics facinating, except for boolean algebra and Bash scripting which almost weren't taught at all, and subsequently were a pain in the arse.

Rating: 6/10

Internet Technologies

Internet Technologies was like a crash course in all things internet. It basically ran through lots of topics very quickly, ranging from TCP/IP to HTML/CSS, to Javascript, to accessibility, and to PHP. If there is one thing that this subject bashed into your head repeatedly with a large hammer, it would be to validate your HTML against the W3C standards.

The lectures were taken by Clinton Woodward and were mostly good. If anything, I sometimes found them boring because I already knew the stuff he was talking about, but whenever some new stuff came up, like some advanced Javascript or a good explanation for the CSS box model, I regained interest. So my boredom wasn't the subject's fault.

I found the labs entirely pointless because they were so ridiculously easy. I basically never needed to ask the tutor anything because I already knew it all. All the labs really did was further bash in the "validate, validate, validate" message deep into my skull.

The assignments were better. In the first assignment I had to group up with some friends and create a standard set of XHTML that each of us individually would style with CSS. We then had to present our work to the lab group in a presentation. Again, I found this easy, so I spent some time creating a dynamic stylesheet switcher in Javascript as an extra feature.

Although I knew most of this subject already, there was one main valuable thing it taught me: good standards. I taught myself HTML and CSS by hacking and Internet technologies showed me the way it should be done: standards compliant, don't use IDs more than once, etc. I look at DigitallyCreated's HTML now and cringe. I should update it someday, because its really shocking.

Rating: 8/10

Object-Oriented Programming

Object-Oriented Programming continued from where Algorithmic Problem Solving left off. It handled the transition from procedural programming to object-oriented programming. The subject was taught in C#, which was a new language for the PSDs to learn.

The subject was taken by Andrew Cain, and was presented in his typical Beyond Bulletpoints style that we found very effective when used in Algorithmic Problem Solving last semester. The lectures taught broad concepts which were honed and developed in the labs and assignments. Apart from one lecture, C# was taught only in the labs, which was very effective since the best way to learn a language is to practice it, not to hear about it in a lecture.

A lot of the OO design theory wasn't taught in the lectures in detail, and was left for reading tasks. This was rather boring, but Andrew had created reading questions to answer after reading the text book. They were a pain in the arse, but did their job well: forcing you to remember what you read. A much better approach than just straight reading.

Although, some OO design was taught in lectures, I found I learnt the most doing the assignments. The second assignment was the one that taught me OO. The assignment was to create a Zork style text-based adventure game. The actual design was already done by Andrew and we had to read his notes and implement it in C#. This was a really good way for us to look at how OO is done, without going in too deep initially by having to create our own design. Creating your own design was handled by assignments three and four.

Object-Oriented Programming was structured differently to other subjects. The third and fourth assignments were optional but required if you wanted to get a distinction or high-distinction respectively. There was one test and no exam (unless you failed the test). This was a good structure and meant that people who wanted high marks had to work for them, which is fair enough. Having a test instead of an exam meant that we could use computers during the test and write code on a computer (fancy that!). This was a good way of doing it, since it tested actual real skills, instead of the useless skill of programming on paper.

OOP was the best subject of the lot. It was challenging and interesting and taught me many valuable programming skills. I loved C# so much that I now count it as my main programming language.

Rating: 10/10

Usability

The content of Usability promised to be good: how to create applications that are easily usable by the end-user, however, the subject's implementation left a fair bit to be desired. My first disappointment with this subject was that Usability taught the theory behind creating usable applications, not actually how to create usable applications. Sure, it showed how to follow a process to research how to create a usable program, but there were no guidelines like "all popup dialogs must have an OK button".

The main problem with Usability wasn't what it was trying to teach, since what it was teaching was sensible and useful. The problem was how the information was presented. As you can image, theory on creating usable programs is dry, dull, obvious stuff that feels like its being overcomplicated and theorised for theory's sake. So how this content is presented is very important. Unfortunately, Usability's lectures had boring bullet-point slides with little information, no notes, and a textbook with too much information.

On the plus-side for Usability was its approach to assignments. There was one big assignment which was due in pieces throughout the semester. Although this was a good approach, I felt that sometimes each piece was due too soon, because the assignment was a team project, and team projects are difficult to get organised within short times such as a single week.

The assignment itself was mostly good. It took a practical approach to the theory and asked us to work through the process of designing a kiosk software interface. We started by collecting information like existing solution problems and users' needs. Then we designed prototypes and eventually performed a 'scientific' test on real human subjects by using a lab. This test involved having users sit down and use the system while we watched them through one-way glass and recorded their every movement and comment using cameras and microphones. That was fun.

All in all, Usability wasn't a bad subject, it was just a boring one. With a bit of work, this subject could be made a lot more interesting. You can tell the subject convenors tried to make it interesting by the way they made the assignment (thumbs up), but their approach to the lectures needs a rethink.

Rating: 5/10

Summer Scholarship 2006

The Summer Scholarship (SS) was a program that was offered to all PSD students through a voluntary application process. Only six PSDs were selected to participate, and I was lucky enough to be one of them. The SS was a four week program that was run a week after the exams finished. It ran 9 to 5 for three days a week and paid us a $1200 stipend at the end. The purpose of the program was for us to do some programming projects and learn things as we did it.

The six of us were split into three groups. Three of us worked together using PHP to create a web application based on the Werewolf game. Two of us worked on a C# minesweeper clone (to learn Windows Forms), and then rewrote it in Java using Swing (to see the difference). I worked on my own, creating a side-scrolling game called Escape from Swinburne.

I won't detail much more about the SS since I've talked about it before here and you can read the SS blog here. Basically, the Summer Scholarship was brilliantly fun.

Rating: 10/10

The second semester of PSD, while not as refined as the first semester, was still enjoyable. If the rough edges are smoothed, this semester could have been awesome.

Trivia: I actually started writing this blog in January, got three-quarters through, then got distracted by commitments to my web development business and University. Apologies for the drought.

Even though its the holidays, I have been working harder than ever. Currently, I'm working two days a week at my part-time job and the other three days at the Summer Scholarship at my university. Unfortunately, my preferred living style (going to bed really late and waking up as late as possible) doesn't work well with 5 days a week of full time work, so I've been tired as hell.

Luckily the work is mostly good: in my part-time job I have starting to be elevated from a mere software tester to a software developer. I wrote my first bit of code (in ColdFusion) for them on Monday! The Summer Scholarship is also great. I've been assigned a task where I have to create a simple API for creating games in the Pascal programming language, and to demonstrate that API with a side-scrolling game. The API will be used by next year's PSDs in their Algorithmic Problem Solving subject.

Writing the API in Pascal sucks, because I love real IDEs with code suggesting (Intellisense), and I'm using Crimson Editor (simple as hell text editor) to write my Pascal. Also, Pascal isn't exactly a language that is widespread, so learning it hardcore is (almost) wasted. I can't even use the object oriented features of the language since the APS students won't know OOP yet! The other guys get to write in C#, Java and PHP! But knowing that next year's APS students will use what I write makes it worthwhile and mollifies me.

Most of my blogging over the next three weeks will probably be on the Summer Scholarship's PictBlog at Blogspot, so keep an eye on that. As a side note, Blogspot's blog editor sucks. I had to edit my post there at least six times before it was correct. The worst problem was, for some reason, my text didn't word wrap and it poked out over the right-side navigation menu (overlapping it) and stretched the page. Hopeless.

Outside of work, I have also been busy writing the PHP for Aurora, the CMS that will power web solutions created by Pulse Development (my cousin and I's web design business). Aurora is written in PHP and I was happy to find that PHP 5 has almost all the OOP features that C# has: interfaces, inheritance, polymorphism, etc.

Aurora will power this website once its done (in fact I'll use DigitallyCreated as a kind of test bed for Aurora), so you'll get a nicer blog and news interface, and it'll be a hell of a lot easier for me to update it (hopefully increasing my blog count). Also, you've probably noticed this page getting stupidly long; Aurora will split it automatically over multiple pages. It will also do automatic generation of the RSS feeds for this blog (thank god, I do it manually at the moment!).

Finishing up, I'll leave you with a warning: I read an article over at the INQ about one of their reporters who got RSI (yes, that thing you ignore the warnings about). The afflicted hack wrote an article about his experiences with RSI and it sounds entirely nasty. He ended up with arms that didn't work. Normally, I don't really read this sort of stuff, let alone get worried about it, but this hits close to home since I do a lot of typing and I really don't want to break my livelihood (you can't code C# with speech recognition when your arms are stuffed). I would suggest you read it, so as to avoid it yourself. Find the article here.

Ah yes, I have been putting this off since I am lazy, but now with Semester 2 in full swing, I thought I’d better get to it before I forget it.
I do the Professional Software Development (PSD) course at Swinburne and this is my first year. I had four subjects in Semester 1, so I will review each of them, one at a time.

Algorithmic Problem Solving

This subject involved learning the very basics of programming: how to write code, and how to solve problems using standard coding structures eg if, while, for etc. The subject used Pascal as a syntax simply because Pascal is a good teaching language. One of the advantages of this subject is that it doesn't throw the student straight into object oriented programming from the get go and gets them used to procedures and functions etc first.

It was very easy for me since I have done lots of programming before, but that didn't stop it from being the best subject of the semester. It was taught by Andrew Cain, a very good lecturer who brings his enthusiasm for programming to every class. He also does away with bullet-points in lecture slides, and uses more graphics and animations to convey his concepts, which helps alleviate the boredom that most lectures entail.

The exam for the subject was very easy but it did, however, cover all the work that we had done that semester so I think it was justified in being easy. The fact was, if you could do what was on the exam, then you had done the work during the semester and that’s what counts.

Rating: 10/10

Database Analysis and Design

This subject was a simple introduction to databases. It taught the student how to properly design a good database in third normal form, and also how to program databases using SQL. The lecture slides were incredibly detailed, which made this subject very easy to learn since you could just look at the slides if you needed answers.

The tutorials, however, were not so flash. The guy who took our tutorial obviously spoke English as a second language so it was clear that he often had trouble answering questions not because he wasn’t good at databases, but because when questions were shot at him in English he got easily confused. The result normally ended up with a “chasing your own tail” situation where your question didn’t get answers. That said, the guy was extremely helpful when I needed my assignments to be remarked.

Which brings me to my pet bitch about this particular subject. I had to have two out of three assignments remarked because they had been marked incorrectly. This really annoyed me because is showed lack of care on the part of the markers and/or incompetence. I really should not have to teach the subject to them.

The labs for this subject were particularly useless, again not because of the work material, but because of the lab tutor. She was pretty useless. All she did was sit there until someone asked a question and when they did (at least whenever I did) she invariably either didn’t understand the question, or got the answer wrong.

However, the subject on the whole was good and I learnt some very useful database design techniques which I will be putting into use soon.

Rating: 8/10

Computer Logic and Essentials

This subject strove to give a shallow understanding of the mathematics behind computers. So it taught things like binary, hexadecimal and normal base 10 number conversions, encoding schemes, predicate logic, set theory, relations and functions and graph theory. The way the subject skimmed over these topics was ultimately the thing that made it hard for me. In mathematics you need a full understanding of how things work to be able to get things right. Because we only skimmed the surface of topics in this subject, we often didn’t know whether something was right or wrong. This was especially evident in the predicate logic section where we were taught a loose notation that resulted in a lot of different correct answers. This made learning a little difficult. That said, we did need to skim over the subject materials because otherwise there would not have been enough time to learn it all. So this really was more of an awareness subject.

CLE was taught by Raj Vasa, another good lecturer who has a great style where he can talk about a subject in a very casual and informal way, dropping in funny comments and opinions all the time. This meant, even though the subject material could be a little dry, the lectures were never boring.

What annoyed me most about this subject was that it didn’t give us many exercises to practise on. You should take that statement with a grain of salt, since I am not your average student and in maths subjects I like to have lots of exercises to learn from. The exercises that we were given did not come with answers, which is my pet bitch about this subject. This made it very hard to verify your work because you had to manually go and see Raj to get answers instead of just checking an answer sheet.
Raj said this was because he didn’t want people just looking at the answers rather than doing the questions. However, I feel that since this is university and supposed to be a self-learning environment, anyone who scuppers themselves doing that can deal with it themselves. Their stupidity should not limit others.

Rating: 8/10

Introduction to Business Information Systems

There always has to be one crappy subject, it seems, and this is it. Introduction to Business Information Systems (IBIS) attempted to teach you how IT integrates and is used in business. Sounds good, but it wasn’t.

To start with, the lecture content was a mish-mash of topics, which would switch around in a lecture making it very hard to figure out what was going on. The lecture slides were bad, barely explaining the content of the lecture and full of diagrams that meant absolutely nothing. One of my friends only turned up to four or so lectures and still got a good mark for IBIS. That’s how useless the lectures were.

The tutorials were also bad. I didn’t get a single thing out of the tutorials. There were no exercises to be answered, nothing. Just discussions on seemingly irrelevant topics. The labs were also useless, teaching us how to use Excel and Access. Things like: to open Excel go Start menu -> Microsoft Excel. I’m sorry but this sort of thing is taught in school, we don’t need it again. I finished all the lab work for the semester within scant weeks and didn’t turn up to any subsequent labs.

The textbook was bad. It was boring, full of diagrams that made absolutely no sense, and seemingly expected us to know what the world had been like before computers so that we could see the impact. I’m sorry, but I wasn’t alive when that time passed into obscurity, so how am I supposed to relate to that. It made a big deal about things like portals and transaction processing systems etc things that people my age take for granted. Trying to look at those from the eyes of someone who never had that stuff is impossible for me, because I don’t know what it was like to not have it.

Luckily, for those PSDs taking the course next year, our bitching about how bad this subject is has caused this subject to be removed from the course, which is brilliant.

Rating: 3/10

So all in all, Semester 1 was pretty good, with the exception of IBIS.