moogallery plugin has just been released and charged to the mootools forge. Actually the plugin was already available from ajs, the javascript "addon" library for mootools which I populate with scripts I often use in my work.

moogallery is a plugin for mootools that allows you to create a gallery of images in a table format with tips and lightbox included. It 's enough to provide the container which has to contain the gallery and the path to the thumb and the whole images with related information (title, description, credits) to generate an autosized gallery inside the container in which the thumbs are loaded sequentially. Each thumb has attached an over event (showing the image title) and a click event ...

read the full post

Some times ago I wrote about the private static and instance members in mootools classes. Now it's time to speak about the protected members in mootools classes.

So the goal here is to obtain some members which are inherited from the parent class and accessible to a child class but not outside.

The trick is to use the Object.merge function to merge together the private properties of the parent exposed to the children through a protected method and the private properties of the child. Look at the following code:

1. var ids = 1;
2. 
   
3. var myParentClass = (function(){
4. 
   
5.   var _protected_prop = {};
6. 
   
7.   return new Class({
8. 
   
9.     initialize: function(id, par1, par2) {
10.       this.id = id;
11.       ...

read the full post

This is the fifth and last part of the django deploy environment, you may find the fourth part here.

In this part we'll see how to automate the deployment using fabric.

What the hell have fabric to do?

Well, fabric have to do all the work for me in the sense that once I've done some changes to my project and pushed them to the bare repository I want to update the production environment with only one command. I'd like also to setup initially the whole environment with only one command.

How does it work?

First of all install it, so with the virtualenv activated:

$ pip install fabric

Done.

Now reading from the official site:

Fabric is a Python (2.5 or higher) library and command-line tool for streamlining the use of SSH for application deployment or systems administration tasks. It provides a basic suite of operations for executing local or remote shell commands (normally or via sudo) and uploading/downloading files, as well as auxiliary functionality such as prompting the running user for input, or aborting ...

read the full post

This is the fourth part of the django deploy environment, you may find the third part here.

In this part we'll see how to freeze the project requirements, use versioning and prepare all in order to automate the deployment in production with fabric (which will be the argument of the last post, part 5).

Create a requirements.txt

As said in all previous posts, all the packages used by our project have been installed in a virtualenv which is strictly connected to our project. And if you were asking yourself why this is a convenient way to approach the django developement issue here comes the answer.

Activate the virtualenv, go inside the container folder of your django project and then perform this simple command

$ pip freeze > requirements.txt

This command simply creates a requirements.txt files which contains all the project dependencies, look at the image illustrating the project folder structure in the part 2, you'll see the same file there.

The nice part here is that you may setup an equivalent environment, with all the dependencies ...

read the full post

This is the third part of the django deploy environment, you may find the second part here.

In this part we'll see how to set up nginx and uwsgi to work with our django project.

Let's install and configure uwsgi

Be sure to have the virtualenv activated (see part 2), and then install uwsgi

$ pip install uwsgi

Ok now we have to configure our project to work with uwsgi, open and edit the myproject/myproject/wsgi.py file, mine looks like this:

"""
WSGI config for sic2012 project.

This module contains the WSGI application used by Django's development server
and any production WSGI deployments. It should expose a module-level variable
named ``application``. Django's ``runserver`` and ``runfcgi`` commands discover
this application via the ``WSGI_APPLICATION`` setting.

Usually you will have the standard Django WSGI application here, but it also
might make sense to replace the whole Django WSGI application with a custom one
that later delegates to the Django one. For example, you could introduce WSGI
middleware here, or combine a Django application with an application of another
framework.

"""
import os ...

read the full post

Ok, this is the second part of the django deploy environment, you may find the first part here.

In the prevoius post we have seen how to install nginx webserver an some system packages, both in locale and remote, now it's time to start our developement in locale.

Let's create a new virtualenv

The use of virtualenv is incredibly comfortable and lets you keep separated environment for different projects. So first of all create a new virtualenv in the place you prefer

$ mkdir ~/virtualenv
$ cd ~/virtualenv
$ virtualenv --no-site-packages myproject

Done, now we can activate the virtualenv so that every new python package will be installed in it, so

$ source ~/virtualenv/myproject/bin/activate

MySQL as the database server

Why MySQL? Only because I'm easy with it, I know its syntax, I'm accustomed with it and because I use it at work.
But, since the role of mysql in the whole deploy structure finishes here, you may want to use a different db server, more efficient, lightweight and which uses less system resources

In the first post ...

read the full post

After googling for a while, asking my guru and some tests I was able to setup a deploy environment for django projects.

The web server is nginx, the database server mysql, I use uwsgi as wsgi server, all the code is versioned using git, the python libraries are installed in a virtualenv, db migration is assured by South and the deploy is automated using fabric.

While writing this post the whole environment is working but I think it may be adjusted in some ways, so let's take what follows as a guideline to improve in many aspects.

I assume we are working in locale and deploying directly to a production server, ignoring the staging phase.

Installing some packages (locale and remote)

To set up the environment we need python >= 2.6, python-dev, python-setuptools, pip and virtualenv, so (in a debian/ubuntu os):

$ sudo apt-get install python python-dev python-setuptools
$ sudo easy_install pip
$ pip install virtualenv

Ok that's all, the other python packages will be installed in the virtualenv, so now let's continue installing git and mysql

$ sudo apt-get install git ...

read the full post

Let's see two patterns that may be used to have private members in mootools classes.

Private static members

Here is quite simple, it's enough to use a single execution function and js closures and provide the setter and getter methods to change and retrieve the member's values.

var myclass = (function() {
  var _name = null,
      _age = null;
  return new Class({
    initialize: function() {
      // do some stuffs
    },
    setName: function(name) {
      // do some checks here
      _name = name;
    },
    setAge: function(age) {
      // do some checks here
      _age = age.toInt();
    },
    getName: function() {
      return _name;
    },
    getAge: function() {
      return _age;
    }
  });
}());
var myinstance = new myclass();
console.log(myinstance.name); // undefined
myinstance.setName('jack');
console.log(myinstance.name); // undefined
console.log(myinstance.getName()); // jack

So what happens here is that the two variables

_name and _age

are in the scope of the single execution function, and so not accessible from outside. But their value is retained by the returned object which yes can access them since it is ...

read the full post

Wow, the first post of the last year of the world...

In the last weeks I've discovered the importance of the semantics rules applied to the web documents (well, really I knew it before, but I had never given it the importance it has).
The html5 specification introduces some new interesting html elements which plays a leading rule in this sense. Here I speak about some of them since many and many articles may tell you the same story and probably in a better way, look at this for example.

With the older html4 and XHTML the semantic structure of the page was determined essentially by the title tag in the head of the document and by all the h1..h6 tags in the body, which all represents an headline in a descendant order. In particular if you wanted to have a semantic structure with only one external root element you had to use only one h1 element. Then you had to use the others (in descendant order) to create semantics subsections.

The html5 specification introduces some semantic elements which may be used to create more complex semantic structures, and solve some situations that couldn't be managed earlier ...

read the full post

Il succo è questo:
ho scritto due post sul blog della otto (la tanto cara azienda in cui lavoro), in cui illustro come si possa fare per rendere vim un editor perfetto per sviluppare codice php. Allora siccome sarebbe inutile ripetere qui le stesse cose e soprattutto non ne ho voglia, vi linko semplicemente i due post in questione, buona lettura.

Vim for php programmers parte 1

Vim for php programmers parte 2