960 Grid System

The 960 Grid System is an effort to streamline web development workflow by providing commonly used dimensions, based on a width of 960 pixels. There are two variants: 12 and 16 columns, which can be used separately or in tandem.


In an effort to help developers and designers adopt this win-for-all approach to layout, Andrée Hansson has created the 960 Gridder browser overlay which can be triggered through a simple link in the browser.


Activating the 960 Gridder on this blog eventually looks like this, revealing that I have a small breakage of the 960 Grid system…


Please make a note of the control panel in the left side which allows for simple tweaking of the grid overlay… really really cool stuff.

Check it out…
960 Grid System
960 Gridder


YAGNI… one of the most important concepts

In software engineering, YAGNI, short for ‘You Aren’t Gonna Need It’, suggests to programmers that they should not add functionality until it is necessary. Ron Jeffries writes, “Always implement things when you actually need them, never when you just foresee that you need them.” According to those who advocate the YAGNI approach, the temptation to write code that is not necessary at the moment, but might be in the future, has the following disadvantages:

  • The time spent is taken from adding, testing or improving necessary functionality.
  • The new features must be debugged, documented, and supported.
  • Any new feature imposes constraints on what can be done in the future, so an unnecessary feature now may prevent implementing a necessary feature later.
  • Until the feature is actually needed, it is difficult to fully define what it should do and to test it. If the new feature is not properly defined and tested, it may not work right, even if it eventually is needed.
    It leads to code bloat; the software becomes larger and more complicated.
  • Unless there are specifications and some kind of revision control, the feature may not be known to programmers who could make use of it.
  • Adding the new feature may suggest other new features. If these new features are implemented as well, this may result in a snowball effect towards creeping featurism.

The above excerpt is taken from today’s Wikipedia entry… Check it out…

ActionScript 3.0

Advanced ActionScript APIs… by Jacob Wright

While researching a question put forward by one of the Flex developers in Hello about Serialization/Deserialization to/from AIR databases, I stumbled across a video where Jacob Wright gets hands-on and concrete in giving ActionScript developers tips on how to create reusable libraries…
Including things such as using Proxy, IExternalizable, Code Namespaces and how to plan your new great API which will be easy to use for others and represent a lot of power…



One of the most frequent requests I have pending in my Knowledge Pipeline is the question about how to implement REDO/UNDO… the classical approach seems to be the individual developer’s imagination, however it may prove to be the worst reference since it tends to diverge quite strongly in quality of implementation.

Check out the original Memeto pattern…. its quite cool in its implementation.


Exception Shielding… let's do it

Use the Exception Shielding pattern to sanitize unsafe exceptions by replacing them with exceptions that are safe by design. Return only those exceptions to the client that have been sanitized or exceptions that are safe by design. Exceptions that are safe by design do not contain sensitive information in the exception message, and they do not contain a detailed stack trace, either of which might reveal sensitive information about the Web service’s inner workings.

For some anticipated exceptions that are safe by design, such as data validation errors, the Web service returns appropriate information to the client. For other exceptions, such as authentication failures, the exception logic sanitizes the exception, replacing it with an exception that is safe by design.

Remember, always create systems exposed to the internet based on some basic premises, such as e.g. not telling the caller of a service something revealing the implementation, but tell the caller something that only relates to the logical layer. Don’t do it for security alone, but allow the (developer) client of your service to gain enough information to go on a qualified bug-hunt…


Quince… UX patterns library…

As I get older in this crazy business of attracting users and even going as far as attempting the daunting task of trying to make them happy and satisfied, I find myself examining HCI studies and other user centric disciplines…

Enter Quince…

Among one of the interesting ones getting a lot of attention these days are UxD patterns… first they got some love from Yahoo… and now anyone doing Web will have a UxD pattern library with at least 20% proprietary patterns (however, come to think of it, how can it be a SW pattern if its proprietary !?) … anyways…

If you find yourself working with real humans from time to time as end-users, don’t hesitate to check out Quince…

You can browse the library in a number of ways…
But I definitely recommend that you take it for a spin with Silverlight installed… it will definitely improve on the overall experience.

Infragistics are pretty cool…


Design Patterns : “Supervising Controller” or ”Presentation Model”

When skinning a UI component, a developer is always faced with the option of using “Push” or “Pull” for getting data from the Component to the Skin.

Eventually the decision can be inferred from the way the Adobe Flex framework itself has been implemented in the upcoming release: Adobe Flex 4 – codename “Gumbo”.

Here transcribing from the documentation for skinning…

There are different ways to pass data back and forth between the skin and the component. One is the push method; the other is the pull method. The push method means taking a property from the component and stuffing it into the appropriate skin slot. On the other hand, if the skin asked the host component what the property value was, that would be the pull method. The pull method would use binding in the skin to grab the content from the component. In the push method, the component pushes the value down into the skin. For example, in FxContainer in the content setter, we push this value down to the contentGroup part. Though there’s no hard rule when choosing between the two different methods, in the framework, if the functionality is optional in the skin, we use the pull method. However, if the functionality is required in the skin, we use the push method.

It’s important to note that the Adobe Flex Gumbo team is deviating a bit on this topic from the formal definition given by Martin Fowler, where the Gumbo team have the decision following the line between elements being required or optional, Martin Fowler has the decision follow a complicated / not-complicated distinction… despite my great admiration for Martin Fowler and my strong preference for general solutions – I think I will attempt to mostly follow the Gumbo platform designers based on the perception that consistency is better than obtrusive idealism.

FYI… “Supervising Controller” is taken from the context of the “Supervising Presenter” as discussed here by Martin Fowler…