For some months now, I have been working on a single page application based on YUI; it's not public yet, but hopefully, it should be in a few months. Of course, each part of the application is unit tested and the natural choice in this context is to use YUI Test. The documentation of the YUI Test component is quite good but when I started the project, I missed a more step by step tutorial on how to test a custom component and on which tools I need to install. For those who are used to write unit tests for backend code, testing frontend JavaScript code is not fundamentally different, you still need to write code that can be tested and then you can write the tests and run them.

Code example

First, we need some code to be tested. To keep this post simple, I wrote a very simple YUI view called Move it view, it does not do much:

1. when it is rendered, it adds a class on its container and it enables a button
2. when the user taps on the button, it disables the button and adds a class which makes it in movements.

You can test it on my Github pages and look at the source code on Github as well. I know, the only way to stop the movement is to refresh the page, it's because I like to move it ;-) More seriously, this small list of features gives us what we'll have to test, the more you add features, the more you need to test.

Writing the tests!

Structure

The first thing to write is the HTML file which will be used to bootstrap the tests. It can directly contain the test cases but I personnally prefer to put the test cases in an external JavaScript file. Since the Move it view enhances an existing markup, a simplified version of this markup (the div class="container" here) needs to be embed in the HTML:

html>
head>title>Move it view teststitle>head>
body>

div class="container">
    button disabled="disabled" class="moveit">Move!button>
div>

script type="text/javascript" src="http://yui.

la suite...

Après un première article sur les notifications HTML5, je vais continuer cette série sur les notifications avec l’e-mail. Comment notifier simplement un utilisateur par e-mail ?

Installation de la librairie

Dans notre exemple, nous allons utiliser la librairie SwiftMailer produit par SensioLabs, l’éditeur de Symfony.
Pour l’installer, nous allons utiliser Composer :

{
  "require": {
    "swiftmailer/swiftmailer": "*",
  }
}

Puis en haut de notre fichier PHP, nous allons inclure l’autoload de Composer.

include_once './vendor/autoload.php';

Configuration du serveur SMTP

Nous allons configurer SwiftMailer pour qu’il utilise un serveur SMTP pour envoyer les e-mails.
Il pourra utiliser GMail :

$oTransporter = Swift_SmtpTransport::newInstance('smtp.gmail.com', 465, 'ssl');
$oTransporter->setUsername($this->username);
$oTransporter->setPassword($this->password);

$oMailer = Swift_Mailer::newInstance($oTransporter);

Ou il pourra utiliser OVH :

$oTransporter = Swift_SmtpTransport::newInstance('smtp.votredomaine.tld', 25, 'ssl');
$oTransporter->setUsername($this->username);
$oTransporter->setPassword($this->password);

$oMailer = Swift_Mailer::newInstance($oTransporter);

Mais il pourra évidemment utiliser votre serveur SMTP.

Configuration du message

Après avoir configuré le serveur SMTP, on va configurer le message que l’on souhaite envoyer.

On crée une instance de message :

$oMessage = Swift_Message::newInstance();

A partir de cet instance, on peut lui définir certains attributs :

• le sujet :
  

  $oMessage->setSubject('Subject');

• l’expéditeur :
  

  $oMessage->setFrom(array('email@domain.tld' => 'Nom Prénom'));

• le(s) destinataire(s) :
  

  $oMessage->setTo(array('email1@domain.tld' => 'Nom1 Prénom1', 'email2@domain.tld' => 'Nom2 Prénom2'));
  $oMessage->setCc(array('email3@domain.tld' => 'Nom3 Prénom3'));
  $oMessage->setBcc(array('email4@domain.tld' => 'Nom4 Prénom4'));

• le corps du message :
  

  $oMessage->setBody('Body');

• les pièces jointes :
  

  $oMessage->attach(Swift_Attachment::fromPath('file.

la suite...

Apr

Nous allons à travers cet article, établir la gestion des utilisateurs sous le framework Codeigniter. L'utilisateur devra se loguer, une vérification de ses identifiants sera effectuée.

Si tout se passe bien, ledit utilisateur aura sa session et lorsqu 'il se déconnectera, elle sera détruite. Vous pouvez améliorer ce code et l'adapter à votre projet. Sans plus tarder,...

• Youtube enables Chromecast support for embedded videos
• Harmonic Inc made a white-paper on Delivering Quality Ultra HD (this paper is a little older, it was out last August)
• Wowza announced his new version of Wowza Media Systems : Wowza Streaming Engine

Je me demande souvent pourquoi les personnes qui n?ont jamais tapé une seule ligne de code dans leur vie ne comprennent pas la complexité de notre métier.

Et si une réponse évidente est déjà dans la question en elle-même, je pense qu?il est tout de même intéressant de pousser la réflexion un peu plus loin, ne serait-ce que pour pouvoir améliorer notre communication, par exemple lors d?une planification de tâche ou une discussion à propos du nombre de jours nécessaire à un développement.

Et l?une des réponses que j?ai trouvées est que le non-informaticien a une vision extrêmement simplifiée de nos problématiques.

Ainsi, pour un néophyte en programmation, la gestion du temps est une chose très simple, puisqu?il y a des secondes, des minutes, des heures, des jours et que tout cela mis bout à bout permet d?obtenir des années, des siècles et même des millénaires.

Et de plus, tout cela est régi par des règles universelles, car tout le monde sait que 60 secondes forment une minute, que 60 minutes forment une heure et que 24 heures constituent une journée.

Le tout est de plus utilisé quotidiennement de manière quasi automatique par le commun des mortels depuis plusieurs millénaires, et si le commun des mortels est capable de le faire, un ordinateur devrait en être tout autant capable.

Sauf qu?en réalité, le temps et sa gestion sont infiniment plus complexes, car pour paraphrase Albert Einstein, il s?agit d?une notion toute relative.

Toutes les années ne font en effet pas 365 jours, comme tout les mois ne font pas forcément 30 ou 31 jours et certaines journées peuvent faire 25 heures, voir même contenir des semaines intercalaires.

De plus, en fonction de la position géographique, une date n?a pas forcément la même signification, puisque le 14 février à 18 h en France peut être le 15 février à 2 h à Tokyo.

La représentation d?une date peut également prendre moult formes, en fonction de la langue, du calendrier, de l?époque ou de la culture utilisée, ce qui peut par exemple mener à des ambiguïtés si le référentiel n?est pas précisé.

Ainsi, 9 h peut tout aussi bien signifier 9 h ou bien 21 h.

De plus, une date pourra avoir une signification différente en fonction de l?ordinateur utilisé, grâce par exemple à la magie de la localisation.

Le développeur doit donc prendre tout cela en compte, et même si les règles sont bien connues, faire les bons choix techniques en fonction du contexte d?utilisation et prendre en compte ces règles pour répondre correctement à un besoin peut devenir une véritable gageure.

Et si d?aventure les règles relatives au métier sont également complexes, la problématique peut devenir rapidement très complexe, et si vous avez le moindre doute à ce sujet, je vous invite pour vous en convaincre définitivement à, par exemple, lire les textes de loi régissant les 35 heures ou bien encore les congés payés.

la suite...

Je me demande souvent pourquoi les personnes qui n?ont jamais tap