Posts in Category "actionscript"

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.

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.

.

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.

Shift + F2 vs. AS3LR

If you’re smart enough to be developing in ActionScript, you’re also probably smart enough that you have figured out a way to bookmark the ActionScript Livedocs. However, there always seems to be reason to try access the docs at a time when finding your bookmark is a hassle. For me, that usually happens during peer programming. When I’m working at another person’s machine, they don’t usually have things set up just as I would, and finding an entry point for the current docs can be a little frustrating.
First, if you’re using FlashBuilder (or FlexBuilder), you can always use the ‘Shift + F2′ shortcut. This is mapped to ‘Go To Documentation’ in the ‘ General > Keys’ section of the FB preferences. This opens the Language Reference in the context the Eclipse help viewer.
Since I don’t like having the help viewer clutter the documents, I tend to go straight to a browser and punch in a URL. Fortunately, there is a handy link that automagically resloves to LiveDocs for the current Flex Language Reference.
http://www.adobe.com/go/AS3L
I don’t know for certain, but AS4LR seems likely once Gumbo is out of beta. For now, the AS3 Docs offer a link to the AS4 docs should you need it.