Saturday, 23 August 2008

Flex Programming

The last week has seen me focus on completing a programming exercise using Flash and the Flex development tools. It is difficult to believe that after 17+ years in the computing industry programming on a wide range of equipment and in a range of languages, and 17+ years of teaching students to program at tertiary institutions, that I am having to prove that I am capable of programming and of learning new environments quickly. Still if that is what it takes then we will do it.

I wasn't overly confident to begin with as I have found JavaScript frustrating and Flex using a combination of an XML based language for developing the layout and ActionScript. ActionScript and JavaScript are very similar sharing a common standard of ECMAScript. The company also wanted me to use a particular model-view-controller (MVC) framework for the exercise so there was quite a bit to learn. They also mentioned a FlexUnit testing framework and as I don't go the simple path, I decided that I would use that as well especially as they claim to use agile methods and I prefer test-driven or behaviour-driven approaches.

Over the last week, I have downloaded Flex Builder, the frameworks, borrowed books from the library, and set about learning the language, environment, and frameworks. There are two testing frameworks so I compared both a selected the one that I found easier to use. The end result was a small data entry system that felt more like a desktop application rather than a web-based application.

Maybe using a solution like Flex would give me an easier road to the type of facilities that I want to offer on our website. Flash is one of the options for displaying the 360 and spherical images so it would integrate nicely. Watch this space.

One of the things that I did with this exercise was write journal entries on the experience. Others have done this and published them on the web. I think I still need to learn about writing up the details as the entries make sense to me but have few code examples.

Three significant learning issues came out of the experience.

  1. When I installed Flex builder, it told me that I needed to update the Flash Player but I was sure that I already had the latest version installed so declined. Well, I did have the latest player installed but not a version that incorporated the debugger. Without the debugger feature, I couldn't step through the code and the testing frameworks simply reported success of failure. They didn't provide me even with the expected and actual reporting line. Once I was frustrated enough to try and resolve why the debugger wouldn't work and reinstalled a version of the player that incorporated the debugger, not only was I able to trace execution and use breakpoints, the testing frameworks actually began to report expected and actuals, and gave a stack trace so I knew where the problems were occurring. This made a surprising difference to progress and reduced the levels of frustration. Lesson: If you are told an install that something is out of date then check what the problem is and resolve it before moving on.

  2. Flex Builder doesn't know how to do refactoring other than rename. This proved to be a real frustration as I endeavoured to extract methods or relocate items within the hierarchy. Refactoring and test-driven development go hand-in-hand. Not having one part of the combination didn't lead to good code design. I recognised that I was already too eager to move on to implementing new functionality. Not having the refactoring tools just added to my resistance to get in and improve the code design before moving on to the next feature. I did find that I was fairly naturally looking for ways to reuse already written code and I was a little frustrated that I didn't solve this with a couple of my form panel layouts that only differ by the source of the data in the data provider tag. Moving on, they may differ by more than that but since this was a proof of concept, well proof of skill, exercise that may never happen. Lesson: Ensure that you refactor and look for support in the tools.

  3. I have often heard questions asked in programming forums about how big a step should a test represent. During this process, I often thought that my next test was simply a small step but once I started coding, I found myself running into problems. More than once, I went back and wrote another test that simplified the expected results. Guess what, that often resulted in a much smaller amount of code needing to be added or modified in that step. I am beginning to think that if a test requires more than a couple of lines of code to be added to the production code then the step is too large. Certainly, don't make a test that requires too many variations to be checked to ensure that it works. Guess what! It is likely to cause grief. Part of this project was about ensure a space was covered by a number of rectangles but that none of the rectangles overlapped. The place to start is with a rectangle that covers the whole area then look at two that cover the whole area. When you start looking at overlapping then again avoid having any uncovered area and having multiple overlaps until the basic functionality is there. Grow complexity in small steps. The smaller the better. The debugger becomes a thing of the past. Lesson: Ensure that tests increase the program complexity in as small a step as possible.

I hope this proves helpful to someone.

No comments: