DigitalSpirit - Test

Css3 en action avec Firefox 3.1b1pre

hugo — Tue, 07 Oct 2008 13:30:00 +0200

Voici une petite vidéo de ce qu'il sera possible de faire avec les CSS3, et, notamment, les transformations proposés par WebKit et border-image.

Css3 in action with Firefox 3.1b1pre

Css3 in action with Firefox 3.1b1pre from hugo on Vimeo.

Pour le déplacement des post-it, j'ai utilisé jquery-ui, j'aurai tout à fait pû utiliser -moz-transform: translate() mais le but était, évidemment, de montrer quelque chose qu'on a pas l'habitude de voir : la rotation et le redimensionnement d'objet en CSS...

Actuellement, la spécification n'est encore qu'un brouillon (ce qui explique l'utilisation du préfixe "-moz-") mais il existe un comportement, qui me semble gênant, ainsi, si on souhaite appliquer une transformation de type rotation ou redimensionnement, il faut passer par le mot-clef Css -moz-transform, édudiez l'exemple suivant :

p {
    -moz-transform: rotate(15deg);
    -moz-transform: scale(2);
}

Que va-t-il se passer ?
Les élements paragraphes vont subir une transformation de type scale, c'est tout, pas de rotation, le problème est qu'on ne peut pas, pour le moment, définir une transformation sans modifier les autres, ainsi, si une feuille de style externe veut appliquer une rotation à tous les élements p de la page, elle pourra le faire mais en "écrasant" aussi les autres transformations...cela est tout à fait normal à vrai dire, c'est écrit dans la spécification...

Ne serait-il pas judicieux de créer des propriétés transform-rotate, transform-scale, transform-skew...?

Testez par vous même : http://www.digitalspirit.org/lab/css3/transform.php (Rotation en cliquant sur la punaise, redimensionnement en cliquant en bas à droite du post-it et création de post-it en double cliquant sur la punaise)
Transformations en CSS3 sur le blog de Laurent Jouanneau
Explications sur le site de Clochix

Mémoire Flash et aimant font-ils bon ménage ?

hugo — Thu, 24 Apr 2008 21:01:00 +0200

Je me baladais dans une grande surface informatique lorsque j'ai entendu un vendeur raconter, sûr de lui, que la proximité d'un aimant et d'une mémoire flash aurait des conséquences dramatiques pour cette dernière, à savoir une perte de données irrémédiable.

Quelques temps auparavant m'était justement arrivé cette mésaventure, je cherchais ma clef usb que j'avais fini par retrouver collée...à un aimant et cela, sans le moindre dégâts sur les données.

Je repartis du magasin en me disant qu'il serait bon de savoir si, oui ou non, les aimants étaient dangereux pour nos précieuses données contenues dans des mémoires flash, en théorie non, mais à force d'entendre cette légende, j'ai pensé qu'il serait bon de tester, c'est le but de cet article...

Procédure de test

Afin de vérifier le danger ou non d'un aimant à côté d'une mémoire de type Flash, nous allons mettre un aimant à proximité immédiate d'une carte Flash pendant des durées croissantes en contrôlant à chaque étape l'intégrité des données.

Les protagonistes sont les suivants, tout d'abord, les cartes mémoires :

Deux aimants « collés » l'un sur l'autre, petits mais costauds, je n'ai pas mesuré l'intensité de ces aimants mais pour essayer de vous donner une idée, je peux vous dire qu'il est très dur, voir impossible, de les séparer à la force des mains une fois l'un sur l'autre...

Pour s'assurer de l'état des données après chaque phase de test, une lecture sera faite dans la carte et une comparaison de md5 sera faite sur l'intégralité de la carte.

Afin d'avoir un rendu plus lisible, le contenu de la carte sera une image au format TGA et c'est Léonard de Vinci qui nous prêtera son auto-portrait, la détérioration du contenu altérera visiblement l'image ainsi, il sera possible, en cas de détérioration de la mémoire flash, de voir visuellement les zones abimées.

Pour simplifier les tests, j'ai créé 2 scripts :

fl_create_ref : Créer les fichiers de référence
Liste des arguments :
- d : Le périphérique (ex: -d /dev/sda1)
- f : Identifiant de la flash (voir les numéros collés sur les clefs)
Le script exécute les actions suivantes :
1. Charge les données de l'image (sans l'en-tête) dans le périphérique
2. Dumpe la mémoire flash du périphérique et stocke le contenu dans un fichier, ce dernier servira de référence
3. Calcule le Md5 de la référence
fl_test : Exécute un test du périphérique
Liste des arguments :
- d : Le périphérique (ex: -d /dev/sda1)
- f : Identifiant de la flash (voir les numéros collés sur les clefs)
- s : Étape (step), c'est à dire, le premier test, le second, etc...
Ce script va se contenter de lire la mémoire flash, stocker le dump, calculer la somme Md5 et finalement exécuter une comparaison entre la référence de la mémoire courante et le dump obtenu.

