Menu

Adding a subtle background noise to Web pages is becoming a design trend: it produces a nice old-skool “analog” look that feels more like the “real world”. Neat examples are Forrst.com or Stripe.com, as well as many UI elements in iOS5.

Click the image to see a demo of NoiseGen, the jQuery plugin discussed later in this article

The usual way to achieve the effect is to use an image editing software to produce a PNG image and then set it as the background-image through CSS. Still, this approach has some drawbacks. First of all, the image has its bandwidth footprint. Moreover, fine-tuning background noise during development can be very time consuming, having to come back to the image editing software to save a new image each time you want to adjust the effect. Luckily, there’s a solution: using JavaScript and the HTML5 canvas element to dynamically produce a background image.

The idea is simple: create a canvas element, paint it with noise, and then set it as the background-image through CSS.

Unfortunately, some browsers do not support the canvas element yet (guess who?), so we need to provide for a graceful fallback. Also, it would be cool to have the possibility to finely tweak parameters like opacity, dimension of the image, size of the noise grains, statistical distribution of noise, colors, etc…

Luckily, we’ve got you covered! NoiseGen is an open-source jQuery plugin that does exactly that, offering support for a fallback image for crappy old browsers and many useful configuration options. Using it is straightforward:

Here we’re adding background noise to the body element. Cool browsers will do that dynamically on the client side, while old browsers can rely on the bandwidth hungry image. Moreover, we can finely tweak the look of our background:

Last week I played with a SOAP API with savon.rb to develop a newsletter system.

This API require authentication with a two-way handshake. At first you send a login, a password and a key and it gave you back a token. When you ended operation you should send a “close connection” command.

This is a popular way but when you use it in a model seems a bit tricky so I decided to hide this method inside a custom class.

It works but the webservice il very slow, opening and closing connection require about 20 seconds and for hundred operation is too much time.

Another way is to encapsulate authentication process inside object initialization and finalization. For this we need something similar to a C++ constructor and destructor method. Ruby has got the initialize method similar to constructor but it does not have a standard destructor. Luckily we can emulate it.

The ObjectSpace module enable you to define block that is executed when the object is destroyed using the define_finalizer method.

ObjectSpace.define_finalizer(self, Proc.new{@api.close_connection})

In the initialize method we can open the connection and define this finalizer. We can rewite the method as follow:

The application had two controllers: Products and Clients. We added to the Products controller a function that shows a static message when we click on the button. Now we want to fetch the data to display from the database.

Each time we start the application, the closure in db.js run the migrations not already executed. We can run the app to create the table then add some fake data with a SQLite manager. Alternatively we can create another migration to add sample data, it’s up to you.

With this fourth part we conclude this series of tutorials. It’s not too much, just a start but we are planning to create a new series of tutorials in september that will cover the coding of a complete application with Appcelerator on Rails.

We are going to create a small application with 2 empty tab, with a very simple logic, that at the end will look like this.

First create the controllers and the views. We need the ruby interpreter (version 1.8.7) in ordert to run the generators. If you have no Ruby interpreter installed on your system, you can find one here.

Hi again, in this four parts tutorial I will present some ideas and projects to implement a MVC framework for Appcelerator Titanium, a multiplatform (iOS and Android) Javascript framework to build native mobile apps.

In part 1 we discovered the structure of Appcelerator on Rails. It’s a quite well designed framework, the basic ideas are good but there are several limitations. The first problem comes from the implementation of the controller.

The closure at the end of this class instantiates the controller only when you include the file. If you want to instantiate one more, you must include the class file again and this isn’t good from a coding perspective. A better implementation would split definition and instantiation.

This, as well as having potential advantages in terms of memory usage, it’s more rational too.

Another advantage is the ability to access global variables inside the controllers and views without weird tricks, something not previously allowed.

These were functional improvements: another improvement is to clean the included code. The Appcelerator on Rails’ library files are full of code that is no longer used. As well as increasing the size and memory usage it also generates a long series of warnings that complicates debugging. Cleaning and tidying these files is a necessary work.

Fabio Barbieri, the developer behind these improvements, has made ​​a preliminary sample of the code, cleaned and fixed, that can be downloaded here.

That’s all for part 2. In the next part I will present how to build a simple app starting from these considerations.