303 See Other

Location: http://architecturalatrocities.com

Stability tip for running Sequel in Rails on Passenger

If you use Sequel in a web app running in Apache, here’s a stability tip: make sure you reconnect to the database when Passenger forks.

Read the rest of this entry →

Ruby 1.9 and encodings, lament № 1

Yehuda Katz, has done an excellent writeup on Ruby and encodings, but under the heading “Why this is, in practice, a rare problem”, I think he’s explained exactly why, in practice, there is a common problem:

In practice, most sources of data, without any further work, are already encoded as UTF-8. For instance, the default Rails MySQL connection specifies a UTF-8 client encoding, so even an ISO-8859-1 database will return UTF-8 data.

Many other data sources, such as MongoDB, only support UTF-8 data internally, so their Ruby 1.9-compatible drivers already return UTF-8 encoded data.

Your text editor (TextMate) likely defaults to saving your templates as UTF-8, so the characters in the templates are already encoded in UTF-8.

And then Ruby 1.9, unless you explicitly tells it otherwise, defaults to interpreting the file, and all strings defined in it, as ASCII and all that is for nothing.

Installing the MySQL gem in Snow Leopard

Installing the native MySQL gem (simply called mysql) isn’t as easy as it may seem — unless you’ve installed both MySQL and Ruby using MacPorts, in which case it is.

There are a few problems that crop up when installing the mysql gem: the build process may not find the MySQL libraries, they may build them for the wrong architecture and you may not have gotten all the required files when you installed MySQL.

Read the rest of this entry →

parseInt and hexatridecimals

There’s a bug in ActionScript 2′s parseInt: it strips “0x” or “0X” from the start of the string, regardless of the base. It’s ok in most situations, since “0x” isn’t a valid part of any number base — except 35 and 36. And that’s where the bug lies. If you run parseInt("0XABC", 36) you should get 1553016, but instead you get 13368, which is ABC in base 36.

There’s a very simple workaround (if anyone besides me is actually doing this and using ActionScript 2), and that’s to add “00″ to the start of any base 35 or 36 number passed to parseInt. Why not “0″? you may ask. That would only shift the problem to numbers starting with “X”.

The issue seems to be fixed in ActionScript 3.

Look! I’m not dead!

…but I do other stuff now.

I haven’t updated this blog in over half a year, sorry about that. It’s just that my focus used to be Flex, and I almost haven’t written a single line of Flex code in just as long. I’ve updated the about page with new info.

Hopefully more will follow (ah, those famous last words).

Quoted in “Professional Cairngorm”

Seems like I’ve been quoted in a book with the (contradictory) title Professional Cairngorm. It’s the now (in)famous Architectural Atrocities 9: Cairngorm’s Model Locator Pattern again. It’s not the best quote to take from that post, but beggars can’t be choosers.

The quote is on page 267 in the chapter “Criticisms of Cairngorm” (where else), and it can be found through Google Booksearch. The chapter also quotes Neil Webb as a critic of the Singleton pattern.

I applaud the author’s good taste in including a chapter on criticisms — although I think that if he really had taken the time to understand what both Neil and I have said he wouldn’t just put us under the sub header “Singled out — Bad Singleton, Bad”. Our critique goes far beyond Singletons and Monostates. Even so, if that is the level you aim for, then those things need to be said too.

Debug both Flex and AIR apps from the same FlexBuilder project

For some reason FlexBuilder forces you to choose between creating Flex projects and AIR projects, and it doesn’t let you change a projects nature after it’s been created. This means that if you create a Flex project you will not be able to compile, debug or profile any AIR applications that you happen to build from the same code base. This has annoyed me to no end, but I have finally found the solution.

Read the rest of this entry →

Architectural Atrocities, part 11: Not yet another namespace construct

Gumbo introduces many new classes, some of which are re-implementations of existing Halo classes (and thus have the same name). In order to disambiguate between Halo and Gumbo, Gumbo classes are prefixed to avoid collisions. Gumbo components that have Halo equivalents, like Button, List and CheckBox, are now prefixed with the letters “Fx”. This means in MXML, a Gumbo Button would be instantiated via the <FXButton /> MXML tag, and a Halo Button would continue to be instantiated via the <Button /> MXML tag. Additionally, the new animation classes in Gumbo also follow the same prefix policy. A Gumbo resize effect is instantiated via the <FxResize /> MXML tag while a Halo resize effect is instantiated via the <Resize /> tag.

From Gumbo Component Architecture

So what are they going to do for Flex 5, use “Fx2″?

Seriously, ActionScript has three* namespace constructs already, why introduce a fourth? Using prefixes is a hack to get namespaces in language that lacks them (like C or PHP), but packages were invented to solve exactly this problem.

In MXML it’s dead simple to use namespaces and prefixes to differentiate between different components with the same class name (e.g. <mx:Button> vs. <fx:Button>). The only place where it gets a bit messy is in ActionScript, but it seems to me that it is a fringe case when you want to juggle both a Halo and a Gumbo button or both a Halo and a Gumbo list in the same class (a Halo list and a Gumbo button, sure, but that wouldn’t cause a clash). I can see it happening, but not often enough to warrant such an ugly solution as this.

I remember when AIR was called Apollo and the WindowedApplication class was called ApolloApplication. This is the same kind of short-sightedness.

* Three namespace constructs: packages, namespaces and XML namespaces (which are different from packages since you can manually flatten a package structure with a manifest, e.g. the Flex namespace contains both classes from mx.core and mx.controls, and others).

Update: Adobe has decided to revert the decision of prefixing the new Gumbo classes. Good for everyone.

How to work around the lack of ExternalInterface.objectID in ActionScript 2

I would guess that not very many of those who read this blog have used ActionScript 2 lately. I have had the unfortunate luck of having to write some of it during the past few weeks and I don’t recommend it. However, I ran into a problem that I’d like to share the solution to, if anyone else would even find themselves in my position.

Read the rest of this entry →