•    memorization
•    converting from top-down to bottom-up

Another very common problem when dealing with dynamic programming is the longest common subsequence problem (for brevity since now “LCS”). The “LCS” problem is as follows

We are given two strings: string S of length n, and string T of length m. The goal is to produce their longest common subsequence: the longest sequence of characters that appear left-to-right (but not necessarily in a contiguous block) in both strings.

The problem can be solved comparing the two strings; in the case S and T have a different length the desired subsequence has to ignore the ending elements of one of the two strings, in the case S and T have the same length all the characters have to be considered.
As subproblems the algorithm will look at the “LCS” of a prefix of S and a prefix of T, running over all pairs of prefixes. For simplicity, let’s worry first about finding the length of the LCS and then we can modify the algorithm to produce the actual sequence itself.

The longest common subsequence(LCS) problem is one of the classical and well- studied problems in computer science. The computation of the “LCS” is a frequent task in DNA sequence analysis, and has applications to genetics and molecular biology.  Another practical application of the “LCS” algorithm is in order to compute the file differences.

Theoretically speaking the algorithm just fill out a matrix row by row, doing constant amount of work per entry, so this takes T(mn) time overall. The work actually performed is a comparison between the chars of the two strings at specific indexes.
The final answer (i.e. the length of the LCS of S and T) is in the lower-right corner.
To find the common sequence, the algorithm just walk backwards through matrix starting the lower-right corner.
If either the cell directly above or directly to the right contains a value equal to the value in the current cell, then move to that cell (if both to, then chose either one). If both such cells have values strictly less than the value in the current cell, then move diagonally up-left, and output the associated character.
This will output the characters in the LCS in reverse order.

Consider a practical example and search the “LCS” of the following strings

•    ABAZDC
•    BACBAD

The algorithm will fill out a matrix like the following one and running backward the matrix the output will be DABA that is the “LCS” between the two strings.

From a  practical point of view the following diagram shows up the classes involved into an ActionScript “DP” solution to the problem.

Let’s start to examine what model used by these classes.
The class LCSTable is the one to use in order to represent the matrix outlined at the beginning of the post, for this reason the constructor accept two arguments that represent the rows and columns of the matrix (i.e. the length of the two strings that will be examined) and use them to create an Array of Vectors

public function LCSTable(rows:int, columns:int){

	_table = [];

	for(var i:int = 0; i <= rows; i++){

		table[i] = new Vector.(columns + 1, true);

		for(var j:int = 0; j <= columns; j++){

			table[i][j] = new LCSCell(0, LCSCell.UNDEFINED);

		}
	}

}

The property _table is exposed through a public getter and return the array of Vectors that is the way all the cells are represented into the model.
The LCSCell class is pretty simple, it stores the total number of matching strings and the direction the algorithm has to follow to walk backwards through matrix starting, the direction is stored into four static constants

• public static const UP:String             = “^”;
• public static const LEFT:String         = “<”;
• public static const DIAGONAL:String     = “\\”;
• public static const UNDEFINED:String     = “+”;

when the LCSTable create the new cells set the direction to UNDEFINED and the total to 0.

The core of this solution for the longest common subsequence problem is the LCSParser class, let’s start to explore it.
The constructor of the class needs two arguments (i.e. the strings to compare) and store them into two private members of the class

public function LCSParser(first:String, second:String){

	firstString = first;
	secondString = second;

	init();
	populate();

}

The protected method init() store the number of columns in other two private members and initialize the table setting the default values of the cells (i.e. direction UNDEFINED and total 0)

protected function init():void{

	_lcs = "";

	columns = firstString.length;
	rows = secondString.length;

	table = new LCSTable(rows, columns).table;

}

The populate() method creates two local variables to keep track of the total numbers of matching strings for each column and start the exploration of the LCSTable with tow nested for loops

var totalTemp1:int;
var totalTemp2:int;

for(var i:int = 1; i <= rows; i++){

	for(var j:int = 1; j <= columns; j++){

              // Additional code here

        }

}

In the body of the loop the method checks if there are matching characters or not in the two stored strings. If there is a match the current cell is updated considering if it belongs to the first row or column of the table (in this situation the total is 0 and the direction is intentionally left as UNDEFINED) or not.
When updating the cell the local variable totalTemp1 is used in order to increase the total property of the LCSCell instance properly.

