Lanny McNie

As the dev mgr, Lanny oversees the technical day-to-day details of production and makes sure things get out the door.


Spelling Plus Library Open Sourced

We would like to let everyone know that Spelling Plus Library (aka SPL), our Flash/Flex spell-checking library has been released open source.

We first released SPL as a commercial component over 6 years ago, with a major overhaul to support the Text Layout Framework almost 4 years later. It was always our goal to provide a high quality, performant, and feature rich product, backed by great support. As the requirements of the industry have shifted, and the demand for Flash components has dropped, we felt it was a great time to release it to the community at large.

The entire SPL repository is now available under an MIT license, meaning it is free to use for everyone, including on commercial projects. This includes:

  • The SPL source code. Word list loader and parser, text highlighter, and spelling suggestion and replacement utilities
  • The Flex-based AIR application that helps create, modify, and export word lists
  • All examples, spikes we used for testing, and some internal demos
  • The build process to export Flash and Flex SWCs
  • Generated word lists using custom compression for US and UK English, along with tested word lists for Spanish, French, and German.

You can check out the GitHub repository to get everything. Feel free to submit pull requests. Please note that we are no longer supporting SPL, so any questions or issues reported may not get immediate responses.

Thanks to our supporters over the years, we are super proud of what SPL has accomplished, and hope that it will continue to see life moving forward.

Creating Great Developers: Shadowing

Earlier posts in this series: “Introduction“, “Hiring“, “Orientation“, “Training“, “Planning“, and “Production“.

Once the new hire has successfully delivered their internal project, they are ready to move to the next phase of training: project shadowing.

We pair the new hire up with one of our senior developers, and have them work on the same project and tasks in parallel. At the start of each week, the senior developer will sit down with the new hire to outline the goals for the week, help prepare micro-deadlines (ie. production targets for each day), and provide some guidance on architecture and approach.

Throughout the week, the new hire works towards the assigned goals, and is free to ask their mentor for help or advice in an appropriate, organized manner. We schedule time for the senior developer to account for this, so that it does not create a burden on them.

At the end of the week, the trainee is provided with the mentor’s source code and given some time to compare it to their own efforts. They then sit down with their mentor to review their code quality, communication, and productivity. This also gives the trainee an opportunity to ask additional questions that arose during development or (more critically) while they were comparing their efforts to the senior developer’s work.

Besides being another great learning opportunity, it also provides the trainee and the senior staff with applied benchmarks as to how they are performing on a real project, without the risk associated with actually placing them on a client project. An important factor is that shadowing is treated as a serious project by both the trainee and the team, with a project manager, deadlines, and testing / quality control.

We repeat this process for 3-5 weeks, depending on the trainee’s performance. Most weeks we will switch mentors, so that the trainee is exposed to a variety of working / coding styles.

At the conclusion of shadowing, the trainee has been with us for between eight to twelve weeks, and is ready for their three month review, which will is the subject of the next article, available here.

Spelling Plus Library (SPL) Version 2 Released

I’m happy to announce that we have released version 2.0 of our Spelling Plus Library (SPL). SPL provides real-time (as you type) spell checking for Flash, Flex, and AIR applications built with AS3. Version 2’s most significant new feature is full support for TLF text and components, including the Spark component set in Flex 4. We’ve also made a number of other bug fixes and enhancements.

To make up for the long wait for this version, we’re offering existing customers who purchased SPL within the past year a free upgrade, and a significant (~60%) upgrade discount to everyone else who owns a previous version of SPL.

We’ve already started work on SPL 2.1, which will add a number of new features targeted at mobile, and will be a free upgrade for all SPL 2 owners.

For more information on SPL, check out the product page here.

Thoughts on Adobe Squiggly & Developer Relations

Squiggly is the new spell checking component that Adobe recently released on labs. I haven’t had a chance to test it in depth, so I’m not sure yet how it compares to our Spelling Plus Library, but I have to admit that its release frustrated me a bit.

I’m not at all worried to have competition in the space, we’ve had a good run with SPL so far, and competition is always welcome. Rather, I’m concerned about who I’m competing with.

See, one of the things that the Flash world really lacks is a strong commercial component marketplace. We have a thriving OSS culture, which is awesome, but while it is very prolific it rarely creates highly reliable, documented, and well-supported libraries. It’s a weakness of the platform, especially when you look at the hundreds or thousands of enterprise class commercial components available for languages like Java or C#.

That’s why, when Adobe spends a large amount of resources building a spelling component that directly competes with one of the few successful commercial components in the Flash world, it frustrates me. It’s not the potential impact to our revenue from SPL (which was a largely unexpected bonus of building it), competition is an expectation in this industry, and I wouldn’t be writing this post if it was a third party that built Squiggly. Rather, it’s the message it sends to other potential component developers.

Adobe could have used SPL as a customer success story to entice other developers into offering high-quality components. They could have even helped promote SPL, to actively encourage the growth of a commercial eco-system. Instead, they issued a warning to those same developers that if you build something that generates demand, they will compete with you directly (or worse yet, release a competing component for free).

