GMail 2.0 pour Téléphone Mobile

Google vient de publier la nouvelle version de GMail 2 pour les appareils SmartPhone.
GMail 2.0 est une application Java. Cette particularité la rend compatible avec presque tous les SmartPhones du marché.
Cette nouvelle version présente une amélioration significative des performances, un support "offline" et quelques améliorations bien utiles.

Pour installer cette nouvelle application sur votre téléphone, naviguer vers l'adresse m.google.com/mail



Source: Cet article sur PCInpact.

Citation de Walt Disney

Ne regardez pas en arrière.
Allez de l'avant, 
pour ouvrir de nouvelles portes, 
faire de nouvelles choses par curiosité.
La curiosité nous fait découvrir de nouveaux chemins.

Walt Disney

Merci françoise.

La surchauffe de l'eau au micro-onde

Au détour d'une lecture sur le net, je suis tombé sur le message ci-dessous.
Je dois avouer que l'explication "scientifique" semblait plausible, malgré cela, je restais perplexe quand à l'histoire.
J'ai donc décidé de faire quelques recherches complémentaires sur le Net afin d'étayer les propos.

Comme la surchauffe de l'eau au micro-onde existe bien... je fais suivre l'information.
Je partage d'ailleurs le résultat de mes recherches... jetez donc un coup d'oeil sur les liens et vidéos au bas de cet article.

Danger dû au sur échauffement de l'eau dans un micro-ondes.

