FlexPMD: Code quality tool for Flex and Action Script
17.12.09Filed Under: Flex with 0 Comments
Being accustomed to the development tools for Java development it has been really frustrating to move into the world of Flex and Action Script with it’s immature IDE’s. However it seems as if this is finally getting attention at Adobe and the Open Source project FlexPMD is really becoming a great tool for assuring quality of code for large code bases. It allows you to have a rule set set up for your development team to ensure your code share a common set of requirements for code of high quality.
Maintaining your rule set is easy with the Adobe FlexPMD Ruleset creator which provides a nice view for enabling / disabling rules for your project. After all, it is not all rules which are just as important to everyone and having an application which makes this easier.
The Flex PMD Eclipse plugin enables you to introduce quality control as a natural part of your work flow. It can be run as part of your build process or as a separate command later. You can identify code smells or potential duplication of code due to cutting and pasting of code blocks using FlexCPD. FlexPMD is not for Eclipse only, but can be executed from Ant, Maven, TextMate, Flash Develop.
You can also use FlexPMD as part of you continuous integration process and the wiki shows samples of how it can be used with the Java CI server Hudson.
Props goes out to Adobe for giving this project attention and hopefully it will help the Flex community to deliver code of even better quality than before.
Flex on Linux is hard work
03.08.09Filed Under: Flex with 0 Comments
I have for some time been running Ubuntu on my work-at-home-computer. Having to work with Flex on Linux is a constant struggel and I can understand why most people would just give up. I can see that the number of Flex developers on Linux is quite small, however I think it’s a shame that we’re pretty much left on our own. I don’t know if Flash Builder will ever make it onto Linux. However I have been able to get some work done with Flex Builder on Linux. There are however a few difficulties which I thought would be of interest to others.
Flash Player Debug version
I don’t know why this is so damn hard, but for me (and according to Google quite a few other people as well) this was a hard job. First off you need to download the debug version. Then some posts say that all you need is to override the libflashplayer.so file in ~/mozilla/plugins/. For me however this only resulted in the debug version being there the first time I launch my Flex app, but only once. After the first launch it was back to the standard version. Not beeing to keen on figuring why this funky behaviour happened I took the bull by the horn and ran a grep for all occurences of libflashplayer.so and replaced it with the debug version. Now I have the debug version every time 
No events? No import flash.*?
When setting up a project you may get some issues with classes from the flash.* packages. Resulting in the inability to say stuff like addEventListener, which is something you really want to be able to do. You can Google for the topic and find some interesting posts. To get around it you just remove the one set up by the SDK and find the version you need in the SDK. In my case this was verison 10. Having done this all my code completion stuff worked.
I know there where a few other issues related to installing FB, but I’ve put them so far in the back of my mind that I can no longer reach them. I hope this might help some of you having problems with Flex on Linux.
The evolution of a Flex project
17.07.09Filed Under: Flex with 2 Comments
One of the most challenging tasks when being architect on a large project is to keep some kind of track on what developers are doing while you are wasting away time in planning meetings and all other kinds of useless management activities. In the Flex echo system there are very few tools which help you track the code being produced and the quality of the code produced. Being a Java developer I am accustomed to have a set of tools which help me analyze code quality on a large scale enabling me to keep track of development without getting too deep into the details. There are some tools available for measuring code quality in Flex and Action Script, but they all seem immature and not really ready for actual use. Therefor I decided to abandon my quest for code quality and settling for keeping track of what is produced.
The tool
Equipped with the basic shell commands available in Linux I set out creating a simple shell script which works through the workspace directory of our CI server Hudson. The script runs each night and produce a report XML which gets aggregated using a PHP script to get all the statistics. On top I built a simple Flex dashboard which visualize the findings for the script.
The script counts the number of source files for MXML and ActionScript and also counts the number of code lines in each of them. During the work with this script an issue with build time surfaced, so we decided to add a tracking for that as well. The build time and SWF-file size parameters gets read from the Hudson status XML files.
The findings
Having run the script for a couple of months I have some data show how our application is growing and at what pace. The end of the graphs shows how Norwegian summer vacation effects the amount of code produced (number of developers is reduced with about 90%).
The most worrying graph right now is the number of code lines in our MXML files. Looking at the graph for code lines and number of files you will notice that we have a considerable larger amount of AS files than MXML files. However the number of code lines are not that far apart, which could lead to one of the following inclusion:
- MXML files are bloated and need to be trimmed down
- AS files are naturally smaller and there is no need to worry
Looking in detail at the code we’re closer to the first conclusion than the second and this is useful. Another interesting finding is that we’re not doing a good job of managing our assets as the file size just keeps growing. This told me that we needed to ensure that all developers understood the impact of embedding images in the application and that this is something which must be taken into considered when adding new images.
Anyway, I just found it interesting to see how the application will continue to evolve. We’re not to complete the project for another couple of years so it would be interesting to see what these graphs looks like in 2011. If you have made any similar efforts it would be interesting to hear how other projects evolve.
I will FlexMojo no more
25.06.09Filed Under: Flex with 6 Comments
Being a Java developer my preferred tool for building applications is Maven. Adobe does not seem to know of this tool which as been the industry standard for some years time and therefor there are no official Maven plug-ins for building Flex applications. I have used Israfil and Flex Mojos for some time and my experience is that none of them are worth the trouble.
The dead horse
Israfil is a dead project in my opinion. The main contgributer does not add new features and people tend to just fork it and build their own version without being able/willing to commit it back to the project.
The "new " kid on the block
At first glance Flex Mojos looks like the right tool for the job, however after using it for some time I think it’s not worth the trouble and I will try to explain why.
It is a bad idea (and maybe not legal) to have the Flex SDK as a dependency in you POM. §Using the compiler Java API is also a bad idea as you get situations where your code builds just fine in FB and breaks when using Flex Mojos. This is extremely annoying and you have to spend a lot of time on something which is a waste of time.
Maven is just too strict
One thing which all Maven plug-ins have in common is that they enforce you to structure your Flex projects to suite Maven’s needs instead of what make sense. The concept of one artifact for each project does not work well with the Modules feature in the Flex framework. Nor does it provide an easy way to compile CSS-files to SWF-files without creating a new project. The Maven requirement makes you have to add a lot of complexity to your project as you need to create a lot of modules and projects just because of a requirement which makes no sense in Flex development.
What’s a girl to do?
What do I recommend? I recommend using the Flex Ant Tasks that ships with the SDK and use the Maven Ant Runner plug-in. This solves the problems mentioned related to Flex Mojos and it allows you to benefit from all latest innovations in the SDK right off the bat. With the plug-ins you have to wait for any new feature to be implemented.
Disclaimer
I do not write this to piss off the authors of the plug-ins mentioned as they are all doing a great job. I really hope you get the plug-ins right so that I do not have to maintain Ant build scripts, so the best of luck to you. However I just felt that I should come clean and say what is my preferred way of building Flex applications.
Start using the FlexUnit 4 beta today
22.06.09Filed Under: Flex with 5 Comments
I’ve been playing around with the beta of FlexUnit 4 and I must say that it is exceeding my expectations. The single most painful thing to do in FlexUnit is to perform unit testing of user interactions. With the amount of code and pain involved in doing so not many people used the framework. However with FlexUnit 4 it’s so much easier, thanks to the inclusion of the Fluint framework into FlexUnit.
You should upgrade now!
There is no reason why you should not upgrade today. FlexUnit 4 is backwards compatible and you can migrate each unit test whenever you would like. With the introduction of Fluint and it’s support for Sequences it is possible to unit test user interface interactions without having to write tons of code to accomplish it. You get to write less code and another very important aspect is that you can actually understand what your tests do some time later because of the simpler syntax of testing.
FlexUnit 4 is a huge step from the old versions and it is now on the same level as JUnit and other test frameworks. Especially with the easier configuration of test runners, unit testing and continuous integration will be so much easier in the future. I am also over the moon about the FlexUnit plug-in which is coming to Flash Builder.
Upgrading to FlexUnit4
I have a few projects with unit tests using FlexUnit 0.9 and upgrading to FlexUnit 4 is very simple. All your tests can still be reused and all that is required is that you change the way you setup the test runner.
Here is how little I had to change in one of my projects:
private function onCreationComplete():void {
testRunner.test = createSuite();
testRunner.startTest();
}
private function createSuite():TestSuite {
var testSuite:TestSuite = new TestSuite();
testSuite.addTestSuite(SomeModelClassTest);
testSuite.addTestSuite(SomeUIComponentTest);
return testSuite;
}
....
<flexUnitUIRunner:TestRunnerBase id="testRunner"/>
With FlexUnit 4 this is actually made simpler, just have a look:
private var core:FlexUnitCore;
private function onCreationComplete():void {
core = new FlexUnitCore();
core.addListener(new UIListener(testRunner));
core.run(SomeModelClassTest, SomeUIComponentTest);
}
....
<flexUnitUIRunner:TestRunnerBase id="testRunner"/>
What else is new?
I assume you have read the post FlexUnit 4 feature overview which gives a hint at what you can expect. Besides this one page the documentation is pretty much non-existing, but you can have a look in the source tree in the branch 4.x for samples of how to use the new features.
One would expect that it would be possible to see all the new features documented as unit tests, however it does not seem as if the FlexUnit team believe in dog food as the unit tests are far and few between.
Go download the FlexUnit 4 Beta 1 now!
Cairngorm coming alive?
02.04.09Filed Under: Misc with 0 Comments
I’ve written about how much I think Cairngorm should be put to sleep, but having a big mouth sometimes has the downside that you might have to your money where your mouth is. Allistar challenged everyone who’d been complaining about Cairngorm to step up and join the Cairngorm Committee, so I did.
Just this evening the Committee had their first conference call and it actually might look as if the framework might come back from the dead. What is even better is that it might actually become a better more developer friendly framework.