SOA basics

If you haven't been living among the penguins in Antarctica for the last few years, you probably have already heard about Service-­oriented Architecture or SOA.
Nonetheless it is still a bit dificult to find a straightforward definition on what it is... So here it goes!

SOA is a standards based approach for building application modules – called services ­- in a way that facilitates the integration between different applications.

From a technological standpoint there is nothing new in SOA. It's main advantage when comparing to previous approaches (like CORBA) is the fact that it is based in Industry accepted standards and as such doesn't depend on a single vendor implementation and can be widelly adopted.

SOA applications can be composed by services built with different development platforms (such as .NET or JAVA) and available in completely different locations (lets say an application running in London call a service located in a server in Taiwan that at it's turn calls another service in New York).

Why to version control your projects?

If you have ever been involved in a group project in which the members work in the same set of files (like a software development project) you will probably have noticed the issues that appear almost immediately:

• What is the latest version?
• Is this or that feature already present?
• Who did what?
• Where have the changes I spent 10 hours working on last week gone?
• How to conciliate my changes with everyone else's?

Some of these issues could be fought with a -very- well planned project, in which each member would have his responsibilities well defined and clear cut and little or no overlapping would exist with other member's part on the project.

In a typical software project this would mean at least a well defined set of classes and interfaces between them, a good UI prototype and very precise analysis documentation. Now, we know that in times of 'Agile development' this scenario isn't very common.

This kind of detailed planning takes time and resources that are often scarce.
On top of it, this theoretical 'isolation' of each member would be counter productive, since the developers would not benefit from the overall view of the application being developed and testing would become much harder to do during the development. It would not be a group project but individual projects brought together at some point.

Another option would be having someone to periodically (lets say daily) manually merge all the changes in a new 'base project' that would be used for further development. This is a time consuming task and very often requires deep understanding of the application being developed and technologies in use.

Well, there is a better way to do that and It's called version control systems. These systems are client-server applications that take care of serving the files composing a certain project to the people interested in it, pretty much like a shared network drive would do.
But unlike a regular network share, these systems keep historical data of the files stored there, meaning that once a file is sent to them, it will be there 'forever'. If the file is changed, the older version is archived and will be available at any time it's needed.

Version control systems also keep information on what changed from one version to another, who did the changes and helps on the process of merging new changes into the project.

The most popular version control systems are CVS (concurrent version system) and Subversion.
CVS is the most used but it's shortcomings had given space for the creation of Subversion, that is intended to work in a similar fashion but address CVS's failings.

What is Boirque?

Boirque was the name of the long-deceased dog of my also long-deceased grand-uncle.
He was an half-wild dog who spent most of his days in the jungle near to my grand-uncle's little farm, hunting.

I and my brothers used to amuse ourselves during our childhood holidays in Minas Gerais' country-side (BR) by feeding Boirque whole raw eggs, which he ate with much pleasure, breaking them inside his mouth.

I liked the dog and I like his name, which has no meaning in Portuguese, but might mean something in ancient Tupi-Guarani (the language of the once largest Brazilian Native tribe) or some African language.

In its after life, Boirque lends his name to my blog.

Subversion quick reference guide

These are some basic subversion commands used in day to day operations, they are meant to be used on the command line client, but the basic concept is the same on the GUIs. The commands are meant to be given in one line. The # means you are logged in as ROOT (or other user with RW access to the repository) and the $ means a regular user.

Creating a new repository

# svnadmin create /Path/to/repository

Initial import of files
In your workstation, change the current dir to the folder in which the files are located

$ svn import ./projectFolder/trunk/ https://www.myServerURL.com/repositoty/project/trunk/ -m "Initial import"

Checking out a project to the workstation
After the initial import, your source folder isn't yet a 'working copy'. You have to check out a fresh copy from the repository in order to use subversion commands on it.

$ svn co https://www.myServerURL.com/repositoty/project/trunk/ project

This will create a new folder 'project' in your current working dir with the project files. If you want, you can rename this folder normally, but to rename anything inside it, you must use subversion commands so the system is aware of your modifications. When you checkout a project, the SVN client creates a hidden folder '.svn' inside each directory of the project. This folder contains files used by Subversion to signal that this is a 'working copy' of some project under version control.

Sending changes to the server
In the directory where the modified files are located

$ svn commit -m "New method to count the weight of hypos in the Windows version"

Checking the revision log
From your project folder

$ svn log

To see the log of a project that is not in your workstation:

$ svn log https://www.myServerURL.com/repositoty/project/trunk/

Updating your local copy with the latest version on the server
From your project folder

$ svn update

This will bring your copy up to date with the latest version available.
Keep an eye on the letters that appear next to the name of the downloaded files:

• A = Added. File added
  
• G = Merged. Changes on the file on the server where added to your changes
  
• C = Conflict. Some changes you made conflict with changes on the server.
  
• U = Updated. Arquivo foi atualizado.

Updating a file (our the whole copy) to an older revision
From your project folder

$ svn update -r 999 fileName

999 is the revision number. To update the whole working copy:

$ svn update -r 999

Deleting and moving files and directories
From your project folder

Delete:

$ svn rm fileName

Rename:

$ svn mv OLDfileName NEWfileName

This will rename the file. To move it, add the destination directory name before the destination file name.

$ svn mv OLDfileName ../OtherDir/NEWfileName

The SVN command line client can't move more than on file at a time.
To do that you can use the shell (bash)

$ for I in *.txt; do svn mv $I ./newFolder; done

This will move all .txt files from the current folder to ./newFolder

Create a folder

$ svn mkdir folderName

The rm, mv and mkdir commands affect only your working copy.
To apply them to the server, execute a 'commit'.
If you want to execute them directly on the server, give the full URL to the file on the command line
(eg. https://www.myServerURL.com/repositoty/project/trunk/fileName)


Creating a TAG (to flag a release, for example)

$ svn copy https://www.myServerURL.com/repositoty/project/trunk/ https://www.myServerURL.com/repositoty/project//tags/1.0.42 -m "New version 1.0.42"

Listing project files and tags
Listing files in the 'trunk'

$ svn list https://www.myServerURL.com/repositoty/project/trunk/

Listing existing tags

$ svn list https://www.myServerURL.com/repositoty/project/tags/

Checking out a tag

$ svn co https://www.myServerURL.com/repositoty/project/tags/1.0.42

Checking the state of the working copy
The 'svn status' command allows us to see which files where modified locally and/or in the server and thus make our copy outdated.

Checking for files modified locally

$ svn status
or
$ svn status fileName

Checking for files modified on the server

$ svn status -u

Files preceded by a * where modified on the server. Use 'svn diff' with the full URL to see the changes.

$ svn diff https://www.myServerURL.com/repositoty/project/trunk/fileName


Creating an alias to an external project

We can create an 'alias' pointing to a folder in another project within our current project.
This is done using the 'svn:externals' propriety.
From your project folder:

$ svn propset svn:externals 'externalLib https://www.myServerURL.com/repositoty/OtherProject/trunk/libs/' myProject

Obs: The 'libs' folder can't already exist in the 'myProject' or the process won't work. It will be retrieved from the trunk of the 'OtherProject'

To edit a propriety value, use the command ‘propedit’

$ svn propedit svn:externals myProject


List all currently set proprieties in a project

$ svn proplist dpz


The MERGE command

This command compares 2 revisions of the repository and applies (merges) the differences between them in a local copy.
From your project folder:

$ svn merge -r 700:751 https://www.myServerURL.com/repositoty/Project/trunk

This will retrieve all the changes happened between versions 700 e 751 in our project TRUNK and apply it in our ‘working copy’ in the current directory (that can be a branch).
The command will produce a list of the modified files. You should check the files, accept the changes and commit (or revert).

$ svn ci -m 'merge of r 700:751 from trunk to release branch'


You can get more detailed info in the chapter 4 of the 'Version control with Subversion' book:

http://svnbook.red-bean.com/nightly/en/svn.branchmerge.html

Dinamically acessing controls in C# .NET

Have you ever needed to create / access controls in your C# .NET applications?
something like substituting the following code:

Button1.Text = "click-me;
Button2.Text = "click-me;
Button3.Text = "click-me;

by this:

for (int i=1 ; i <= 3; i++){
         String btn = "Button" + i;
         btn.Text = "click-me;
}  

Well, if you try the code above in C# you will see that it won't work.
It's because 'btn' is still a string and not a Button Control.
Even if you try to make 'btn' a real Button it still won't be pointing to the control you created in the design mode of Visual Studio:

Button btn = new Button;

Will actually give you a new Button, with a different internal ID (clientID), pointing to a Button other than the one in your UI.

How can you solve this? You can place your Controls in a Hash Table with the Control ID as a key and the control as a value when you create them, you can use reflection or you can iterate between the controls in a page until you find the one you are looking for.

The following code snipet shows you how to retrieve a control by iterating in all the controls in a page. It receives the Control ID and the page (which is a control itself) and returns null or a control matching the given ID. The method is recursive, meaning it calls itself everytime if finds a new control.

// The calling code
// The Control has to be cast to a Button.
// 'this' is the current page and 'btn' the button name
for (int i=1 ; i <= 3; i++){  
   String btn = "Button" + i;  
   Button b = (Button) retrieveControl(this, btn);  
   b.Text = "click-me;
} 

// retrieve a control from the active page 
// the method iterates between the page controls until it finds the correct 
// it calls itself everytime if finds a new control that may have inner controls   
protected Control retrieveControl(Control c, string controlName)
{       
    for (int i = 0; i < c.Controls.Count; i++)
    {       
        Control m = c.Controls[i];
        if (m.ClientID != null)
        {
            if (m.ID.Equals(controlName))
            {
                return m;
            }
            else
            {
               Control  x = retrieveControl(m, controlName);
               if (x != null) { return x; }
            }
        }
    }
    return null;
}

Adding the controls to a Hash Table can be a better idea if you are also creating them dinamically.
Reflection is a powerfull tool that allows you to retrieve information from the assembly but for this purpose it may not be as clear as the code above.