Premature optimization is the root of all evil

Other April 24th, 2009 @ 10:04

From time to time, discussions pop up on how to optimize your code. “Create your arrays like this”, “define your variables like that” etc. Today I read a blog post by Sean Moore, summarizing a lot of (alleged) performance optimizations in AS3. It contains quite a few incorrect points, but probably serves quite good as a place to find out the truth behind some optimization myths. There are a few interesting comments in the “comments section”…

Anywho. My opinion is that you should rarely bother to do this kind of micro optimizations of your code. Maintainability and readability of the code is way more important, especially in larger products as those we’re working on. People should put more effort in that area, than saving a nano second here and there. (Also, there’s often far better places to optimize the code than in variable declarations and arrays…)

I hate it when I come across code like this (JavaScript in this example):

var i = 0, j = 1, k = 2;

… as opposed to the more human readable:

var i = 0;
var j = 1;
var k = 2;

There’s no real reason what so ever to write code like that! It just makes it harder to read and maintain.
I guess maybe that’s why I’m not a preacher of the chaining madness in jQuery…

(The headline is a quote from Donald Knuth, which I think applies to any programming language, at least all of those I’ve been working with).

Why and how to use MXML?

Flash & Flex April 23rd, 2009 @ 16:04

I’m yet to fully understand the “awesomeness” of using MXML in your Flash/Flex applications. I’ve always written my code in AS (1,2,3) and set up the views by combining AS code with laying them out in the Flash authoring environment. And I have to say that’s worked out well!

But MXML is said to improve productivity as be “easier to write” and that is a matterI’ve been delving into quite a lot over the past months. (Unfortunately “easier to write” usually comes with a bunch of unneccesary, over-the-top functionality…).

What do others say?

Recently I’ve been trying to figure out how to use MXML together with AS code. I’ve scanned the web for articles, and have found a few interesting. This one, by Dan Orlando, seemed to be on the same track as myself. Also, I’ve previously come across this one, discussing a few pros and cons of MXML.

I don’t know the answer… yet.

I haven’t really come to any conclusion yet, but I’m hoping to do so shortly. I’m sure there’s benefits from using MXML – i.e. to lay out your views – but it’ll be interesting to see how to best combine it with “regular” AS code…

This was a post in the midst of something, but more is to come on the topic, for sure!

EDIT: I’ve posted a presentation about Flex (and MXML).

Kill your standards darlings – IE still rules

Browser Compatibility April 21st, 2009 @ 11:04

From time to time, I have a look at various browser statistics to check if there’s been any changes in the usage share of browsers. Even though non-IE browsers take more and more shares on the market, Internet Explorer still rules (with around 70% in average). In some areas, the share is even higher; I worked on a product recently where we had an “IE share” of 97% …

What this means to us as professional web developers, is that all products (sites) must be 100% functional in Internet Explorer. There’s no room for excuses like “but it works in Firefox”. There can be no important features/styles/etc that only works in non-IE browsers.

I read about a lot of web developers saying “ignore IE and develop according to the standards”. Maybe that works for your own personal web site, viewed by 10 users a month. But if you’re running a professional site, supported by a large business, you can’t make it a crappy experience for all the regular users out there who aren’t using the latest Firefox or Safari build. That’s just dumb.
When the non-IE browsers have 95% of the market, we can start talking about ignoring IE and its quirks.

I’m not saying I like fixing IE bugs/quirks, but it’s a part of the job, just like any other task. Firefox (my own preference), Safari, Chrome or whatever are surely awesome browsers, far better than IE. But it doesn’t matter, because it’s only us “experts” and hardcore users that know about it. Your target group doesn’t.

So make it your primary goal to have the site working 100% in IE! If you want to use the extra goodies provided by other browsers, make that the little extra functionality that makes it a 110% experience in standards browsers.

(I do my primary development using FF and Firebug (as it’s much more efficient), and do a test round in IE 6+ when I’m done with the design. )

Spot on, senocular

Flash & Flex April 9th, 2009 @ 09:04

I came across this post on newbie Flex development for us experienced Flash developers. I think senocular is spot on here; many of the highlights are things I’ve come across myself when fooling around with Flex.

No reason not to keep trying, though! :-)

Insights from the Adobe Rich Internet Experience Tour

Flash & Flex April 1st, 2009 @ 18:04

Today, myself and a few co-workers spent our afternoon at the Adobe “Rich Internet Experience Tour” seminar here in Stockholm. The topics – focused on web development – were:

My main interest was the (more) in-depth demo of Flash Catalyst and Flex, which I’ve been investigating quite a lot lately (and also given some more or less harsh comments on).

Flash Catalyst strikes back!

After today, I’m more impressed with the capabilities of Flash Catalyst – at least if it’s used properly. It was nice to hear Enrique emphasize that it was intended for the View part of the application (in an MVC app). Previously, I’ve interpreted the fuzz about Flash Catalyst as a replacement for the entire MVC model (basically a replacement of regular coding), but that’s not (necessarily) the case.

If we were to use FC purely as a tool for the View Components in our applications, we could really improve our productivity massively. But to me, it stops there. I would keep away from using the different “states” in FC, i.e. to create the various views in the app. Single-view only, please! :-)

But it’s all on a pretty much theoretical level, really, as FC is still on a very early stage in its development (seems like we’re at least a year away from first real release). But it looks interesting, to say the least!

My notes from the seminar

I put down some notes on my mobile phone during the seminar. Maybe some rambling, but hHere it goes:

  • Good to use Flash Catalyst – only for isolated components? Avoid using “states” in FC?
  • What are the capabilities of FXG? What’s the syntax like?
  • Does FXG “skin classes” (and likes thereof) be in MXML? Can regular AS classes be used instead?
  • Can FXG code be imported to Flash Catalyst?
  • How can Flex and FXG be combined with regular AS classes?
  • Try putting more use to SWC files?
  • How are SWC files used with Flex? How are component files (binaries) managed in Flex in general?
  • Would Gumbo (new Flex Builder) be interesting to use?
  • Take a look at Blaze DS for data services. Using HTTP protocol. RTMF to be used when more instant feedback needed.
  • Have a look at Adobe AFCS.

All in all…

  • Flash Catalyst seemed a lot more interesting in a live demo and I look forward to seeing the public beta (without expecting too much…) :-) .
  • PixelBender was really cool (a lot more cooler than its docs :-) )!
  • The presented “case”, My Home,  was very cool, but perhaps a bit Big Brothery. Doesn’t feel too secure…
  • A good seminar; better than expected!