Il y a environ cinq jours, mon fils de 26 ans a décidé de prendre une tasse de café instantané. Il a pris une tasse d'eau et l'a mise dans le four à micro-ondes pour la réchauffer (ce qu'il fait régulièrement). Je ne suis pas certain de combien de temps il a mis sur la minuterie, mais il m'a dit qu'il voulait l'amener à ébullition. Lorsque la minuterie s'est arrêtée, il a enlevé la tasse du four. En prenant la tasse, il a noté que l'eau ne bouillait pas. Soudainement l'eau dans la tasse lui a 'explosé' au visage. La tasse est demeurée intacte jusqu'à ce qu'il la jette hors de ses mains, mais l'eau lui a sauté au visage à cause d'une accumulation d'énergie. Il a des cloques partout sur le visage et a subi des brûlures au premier et deuxième degré qui resteront probablement. De plus, il a perdu partiellement la vue de son oeil gauche. Lors de son arrivée à l'hôpital, le médecin qui le traitait a mentionné que c'est un fait courant et que l'eau (seule) ne devrait jamais être réchauffée au four à micro-ondes. Si on doit le faire de cette manière, quelque chose devrait être introduit dans la tasse, tel un bâton de bois ou une poche de thé (sans agrafe) afin de diffuser l'énergie.

Explication scientifique de ce phénomène.

Ce phénomène est connu sous le nom de sur-réchauffement. Ça se produit lorsque l'eau est chauffée et particulièrement lorsque le contenant est neuf. Ce qui se produit, c'est que l'eau se réchauffe plus rapidement de ce que les bulles de vapeur peuvent se produire. Considérant que les bulles ne peuvent se former et dégager la chaleur accumulée, le liquide ne bout pas, se réchauffe et dépasse son point d'ébullition. Ce qui se produit par la suite, c'est que lorsque l'eau est déplacée soudainement, le choc est suffisant pour causer la création rapide de bulles qui expulsent l'eau chaude. La formation rapide de bulles est également la raison pour laquelle des liqueurs carbonisées se déversent lorsqu'elles sont brassées avant de les ouvrir.

Prière de faire circuler ces informations aux personnes que vous connaissez afin de prévenir les blessures graves et la souffrance aux autres.

D'après le site HoaxBuster, le phénomène existerait bien (voir ce post).
Voici quelques informations complémentaires via une recherche de "superheating water in microwave" sur Google.
Vous trouverez ici une explication du phénomère... malheureusement, c'est en anglais.

Racket virtuel dans un monde réèl

De nos jours, je crois que la plupart des parents font attention aux problèmes de racket scolaire.Ainsi, il est courant de voir des parents conseiller à leur enfant de ne pas prendre sa console de jeux portable, de faire attention à son GSM, son lecteur MP3, de ne pas ostensiblement arborer des signes de richesse, etc.
Bref, le parfait manuel pour retrouver nos enfants en vie chaque soir....

Maintenant, il faudra également mettre nos enfants en garde contre le racket virtuel.
Avoir des objets dans un monde/jeu virtuel peut également motiver la convoitise.
Ansi, deux adolescents des Pays-Bas viennent de se faire condamner pour racket virtuel.

Cela semble peut être ridicule... mais réalisez quand même qu'un gosse s'est retrouvé tabassé et menacé avec un couteau pour céder une amulette qu'il possédait dans un jeu en ligne!

Source: Cet article sur PCInpact.

Generation PDF

Voici quelques références utiles concernant la génération de document PDF:

Outil de conversion pour application WEB:

• Prince pour la génération PDF depuis des documents html, css et XML.
  Prince est utilisé par Google Doc.
• Apache FOP permet également la génération de documents en ligne mais bassé sur des documents XML et une XSL-FO (formatting Object)

 Applications pour Windows:

• CutePDF writer (freeware)
• doPDF (freeware)
• PDFCreator (freeware)
  

 Références:

• Liste de logiciels sur Wikipedia (très bon article en anglais).
• Description de PDF (Portable Document File) sur Wikipedia (très complet).
• Article comparant PDF et XPS (Xml Paper Specification)
  

SQL Server Training - Estimated Execution plan

L'affichage du plan d'exécution est possible de différentes façon (entre autre via l'interface du SQL Analyser ou via SET STATISTICS XML ON).
Un précédent article sur les stored procedure traitait de cet activation.
Celui ci, plus pragmatique, fournira quelqyes de détails utiles pour la lecture du plan d'exécution.

Les flux d'informations
Les flux d'informations sont symbolisés par des flèches plus ou moins épaisses.
Plus elles sont épaisses, plus le flux d'information est gros (en terme de milliers de records).
Il va de soi que les flux d'informations en amont du plan d'exécution (les sélections de données depuis la DB) doivent être aussi restreints que possible.
Plus ils seront importants et plus le coût s'en ressentira sur le temps de traitement (jointure, tri, filtrage) et la consommation de la mémoire de travail.

Les jointures
En interne, l'engine SQL utilise plusieurs algorithmes pour joindre des rowset de source différentes.
Parmis ces algorithmes, il y a:

1. Le Merge Join.
2. Le Hash Join.
3. Le Nested Loop Join
   

Le Merge Join
Le merge join est l'opération la moins couteuse et la plus rapide.
Les deux rowsets peuvent être joints en une seule opération continue.
Cette opération n'est possible que si les deux rowset sont stockés (produit) avec le même tri.

Le Hash Join
Opération plus couteuse que le merge join et donc plus lente. Dans ce cas de figure, une clé de hashage doit être produite sur les données avant une opération de Merge Join.
Cet opération nécessite l'usage d'une "table temporaire" pour stocker les résultats intermédiaires, elle est donc gourmande en mémoire.

Le Nested Loop Join
L'opération Nested Loop est sans conteste l'opération la plus couteuse (et de loin). 
Pour chaque entrée d'un rowset, SQL Serveur effectue une opération de recherche dans le second. Le Nested Loop Join a donc des performances catastrophiques.
Cette jointure n'est envisagée par SQL server qu'en dernier recours.
Une façon de l'éviter est, en autre, de donner un maximum d'informations au "query optimizer".
Cela est possible:

1. En complétant au maximum la requête SQL (plus de critères dans la clause WHERE, augmenter les critères de jointures dans les joints, etc).
2. Réécrire la requête SQL différement (par exemple, remplacer les outer join par des sub-query).
   

SQL Server Training (Jour 4) - View et Stored Proc

Views
Les vues sont vraiment très populaire dans beaucoup de companies pour les raisons suivantes:

• Les données sont publiées via une View sur laquelle on applique la sécurité. Un access direct aux data model n'est jamais fournit.
• Les données sont modifiés à l'aide de stored proc (utilisation de sécurité EXECUTE).
• Dans ce cas de figure, la view intervient comme une couche d'abstration masquant le Data Model sous-jacent. Il est dont possible de faire évoluer le schéma sans que cela perturbe les applications clientes en adaptant les views.
• Permet d'organiser les données pour export (bien qu'il y ait d'autres outils pour cela).
• Permet de nommer clairement (humainement compréhensible) les colonnes.
• Permet de masquer les informations non pertinentes.
• Par défaut, les enregistrements d'une view peuvent être mis-à-jour ou effacés (si la view n'est, bien entendu, pas trop compliqué. Voir 7-10).
  

Désavantages:

• Il faut garder à l'esprit que les views diminuent les performances du moteur DB (parce que les noms sont évalués on-the-fly). Ainsi, on veillera à ne jamais dépasser 5 niveaux (View built on another view).
• Eviter les jointures dans le views (après 5 jointures, les performances sont terriblement mauvaises).
  

SCHEMABINDING

Les views n'utilisent pas de contrainte fortes sur le schema (Par default, SCHEMABINDING n'est pas actif). Cela présent un avantage et un inconvénient.
L'avantage est qu'il est possible de modifier le schéma sous-jacent sans devoir effacer et recréer la view. C'est vraiment pratique pour les opérations de maintenance. Cependant, si erreur il y a (parce qu'il manque une colonne nécessaire dans la table sous-jacente), elle ne sera révélée que lorsque la view sera accédée.
Avec un SCHEMABINDING, il sera impossible de modifier les tables sous-jacentes sans détruire les views qui l'utilise (pour les recréer après).
Cela diminue certe le risque d'erreur mais rends la maintenance très contraignante.

Persistant Index

