Some Vexing Glitches

In preparation for pre-launch (alphas) of the Dynamic Forms tool at NearState, we've been trying to get a web-site thrown together which can host the basic content we need. Gabi designed a nice logo for us, and the intent has always been to animate the logo on the web-site. After some extended R&D :P I finally managed to get some decent animation going with cleaned-up SVG exported from Illustrator.

As with the main products, we use Chrome during development, and cross-browser test on Firefox, Safari and IE (and Opera if we're feeling energetic). SVG has always rendered fairly well, although it had some nasty glitches in IE <8. In fact we have a detection for those browsers and use a static image instead. 

However, since ~Chrome 18 (I think it was) we now get a wierd flicker when animated elements cross over SVG text elements. <sigh /> And that means more hoking around in the markup to try and fix it. 

I know there's the option to switch to Canvas but is that really the best option? SVG still looks better on older browsers, and it's so much closer to what Gabi works with as a designer. Canvas is trendy, so I suppose that means the browser vendors will watch their implementations more closely. 

Innovation. Pah. It's all fine until you're doing it at 2am. Unless - sometimes at about 2:38am when magic happens. 

gbL.jsMop >> github

Well, I've finished initial work on the message passing framework we're using at nearstate for our F1 forms project. (http://www.nearstate.com#f1dynamic).

The framework is called gbL.jsMop (i.e. message-oriented programming).

More here: http://goofballlogic.github.com/gbL.jsMop/

Ted Dziuba is not cancer

But I still don't know if I really like him.

From his infamous post on node js, I proceeded to many other entertaining and flowery articles. Worth a read even if you end up thinking he's probably just another obnoxious American prick (which wouldn't be very fair of you if you've never met the guy).

One post that has stuck in my mind is one about process and software development methodology (and the virtue of almost-not-having one).  I think he may have a point here. I know he howls and whines like a starving dog in heat but he's right - much of this corporate bs "standups", "backlog lists" etc. really does not work very well. It might work ok in an idealised environment, but I've yet to see e.g. a Scrummaster run "proper" scrum, or even a variant which preserved any of its virtues in a corporate environment. At least in my time in London... It doesn't matter if it's a startup, a bank or an educational firm, large or small, they all end up relying on meaningless process because it lends structure, but that structure itself has no further meaning and uses up large amounts of time and emotional energy.

The same is true of mountains of unit tests and associated mountains of endlessly injected services into classes that would be small, simple classes in the absence of trying to shoe-horn TDD into the mix. Don't get me wrong - I love a bit of TDD, and I feel safer with some of my projects knowing it's there - but not usually in corporate projects. In those situations, you have a huge solution drowning in endless layers of redirection, specialised handling and most importantly - endless mapping of one layer's entities to another layer's entities - all of which, I suppose, should be TDD'd. So you write reams of tests for mapping entities (yes I know about automapper) which represent logic which shouldn't be there in the first place. (yes I know about BDD). All the unit testing in the world doesn't compensate for a lack of good architecture, and a lack of understanding of the virtues of small, autonomous systems communicating with messages (as opposed to a large stack of crud).

Why do businesses keep building these crap systems? Is it just a lack of bravery to separate things into meaningful discrete units? Are we that afraid of deployment? Is it too much to ask that "the website" isn't just one thing (or two if you count the database)?

Well, I'm not up for it any more. I will be asking about architecture in all future interviews for work I take on. What I want to know is - "how do you divide your systems up into meaningful subsystems?" "how to those subsystems communicate with each other?"