Building blocks of agile modeling

I have heard tons of time the term agile modeling from other developers both in my team and in other teams, with this small article I don’t want to create a reference for the agile modeling process (there are already a lot of resources on-line) but I want to point your attention to some terms and to the procedure I’m used to use during the development of Flex projects.
One of the main issues during the live cycle of a project is the communication between the customer and the development team, what you need is an easy and agile way to define the functionalities of the software that enables the two teams to understand the goals of the project and eventually to change the scope of the features planned for each release.
In order to avoid a situation in which the customer and his team make one all-encompassing set of decision at the beginning of the project you can start to use stories and spread the decision making across the duration of the project.
An user story describe in a very short way a functionality that will be valuable for the customer using a jargon that is not too much technical, moreover a story can be used to track the activity of the development team and to keep track about the conversation between the two main actors of a software development project: the customer team and the development team.
Traditionally the stories are hand written and pointed on a dashboard, so the use of stories is not a way to document a project but a way to represent customer requirements in a very informal way.
In order to write a story that can be useful for the project you have to avoid to put technical statement inside the story, the reason why is that the technology stuffs are related to developers only.
Imagine the simple scenario in which you have to describe the login form of an application, you can put in place these stories

    User can login in the system
    User can recover his password
    User can cancel the login process
    Login form will connect the data base

The first three stories represent a good example, the last one not because this is something that the application need to do but not something that can be clear for the two actors of the development process, move this in the technical specification that will be based on the stories or remove it completely because is quite obvious that some server side interactions are needed in order to run an application.
The key point here is that stories have to be written in a way that customer can evaluate them, project managers can understand them and developers can easily provide information about the time they need to implement the feature.
Sometimes stories are not so simple, imagine if you have to write down stories for a research form in which the user can select multiple and sometimes complex criterion, the functionalities the user can use may be represented with more than a story (remember that stories have to be short), in this scenario you can group them under an epic; an epic can be split into two or more stories (actually I suggest to keep 10 as the maximum number of stories under each epic).
Don’t incur in the mistake to split stories in too much epic and stories until you are able get a story that define all the details, details are a task for the technical specifications that usually (but not always) come after the customer and the development team have complete the stories / epics exercise.
When one of the team need to discuss some details add a note to the story inside the story itself

    User can search for a piece of inventory
        A piece of inventory can be searched accordingly to the price
        A piece of inventory can be searched accordingly to the location
            note: show the location selection

but keep the note as a part of the story itself and if you discuss the story with one of the two teams add relevant information as part of the note.
When you have a story completed you can also add some information about how to test the story, in the real world you can do it writing the tests on the back of the card, otherwise if you use some web application 99% you this option. If you are using another tool you can put the test in a box connected to the story and use the green as the color background.
In order to plan a release with the customer you can put a set of story in a pile (also an Excel file is good enough) in which the stories priority is based on the pile order and use the estimation for the delivery that each developer put on a story in order to understand when the release can be deployed.
If the pile time is not satisfactory for the customer you can split the stories in more than one pile, each pile now represent an iteration of the live cycle of the software.
The time the development team needs to complete a iteration represent the speed of the team and this factor will be the one that a project manager can use to plan new release with the customer without asking a continuous opinion to the development team.
In order to write a good story you can rely to the Bill Wake definition, a good story is
•    Independent
•    Negotiable
•    Valuable to user, customer and developer
•    Estimable
•    Small
•    Testable
Each story has to be as much as possible without any dependency on other stories but if you can’t remove the dependencies you can combine the dependent stories into one larger but independent story or you can find a different way to split the stories.
Stories are negotiable, they are not written contracts or requirements that the software house must implement, stories are short descriptions of functionalities the details of which are negotiated in a conversation between the customer and the development team.
With this approach you can avoid the situation in which a customer is afraid that during the development process everything he said can be used against him.
Actually the stories are a reminder for the developer and the customer to have a conversation then they have to be no more than one sentence or two with some possible notes.
A story has to be valuable for different purposes and so have to be written with a jargon that is understandable for the customer team, the development team and the test users, the best approach is that the customer write the stories but that is not possible the development team have to handle this task carefully.
It is important that the developers are able to estimate the effort to design and develop each story, if the developers or the customers don’t understand the story this is a good starting point for the project manager to write down the agenda of the next meeting.
If the estimation is not possible because there is a lack of knowledge the team can move one or two members on spike, a spike is a brief experiment to learn about an area of the application that is not clear.

