Flex4 Dotted “Line”

Quickly, I wanted to share some code around creating the elusive ‘dotted line’ in Flex4.

The end goal is a divider made up of 1px dots, like this:
dotted line example

My solutions isn’t a true line, in that you can’t you can’t draw it on a diagonal. However, if you need a 1px horizontal divider, here you go. This is simply a Rect with a bitmap fill, using a dot as the bitmap. The bitmap is actually 1 pixel by 2 pixels, with the right pixel colored (#808080) and the left transparent, as such:

example of the dot png

Here’s the code that would draw your “line”:

<s:Rect width="500" height="1">
<s:fill>
<s:BitmapFill source="@Embed('/assets/images/dot.png')" fillMode="repeat"/>
</s:fill>
</s:Rect>

That’s about it. You can download the dot PNG here. Or, just make your own in Fireworks.

Tomcat and OSX – oh joy

I’ve been fiddling around getting Tomcat running on OSX 10.6, which is trivial if you do things right, but here are som potential snags. This might be documented all over the place, but I’m making a note here for myself. I think I’ve installed Tomcat on about 50 machines over the years, so I enjoyed some nice flashbacks as I sorted this out.

First: download Tomcat. derp.

Second: check the md5 hash using ‘ $ md5 <zipfile> | grep -v <expected hash>‘. Or, don’t check it. Probably not a ton of people hacking a keystroke logger into Tomcat. I think checking the hash is fun.

Third: extract the archive. derp de der! Folks recommend /Libraray/Tomcat/Home/ as a final resting place. If you don’t have execute permission on the extracted directory, make it so. I like 'chmod a+x' instead of '777', but whatever works. If you don’t do this, you’ll get complaints about permissions, or that ‘catalina.sh’ is missing, or even worse ‘BASEDIR environment variable is not defined correctly’.

Fourth: run Tomcat. der derp der derr!!! Here’s where things can go a little crazy. You don’t have to set $CATALINA_HOME as a environment variable. You don’t even have to set $JAVA_HOME, which should be /Library/Java/Home. There is a startup.sh and shutdown.sh script in the /bin directory of the Tomcat install (ie /Library/Tomcat/Home/bin). I prefer to make my own wrapper for these scripts, named tomcatStart and tomcatStop, and put them in my ~/bin folder, which is in my path. That way I don’t have to type the whole path to the Tomcat scripts, and it’s a little more explicit as to what I’m starting up or shutting down. Alternately, you could just call Tomcat’s catalina.sh script, with either start or stop as an argument.

Be aware that calling an executable script directly, eg '$scriptname' is different than calling it using the source operator in bash, eg '$. scriptname‘. Using the source or ‘.’ operator causes the shell to run the script directly, instead of using a subshell. This will cause an error, because the $0 argument will become ‘-bash‘, instead of the path of the script.

Fun Fact: you might have (depending on your download method) the HFS+ bit set which ‘quarantines’ files from the internet. You will see an ‘@’ in the extended list attribues, ‘-rw-r--r--@‘ <— like that. That means you have the quarantine plague. It won’t keep the files from starting up, but you might get a warning message if you try to open the files with a visual editor. The remedy? Run ‘xattr -d -r com.apple.quarantine *’ to clean this up.

flashlog.txt

‘ve been working on some code that has made it difficult to use the normal FlashBuilder based process of running in debug and using the step through debugger. This has me spending a lot of time reading through the flashlog.txt file that the debug player output. I also spend a lot of time seeing the dirty secret trace output that every single SWF on the net seems to belch into the log. On a whim, I wrote a script to switch the logging on or off. If you do much work with scripting or sed, this is pretty basic.

sed -i '' 's/=./='"$1"'/g' /Library/Application\ Support/Macromedia/mm.cfg

Put that in a file (such as ~/bin/setFlashLog), make sure you have execute permission, then just type ‘setFlashLog 1′ or ‘setFlashLog 0′, depending on how you want your logging (on or off).

Not being happy with that, I wrote an even more elaborate script to toggle the setting to the opposite of whatever it’s set at now:

read -r FIRSTLINE < /Library/Application\ Support/Macromedia/mm.cfg

len=${#FIRSTLINE}
idx=$(($len - 1))
value=${FIRSTLINE:idx}

if [ "$value" == "1" ];
then
sed -i '' 's/=1/=0/g' /Library/Application\ Support/Macromedia/mm.cfg
echo "flash logging: off"
else
sed -i '' 's/=0/=1/g' /Library/Application\ Support/Macromedia/mm.cfg
echo "flash logging: on"
fi

As with all things *nix, there's probably about 12 other ways to do this. However, since sed was the current favorite hammer, that's what I used to pound the nail. Note that you need the debug player for anything to show up on the log. Also note that the player checks this setting at the time a SWF is loaded, and outputs accordingly. Once the SWF is running, a change in the setting will have no effect.

Code Review == Code Smell

I’ve been engaged in various forms of code review over the last few months, and have come to the conclusion that, while it’s better than nothing, teams should wonder why there is the need for code review. Craftsmanship should be integrated into the act of writing code, not addressed in a secondary process after the fact. In this light, code review represents a greater problem — a lack of commitment to craftsmanship in the coding process. If you find code review is time consuming, or difficult to integrate into your process, it might help to address issues that are closer to the root of the problem.

Most teams will claim some level of attention to quality, but not many make it the foundation of their work. All teams should be delivery focused, but take this too far, and craftsmanship can quickly suffer. Worse, management has a bad habit of failing to see the value of craftsmanship. ‘Faster’ is always the watch word. Development time should deliver as many features as possible. This lack of vision misses the point that decreased maintenance, avoiding re-work, or improved extensibility can all be cost saving outputs. These things are nearly impossible without software craftsmanship. These things cannot be rushed. While there does need to be a balance, if quality is compromised, code review is often used to keep craftsmanship from being ignored all together.

This may be easier because software development has a long tradition of testing for defects and applying fixes defects well after the code has been delivered. There is a strong parallel between code review, in that problems found are something that should have been handled during development, not after the fact. Also, the further along development goes, the more expensive it will be to fix the problems. The same principles apply to code review.

In this light, the most costly and least effective approach is to review code after delivery. When reviewers are not the original developers, the code will be harder to understand, decreasing effectiveness. When reviewed by the original developers, they may have moved on mentally, so the team must spend time to shift focus. Just like bug fixing, there’s an incremental cost, depending on how late the problem is addressed.

A better approach is to have developers periodically review each other’s code, preferably at some specified interval. While still not ideal, this at least takes place closer to when the code is written. Review might be done on completion of a feature, or at the end of a sprint. There are tools which can watch SCM, provide structure for the review process, highlight changes, track comments, and manage the workflow of the review. Again, time will be lost to to the review process, along with the cost of switching from code writing to reviewing and back.

Notice a trend of time being spent? Once we accept that lack of quality will result in time being spent on either code review, or defects, it seems obvious what the best choice is. Rather than spend the time in a reactionary way, time could be spent making an investment in the quality of the code. The need for review is the smell that indicates not enough investment is being made during development.

How do we make ‘review’ part of the actual development process? First, teams need to decide what craftsmanship means. There are entire books on the subject, but it’s not hard to figure out some basics. A first step could be agreeing on consistent formatting. Beyond that are more standards, like package naming, the organization of the code, and other development practices. At the most comprehensive, a plan around craftsmanship should also include architectural strategies and patterns. Ideally, there is an ongoing dialog within the team, where discussion of the code’s design is synonymous with deciding how the principles of craftsmanship will be applied.

Once these standards are set, there are various tactics for ensuring they are implemented in real time. In addition to relying on the good habits and integrity of the developers, a team may choose to use of a monitoring tool, like PMD. Teams may also choose to practice pair programming. The benefits of pairing are widely known, and well beyond the scope of this writing. In most cases, it helps to document expectations, to provide references and examples for development. Individuals should feel they have the time to apply these practices at every step of development. If development is rushed, this is usually the first thing to go, so management needs to provide the necessary breathing room.

Striving for craftsmanship in real-time will also bring up the quality of delivery, lowering the amount of defects, which will further the return on the investment. This process may need to be backed up with an occasional code review, preferably a causal peer review, prior to delivery. The need for review should decrease as the commitment within the team grows. In addition, as the team improves, the findings of review will become less significant, meaning less time will be needed to make corrections. Essentially, your reviews will smell better.

.

Craftsmanship, Priorities, and Agile

In Adobe Professional Services, we are big on software craftsmanship. We are committed to clean code, T.D.D., the SOLID design principles, and the idea that craftsmanship will increase customer value. This is not always an easy crusade to be part of, largely due to the fact that our work is usually beholden to the needs of our customer. There are many cases where the customer may make demands that suggest we compromise our standards. For some, this is a cry to battle, and the ensuing tension can make a project troubled, to say the least. There are times when this seems to come down to an ‘all or nothing’ stand on quality, with ‘push back’ being the war cry of developers. I feel this is a common pattern in the software industry, but extreme stances are never a good way to get things done. This is where Agile comes in.

Agile is the rule of the land in Professional Services (and across many product teams at Adobe). There is an important aspect of Agile that may help move things away from an all or nothing dialog around the inclusion of quality in delivery. In general, Agile can be seen as guidelines for achieving balance. In Agile’s very definition, the things that are ‘favored’ (individuals, interactions, working software, collaboration, response to change) are just that; favored. They aren’t strictly demanded, and there isn’t a formula for measuring the percentage of implementation. Problems come when any one principle is ‘favored’ more than another. In this case, the ‘commit to technical excellence and good design’ principle of Agile can be taken to an extreme, while the customer may be taking ‘deliver working software of business value’ to their own extreme. If either principle becomes a goal in itself, this begins to limit the inclusion of other, equally important goals.

The frustrating thing for developers, especially those committed to quality, is that business value should ultimately be decided by the customer! In the end, we should strive to provide quality as a rule, but the customer keeps the lights on, so delivery should take precedence. If the customer is not giving enough allowance for quality, one approach is to help them see the business value of quality, rather than simply pushing back. However, Agile provides other ways for developers to shield themselves from focus moving too far toward delivery.

Another principle is the idea of “maximizing simplicity”, which is measured by the amount of work *not* done. Delivery of working software is supposed to be the *only* measure of progress. However, a good team can work within that definition to provide an adequate balance between value, architecture, and quality. Craftsmanship, pragmatically applied, is non-negotiable. The point of balance is to be doing just enough, while not becoming and end in itself. This is the same principle behind stories being a seed, rather than detailed requirements, and the deferred design that comes in sprint planning. The ‘just enough’ idea should be able to provide some padding for the dev team, so that quality doesn’t have to be completely dropped in the face of delivery pressure.

In the end, the tension between customer and developers is probably a good thing. A team with out constraints may tend toward over-architecting, and a customer with no technical resistance is likely to create low quality software. For me, a big selling point of Agile is how the principles work together to make life better for both development and the customer.

One Application, Four Frameworks, and All the Code You Can Eat

I’m bummed I didn’t get to attend MAX. One of the things I’m sorry I missed was Christophe Coenraets’ session on Flex frameworks. The ‘which framework’ debate has heated up over the last few years. Being so busy at work, I don’t always get the time I’d like to explore some of the offerings.
During Christophe’s session, there was fairly direct comparison between Cairngorm, PureMVC, Swiz, and Mate. It’s an ambitious and long over-due exercise. I’ve seen some attempts to compare members of that crowd, but the result rarely came across as a direct comparison, and it was rare that the result was useful as a reference. From Christophe’s description, this seems to be the most fair and complete comparison done so far. Considering the code was written by people with a fair investment in each framework, it’s about as good as your going to get.
Check out Christophe’s blog entry that covers the results of the session. Definetly don’t miss the source code, which provides reference apps built with each framework.
Great stuff, really. This is just what an aspiring project architect needs to make an informed decision about which framework or practices best fit the problems they are addressing.

Adobe AIR 2 at MAX

There is some great stuff going on at MAX. Being primarily focused on AIR development, I might be biased in my excitement over the AIR 2 announcement.
Highlights include an updated version of WebKit, support for interaction with native OS processes, multi-touch gesture support, improved socket support, and more. With all that, it’s hard to say what is most exciting. WebKit will add speed, for sure. The native process API opens up a lot of possibilities, as does better control over socket layer connections. While there are not a ton of touch screen devices available, people are getting more used to the idea of multi-touch gestures, so working them into applications will become more common. In all, some cool stuff to think about.
AIR is already proving a useful platform, but with these additions there is a lot more potential. I’m excited to get some time to check out the new features!
More details are posted in the AIR Team Blog.

Coming Soon: Cairngorm 3

With MAX right around the corner, you would expect some build up. For example, Cairngorm 3. Yes, kids, it’s true! A transformation is coming, which will make Cairngorm more than just a micro-architecture. Instead, Cairngorm is broadening its scope to become a collection of tools, practices, and libraries, all of which form a foundation for use in Flex development. At the core of it, Cairngorm still represents a layered architecture, separation of concerns, and test driven development. If it suits your needs, the original Cairngorm libraries are included, with many enhancements. On top of that, a wealth of additional information is added. This content is gleaned from the expertise of Adobe Professional Services and the Cairngorm Committee. This will allow the wider community to share the knowledge that we in Adobe Professional Services have acquired while developing large scale Flex applications. The additional components and recommendations expand beyond a single architecture, and will suit many of the frameworks now being used. This will broaden Cairngorm’s scope, making it a useful tool on any size project.
As to what ‘coming soon’ means, I’ll have to leave that up to your imagination. But when it does become officially available, be sure to check it out!

Squiggly Now Available on Labs

So, you need a spell checker? Finding the current options are either a bit limited, or not free? Adobe has just launched Squiggly, a spellchecker library based on an open source algorithm and dictionaries, as a project on Labs. With Squiggly, you can add ‘check as you type’ spelling to your AIR or ActionScript application with easy to follow examples. It’s a ‘technology preview’ at this point, and only targeted at English for now, but still worth checking out.
Read the official Labs blog entry, or check out the online demo.

Adobe Open Soure: FlexPMD

A few of the team in Adobe Professional Services have been working on a port of PMD to work with ActionScript.
From the overview:

FlexPMD is a tool that helps to improve code quality by auditing any AS3/Flex source directory and detecting common bad practices, such as:

  • Unused code (functions, variables, constants, etc.)
  • Inefficient code (misuse of dynamic filters, heavy constructors, etc.)
  • Over-complex code (nested loops, too many conditionals, etc.)
  • Over-long code (classes, methods, etc.)
  • Incorrect use of the Flex component lifecycle (commitProperties, etc.)

A report is produced describing the violations of a given rule set. FlexPMD includes a rule set that is broad ranging and continually growing.
We have been using this on my current project, and it’s a great tool. Especially handy is the ability to edit or create the rule set. This also integrates well with continuous integration tools, providing updated reports ever time the build scripts run.
Check out on Confluence, the Adobe Open Source website (you may need to log into Adobe to view the link):
http://opensource.adobe.com/wiki/display/flexpmd/FlexPMD