Tuesday, 16 June 2009

Mocking Flex Services

This exercise started as an attempt to be able to test drive the development of an application that used the Cairngorm framework. It turned into implementing a framework that allowed us to mock out the data services and to develop without having the back-end server code available.

This seemed a difficult task until I realised just how dynamic the foundation of Flex really is. The RemoteObject class is a dynamic class. All dynamic classes should extend the Proxy class. Basically, the Proxy class defines the default behaviour for method calls (callProperty) and properties (hasProperty, getProperty, setProperty) that are undefined. By using a Dictionary object, it is easy to redefine these methods and dynamically add functionality to any class.

With my initial experiments, I defined my own RemoteObject subclass that overrode the default callProperty method. This stored the name of the method called and the number of parameters (these come in as an array). This allowed me to write fairly simple tests to ensure that the command / delegate combination of Cairngorm was doing what I expected.

Once I had satisfied myself that the mechanism was working the way that I expected, I added methods to my RemoteObject that allowed me to define the operations and the data that would be returned or possibly to send a fault message back to the caller. In the process of experimenting, we discovered that properties could be added to classes even if the class wasn't declared as dynamic.

The RemoteObject returns an AsyncToken object. It is to this object that the responder object is added. Although the AsyncToken doesn't call the responder, for the purposes of mocking the operation of service calls, it was easier to create a mock AsyncToken and have that call the responder methods as required.

One small trap occurred. I needed to add a delay so that the call to the responder behaved more like a true asynchronous operation. If I didn't, there were some places in our code base that would fail since the response would be received before it was expected. Although the Flash environment is event driven, the Flex code is single threaded. A call to an event handler actually occurs when the event is fired. The solution for mocking purposes is to use a timer event to introduce a delayed event.

When I started this process, I thought it might be more difficult to achieve than it worked out to be. The reason that it proved relatively easy is in part to the dynamic nature of Flex.

Sunday, 14 June 2009

Building a Flex multiple selection drop down component

In the project that I have been working on, we wanted to be able to have a drop down box that allowed multiple selections from a list and another that allowed multiple selections from a tree structure. The default behaviour of the Flex combo box is to allow the selection of one item. As soon as an item is selected, the drop down closes and the selected value is displayed in the combo box. In order to determine what the selected item is, the programmer has to interrogate the combo box or use an event handler to capture the selection. This behaviour presented some problems when endeavouring to implement an application using a model-view-presenter style of programming. It was even more difficult to follow when requiring multiple selections.

Examining solutions to multiple selection showed that many programmers had worked out ways of programming around the combo boxes behaviour. We also originally took this path but could never quite get the box to behave the way we wanted. It either closed unexpectedly or didn't reflect the current selections. It was time to rethink the fundamental design of the combo box.

What did we anticipate as the behaviour for our multiple selection control. We wanted a button control that looked like a combo box that when clicked displayed a drop down of either a list of values or a tree of values. We didn't just want the drop down to display the selected items highlighted, we wanted a check box that would show the selected items. For the tree, we wanted to go one step further and have a node and its branch selected when the node was selected. The button should indicate the number of items selected and a tool tip should show a list of the items selected. We were seeking some fundamental changes to the operation of the combo box.

To address our behavioural requirements, we decided that we needed at least three components. The base button, the drop down control, and a data model that reflected the state of the control. The next issue was to assign behaviours and here I will admit that we didn't always make the best decisions. However, programming is about learning so we have learnt and adapted our design. What I describe here is more of a proposal for the next iteration in the design.

The button has responsibility for opening the drop down and reporting the state of the selections. It makes no attempt to retain the selection state or dictate the closing of the drop down or the selection process. In some respects, it is a fairly simple button. It depends on the drop down and the model to find out the current state of the selections and the drop down control.

