The Beginnings of a Robot

A few months ago, I purchased and old lego mindstorms kit from a friend. He wasn't using it much and I wanted to play around with some robotics in my spare time (as PhD funding is so hard to secure). I figured before investing in a new kit, it would be good to have a play around and install LeJos on an older model.

Since it is not a USB kit, it has in fact caused a lot of hassle. Firstly, connecting to the Com1 port and making sure that the environment variables are set up. Secondly, ensuring that the battery that is used for the infra red port doesn't drain quickly and thirdly having to re-install the firmware for LeJos everytime the battery dies on the RCX block.

All I want to do is install LeJos so I can write code, instead of using the mindstorms software, which is in fact for kids!!! So tomorrow, I will set out in buying a new battery for the IR tower.

In the mean time, here is a photograph of the robot so far. Currently, I have only built it in it's basic elements. Additions to come soon...



I am hoping to invest in the newer NXT Model soon.

Lastly, watch this space for more updates on progress.

End of Sprint Feeling

Is this how you're supposed to feel at the end of a sprint?

(drawing by Wadz)

Robot Problems!

I have an old mindstorms kit (pre-usb days) which I recently acquired off a friend. This is to allow me to play around with robotics in my spare time. Now being an AI graduate and a developer, I don't really want to be using the mindstorms software so I put LeJos (Java for lego) on it before. Once the battery dies, you have to re-install the firmware. Only it's not working. At first I was having problems with the RCXTTY variable not being set, although I've solved that.

The current problem I am encountering is that it tries to install the firmware and then I get the following error:

C:\Lejos\bin>firmdl.bat
read firmware srec
100%
Installing firmware
Loading native libs
Tower error: write failure

I have spent a good part of the night trying to sort this out and only half watching the England game. I've googled for help and I'm at a loss. I have read and followed the the instructions and I'm sure they are correct.

The only other thing I can think of is that the battery might not be at the capacity required to install this. I'll try a battery replacement and if that doesn't work just throw it out the window.

End of Sprint

So we have finished the sprint for this release. The code freeze was last night and the demo this morning. The client were satisfied and the demo was short and sweet. This sprint hasn't been very heavy going, as there hasn't been any new functionality introduced just enhancements of exisiting functionality.

Two recurring issues in this sprint have been:

1) The client constantly chopping and changing what they want and leaving it to the last minute to request these changes.

2) Dev's digressing from the requirements set out in the story and trying to do 'clever' things.

Although 1) might seem like the changes are minor, the issues are more around the bigger picture and the impact that it will have on making the change. This includes amending test scripts, deploying to the sprint test environment, re-testing, fixing any bugs that may arise and assessing any impacts on existing fucntionality. Now, at the beginning of a sprint it's easier to be a little flexible, after all we are Agile but there's a huge difference between flexibility and completely bending over backwards and becoming a bunch of yes people. It should never be the latter!

For 2) Although it is nice to have innovation, when you are working for a client who has specified what they want, if you don't meet that then the innovation means nothing. I witnessed the client actually tell a dev so you've done x, y and z, that's great but not what I wanted. I wanted you to make a minor change to a and that's it. Please can you roll back x,y and z to what it was doing previously! Now this reflects badly on the dev and the sprint team. I've noticed in this sprint, the dev getting rather carried away and digressing away from what they were asked to do without assessing and considering the impact to the rest of the team and the functionality just built! This is very risky and should not really be happening, especially on the day before the demo or even after the demo!

We should be having our retrospective at some point at the end of this week or early next week. I will be raising these issues then!

Prototyping Web Pages

When I first joined my current project, we were in the Elaboration/Construction phase. My job was to prototype the UI component (web pages) using a tool called Axure RP Pro.

Prototyping Advantages
The advantages of prototyping are that it allows direct user involvement with the functionality of the system from the beginning. This allows the user to determine that the use cases are being modeled correctly and the system is performing to their expectations as they are able to see the visualisation and simulation of the requirements and use cases.

Not only is prototyping advantageous to the user, it is also very helpful for the developer as they are receiving iterative feedback which means that the turnaround will be rapid when developing the real system. It also allows them to assess any future enhancements and determine any foreseeable issues for the future.

In terms of documentation, prototyping is self documenting as the pages can be annotated.

Prototyping is throw away code, it is easier to throw away and start again. It is very important to have that option at start of analysis, as continuing down the wrong track due to a lot of investment in developing screens, is generally, a bad idea.

Prototyping Disadvantages
Prototyping has many advantages, but along with the advantages there are disadvantages.

What tends to happen with prototypes is that users and developers forget that it is a throw away system and become very involved in the development of the prototype. They get caught up in getting the aesthetics right instead of focussing on the functional side and become too attached to the system. They lose sight of the fact that prototyping is to demonstrate the functionality and UI as a mock up system.

After involvement with the prototype the user can end up expecting the real system performance to be the same as the prototype. They overlook that in the real system there will be large volumes of data and other system issues like infrastructure, high volume of users accessing the servers etc.