Remember always to keep stories small, epics are sometimes difficult to handle but they can be used as well (not too much!).

Stories must be written in a way that make them testable, I mean that a story can be used as a blue print for the unit testing and for the user test, a story is not testable when it comes from a non functional requirement.
Following this building blocks you’ll be able to write good stories and to start to define estimates for each one, the web is full of resources about that so feel free to investigate and learn more on this topic.

Flex item renderers, an expandable list with transitions

I think that each flex developer at a certain point have had the necessity to work with custom item renderers in order to display data in a fancy way.
There is a lot of knowledge around the web regarding this topic but I want to show the process that has driven me to a list that contains custom item renderers with different states and with transitions between each state.
In order to perform this task I’ll show to you how you can create a simple item render, an item renderer with two different states, an item render with some transitions with a visual bug (it’s the default rendering of the list) and one without any bug.
I know that an expandable list can be done also with a VBox and Repeater and that it perform nicely but the list has a caching procedure of the item renderers that is very useful when you have to render on the screen a great number of complex renderers.

A simple item render
Imagine the simple scenario in which your layout require something more than a label in a list and you need to add for instance a “buy now” button, you can create an MXML component

<mx:HBox xmlns:mx="http://www.adobe.com/2006/mxml"
verticalScrollPolicy="off" horizontalScrollPolicy="off"
paddingBottom="5" paddingLeft="5" paddingRight="5" paddingTop="5">
<mx:Button label=" Buy now " enabled="false"/>
<mx:Label text="{data.name}"/>
</mx:HBox>
and set it as the item renderer in the List control
<mx:List id="list" height="300" dataProvider="{listData}" itemRenderer="SimpleRenderer" />

The dataprovider is an ArrayCollection that contain several Article value objects, the class that define an article can be summarized with the following UML diagram

A multi state item render
Imagine now the scenario in which an item renderer needs to show some data and expand itself in order to display on the screen more information about this item, first of all create an MXML component that extends the VBox and that contain three different states, in the first one the component have to show the article name and a button to expand the content

in the second state the component needs to render the price of the article, a “buy now” button and a control in order to expand the third state

In the third state the component has to render the details of the article

In order to complete this task you can define the UI of the component with the following MXML using the <mx:states> tag to define states, label and event handler

<mx:VBox xmlns:mx="http://www.adobe.com/2006/mxml" >
<mx:HBox>
<mx:Button label="Expand" id="_expand" click="currentState='opened'"/>
<mx:Label text="{this.name}"/>
</mx:HBox>
<mx:states>
<mx:State name="opened" >
<mx:SetProperty target="{_expand}" name="label" value="Collapse"/>
<mx:AddChild position="lastChild">
<mx:HBox id="_dataRender"  width="100%" verticalAlign="middle" >
<mx:Label id="_article"  text="Article" width="80"/>
<mx:Label id="_price" text="Price" width="80"/>
<mx:Button label="Order"/>
<mx:Spacer width="100%"/>
<mx:Button label="Show Details" id="_details" click="currentState='details'"/>
</mx:HBox>
</mx:AddChild>
<mx:SetEventHandler target="{_expand}" name="click" handler="currentState=''"/>
</mx:State>
<mx:State name="details" basedOn="opened">
<mx:AddChild position="lastChild">
<mx:Text id="_detailsData" text="Description" width="100%" height="60" />
</mx:AddChild>
<mx:SetProperty target="{_details}" name="label" value="Hide Details"/>
<mx:SetEventHandler target="{_details}" name="click" handler="currentState='opened'"/>
</mx:State>
</mx:states>
</mx:VBox>

If you come back to the list and set this component as an item renderer you will see that the nested states are not rendered, you have to define the List as a variable row list

<mx:List id="list" height="300" dataProvider="{listData}" itemRenderer="SimpleRendererStates"  variableRowHeight = "true" />

Now the list is able to render the nested states but if you scroll up and down the list you will see that the states and the data of each item renderer are not consistent with your model, this is due to the List behavior that recycle components in order to render data, when items scroll out of view, its itemRenderer will be moved to the bottom of the list.
In order to keep state and data consistent you have to perform some changes in your code, first of all my suggestion is to create a class that can hold state information and data of each item (in this way also if you work with remote value object you don’t need to make any change on the server side), the class can be summarized with the following UML diagram

