Archive for the ‘Uncategorized’ Category

Create a custom dojo build

Sunday, July 25th, 2010

When you develop an application with dojo, you can pretty quickly end-up with tens of http calls to load all dojo.require() files on demand. In my case, for a simple script relying on dijit.Dialog & dijit.Tooltip, firebug reporting more than 25 http calls for individual files. In production, this is not optimal at all.

So we will try to use dojo utilities to create our custom dojo file containing all (and only) the required dojo code into a single file. Problem is that there is scarce help on this matter on the Internet and official documentation is not correct!

Here are the steps:

  1. download a dojo- SDK (or “source-release”) (http://dojotoolkit.org)  (the uncompressed code is not enough), it contains data required to create dojo builds
  2. ensure java 1.4.2 or later is set up on your computer
  3. unzip dojo sdk file and go to: cd <dojo_folder>/util/buildscripts
  4. now create a new file that you will save wherever you want and call it “myapp.profile.js
    In this file we will put the following content:

    dependencies = {
    layers:
    [
    //This layer is used to discard modules
    //from the dojo package.

    {
    name: "dojo.js",
    customBase: true,
    discard: true,
    dependencies:
    [
    "dojo._base"
    ]

    },

    //This layer is used to discard modules
    //from the dijit package.

    //Custom layer mydojo.js which
    // includes our custom Dojo artifacts
    {
    //place the file under dojoRootDir
    name: “../../mydojo.js”,
    layerDependencies:
    [
    "dojo.js",
    ],
    dependencies:
    [
    //modules to be included from the
    //custom project. You can probably
    //list a single module here which in
    //turn declares all the required
    //modules as opposed to listing all the
    //modules individually. Please take a
    //look at dojoRootDir/dojo/_base.js
    //file for an example.
    // "dojo._base"
    "dijit.Dialog",
    "dijit.Tooltip"

    ]
    }
    ],

    prefixes: [
    ["dijit", "../dijit"],
    ["dojox", "../dojox"]
    ]

    }

  5. customize this file as you wish, basically simply list all the module you need where I put dijit.Dialog & dijit.Tooltip. Do not worry about modules required by these two modules, they will be automatically inserted by the build script!
  6. now run the following command:
    ./build.sh profileFile=<path_to_myapp.profile.js> action=clean,release releaseName=cusomizedDojo
  7. wait a few minutes (maybe more!)
  8. when the script has finished running, go up to dojo-root folder, a new folder named ‘release’ has been created, your dojo code is in there! The file you’re interested into is at the root of this folder and is named ‘mydojo.js’ or whatever name you put in your profile file.
  9. That’s it!

One-step further

At this point, we have generated a mydojo.js file containing all shrinked code for our dojo modules. Problem is that it does not contain dojo.js itself! It tried to include ‘dojo._base’ as a required module but it did not work. What I did was simply to open dojo.js in a word editor, copy its content and paste it at the top of mydojo.js file.

Now you have all your dojo-related js code in a single file! Exactly what we wanted.
If we insert this file in our code, replacing regular dojo.js file, we can see in firebug that no-more http calls are made!

Important notice

In my case, a folder named ‘nls’ was generated. It seems that this folder content cannot be incorporated into the single js file by build-script => I left it on its own in my /js folder and a single http call is made to retrieve the content of appropriate language file. A single extra http-call seems acceptable to me so  I left it this way.

Illustration

Before:

After:

Woooow! this is far better.

sources

find your bios version directly from bash (ubuntu / debian)

Friday, May 8th, 2009

To find your bios version, simply run “dmidecode -s bios-version” as root

sources

XPath, SimpleXML and default namespace

Friday, January 16th, 2009

I explained in a previous post (SimpleXML and default namespace) how to register default namespace on SimpleXMLElement in order to execute an xpath query, and why in some cases this step is simply mandatory.

Bad news is that xpath-namespaces are registered on a per-node basis. Ie. if you execute an xpath query on another SimpleXMLElement (let’s say a child of the node on which you registered your default namespace), then you need to register it on this node too for your xpath query to get successfully executed.

You need to register xpath-namsepaces on each SimpleXMLElement on which an xpath query gets executed (including if this element has been retrieved using an xpath query on an element on which xpath-namespaces have already been registered).

sources

taxe tv pour ordi!

Friday, January 16th, 2009

http://www.latribune.fr/entreprises/communication/publicite-medias/20090115trib000332111/le-senat-adopte-la-hausse-de-la-redevance-et-son-extension-aux-ordinateurs.html

choosing a flat

Monday, October 6th, 2008

Rules to keep in mind when choosing a flat:

  1. always on the last floor: simply impossible to live with neighbors above (dog nails on the floor, people walking, unknowm object rolling…)
  2. never chose a building that has all its rooms on the street/road: you won’t have any room where you don’t hear cars, people shouting, klaxons, buses…) this is extremely exhausting, make sure you have at least one room that’s far from the road
  3. avoid “cubes”, ie. a flat with at least four neighbors: make sure some rooms are isolated (there’s always neighbor’s tv, phone, scoring noises…)
  4. avoid HLM, prefer small flats: the more people there is, the noisier (more people = more chance to have dogs within close flats, more people leaving – going in, more people refurnishing – drills and so on – a flat)

