accessing ruby I18n locale messages from the web client

I like to keep my client-side code completely decoupled from the server-side but I still want to keep one message source for localization.

The ruby stack I use includes Sinatra, Sinatra::I18n and the I18n gem for localization and this is the simplest and most effective way (that I’ve found) of accomplishing this:

The Sinatra route:
get '/locales/:locale_name/messages.js' do |locale_name|
    locale = locale_name.to_sym
     
    if I18n.available_locales.include? locale then
        messages = I18n.backend.send(:translations)
        "var m = " + messages[locale].to_json 
                    + "; t = function(k){ return eval('m.' + k); }";
    else
        not_found
    end
end 

This way the yml locale file is loaded and served and wrapped for quick use.

In the client just request the messages script and then when you need a message call t(‘message key’) just like you’d do it in ruby :)


var message = t('message.key');

cause and effect – more testing doesn’t necessarily improve software quality

A short story about cause and effect I had in my backlog.

Jim works for a software company or, why not, he may even own it.

Jim realizes that the quality of the software that gets built in his company decreases year-by-year, all over the board.¬†He’s been seeing it for some time now but it seemed like the guys have it under control. You know, the guys know what they’re doing.

After awhile things seem to slip even further….

Continue reading cause and effect – more testing doesn’t necessarily improve software quality

what’s in a name: Single Page Application

Just found out that there’s a name for the type of apps that we’ve been working on for the last couple of years. It even has a catchy acronym.

So, you know those RESTful API accessing, JavaScript + JSON powered, highly dynamic, limited HTML web apps that everybody is developing lately?

Those are actually¬†Single Page Applications, or¬†SPAs.¬†There’s even a¬†Wikipedia entry¬†describing¬†the 10 year history of¬†SPAs.

The only good thing is that the page mentions thin server architecture, which is a big win, and probably the only thing that makes sense Рthe rest is just somebody misspelling AJAX driven web app.

Comparing SaaS Cloud apps hosting and provisioning options

This is what popped up while going through a thought experiment on choosing hosting and provisioning for the development of a new Software as a Service offering.

The options considered are:

  • PaaS with multi-tenancy ‚Äď use a PaaS offering (think Cloud Foundry,¬†Heroku, Google App Engine and¬†Windows Azure Compute) to host a multi-tenant system. Provisioning for a new client is zero-cost done inside the system
  • PaaS with one environment per client – use a PaaS offering (think ¬†Cloud Foundry,¬†Heroku, Google App Engine and¬†Windows Azure Compute) to host a regularly developed system. Provisioning for a new client means configuring a new PaaS environment, adding an instance and deploying
  • IaaS with multi-tenancy ‚Äď use an IaaS offering (think Amazon EC2 or Windows Azure Virtual Machines) to run a stack of Virtual Machines configured to run your platform of choice, hosting a clustered multi-tenant application. Provisioning is zero-cost after initial setup
  • IaaS with one stack per client – use an IaaS offering (think Amazon EC2 or Windows Azure Virtual Machines) to run one stack of Virtual Machines configured to run your platform of choice, hosting a clustered (or not) regularly developed application for each client. Provisioning means creating stacks, adding virtual machines, installing OS, DB, platform and deploying application

For convenience I also added a category called UGLY, just to highlight what I consider to be the worst point of each option.

SaaS

Over PaaS with multi-tenancy

Over PaaS with one environment per client

Over IaaS with multi-tenancy

Over IaaS with one stack per client

GOOD

  • Application must comply with platform constraints
  • One version for all clients
  • Single location deployment
  • Automatic scaling
  • Simpler, faster provisioning
  • Simple monitoring at the application level
  • Looks cheaper, pay by CPU-time and resource usage
  • Application must comply with platform constraints
  • Allows for multiple versions at the same time for different clients (even deep¬†customization)
  • Automatic scaling
  • Simpler provisioning
  • More control in choosing platform and technologies
  • One version for all clients
  • Can use farm-deployment for single location deployment
  • Simpler, faster provisioning
  • Simple monitoring at the application level
  • More control in choosing platform and technologies
  • Allows for multiple versions at the same time for different clients