The drop down and the model are closely related. If a tree control is used for the drop down then the data model needs to reflect the tree structure (OK, in Flex, the data model doesn't need to be a tree if you implement a descriptor that will make the model appear as a tree but that is another issue). In our case, we implemented a selectable collection and a selectable tree data structure. These not only held the data but also reflected the selection status of the items. The data model also returned a count of the selected items and a text list of the selected items. The model is responsible for maintaining the state of the control's component parts.

The drop down looks after knowing how it should be opened and how and when it should be closed. It also knows how to interpret the underlying data model to produce the appropriate selection states on the screen. The drop down control is concerned with how to present the data and not with how to manage the state of the data.

To make the control components more flexible, they should be implemented to a standard interface. That way, the button component can use a factory object to build the drop down and not be concerned as to the type of the drop down or the behaviour of the drop down. A similar principle applies to the data model. This way, the programmer can extend the model to new applications without having to redevelop from scratch.

There is another issue that I am still working through. Should the data model provided to the control conform to the controls requirements or should there be a factory object that can build the data model required by the control? Using a factory would mean that the control could be reused in a wider range of applications without enforcing the programmer to know how to prepare the data. For more complex data structures, the programmer may need to provide mechanisms for interpretation but that isn't really a major issue.

So far we have versions of these controls for a list and for a tree but I see the next being for selection from a grid of icons. As time permits once we settle in the UK, I may look at developing these controls for the open source market. My primary concern is that as many of the components making up the controls are reusable and reflect a flexibility of design.

Religion as the opiate of the people

Barclay in his commentary on Luke's Gospel talks about the Romans encouraging “religion from the cynical motive that it kept people in order. They regarded it as the opiate of the people” (p 85). This same view is portrayed in games such as Civilisation IV.

To some extent, there is validity in this view, since “religion is a man-made activity” (Knight 1981). Unfortunately, we use the word randomly for any belief or practice of faith when we really should be applying it to our economic practices and love of money.

I don't doubt that there are people who claim to be Christian who are doing little more than the rituals on Sunday. In that sense, they are practising their religion. However, there are many more for whom their walk of faith is about a way of living. The association between a belief in Christ and being religious is wide spread but it is possible to have a belief in Christ and not be religious. The idea of belief in God being a way of life isn't a new invention nor one that Christ introduced. Knight when he talks about Leviticus 19:1-4 says “the word “religion” does not occur in the Old Testament” (p 114). God wasn't talking to Israel about a religion or religious practices. He was calling them to be a congregation, a witnessing community. A community that lived out their faith in every act of their lives.

Knight argues that this is reflected in the Leviticus laws through their emphasis on family life and relationships with people. Every law called for a higher standard of ethic than anything that was practised at the time. Knight talks about an eye-for-an-eye as being a higher level of code than the retribution of life for an eye that was happening at the time and could be argued continues in many places around the world even today. Jesus took that ethical stand further calling for us to love our enemies. Something that is not easy to do.

Maybe those computer games that portray religion need to consider the idea of portraying faith or a religion that actually has real influence on the way that people live. Many things have been done in the name of Christianity that are a long way from being what God called for. Those that have done these things have often believed they were upholding the faith but in the end, they destroyed the very witness that God is calling for. The Old Testament is full of examples and God's continual call to Israel to uphold his calling on their lives. The result of their lack of being the congregation, a witnessing community continues in the bitter confrontations of the middle east.

I have no problem in being negative about religious practices that see people living a double standard but I do have problems when this is then equated with any belief in God being unacceptable. In computer games and other media, we need to restore some of the positive messages of being a witnessing community and one that really strives to live out its faith despite our many failings.

Religion can be an opiate of the people, a way of keeping them satisfied but real faith stirs people into action to live out their beliefs in a world that often rejects and discards the believer.


Barclay, W. (1975). The gospel of Luke (revised ed.). Edinburgh: The Saint Andrew Press.

Knight, G. A. F. (1981). Levitcus. Edinburgh: The Saint Andrew Press.

Writer's workshops

I have been meaning to write this blog entry for quite some time. My notes and personal journal writing date it back to early February. Strange but I have a range of themes that date back a long way. Sometimes they sound like a good idea and then drift out of focus.

The writer's workshop has is a tool used by literary writers and picked up by the pattern writing community. Richard Gabriel wrote a book (2002) to help the pattern writing community but it has wider applicability.

When I was reading Gabriel's book, I was looking at ways of fostering interaction in a software architecture forum. Gabriel had mentioned his use of the workshop in this type of context so I felt it was worth trying.

The basic principle of the writer's workshop is to provide feedback to the author of a work in a fairly positive environment. The authors work is circulated before hand so that participants get an opportunity to read it and prepare comments.

During the workshop, the writer has a brief opportunity to read a portion of the work and to point towards something that they would like the group to look at. The writer then steps back and takes no further part until invited to do so at the end of the session.

The moderator then directs the session. Comments during this section should always be made as though talking to other group members and not to the author.

This starts by endeavouring to summarise the work. This isn't a time for judgement but simply trying to show that the participants have picked up the theme of the work and to come to a consensus about its intent. The author will pick up quickly whether they have presented the key thoughts well.

The next stage is highlighting the good things about the piece of work. This helps focus on being positive rather than negative and helps the author see what things people like about their writing.

The next step is suggestions for improvement. Although there is some implied criticism of the work in this section, the goal is to ensure that each criticism has a positive suggestion for improvement. This isn't so much telling the author what to change as providing some feedback about how the work might better communicate its message.

The final step is to invite the author back into the discussion. Since the author has heard all the comments, they get a chance to gain clarification and to some extent respond. The aim isn't to be defensive about the criticism but to try and improve the understanding of the issues.

The moderator then thanks the group for their contribution and in the pattern writers' workshop often a small gift is given to each participant by the author. This is an appreciation of their input on the writer's work.

One of the reasons that I have put this up as a blog is to encourage feedback on some of the topics that I raise and in particular some of the design ideas that I will be putting forward. I also hope that it will be the tone of this blog going forward. I don't want to be a negative critic nor do I want to claim to be some outstanding expert or genius. We all have something to contribute either large or small. Ideas can really be improved through sharing and open supportive discussion.


Gabriel, R. P. (2002). Writers' workshops and the work of making things: Patterns, Poetry ... Boston: Addison Wesley.

Sunday, 7 June 2009

Everyone's a gambler

As we travelled to Feilding for a family celebration for Marilyn's parent's 60th wedding anniversary, we heard the song “gambler.” That song talks about the gambler needing to “Know when to hold them, know what to throw away, know when to walk away and know when to run.” In our present state of sorting through all that we have gathered together over 35+ years of marriage, those words seemed really appropriate. We are having to think about what to hold on to and what to throw away.

But there is a wider significance to that theme. How much of what we have held on to has actually hindered our ability to move forward. We look at a lot of what we have collected and sometimes see it as something that stops us being ready for the next challenge. Discarding some of the physical baggage that we have collected is freeing us to move forward. But it isn't just physical baggage that can hold us back. Often we are held back by our perceptions of how things should operate or be done, or maybe concerns of perceptions of what others might think of us. This baggage often has to be discarded as well so we can move forward.

Over the last six months, I have been working again in an industry position but in this position, I have brought the perspective from my research where I examined the perceptions of programming practitioners. In the work place, I have seen different perceptions in action. I have observed the impact of these perceptions on the code structures produced and on the approach to the task. It would have been wonderful to have been recording discussions and collecting code samples so they could be analysed later but that hasn't been done. All there are are my observations.

But it isn't simply the perceptions about programming that I have found interesting, it is also perceptions about the current recession and approaches to economic management. This is where the gambler song really begins to challenge me. Every step in life is a gamble and that gamble will always be based on the perceptions that we have of the cards that we hold in our hand at any given time. Is the glass half full or half empty? Does it matter how we perceived the state of the glass? I would argue that it does and it will impact how we respond to the events that surround us each day.

How do we perceive employment and the financial system? Does it make a difference? Just this week someone commented on the collapse of General Motors in the US from the perspective of the effects of the lay-offs on the employees. The comment was along the lines of they need employment. Well, do they? What economic perspective says that they need employment? They may need something to occupy themselves that helps bring self worth and they may need some cash flow so they can purchase things they need for living but is this necessarily employment?

Employment to some extent is about distributing purchasing power. It doesn't necessarily mean that people have to be doing meaningful jobs. Some would argue that many jobs aren't actually needed since they produce for a stimulated demand rather than an actual need. If this is the case then how can purchasing power be distributed in a way that doesn't ask people to doing unproductive work.

Of course, we probably should also ask the question of how the distribution of purchasing power was funded. This to me is the real cause of the problem. The funding was achieved through debt financing. The generation of credit in the capitalist system is through borrowing against future wealth. At some point, this debt either has to be repaid or cancelled out. The current process is quite simply cancelling out large chucks of debt. The booms and bust cycles of capitalism are the basis on which the system is built. For a period, the debt increases and growth occurs then there is a collapsing of the debt and a shrinking of the economy. The credit has run out and unless someone wipes it out, then everyone feels the pain as jobs are lost and people are unable to buy the necessities for life.

Western society has brought into a financial mindset that distributes purchasing power through employment and debt financing. That debt financing acts as a control over the people. They lose their freedom to satisfy their needs other than through being enslaved to employment.

The financial system was created by people. It isn't something that exists independently of the people within it. Governments invent rules so they can control how people operate within the economy. Those rules try and restrict the mechanisms for the exchange of the needs of life.

A country's credit rating endeavours to dictate how much the country can borrow and the interest rate attached to that borrowing. But why is the government borrowing for what already belongs to the country. Governments should tell the credit rating organisations to get lost and focus on generating the credit that is need for the country to operate.

In New Zealand, a major court case has just ended. A discussion on a radio program talked about the legal aid bill. That is a debt against the government and is paid for through borrowing or taxes on the people. What did the court case produce? Hopefully justice but the side effect is a bigger debt on the nation. Why can't that debt be written off as a requirement for justice. Without justice, we would have lynch mobs. Of course, it could be argued that the lawyers could have controlled their costs better but there still would have been costs. It is how those costs are paid that can either bring freedom to a country or cripple it through financial slavery. That decision is in our hands.

What baggage are you going to hold on to and what baggage are you going to throw away? What baggage do you want to hold on to in our systems and what baggage do you want to be seen thrown away? What are you vested interests in the current system?