the state property contains a string that represent the currentState of the component, the renderData property represents the data you need to display in the components.
Inside your component override the public data method in order to be sure that each time the data changes (each time the list is scrolled) the UI elements are updated

override public function set data(value:Object):void{
super.data = value;
if(!data)return
var dt:Article = data.renderData;
if(_article)_article.text = dt.name;
if(_price)_price.text = String(dt.price);
if(_detailsData)_detailsData.text = dt.description;
invalidateProperties();
dispatchEvent(new FlexEvent(FlexEvent.DATA_CHANGE));
}

Please not that in the method the article value object has been extracted from the object used to define the data of each item.
In order to keep track of the state of each item render override the currentState method and store the value of the new state in the model

override public function set currentState(value:String):void{
super.currentState = value;
if(data)data.state = value;
}

Now is the time to handle the state value in the commitProperties protected method

override protected function commitProperties():void{
super.commitProperties();
if(!data)return;
currentState = data.state;
}

The List component needs to know the dimension of the item render in order to gracefully adapt each item to its state, this is the reason why in the measure() method you have to explicitly set the values of the properties measuredHeight and measuredMinHeight for each state

override protected function measure():void{
super.measure();
if(!data)return;
switch(true){
case currentState == "":
measuredHeight = 30;
measuredMinHeight = 30;
break;
case currentState == "opened":
measuredHeight = 70;
measuredMinHeight = 70;
break;
case currentState == "details":
measuredHeight = 110;
measuredMinHeight = 110;
break;
}
}

If you compile your application now the item renders display the data and the states in a consistent way.

A multi state item render with transitions
In order to add a transition between each state of the your item renderer add the following MXML tags to the previous component and save it with a different name

<mx:transitions>
<mx:Transition fromState="*" toState="*">
<mx:Resize target="{this}" />
</mx:Transition>
</mx:transitions>

If you try now the list with this item renderer you’ll be surprised, the transitions don’t perform very well because the item renderer doesn’t know anything about the state in the data method so use an event handler for the StateChangeEvent.CURRENT_STATE_CHANGE event

protected function onStateChange(e:StateChangeEvent):void{
if(!data)return
var dt:Article = data.renderData;
if(e.newState == ""){
dt.opened = 0;
}
if(e.newState == "opened"){
dt.opened = 1;
}
if(e.newState == "details"){
dt.opened = 2;
}
}

and store a specific int value in the opened property of each value object.
In the overridden data method add a switch case to handle this value

switch(true){
case dt.opened == 0:
currentState = "";
break;
case dt.opened == 1:
currentState = "opened";
break;
case dt.opened == 2:
currentState = "details";
break;
}

Now your item renderer is able to handle state and transitions but you’ll see that scrolling the List when it has to render again an item each transition is rendered with a delay, this is due to the live cycle of the List that calls a last udpateDisplayList after a while, in order to solve this stuff you have to put your hands inside the List source code and create an easy reusable class for the item render.

A smart multi state item render with transitions
Surfing the web I found a nice article on item renderers but when I read this sentence “I think a resizing itemRenderer is too complex and not really worth the effort. I believe there is a better way to do this using VBox and Repeater. However, the catch with Repeater is that every child will be created. If you have 1000 records and use a Repeater, you will get 1000 instances of your itemRenderer.” my mind started to think to a solution because with a great number of instances of a complex item renderer the performance of each Flex application can be seriously impacted.
I started to read the source code of the List and I found the two methods that recycle or create the item renderers in the list

getReservedOrFreeItemRenderer(data:Object):IListItemRenderer
createItemRenderer(data:Object):IListItemRenderer

In order to avoid the delay I need to change the state of each item renderer in these two methods, the first issues I found are that the transitions defined in the item renderer stop to work and that the height is not rendered.
The other issue I found is that without a base class each time I would like to use smart item renderers in my List I have to start over.
The solution I found is create a VariableRowList  class that extends the List, define a base class for item renderers (I started with a class for VBox based item renderers), define an interface that define a method to use in order to update the state and the height and define the effects I need outside the <mx:tranisitions> tag.
The VariableRowList  class makes an override of the methods used in order to create and recycle the item renderers and attempt to call the method defined in the interface ISmartRenderer the renderer needs in order to handle its state and its height at the end of each method

try{
ISmartRenderer(item).updateState(dt.state);
}catch(e:Error){
trace("It's not an ISmartRenderer implementors")
}