if(firstString.charAt(j - 1) == secondString.charAt(i - 1)){

	var currentCell:LCSCell = getCell(i, j);

	if (i == 0 || j == 0) {

		currentCell.total = 0;

	// if not, set it to 1 plus the value of its upper left element
	} else {

		totalTemp1 = getCell(i - 1, j - 1).total;

		currentCell.total = totalTemp1 + 1;
		currentCell.direction = LCSCell.DIAGONAL;							

	}						

}else{

	totalTemp1 = getCell(i - 1, j).total;
	totalTemp2 = getCell(i, j - 1).total;

	updateDirection(getCell(i, j), totalTemp1, totalTemp2);

}

If there are not matching chars the method updateDirection() is called.
This method consider the position in the table (i.e. actual row and column) and update the direction and total accordingly to the position

private function updateDirection(cell:LCSCell, s1:int, s2:int):void{

	if(s1 >= s2){

		cell.total = s1;
		cell.direction = LCSCell.UP;

	}else{

		cell.total = s2;
		cell.direction = LCSCell.LEFT;

	}

}

Once the table is populated the public method lcs() can be used to recover the longest common subsequence.
The method calls another one to walk backwards through matrix and return a string

public function get lcs():String{

	parseLCS(secondString, rows, columns);
	return _lcs;

}

The parseLCS() method uses recursion and populate the _lcs property accordingly to the direction of each cell

private function parseLCS(data:String, i:int, j:int):void{

	if ((i == 0) || (j == 0)){

		return;

	}

	var currentCell:LCSCell = getCell(i, j);

	if(currentCell){

		if(currentCell.direction == LCSCell.DIAGONAL){

			parseLCS(data, i - 1, j- 1);
			var temp:String = data.charAt(i - 1);
			_lcs += temp;

		}else if(currentCell.direction == LCSCell.UP){

			parseLCS(data, i - 1, j);

		}else{

			parseLCS(data, i, j - 1);

		}

	}

}

A fully working demo is available here with the source code included (right click -> view source),  please feel free to use it as you want but please provide me as much as possible your feedback.

Just in case you would like to go deeper on this topic following you can find some interesting linka

• http://en.wikipedia.org/wiki/Dynamic_programming
• http://wordaligned.org/articles/longest-common-subsequence
• http://igm.univ-mlv.fr/~lecroq/seqcomp/node4.html

Enjoy with dynamic programming!

•    Credit Card
•    OnLine payment
•    Other payment

For each of these families you may have the need to define multiple objects when you system starts

•    Credit Card
o    Visa
o    American Express
o    Master Card
•    OnLine payment
o    Paypal
o    E-check
•    Other payment
o    Wire transfer
o    Check

and add even more objects when the system grows or when new payment methods will be released over the net.
In an e-commerce system you may also have the need to show to the user the appropriate payment system accordingly to his preferences, in order to increase the abstraction of your system you can define multiple Abstract classes and keep the system ignorant on which particular implementation is in use because the factories are the responsible to instantiate them.
Imagine the scenario I described an put it in an UML diagram

The application is composed by a form that contains a submit button and the form fields vary accordingly to the user preferences retrieved by the system.
The CheckOutFactory class is an abstract class that have two concrete implementations able to return to the client the UI needed for each payment (actually the MXML representation of the class). The PaymentContainer is a VBox with a property used to store a reference to the payment form created from the factory that implements an interface that defines two common methods of the payment forms

•    validateFields()
•    submit()

As you know ActionScript 3.0 doesn’t support abstract classes, so the CheckOutFactory simulates the abstraction of the class trough the use of an internal class in its constructor.
Another good way to implement the abstraction is the use of interfaces, this is the reason why I defined a common interface ICheckOut and two other interfaces (IOnlinePayment and ICreditCard) that extend the base interface and that will be implemented in the view of each payment form of the system.
Take a look to the class hierarchy in order to understand where we are and where we are going