I understand that there is a lot of value in Adobe providing an official spell checking solution, assuming it remains updated and well supported. However, at a minimum they could have given us advance warning of Squiggly’s release, or even had a discussion early on to see if what we had built would work for what they need. It must be close, as they are already using SPL in a number of their own projects. They need to work with their developers, not against them, if they want a strong platform long term.

[Important note: I was provided 3 weeks notice of the release. I originally thought it was only a couple of days notice, and so didn’t feel it was even worth mentioning in this post. The notice basically just informed me that Adobe might be releasing an OSS spelling library at some point in the future. In fact, I believe part of the reason that I was so far off in remembering the amount of notice I got (beyond being ridiculously busy at the time), was that it really wasn’t actionable in any way, so I basically dismissed it. It was better than nothing though, I appreciated it, and it is remiss not to have mentioned it. Sincere apologies to Christian.]

I’d like to chalk this up to pure ineptitude and cluelessness. It wouldn’t even shock me if the team that built Squiggly was completely unaware of SPL, despite that showing a lack of basic web searching ability. I’m certainly hoping it wasn’t a case of Adobe seeing something that worked, that filled a need, and that demonstrated demand, and saying “hey, we should do that too”. Either way, it demonstrates a lack of understanding of developer relations, and how to foster a healthy component ecosystem. This is also something that Adobe / Macromedia has a history of doing, so its not like this is a first offense.

Note that the above doesn’t apply to all of Adobe. There are people who get it, and I thank them for bringing this issue up internally. Unfortunately, I think Adobe needs to embrace a corporate culture of supporting their developers both technically and from a business perspective, not just among their evangelists, but also with their product and executive teams. If we’re successful, Flash (and by extension Adobe) will be successful.

What do you think?

Do you have an idea for encouraging a healthy ecosystem for commercial components? Share it here.

Making dispatchEvent More Efficient

In most projects there are tons of events that are dispatched, but that have no listeners subscribed to them. This shouldn’t be an issue, but it turns out that the Flash Player deals with these events inefficiently. Luckily it’s pretty easy to patch this for specific situations.

The code below will run about 5X faster than a standard dispatchEvent call when there is no event listener for the event type.

override public function dispatchEvent(evt:Event):Boolean {
if (hasEventListener(evt.type) || evt.bubbles) {
return super.dispatchEvent(evt);
return true;

Note that the actual time difference is fairly minimal (80ms vs 450ms for 100,000 iterations in my tests), so I would only do this in classes that you are going to create a lot of instances of and which will generate a lot of events that may not have listeners.

For example, I used this in GTween, because you could have thousands of tweens active at the same time, each of them dispatch CHANGE events every frame while active, and it’s very common to create tweens without a listener for that event.

While I think this will work for all cases, I haven’t tested extensively with less common event scenarios. Bubbling events should work, but you won’t get a performance increase.

This change also reduces efficiency for events that do have listeners, but it is very minimal (<10%, 505ms vs 545ms for 100k iterations in my tests).

Always Export a Release Build

When preparing a Flex project for deployment, always make sure to export a release build. I think most people know about this feature of FlexBuilder, but I’m not sure everyone is aware of just how important it is. The SWF that is generated when you run or debug your project contains a lot of extra byte code used for debugging and profiling your content.

This extra byte code has a very obvious effect on the size of your SWF (adding over 35% in some cases). It also has a less immediately obvious (but no less significant) effect on the performance of your application. In one example here at, a 980kb SWF was reduced to 675kb, and some performance intensive code ran over 2.5x faster in the release build than in the debug version.

Never deploy a project without exporting a release build, and be sure to test a release build if you are experiencing problems with file size, performance, or memory utilization.

Multilingual Spell Checking for Flash and Flex

We’re currently finishing off version 1.2 of the Spelling Plus Library, which includes a number of enhancements including:

  • various minor fixes and improvements, including resolving an issue with AIR context menus

  • improvements to the text highlighting engine

  • suggestions algorithm has been refactored to be slightly faster and more accurate

  • support for multiple languages using the roman character set

That last one is a big one, and one that we could use a little help with, if any multilingual folk have a bit of time to spare. Our office is hopelessly monolingual, and we are looking for some brave folk to spend 5 minutes or so just playing with the engine and seeing if it returns appropriate results. We’re currently testing French, Spanish, and German.

If you’re interested, either drop a comment below, or send us an email (use the contact link at the top of the page). Honestly, there’s no immediate incentive for doing it, but we’ll try to figure something out.

RegExr Desktop Released: Regular Expression Tool in AIR

I just uploaded the desktop version of RegExr. It’s just an AIR version of the online application for now, but I’ll add some desktop specific features, and put up a nicer looking page when I have a chance.

With this morning’s announcement of the AIR alpha for Linux, this means RegExr is now the first free tool for editing and testing regular expressions (RegEx) that runs on Mac OSX, Windows, Linux, and online (as far as I can determine). Pretty cool, considering it only took 60 minutes of work to convert the online application to a desktop program and add update notifications.

You can install the desktop version of RegExr here. Or, you can use the online version at

Next up, I plan to add support for testing replace functions, and then a proper lexer.