Comme précisé précédemment, les Views ne sont pas très performantes. C'est encore plus vrai si elles couvrent de grandes tables ou de multiple jointure.
L'une des façon de contourner ces problèmes de performances est d'utiliser une "persistant index" sur la view.
Cette opération d'indexation de view crée effectivement un CLUISTERED INDEX. C'est a dire un index B-TREE contenant les pages de données... comme il s'agit d'une vuew, c'est une copie des pages de donnée qui se retrouvent dans l'arbre.
Et bien entendu, ce sont toutes les données qui sont dupliquée. La view sera effectivement performante... mais il y a un prix (les données sont dupliquées).
Bien que couteuse, cette métode a un avantage indéniable. En cas de corruption de la table source, SQL Server sera capable de récupérer les données corrompues depuis le "persistant index" (avec DBCC DBRepair).  

Maintenance: Utilisation de view et Triggers
Si une table disparait du data-model pour être remplacé par une structure plus compliquée, il est possible de la "re-rendre disponible" via une View.
L'utilisation de TRIGGER INSTEAD OF permet même de continuer à supporter les operations insert/Update/Delete sur la view.

Stored Procedure
Pas grand chose de nouveau à apprendre dans ce domaine. Cependant, ce ne fût pas une perte de temps.

Il est fortement conseillé d'éviter l'usage des tables temporaires (#TempTableName) et des Curseurs lorsque cela est possible. L'utilisation de nouvelles structures et fonctionnalités de SQL Server permettent d'obtenir des codes 30 fois plus rapides.

Il ne faut JAMAIS utiliser le préfix "sp_" pour nommer les procédure. "sp_" est réservé aux "System Procedures". Lorsque l'interpreteur SQL essaye de résourde le nom de la stored proc commençant par "sp_" dans la master DB. Si elle n'y est pas retrouvée, une tentative de localisation dans la DB courante est alors entamée. Cela représente une surcharge d'exécution inutile!

Une stored procedure retourne toujours un entier. Cette fonctionnalité devrait être utilisée pour retourné un status d'éxécution à l'appellant. Par convention 0 = false, 1..N indique un status.
Le status est assigné avec avec l'instruction return (ex: RETURN 2).
Le status est récupèré lors de l'appel par une assignation directe.
Exemple:
DECLARE @UspStatus integer
DECLARE @AParam varchar(50)
SELECT @AParam = 'Hello'
DECLARE @MyResultingText varchar(100)
EXEC @UpsStatus = MyStoredProc "Param1", 5, @AParam, @MyResultingText OUTPUT

Recommandations

• Préfixer les stored procedure avec "usp_" pour "User Stored Procedure" (recommandation).
• Lors des appels de stored procedure, ne pas oublier d'utiliser le mot clé OUTPUT pour récupérer un paramètre par valeur (sinon NULL est retourné).
  EXECUTE @ProcStatus = ProcedureName ParameterValue, @ParameterVariable, @ReturnedValue OUTPUT
• Une stored procédure doit toujours vérifier la validité de sess paramètres.
  IF (@Value <0 )
  RAISERROR( 'Error Message', 14, 1 )
  RETURN
  END
• Lors d'un RAISERROR, ne pas utiliser des erreurs avec une trop grande sévérité car cela rompt la connection (avec des effets indésirés).
• Utiliser la variable @@recordCount pour connaître le nombre de records retourné par la dernière opération SQL.
• Lors de la modification d'une stored procédure, ajouter les nouveaux parametres avec une assignation de valeur par défaut. Cela permet aux applications existantes de continuer à fonctionner sans modification.
• Lors de l'appel d'une stored procédure, utiliser le mot clé DEFAULT pour utiliser la valeur par défaut (signalée dans la définition dans la store procédure).
  

Plan d'éxécution des stored procedure
Le plan d'exécution permet d'avoir une synthèse des opérations effectuées par SQL Server durant l'exécution d'une requête SQL.
L'activation de l'EXECUTION PLAN depuis la console SQL est triviale (depuis la barre des boutons).
Cependant, lorsqu'il s'agit d'une stored procedure, il faut faire appel à des options spécifiques.
Il est ainsi possible de détecter les opérations couteuses dans une stored procedure afin de les optimiser.

Il y a différentes façons d'obtenir des informations d'exécution:

SET STATISTIC IO ON/OFF
Affiche dans les messages le nombre de pages de 8kb lues depuis le disque.
Logical Reads: # de pages qui devaient lues pour atteindre l'objectif.
Physical Reads: # de pages chargées depuis le disque (les autres pages se trouvaient dans le cache).
Read-Aheads: Lors d'operations avec temps de processing perdu, SQL serveur prend l'initiative de lire des pages complémentaires (# de pages chargées en plus dans le cache).

SET STATISTIC TIME ON/OFF

Affiche les details de temps d'exécution dans les messages.

SET STATISTICS PROFILE ON
Fonctionnalité très utile mais malheureusement disparue en SQL2008.
Fournit le plan d'exécution sous forme de table relationnelle.
Il y est possible de lire l'entièreté du schema d'execution presqu'aussi simplement que le graphique lui-même.

SET STATISTICS XML ON
Produit les même information que STATISTICS PROFILE au format XML.
Ce format à l'inconvenient d'être moins lisible et donc plus difficile à exploité par simple lecture. Cependant, il existe une foule de logiciel exploitant ce format pour en reconstituer un graphique.
Contient en autre un noeud nommé MissingIndexGroup.