Test

Tout d'abord, il faut remplir les mémoires et créer les références pour chaque périphérique, cela est fait grâce au script fl_create_ref :

./fl_create -d /dev/xxx -f 1
./fl_create -d /dev/yyy -f 2
./fl_create -d /dev/zzz -f 3

Une fois cette étape effectuée, il faut mettre à l'épreuve les mémoires, pour cela, j'ai mis en contact direct l'aimant avec la puce durant un temps déterminé.

Voici les différentes étapes durant lesquelles les mémoires flash ont été en contact direct avec l'aimant :

10 min
3 h
13 h
240 h

À la fin de chaque test, j'ai utilisé le script fl_test de cette manière :

./fl_test -d /dev/xxx -f 1 -s 2

Le paramètre -s correspondant bien sûr au numéro de l'étape (1 pour 10min, 3 pour 3h...)
Ainsi, à chaque étape, nous avons un dump complet pour chaque mémoire ainsi que les sommes Md5 associées.

Voici l'arborescence des fichiers une fois tous les tests réalisés :

$ tree
|-- README
|-- fl_create_ref
|-- fl_test
|-- flash
    |-- 1
    |   |-- leonard.data
    |   |-- leonard.md5
    |   |-- log
    |   |-- out-1.dump
    |   |-- out-2.dump
    |   |-- out-3.dump
    |   `-- out-4.dump
    |-- 2
    |   |-- leonard.data
    |   |-- leonard.md5
    |   |-- log
    |   |-- out-1.dump
    |   |-- out-2.dump
    |   |-- out-3.dump
    |   `-- out-4.dump
    |-- 3
    |   |-- leonard.data
    |   |-- leonard.md5
    |   |-- log
    |   |-- out-1.dump
    |   |-- out-2.dump
    |   |-- out-3.dump
    |   `-- out-4.dump
    `-- log

C'est donc avec l'oeil averti de Léonard que les tests se sont succédés.

Résultats

Les résultats sont clairs, nets et précis, l'aimant (immobile) placé à proximité immédiate des mémoires flash n'a en rien altéré les données présentes dans les puces.
Les sommes Md5 sont restés invariables et cela, aussi bien pour 10 minutes que pour 10 jours.

L'aimant n'a donc pas réussi à faire broncher le regard de Léonard...Rien de vraiment étonnant en considérant le fonctionnement interne d'une mémoire flash, l'étape suivante serait donc de tester les mémoires flash à proximité de champs magnétiques fluctuants (moteurs, antennes d'émissions...)

Annexe

Vous trouverez en pièces jointes une archive contenant les scripts décrits ci-dessus et les fichiers images qui ont été mis dans les mémoires.

Zaurus sl-c3000

hugo — Tue, 28 Dec 2004 01:41:00 +0000

Enfin, j'ai reçu mon cadeau de noël un peu en avance sur l'heure, bah oui, j'ai été très sage et j'ai reçu un Sharp Zaurus Sl-C3000 !
Pour ceux qui ne connaisse pas la bête, voici une brève fiche technique de ce pda tournant sous Linux (Source : GeekStuff4U.com) :

Processeur: Intel XScale PXA270 @ 416Mhz
Ram: Mémoire Flash 16Mo / SDRam 64Mo
Disque dûr: 4go (oui oui, 4Giga Octets, SL-C3000 dépouillé)
Affichage: 640*480; 3,7 pouces; 65 536 couleurs
Ports: Compacts Flash; Infra rouge; SD; USB

Des photos de la bête :

L'écran en portrait :

Détails de l'écran d'une qualité incroyable :

Un p'tit serveur X, ça vous branche :

Je retourne de ce pas faire mumuse avec mon jouet !