BAD

  • Application must comply with platform constraints
  • One version for all clients
  • Application has to know about multi-tenancy ‚Äď it should be designed to support it
  • Application must comply with platform constraints
  • Must have tight configuration management to handle different versions for different clients
  • Provisioning may be slower, depending on instance creation speed
  • Complex monitoring
  • Must handle horizontal and vertical scaling
  • One version for all clients
  • Increase in deployment architecture complexity
  • Must handle clustering and state
  • Application has to know about multi-tenancy ‚Äď it should be designed to support it
  • Must handle horizontal and vertical scaling
  • Must have tight configuration management to handle different versions for different clients
  • Must handle different deployments and deployment scenarios
  • Complex monitoring

UGLY

  • Platform may enforce application architecture and technologies
  • Platform may enforce application architecture and technologies
  • Must manage operating system, storage and database configurations
  • Must manage multiple, possibly different operating systems, storage and database configurations

 

Some points are good and bad simultaneously. Examples:

  • Application must comply with platform constraints ‚Äď which means that you can’t always do what you want to do, producing
    • GOOD ‚Äď sometimes enforces good coding and resource-usage conventions
    • BAD ‚Äď more effort in developing exotic things
  • One version for all clients ‚Äď there can only be one version in production
    • GOOD ‚Äď less versions to worry about, less things to manage
    • BAD ‚Äď you may upgrade users that want the old version or you may have some users that want deep customizations and that are willing to pay for them

The overall conclusion is that the higher you go, the less you have to manage, the cheaper it gets.

For another good read you can check out the PaaS vs IaaS comparison on http://www.engineyard.com/paas-vs-iaas.

Users and their strange habits

Users are strange creatures, and to demonstrate, here are some quick facts:

  • They want to achieve lots of things as fast as they can, without learning anything new;
  • They hate reading and avoid anything that resembles help or a user manual… or even freaking text boxes;
  • They want user interfaces that look like other user interfaces and that function the way that other applications function but that ultimately achieve a different goal;
  • They want things to just work.

Yup, strange creatures indeed. Who would have thought? Not us programmer types anyway.

None of these facts are new. All of them are known since the dark ages of computing. All of them are well documented and repeatedly demonstrated. It just seems that a lot of the things that we used to know and follow are now forgotten.

Users want well designed products¬†that are tailored to their needs and that help them do what they want to do. Users¬†¬†just don’t want to read the manual and they have ¬†chronic dialog box blindness.¬†For users,¬†the user interface is the product¬†so if you want them to use your product they need consistent and usable interfaces.¬†Users need professionally designed, developed and ¬†production-ready products¬†that just work; not unfinished, buggy, wanna-be software.

Because users are ultimately our customers and because it is the right thing to do if we consider ourselves professionals that is what we must provide. Because that is what they deserve.

You can consider this post a small rant – just blowing off some steam after re-iterating some of these facts to a bunch of confused developers that think users are just plain stupid. They’re not stupid – we are just building software for the wrong people (rocket scientists that can read binary while unit testing in their sleep).

Replacing images and icons with CSS3 web fonts

It’s really hard to create beautiful and clean web interfaces when you have to slice and dice images for every little button, action or highlight. Well, now you can replace them with web-font characters styled with CSS3 – as most browsers have support for them.

Here’s a sample from something I’m working on just to give you a feel:

Image

Wait, there’s more: using styled¬†glyphs instead of images gives you more flexibility with application themes – and less images to mess with:

Image

The nice thing? What you’re actually seeing above is :

<div id="header-toolbox">
     <a href="">c</a> 
     <a href="">U</a> 
     <a href="">S</a>
     <a href="">X</a> 
 </div>

It’s actually¬†dynamically¬†built with JavaScript but you get the idea.

The font that I’m using for the glyphs is Web Symbols, available from¬†http://www.justbenicestudio.com/studio/websymbols/