Yesterday I finished the third and last part of the SCEA 5 Beta exam …
The only bad news is that the results will only be available after February 15th

One good thing, is that this is the only certification I took until now that worth something!
The first objective test is very easy if you already work with system architecture and know at least a little about each Java EE technology …
The second part is not hard too, you have to design a system for a given problem, the only hard part on the Beta was to do it within 2 weeks, and for me those ware two full weeks, I was moving from one city to another, and already had some other things to do, at the end I could work on the project for only 20 hours (it was specified for between 40 and 60 hours), I hope I did it well enough …

The third and last part, is basically to prove that it was really you that created the project …
Before going to the test place, make sure you read all that you send with your project, write down every decision you make and why you made it, this two little tips will help you a lot in the final part of this certification …

Well, not I’ll wait untill February 15th to know if I cleared the exam
Good luck for me and for every one that read to here

If you enjoyed this post, make sure you subscribe to my RSS feed!

Ruby On Rails 2.0 has just been officially released.
If you open your command prompt now and run: gem install -y rails
The rails 2.0.1 will be installed and you will be ready to play!

There are not that many new features, but there are some cool new ones

• Beter named routes for REST
• REST is the standard way for working from now on.
• Rails has support for multiple rendering engines now (for 1.x there was only ERB)
• Better exception handling
• Sessions can now be stored in cookies
• sexy_migrations was integrated into rails core (most of it at least)

Take a look at DHH’s official post and start to play

If you enjoyed this post, make sure you subscribe to my RSS feed!

Working with Flex and Java as backend, I decided that the best choice for the project I’m working now is to simply post XML from Flex and get XML back from Java (Flex works really well with XML).

But there is a problem with that, creating a XML with one or two values is easy, but if you need to serialize a very large object tree you just got yourself a lot of work.

So I’ve wrote this very simple Flex XML Serializer, and decided to post it here, because some one might need some thing similar

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

package teste
{
	import mx.utils.ObjectUtil;
 
	public class Utils
	{
		public static function objectToXml(obj : Object, name : String) : XML{
			var result : XML;
			var info:Object = ObjectUtil.getClassInfo(obj);
			if(name==null)
				name = info.name;
			result = new XML("<" + name + "></"+ name + ">");
			for each (var qn : QName in info.properties){
				var val : Object = obj[qn.toString()];
				if(ObjectUtil.isSimple(val))
					result[qn.toString()] = val;
				else
					result.appendChild(objectToXml(val,qn.toString()));
			}
			return result;			
		}
	}
}

To use is is really simple:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" initialize="appInit()">
<mx:Script>
	<![CDATA[
		import teste.Utils;
		import mx.utils.ObjectUtil;
		import mx.controls.Alert;
		public function appInit() : void {
			var obj : Object = {name:'teste',address:{street:'rua',number:20}};
			Alert.show(Utils.objectToXml(obj,'teste').toXMLString());
		}
	]]>
</mx:Script>
 
</mx:Application>

The generated XML will look like this:

1
2
3
4
5
6
7

<teste>
  <address>
    <number>20</number>
    <street>rua</street>
  </address>
  <name>teste</name>
</teste>

This might not be the best way to work, but I liked this solution for the problem I had

One thing I changed from this code to the code that is in production today is that I’m using XML attributes now, and as you can see below the change was big from the first example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

package teste
{
	import mx.utils.ObjectUtil;
 
	public class Utils
	{
		public static function objectToXml(obj : Object, name : String) : XML{
			var result : XML;
			var info:Object = ObjectUtil.getClassInfo(obj);
			if(name==null)
				name = info.name;
			result = new XML("<" + name + "></"+ name + ">");
			for each (var qn : QName in info.properties){
				var val : Object = obj[qn.toString()];
				if(ObjectUtil.isSimple(val))
					result['@' + qn.toString()] = val;
				else
					result.appendChild(objectToXml(val,qn.toString()));
			}
			return result;			
		}
	}
}

Could not find the difference? the only change was the “‘@’ +” at line 16, and I was using attributes for the values
So, what do you think about this solution?
The next step is to write a deserializer and we’ll make XML rock the Flex world (just kidding :D)

If you enjoyed this post, make sure you subscribe to my RSS feed!

Every one and their dogs use Continuous integration today …
And thinking about the developers and companies that are serious about software quality, they use some sort of TDD or at least write the unit tests for the written code too …
Most of them, at least the one I’m working now, do peer review too (ok, this post does not apply if you are lucky and doing XP)

With this scenario the standard work flow is:

• Write the test
• write the code
• remember to run the test
• if the test passed commit the code to the central repository
• warn some one to do the peer review
• the reviewer checks out all changes from the central repository (your and any other commits )
• the reviewer looks at your changes (after he/she separates it from the other commits)
• the peer review asks for some changes
• you change the tests
• you change the code
• you run the tests
• you commit the changes to the repository

In this workflow we have a great problem …
During all the time in bold the code in the repository probably has problems, or is not yet revised by QA …
Other problems in the standard version control systems are for example:
You cannot access the repository, and cannot commit your work if you are offline, this will cause problems, because your next commit will have more than one change set, so, it will be harder to track what commit caused a bug for example

Of course this approach has benefits too, but if you are using it, you may know its benefits

The idea of this post is to propose a little different workflow, that need a different approach to version control …

The workflow described above is very close to the one used with a centralized version control system, like CVS, Subversion, …

The one I’ll describe, needs a Distributed Version Control System, like Bazaar and Git, I chose Git because it is very fast
I still use a central repository as you’ll see bellow …

• Write the test
• write the code
• run the tests
• if test passed commit the code to your local repository
• ask some one to do peer review
• the reviewer will push your version from your machine
• the reviewer will look at your changes
• if he asks for some changes
• change the test
• change the code
• run the tests
• if test passed commit to your local repository
• push your changes to the main repository

As you can see, this workflow is a little different from the previous one, and we have the following benefits:

• The commit, checkout, create branch, merge branch operations are a lot faster and cheaper because they are done locally
• The “central server” version has always a working version, because you only push your changes there after the peer review, this ensures the build server version is always ready for a demo
• The reviewer of your code pools directly your development branch, what makes easy to find your changes, the changes he/she needs to review
• Merge is really easy

Of course there are drawbacks too, for example:

• You need to learn another version control tool (if you are not using Git yet)
• There is no access control for parts of the repository, every programmer has all the version history of the source tree, but this is easily addressable if your permission system is by project
• In a DVCS there are more concepts than just commit and update, push is not the same as commit and pull is not the same as update
• There are no good GUI tools for Git yet

I have wrote another post about synchronous continuous integration here, and you’ll find a rake task to help you if you are working with Ruby too.

So, I think that is it.
What do you think about this approach? are you using some thing like this?

If you enjoyed this post, make sure you subscribe to my RSS feed!

Just a very quick post!
Imagine the ability to build your own gadgets!
Imagine the ability to program your own gadgets using Java!
Imagine fixing your own bug(s)

Got it?
It will be easier than you can imagine

Really!
I just found this Bug.
Bug is a new concept in Gadget, where all the software is opensource, and you build your own gadget with modules
The base is a mini linux based computer!
The programing environment is a OSGi based framework at an Eclipse Based IDE!

From the site:

BUG is a collection of easy-to-use, open source hardware modules, each capable of producing one or more Web services. These modules snap together physically and the services connect together logically to enable users to easily build, program and share innovative devices and applications. With BUG, we don’t define the final products - you do.

The only thing I can say about that is:
I want one

If you enjoyed this post, make sure you subscribe to my RSS feed!