Over the past several months I’ve put together some rather extensive AS2 class libraries for some ongoing Flash projects. I had noticed that many of the open source libraries available on the interwebs had snazzy html documentation. Putting together this kind of documentation is not only helpful for other people using the libraries (so that they don’t have to go digging through the code), but it comes in handy when the author (me, in this case) hasn’t touched the code for a while.
I’m a big believer in the open-source movement and many times I’ve been able to find an open source solution that does the trick as well or better than a packaged piece of software can. So I started searching under the assumption that I would eventually settle on an open-source solution. In the case of Actionscript documentation, I found my ideal solution in VisDoc. It was one of the few solutions that had a Graphical User Interface rather than using a command line. It produces a beautiful set of documentation files. It works for both AS2 and AS3 (and Java). The one downside is that it’s Mac only. It’s not open-source, but with a sticker price of $40, it’s well worth the time saved. If you’re still looking for open-source or you need an app for your Windows machine, OSFlash has a comprehensive list of open-source documentations tools for Actionscript.
… is a system design principle where the implementation takes into consideration future growth…
…the design includes all of the hooks and mechanisms for expanding/enhancing the system with new capabilities without having to make major changes to the system infrastructure….A good architecture provides the design principles to ensure this—a roadmap for that portion of the road yet to be built…These excess capabilities are not frills, but are necessary for maintainability and for avoiding early obsolescence.
…can also mean that a software system’s behavior is modifiable at runtime, without recompiling or changing the original source code.
This idea is useful when building projects that have iterations or phases. Sometimes the client knows they’re going to want multiple versions of a given project. Realistically though, this happens all the time, even when one is working with little outside influence. An idea doesn’t usually look the same on the screen as it does in our minds or in a script. It needs tweaking and fine-tuning. As designers, we often go through myriad iterations before reaching the final product. Over time, I’ve come to realize ways to save myself future hassle by taking time upfront, at the start of a project, and planning what pieces might change how I can design them to be more flexible and more economic. This ‘brain-time’ early on reduces the ‘oh crap’ time later.
Ever have trouble installing a font with FontBook (or Windows’ non-existent font management software) and don’t want to fork over the money for Suitcase?
Linotype Font Explorer. It’s free for OS X and a Windows version is on its way. It’s gotten me out of two font jams thus far.
Much of my scripting work these days takes place outside of the Flash Actions panel, but occasionally I’ll be working inside the actions panel and want format some of my code to make it more readable. I don’t like hitting the auto-format button because it gets rid of the line breaks (thus making it less readable).
So when I have to indent several lines of code, I select all the lines I want to indent and hit the TAB key. You can also decrease the indent by hitting SHIFT + TAB. This also works in external editors like SE|PY. It’s a little bit slower than auto-format, but it’s a lot faster than clicking and tabbing each line individually.