Prototyping on Our Project
It was decided to prototype the UI on the project as this would allow the client and us to work collaboratively in order to establish exactly what the client wanted. It allowed us to determine the scope of the project.
It also provided the client with a visual representation of the use cases and allowed direct involvement and feedback on the potential system.

We achieved the following through prototyping:

• Input from the client


• Collaborative working through the workshops


• Quick turnaround

Axure RP Pro
Axure RP pro is a RAPID tool for prototyping web pages. It is more like a drawing package than a development system. It maps a storyboard on the model of the system, it achieves this though the use of ‘Wireframes’ of web applications.
The web pages are created by dragging and dropping components onto the screen.
Axure allows the creation of ‘Masters’ which are essentially like templates (i.e headers and footers) in word.

Adding components such as text fields, images etc is relatively straight forward with the drag and drop feature. It is also possible to link to other pages within the project or external links using the side bar on the right hand side. It is just a matter of selecting the component and then from the side bar menu deciding the course of action and whether the action should occur on ‘mouse click’ or on mouse ‘hover’. Linking pages in Axure is like linking one slide to another in Powerpoint.

It is possible to make the web pages interactive; however this is very limited and usually requires a fair bit of work for complex functionality.
As this is a prototyping tool, one would want to demonstrate interactive functionality. In order to achieve this in Axure it is possible to use a dynamic panel. On the main page you would drag a dynamic panel, with a ‘save’ button. You would then need to modify the state, which is essentially like another page. Once you have created your confirmation in the state, you can then link the save button to that state

If the interactivity functionality is fairly simple and straightforward the dynamic panel feature works very well. The difficulty arises in trying to demonstrate complex functionality, such as a tree view menu. The reason being, if there are many items and sub items in this menu then all the permutaions in that state have to be created, which can ultimately result in having many states. Now, if the task is to create the menu and not to modify it at a later stage, although a lengthy process it can ultimately be worth the time and effort. The problem arises if there are constant requests to make modifications here and there, in which case they have to be manually updated for every single state.

Fig 1: Axure RP Pro Editor

In order to view the ‘web page’ it needs to be built. This can be done as a single ‘chm’ file which is displayed as a help file or html pages with an index page.

When the files are compiled there is an option to generate them as CHM files or HTML files. Although in terms of viewing the web page the format doesn’t seem to make a difference, however the difference lies in that a CHM file is generated as a single help file whereas a HTML is generated with all the pages, images etc. So in terms of sending the files to the developers to create the pages it is easier to have a single CHM file.

Fig 2: Built CHM File

Fig 3: Built HTML File

Advantages of using this tool

• It is easy to use and can be picked up very quickly.
  

Mock up of web pages and an interactive demo can be created very quickly.

As the prototype can be viewed in a browser it can be sent out to the client, the Business Analysts and the developers.

The prototype can be version controlled as it is a single self contained unit.

Disadvantages of using this tool

• Everything is saved in a single .rp file even though a file can have multiple web pages this means that there is a lack of collaborative use and only one person can work on the file at any one time even if the multiple web pages are created by different people.



• If the .rp file is divided into two separate files so each developer can work on their web pages but needs to be integrated later on, this can prove difficult as it is a manual task as Axure does not allow importing other projects.



• If there is a consistent master across multiple .rp files and the master changes, the changes then have to be manually updated across the files.



• The final html/chm pages cannot be uses in the real system, so it is a completely throw away system.

Conclusion

• Prototyping is an iterative process that takes place at the Inception/ Elaboration phase


• Prototyping web pages is a quick and easy way that makes the development process easier, through user feedback


• Axure RP v4.6 Pro is a Rapid prototyping tool


• It allows the creation of interactive web pages using Wireframes


• It is easy to use


• It Lacks collaborative use


• New version (v5) meant to be far better

ASP Controls

Controls in ASP are amazing and very useful to use if used in the correct way. One of the nice things about custom controls is that if you have generic functionality across multiple pages, then a nice little feature is to create a custom control and embed that on your pages. This means it's easy to maintain and you're not having to duplicate the same code across pages.

Two annoying things I have found:

1) Developers who create a control and it is only ever used once on one page. Why do this if the functionality is not generic and used across multiple pages? Why not use the .aspx page and write the code directly onto the page.

2) Spaghetti code, where you have a page which has a control, that control contains a control and that control contains a control. It is so hard to maintain or debug this!

Controls are nice to use, I just wish people would learn to do so properly!

Sprinting Again

So, once again we are sprinting once again for the next release. This sprint will hopefully not be too taxing, however already we have encountered some frustrating problems.

First of all a defect raised in UAT 6 weeks after the release went in, meant that our planning session was held up until Thursday.

Once in the planning session, there were people in our team's session who weren't part of our team having an input on our stories. I found this rather unnecessary and frustrating.

It would be better that only the team and other required people are present in the planning session and not just anyone and everyone!

Hopefully the sprint will go well :) On the plus side, I managed to put 2 stories into sprint test before I left on Friday. Yay :)