The ExpandableVBoxRenderer class first of all implements two interfaces, IDropInListItemRenderer and ISmartRenderer, and define a constant that hold an array of objects used to define the heights for each state

protected const STATES_HEIGHT:Array = [{state: "", height: 30}, {state: "opened", height: 60}, {state: "details", height: 110}];

In the constructor of this class you find the definition of a listener for the StateChangeEvent.CURRENT_STATE_CHANGE  and for the FlexEvent.CREATION_COMPLETE events and the policy for the scroll bars

this.addEventListener(StateChangeEvent.CURRENT_STATE_CHANGE, onStateChange);
this.addEventListener(FlexEvent.CREATION_COMPLETE, onCreationComplete);
this.verticalScrollPolicy = ScrollPolicy.OFF;
this.horizontalScrollPolicy = ScrollPolicy.OFF;

The override of the data method use a protected method populateControl() that use the data stored in the  renderData property of the SmartRenderData class in order to populate the UI elements (this method is empty and need to be overridden from the classes that extend the ExpandableVBoxRenderer)

override public function set data(value:Object):void{
super.data = value;
if(!data)return;
data.state = currentState;
populateControl(data.renderData);
invalidateProperties();
dispatchEvent(new FlexEvent(FlexEvent.DATA_CHANGE));
}

In the override of the measure method the class calculates the needed height trough a private method that get the data from the STATES_HEIGHT constant

override protected function measure():void{
super.measure();
if(!data)return;
var currentHeight:Number = recoverHeight(currentState || "");
measuredHeight = currentHeight;
measuredMinHeight = currentHeight;
}

The updateState method defined in the ISmartRenderer interface update the state and the height of the component and call the measure method

public function updateState(state:String):void{
currentState = state;
height = recoverHeight(state);
measure();
}

If you want now start to use this stuffs define the namespace you need to use the VariableRowList   class in your application and place these tags in place of the List you have used before

<gn:VariableRowList dataProvider="{listData}" itemRenderer="it.mxml.expandableList.view.ExtendedRenderer" />

Define now a new class that extends the ExpandableVBoxRenderer and use it as the base class for a new MXML component that will have the same tags of the one you defined in order to handle the transitions except for the transitions that will be removed and that will be substituted from the following effects

<mx:Resize id="openInfo" duration="205" heightFrom="30" heightTo="60" target="{this}" />
<mx:Resize id="openDetails" duration="205" heightFrom="60" heightTo="110" target="{this}" />

Came back in the class and define the public members that point to the controls defined via MXML

[Bindable]public var _article:Label;
[Bindable]public var _price:Label;
[Bindable]public var _detailsData:Text;
[Bindable]public var _details:Button;
[Bindable]public var _expand:Button;

Override the populateControls() method in order to render the data inside the item renderer

override protected function populateControl(data:Object):void{
if(_article)_article.text = data.name;
if(_price)_price.text = data.price;
if(_detailsData)_detailsData.text = data.description;
}

and define the handlers for the click event on the buttons in order to play the effect defined trough MXML (see in the source of the sample application to check the other handlers)

private function onDetails(e:MouseEvent):void{
if(e.target.label == "Show Details"){
currentState = "details";
this["openDetails"].play()
}else{
currentState = "opened";
this["openDetails"].play(null, true)
}
}

In this way your List will be able to render the data and the transition like a charm, check the sample application and the source code (right click, view source) in order to read the complete implementation.

Resources
http://www.returnundefined.com/2006/10/item-renderers-in-datagrids-a-primer-for-predictable-behavior

http://blogs.adobe.com/aharui/item_renderers/

http://flexdiary.blogspot.com/2007/11/order-of-events-for-itemrenderers.html

http://www.adobe.com/devnet/flex/articles/itemrenderers_pt4_print.html

Flex and SVN

I’m sure that tons of flex developers has already used SVN during the development of their projects but I have seen sometimes great difficulties when during the development of a project different coders need to modify the same file or add a file to a project. In the first situation the way to handle merge is not really intuitive, in the second one most of the times the file is not committed.

For this reason I decided to write some notes on SVN and TortoiseSVN 1.5.4 that has been recently released.

First of all please be sure to use a sane repository layout. There are many ways to lay out your repository. Because branches and tags are ordinary directories, you’ll need to account for them in your repository structure. The Subversion project officially recommends the idea of a “project root”, which represents an anchoring point for a project that contains exactly three subdirectories: /trunk, /branches, and /tags.

