20 Dec 07 Tips for the SCEA 5 Beta exam – part 3

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!

Tags: certification, java, javaee, scea, test

Filed in java with 2 Comments

07 Dec 07 Ruby on Rails 2.0 is out!

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!

Tags: news, rails, ruby, update

Filed in rails with 0 Comments

04 Dec 07 Flex/ActionScript3 – Object to XML

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

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:

<?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:

<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:

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 )

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

Tags: actionscript, flex, howto, tip

Filed in java with 2 Comments

03 Dec 07 Powerup your development workflow with Git :D

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!

Tags: development, git, productivity, scm, version

Filed in productivity with 1 Comment

01 Dec 07 Imagine building your own gadgets :D

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!

Tags: cool, gadgets, hardware, opensource

Filed in mobile with 1 Comment