The abstraction of the on-line and credit card payments is reached through the interfaces put on the top of the onLinePayment and creditCardPayment packaging, the view and it’s logic has been keep separated through the Model View Presenter pattern used from each payment form.
Each presenter implements a public submit() method, in this way you can call in a centralized fashioned way the submit of each form trough the PaymentContainer property named element, each presenter will have the responsibility to recover the data from the view and each view, due to the fact that implements the ICheckOut interface, validate it’s fields (a good idea is to validate each credit card with a different Validator, this is the reason why you find an instance of the CreditCardValidator class in the  credit card payment forms.
In order to run this sample (view source enabled) I created an XML file that stores the name of some users and the payment preferences, each node has the following structure

<user name = "Giorgio Natili" mode = "OnlinePayment" type = "PayPal" />

In the main application a combo box is populated with this data and each time you change the selection a concrete factory is created and through the factory a new view is added to the PaymentContainer

private function onUserSelection(e:Event):void{
checkOutFactory = CheckOutFactory.getPaymentFacotry(e.target.selectedItem.@mode);
var s:String = e.target.selectedItem.@type;
checkOutModule = checkOutFactory.getUI(s.substr(0, 1).toLocaleLowerCase() + s.substring(1, s.length) + ".view." + s + "View");
paymentContainer.element = checkOutModule;
}

The checkOutFactory and the checkOutMopdule properties data type represents the layer of abstraction I’m searching for
private var checkOutFactory:CheckOutFactory;
private var checkOutModule:ICheckOut;
The method defined as a listener for the click event inside the PaymentContainer uses the methods defined in the ICheckOut interface to complete his task

private function doSubmit():void{
if(_element.validateData()){
_element.submit();
}else{
Alert.show("Invalid data in the form...", "Attention!");
}
}

At the end of the day we have a quite flexible sample, but which are the benefits of this pattern? It would be simpler to have a switch instead of all this code?
The main benefit is that if you have to add the support for another credit card you have to deal only with the logic stored in the MVP triad you need to add a payment form and the system automatically will be able to handle the new form.
The switch could be hard to maintain in a situation with more than 4 payment methods, moreover the abstraction layer that the system has reached give to you the flexibility to put each developer you want on the new payment forms the system needs without having to explain to the developer anything about the system itself.

There are other possible contexts in which the Abstract Factory pattern can be used

•    Handle different operating systems API in a cross platform application
•    Different traits for users of an application
•    Different version of an application
•    Different performance guidelines

At the end of the day we can recap with the following points the Abstract Factory pattern

•    You want to have families or sets of objects for particular clients
•    Families of related objects have to be instantiated
•    You want to coordinate the creation of families of objects
•    You need to isolates the rules of which objects are to be made

Obviously this is only a small sample and more complex implementation are out of the scope of this blog entry, so feel free to open a discussion on this topic.

The context is your application or a component in your application, the strategy may be a class or a method that define which algorithm your system can use, the concrete strategies are the classes that implements the algorithm that suits the needs of your system.
One of the most sample and concrete samples of the application of the Strategy pattern is the calculation of taxes inside an e-commerce application.
Imagine the situation in which your application has to deliver products all around the world and to apply different taxes factor accordingly to the country your customer lives, this means to use a different algorithm (a strategy) for each country.
We need to define a strategy and apply a different tax factor for each country, so model your system with the following classes and interfaces
1.    Calculator: an abstract class that implements the main algorithm
2.    ENTaxCalculator: the class that changes the algorithm in order to apply the right amount of taxes for the English customers
3.    ITTaxCaclulator: the class that changes the algorithm in order to apply the right amount of taxes for the English customers
4.    ITaxCaclulator: the interface that defines the common operations of the strategy and that you can use in your system as the algorithm data type and that it’s implemented by all the strategies

Let’s take a look to the implementation…
First of all in order to avoid the instantiation of your abstract Calculator defines an internal class in the same Calculator.as file and use it in the constructor

package it.mxml.utilities.taxes{
public class Calculator implements ITaxCalculator{
protected var _amount:Number;
protected var _taxesFactor:Number;
public function Calculator(enforcer:AbstractEnforcer){
if (enforcer == null){
throw new Error("AbstractException");
}
}
protected static function getAccess():AbstractEnforcer{
return new AbstractEnforcer();
}
}
internal class AbstractEnforcer{
// Do nothing
}

Now you are ready to define your algorithms extending this class Calculator and changing in the constructor the _taxesFactor value (for brevity I removed from here the methods used for calculation but you can get them in the source code of the sample you find here).
Imagine to have in your application a small basket and a method that calculate the taxes to apply, you can create the instance of the appropriate tax calculator through reflection and show the result

private function doCalculate():void{
var lang:String = Capabilities.language.toUpperCase();
var amount:Number = 0;
for each (var item:Object in selectedItems){
amount += item.price;
}
var calculator:ITaxCalculator;
var ClassDefinition:Class;
try{
ClassDefinition = getDefinitionByName("it.mxml.utilities.taxes." + lang + "TaxCalculator") as Class;
}catch(e:Error){
ClassDefinition = getDefinitionByName("it.mxml.utilities.taxes.DefaulTaxCalculator") as Class;
}
}

In the complete sample application you find here you can get also the output of this method.
At the end of the day we can recap with the following points the Strategy pattern
1.    Define a family of algorithms (with an abstract class) in order to solve a particular issue of your system
2.    Define the single algorithms making them interchangeable (use an interface)
3.    Define a procedure that is able to detect automatically the con text and which strategy to use (the appropriate algorithm)
4.    Keep separate the algorithm definition / implementation and the selection of an algorithm

Obviously this is only a Mickey Mouse sample, but following this building blocks you can define great strategies for your system.

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

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

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

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

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

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

In this short post I want to summarize the building blocks of code annotation in Flex.

In computing, the programmer often adds annotations to source code in the form of comments. These do not affect the working of the program but give explanations (for other programmers, or potential readers of the code principally, but also as a reminder for the author),  hints or plans for improvement, etc.
Further Annotations can also be added by a compiler or programmer in the form of metadata, which is then made available in later stages of building or executing a program. For example, a compiler may use metadata to make decisions about what warnings to issue, or a linker can use metadata to connect multiple object files into a single executable.

In computer programming, a Java annotation is a way of adding metadata to Java source code that can also be available to the programmer at run-time.
Java annotations can be added to program elements such as classes, methods, fields, parameters, local variables, and packages.
Unlike tags added to Java documentation and processed with tools such as XDoclet, Java annotations are completely accessible to the programmer while the software is running using reflection.

Class annotations, also known as metadata in Flex, are extremely valuable as they allow developers to provide additional information about classes, properties and methods which may not be appropriate to convey through implementation details such as Marker interfaces or some other means.

You can create your own custom metadata following the same format. The example which follows defines a custom metadata attribute utilized for annotating a class with version information. The name of the annotation is “Version”, which contains three properties; major, minor and revision.

package{

[Version(major="1", minor="2", revision="123")]
public class Model {

}
}

Accessing custom annotations in Flex is accomplished via the flash.utils reflection APIs; describeType, getQualifiedClassName and getDefinitionByName.

ArrayElementType metadata tag can be easily associated to code annotations in fact when you define an Array variable in ActionScript, you specify Array as the data type of the variable but you cannot specify the data type of the elements of the Array.
To allow the Flex MXML compiler to perform type checking on Array elements, you can use the [ArrayElementType] metadata tag to specify the allowed data type of the Array elements, as the following example shows:

public class myComponent extends VBox {
[ArrayElementType("String")]
public var users:Array;

[ArrayElementType("Number")]
public var orders:Array;

}

In a more complex environment you can use java beans in Flex as the datatype of the ArrayElementType tag specifyng the fully qualified name of the class or get inspiration from this article http://www.flexpasta.com/index.php/2008/05/19/blazeds-with-annotations-for-remote-objects/ that is strictly related to Flex and Blaze DS (i.e. java based enterprise applications).

This tag only works for Arrays – there is no way to set the type of elements in ArrayCollection, to have typed array collection, you can take existing ArrayCollection.as rename it to YourArrayCollection.as and modify source property and add ArrayElementType tag with your prefered type, (I have not tried it but it should work) or even better extend the ArrayCollection in order to create your custom collection with the support for the ArrayElementType metatag.

In order to check the generated code add the -keep parameters to the flex builder compiler.

* Periodically checking for updates based on an interval or at the request of the user
* Downloading AIR files (updates) from a web source
* Alerting the user on the first run of the newly installed version or performing data migration
* Confirming that the user wants to check for updates
* Displaying information to the user on the new available version for download
* Displaying download progress and error information to the user

The update framework supplies a default user interface that your application can use. It provides the user with basic information and options related to application updates. Your application can also also define its own custom user interface for use with the update framework.

For more info chek this link.

Flex Google Analytics Magic component will now allow you to track all of your Flex Application activities through Google Analytics. The magic is that you only have to write one line of code in your Flex application to enable this if you use this component. The Flex Google Analytics Magic component will automatically track all user navigation clicks, button click, check boxes, radio buttons and a number of other controls within your app automatically.

Nice stuff!!!