=> always top-floor, no tube-on-the-street, no cubicle, and if you have choice, prefer smallest building
(flat inner appearance is not important, you always can improve it, whereas above stated elements, you cannot)

Zend_Translate: further separate content from code + avoid doublon in source language

Tuesday, September 9th, 2008

There something I am not comfortable with Zend_Translate_Adapter behavior, it’s the fact that source string is used as key for translation array.
To me it looks like mixing css and html within the same file, I prefer having css in dedicated files and html in dedicated files too. Here my approach is the same. Since content is translated in multiple languages (using translation tools => therefore stored in dedicated files), I don’t want to have it anymore within my php file.

I find current implementation too risky. Let’s take a simple example: I have a single sentence, both in French and English (translate in Xliff format, or array, or csv or whatever), stored in translation.xlf/php/txt file. English is my source language, and French my target language. Let’s say we translate “My car is blue !” => “Ma voiture est bleue !”. I’ve made a typo on purpose within English string, we will see required steps (and attached risk on each step) to change the content (basically remove the space before “!”).

With current implementation:
- I have a dedicated file: translation.php with content: <?php $translation = array(‘My car is blue !’ => ‘Ma voiture est bleue !’); ?>
- I have several view scripts (ex: mycar.phtml) in which I call my Zend_Translate instance: $translate->_(‘My car is blue !’);
So far so good. Now I want to update my source sentence, to correct this typo and display ‘My car is {color:red}blue!{color}’ instead of ‘My car is {color:red}blue !{color}.’
1. I do what seems most logical to me, I update translation.php.
In 90% of cases, I know I will stop it and forget to update all my view scripts where I call this string => This update is worst than before, because if I don’t update my view script, I’ve broken my translation array and the result is that I still have my typo displayed, and now when I use French locale, string is no longer translated and default to message_id (ie. in English and with typo)!
2. Let’s say I am lucky and I remember I need to update my view scripts.
First, I don’t like having to look within all my view scripts to find where I use this string, and update it everywhere (99% of chance I will forget one entry or make mistakes updating it)
Second, it does not look normal to me to have to modify my php files when I have dedicated files to handle content in several languages.
Third, let’s say I’ve translated my content in a third language (Spanish). Since English is my source language, it is used as source string in all my translated languages => updating an English typo makes me update content files in all other languages!

My approach is really to separate content from code, and make languages less dependent from source language.
Instead of defaulting to $messageId when…

Doublon in source language (since $messageId must correspond to source string) => double update required + explain that source language is already present but not used in current implementation (we use $messageId which is expected to replicate source content)

[necessary tools]

Monday, June 2nd, 2008
  • xp: online in less than <5 mins
  • start small: bits per bits, and not everything at once “small steps are better”
  • develop parts in isolation, as standalone components, and make them communicate
  • when changes are made => set them online immediately
  • document code as you type (and require code to be properly documented (incl. js). With php, implements phpdocumentor standards => generate an api documentation immediately
  • xp: yagni
  • xp: the quicker way the better
  • set up a bug tracker (trac?)
  • set up a version handler (subversion?)
  • implement unit tests (including manual tests) and run a checklist on them
  • roadmaps
  • define and communicate on practices in place such as:
  1. coding style
  2. code documentation style
  3. file name convention
  4. revision control storage
  5. frequence of changes into revision controls
  • => once define, write them down on a wiki (incl. into Trac) so that they can be used as reference and communicate on them
    (can seem a bit heavy to do all this prior to any coding, but it’s absolutely necessary because will save huge pains in the future + it’s reusable for other projects)
  • add code reviews too

Hello world!

Monday, June 2nd, 2008

Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!