“trunk” is supposed to signify the main development line for the project. You could call this “main” or “mainline” or “production” or whatever you like.

“branches” is obviously supposed to be a place to create branches. People use branches for a lot of purposes. You might want to separate your release or maintenance branches from your feature branches or your customer modification branches etc.

“tags” are not treated as special by Subversion either. They are a convention, perhaps enforced by hook script or authoring rules, that indicate you are creating a point in time snapshot. Typically the difference between tags and branches is that the former are not modified once they are created. You might call your tag folders “releases” or “snapshots” or “baselines” or whatever term you prefer.

Be sure to Commit logical change set. When you commit a change to the repository, make sure your change reflects a single purpose: the fixing of a specific bug, the addition of a new feature, or some particular task. Your commit will create a new revision number which can forever be used as a “name” for the change. You can mention this revision number in bug databases, or use it as an argument to SVN merge should you want to undo the change or port it to another branch.

Merging changes sounds simple enough, but in practice it can become a headache. The problem is that if you repeatedly merge changes from one branch to another, you might accidentally merge the same change twice. When this happens, sometimes things will work fine. When patching a file, Subversion typically notices if the file already has the change, and does nothing. But if the already-existing change has been modified in any way, you’ll get a conflict.
Ideally, your version control system should prevent the double-application of changes to a branch. It should automatically remember which changes a branch has already received, and be able to list them for you. It should use this information to help automate merges as much as possible. Unfortunately, Subversion is not such a system. Like CVS, Subversion 1.0 does not yet records any information about merge operations. When you commit local modifications, the repository has no idea whether those changes came from running SVN merge, or from just hand-editing the files.
What does this mean to you, the user? It means that until the day Subversion grows this feature, you’ll have to track merge information yourself. The best place to do this is in the commit log-message.

Let’s take a look to a practical Flex development situation, first of all you have to install Tortoise SVN on your machine and create an empty folder for your project (I’m supposing that you have already started to work on some stuff and that is the time to go under source control and that you are the one that will create the repository).
Right click on the folder and select the import option

01.gif

In the dialog that appears insert the data for the remote repository

02.GIF

Right click again and perform the check out, now your folder is synchronized with the remote repository.
Copy the files you need in the folder and perform a commit, you’ll be prompted to select the files you want to commit

03.PNG

It’s a good habit to remove properties, project, bin-debug, bin-release, etc. in order to perform this task you can deselect the files from this dialog or you can select a specific file, right click and remove it or all the files with the same extension from the synchronization of the repository

04.gif

Now you are able to work quite easily with SVN but remember that

·         in order to rename a file or a folder you must first checkout the file or folder to your machine. Once it’s on your machine, right-click on the file or folder, and select the menu option SVN Rename,

·         in order to delete a file or folder, simply right-click on it, and select the Delete… option from the Tortoise SVN menu

·         to add a file or folder, check out the repo (if you haven’t already done so). move the new file(s) and folder(s) to the location you want them in the repository (for e.g. to add the file newfile.mxml to the mxml/trhunk/newclient/ folder, move newfile.mxml to that folder). Now, with everything in its place, right-click on the file(s) and folder(s) you want to add to the repository, and select the SVN Add… menu option

Basically all the usual operations of an operating system needs to be performed trough the Tortoise SVN contextual menu.

SVN is not a back-up system, is a way to handle versioning and conflict, what happens if you make some changes to a file and another developer make the changes to the same file and both of you make a commit at the end of your working day?
SVN will try to make a merge but sometimes it’s not possible so be careful when you do the commit and use the Check for modifications function from the Tortoise SVN menu option

05.gif

If something goes wrong during the merge you’ll keep your work safe because in the file you are committing SVN will add the change log in the code

<<<<<<< .mine

                var beautiful:int = 5;

=======

                var ugly:int = 5;

>>>>>>> .r10

and in your folder you get a copy of the file with the release name.
I wasn’t a fun of SVN the first time I used but now I am happy to say “It works!”.

Resources
http://electricjellyfish.net/garrett/talks/oscon2004/svn-best-practices/
http://blog.evanweaver.com/articles/2007/08/15/svn-branching-best-practices-in-practice/
http://www.iovene.com/5-svn-best-practices/
http://svnbook.red-bean.com/en/1.4/svn.tour.cycle.html
http://www.changelogic.com/SvnProjectSetup
http://svnbook.red-bean.com/en/1.0/ch05s04.html#svn-ch-5-sect-6.1