Débogger des ISAPI avec Delphi 2007

Configurer correctement IIS
En suivant scrupuleusement les recommandations de cet article, nous pouvions débogger nos DLL isapi écritent en Delphi 2007.

Des breakpoints qui ne s'activent pas!
Cependant, de temps à autres, il y avait des modules isapi pour lesquels les breakpoints n'étaient pas activés alors même que les "debug infos" étaient visiblement inclus (petit point bleu dans la marge après la compilation) .
Comme signe caractéristiques de ce disfonctionnement, les breakpoints viraient à la couleur "caca d'oie" tout en arborant un symbole breakpoint univoque (un signe d'interdiction) au moment du chargement du module isapi.
Après de multiples essais pour inclure autant de debug information que possible, c'est une peu part hasard que j'ai activé l'option "Include remote debug Symbols" dans la section LINKER des options du projet.
Après cet activation, mes breakpoints ont soudainement fonctionnés correctement. Génial!

Configuration screenshots
Voici quelques prise de vue d'une configuration qui fonctionne parfaitement pour débogguer des dll ISAPI avec IIS.
Cliquer pour agrandir

 

  

  

 

Découvrez Ubuntu

Pour les curieux disposant de peu de temps où manquant cruellement de courage pour entamer la lecture d’un ouvrage d’une centaine de page, voici un superbe mini-guide sur Ubuntu.
Du haut de ses 5 pages richement illustrées, ce mini-guide (au format PDF) introduira le lecteur au système d’exploitation libre Ubuntu ainsi qu'a son richissime écosystème.
Ce guide est un excellent point de départ pour tous les néophytes et assurément un document de référence pour les autres.

Merci à Aurélien Paulus, étudiant Belge à l’origine de cet ouvrage.
Vous pouvez poursuivre votre lecture sur son article ici.

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.

SQL Server Training (Jour 3) - Intégrité et Trigger

Voila, je vais vite profiter d'une petite pause pour publier le résumé d'avant hier.
Je commence vraiment à crouler sous l'information :-)

Intégrité des données
Aujourd'hui cours sur la gestion de l'intégrité dans les DB.
Il y a trois façons de gérer l'intégrité:

1. Domain Integrity: Contrainte sur les colonnes, restreindre les valeurs dans le colonnes.
2. Entity Integrity: intégrité des enregistrements. Chaque record doit être identifié de façon unique (utilisation de Primary Key)
3. Referential Integrity: L'information contenue dans une colonne doit correspondre au contenu d'une clé primaire d'une autre table.
   

Options pour renforcer l'intégrité des données:

• Data types.
• Rules:  utilisé pour définir les valeurs acceptables dans une colonne. (OBSOLETE, not Ansi compliant).
• Default Values: permet de définir la valeur par défaut de certains champs. (OBSOLETE, not Ansi compliant).
• Xml Schema: Permet de renforcer la validation des données dans les champs XML.
• Triggers: Permet l'execution de code au moment de la sauvegarde/mise-à-jour/effacement d'enregistrement. Les triggers permettent un controle poussé de l'intégrité et du flux de donnée.
• Constraints: Ansi compliant. Definit comment la moteur DB doit renforcer l'intégrité des données.
  Il existe plusieurs type de contraintes:
  
  
  1. Primary Key
  2. Default
  3. Check
  4. Unique - La valeur contenue dans la colonne (ou combinaison de colonnes) doit être unique pour toute la table.
  5. Foreign Key  
     

Limite des contraintes:

1. Ne peut pas extraire des données depuis une autre table.
2. Ne peut pas faire appel à une stored procedure.
   

Check Constraint
Cette contraite permet de faire des vérifications sur les données (sur base d'expression) lorsqu'elles sont modifiées.
Cette contrainte est l'une des plus mal estimée alors qu'elle est la plus simple et fournit l'une des plus grande valeur ajoutée.
Plusieurs Check Constraint peuvent exister sur un même champ.
Un Check Constraint peut faire référence à un autre champs de la table (mais pas à une autre table).
Les "Check Constraint" ne peuvent pas contenir de sous query (voir Trigger).
Avantages:
Permet la modification d'information depuis une application tiers (Access) ou l'administrateur (SQL Statement) sans mettre l'intégrité des données en danger.
Note:
Il est possible de désactiver des "Check Constraint" pour accélérer le traitement de longues opérations (update, reload).

Foreign Key Constraint
Cette contrainte permet de s'assurer que la valeur d'une colonne correspond bien au contenu de la clé primaire (unique) d'une autre table.
C'est une contrainte d'intégrité référentielle.
Pour un champs soumis à une foreign key, il est impossible d'y introduire une valeur illégale. Bien que protégeant bien l'intégrité des données, les Foreign Keys présentent quelques désavantages les rendant peu populaire.
C'est ainsi que beaucoup de sociétés préfère ne pas implémenter ce genre de contraintes en production (leur préférant les triggers).

Actions:

Lors de la définition des "Foreign Key" constrainte, il est possible de préciser une clause CASCADE (update or delete). Cette dernière clause permet d'indiquer quel operation doit être exécuté sur le record lorsque la référence est modifiée ou effacée.
Par default, l'action est NO ACTION dans les deux cas.
Il est possible d'utiliser CASCADE qui est vraiment dangereux lors de l'effacement de la référence car il efface également les dependences.
Si orderDetails.ProductID reference la table product avec DELETE Cascade, alors l'effacement d'un produit efface également toutes rows orderDetails (where orderDetails.ProductID=product.productID). OUPS!
Il existe également des options SET NULL ou SET DEFAULT (voir 5-21). 

Désavantages:

• Limite les operations de modification de schéma (renommer des colonnes).
• Consomme des ressources (il faut faire un choix entre performance et sécurité).
• Peut se montrer lents lors que la clé primaire de référence appartient à une table très grande.
• Nécessaire de désactiver ce type de contrainte lors du rebuild des indexes.
• Représente des contraintes d'utilisation vraiment excessives pour les DB de reporting. Il est en effet courant d'effacer et de recharger de nouvelles données en masse dans ce genre de DB. Dans ce cas, les foreign key représentent des contraintes non nécessaire puisqu'il n'est pas possible de tronquer la table... et la mise à jour d'information en masse est fortement ralentie par la vérification de la contrainte.
  

Default Constraint
Vraiment utile pour s'assurer que certains champs soient tooujours correctement initialisés.
Sont utilisation est recommandée. 

Triggers
Les triggers permettent d'activer du code (actions) lors d'un événement d'insertion/update/delete de records sur une table.
Le trigger est appelé une seule fois par opération (quelque soit le scope de l'opération). Qu'une requête sql modifie ou efface 1 ou 2000 enregistrements (en fonction de sa where clause), le trigger ne sera activé qu'une seule fois pour la modification entière.
Les triggers sont toujours executés dans la même transaction que l'événement.
Il est par conséquent possible de faire un rollback pour annuler l'événement d'origine.
Mais en contre partie, il faut veiller à avoir un trigger aussi court que possible afin de limiter le temps de transaction.

Il y a deux type de triggers:

1. After Trigger: Trigger qui sont exécutés après l'événement sur la table. Ce qui permet par exemple de vérifier des contraintes d'intégrité ou de maintenir des tables d'audit. 
2. Instead Of Trigger: Trigger qui remplace l'événement. Ce qui permet de modifier le comportement standard de SQL Server. Eg: remplacer un effacement physique par un effacement logique ou encore répartir l'information au sauvegarder entre plusieurs tables (utile lorsque le trigger est placé sur une vue).
   

Recommandation d'usage:

1. Récuperer les records insérés ou mis-à-jour depuis la table virtuelle "udpated".
2. Récuperer les records effacés depuis la table virtuelle "deleted".
3. Le trigger doit être écrit de façon fonctionner avec une table deleted et updated contenant plusieurs enregistrement (erreur courante).
4. En cas d'effacement, toujours faire un count(*) from deteled pour s'assurer qu'il y a des informations à effacer.
5. Par default, un trigger n'est pas récursif sur sa propre table.
6. Un trigger peut déclencher un trigger sur un autre table (cascading firing)
   

Informations diverses:

• Pour tester si un champ a été modifié, utiliser la fonction Update(FieldName)
• Pour stopper une trigger (rollback), utilser RaiseError( N'Message', 10, 1 )
• Lorsqu'un trigger insert des records dans une autre table, utiliser le mot clé OUTPUT pour récupérer les valeurs des champs identity dans une variable de type table (voir autre article à venir)
  

Cas d'utilisations:

• Effectuer un effacement logique (active=0) lors d'une instruction DELETE FROM.
• Eviter les effacements physique en les interdisants. Meme si la sécurité est mal configuré, il ne sera pas possible d'effacer les records.
• Propagation d'état. Par exemple, la désactivation d'une catégorie de produit peut egalement désactiver tous les produits et ajouter un commentaire aux commandes en cours sur ces produits.
• Permettre d'effectuer des vérifications complexes et de retourner des messages d'erreurs préçis.
• Remplacement de Foreign Key constraint... car les trigger peuvent être désactivés et réactivé pour accélérer des opérations de maintenance. La contrainte d'intégrité implémenté dans le trigger ne sera revérifiée que lors d'une nouvelle modification de l'enregistrement.
  

SQL Server Training - Migration et compatility Level

Durant mon training, j'ai eu l'occasion de mettre la main sur une série de script de diagnostique SQL2005 plus que très intéressant (missing indexes, Index Fragmentation, Index usage, etc).
Ces scripts sont, bien évidement, exécutés depuis une console TSQL et fonctionnent comme attendu.

Par contre, certains d'entre-eux ne fonctionnaient absolument pas la DB de TrialXS.
Vraiment étrange si l'on sait que ces scripts n'analyse que des données système.


La réponse est simple... La DB TrialXS est restaurée depuis un backup SQL2000.
Par conséquent, le compatibility mode "SQL 2000" est appliqué à la DB (voir DB Options) sour SQL2005.
En modifiant le "compatibility mode" j'ai enfin réussit à tester mes merveilleux scripts.

Par contre cela lève une nouvelle question: 
Comment nos applications ISAPI (ou script de migration DB) vont-ils réagir en se connectant sur une même DB configurée en compatibility mode SQL7 (prod actuel) ou SQL2000 (ancien env. développement) ou SQL2005 (actuellement non activé)?


Pour des raisons évidentes de facilités de maintenance (à venir... mais avec les super trainings scripts SQL), les "compatibility mode" des DB de production doivent être configurés SQL2005.

SQL Server Training (Jour 2)

Que retenir de cette deuxième journée:

XML
Maintenant que SQL Serveur dispose d'un datatype natif XML, il est possible:

1. De stocker du contenu XML dans un champs et d'y appliquer des méthodes de traitement spécifiques (XQuery).
2. De générer directement du contenu XML depuis une requête SQL (FOR XML).
3. D'accepter un input XML, de le parser et le transformer en données relationnelles (OPEN XML).
   

Ce chapitre fut relativement intéressant. Surtout concernant la génération de document XML directement depuis des requêtes sql.
Dans ce dernier cas, si l'output n'est pas trop conséquent, cela peut vraiment présenter un avantage. Dans le cas contraire, la mémoire cache et Execution Plan Cache seront pénalisés afins de pouvoir générer le document.
L'intégration de XQuery permet de faire des requêtes vraiment puissantes mixant traitement XML (sur du contenu XML d'un champ) et datatype SQL. Cependant, cela nécessite un parsing des documents XML row par row... ce qui est vraiment très pénalisant pour un moteur de DB.
A noter que la mise en place d'index XML primaire et secondaire (FOR PATH) permettent de réduire le temps de processing XML de façon significatif (D'un coût de 266 à 0.1).
Finallement, d'un avis tout personnel, je ne suis pas certain qu'il soit intelligent de stocker du contenu XML dans une DB en vue d'un traitement quelconque (surtout s'il est récurrent).
L'intégration de contenu XML n'est pas en concordance avec l'aspect d'exploitation relationnel de l'information. Par ailleurs, durant le training, nous n'avons pas fait la référence à un cas existant (même sur demande).

Définition des indexes
Nous avons également eu l'occasion de nous consacrer sur la gestion, la création et le l'optimisation des indexes.

Clustered Index:

Index dont les data pages sont stockées dans l'ordre physique de l'index.
L'index cluster est basé sur un arbre B-Tree BALANCE (équilibré autour du noeud root), chaque noeud disposant de relations "sibling" en plus des relations ascendantes et descendantes.
L'introduction d'un nouvel enregistrement dans de tel index est couteux car il faut eventuellement insérer des pages dans l'arbre, modifier les relations entre les différents noeuds... mais surtout garder l'arbre balancé.
L'avantage de cet index, est que SQL server maintien des statistique permettant d'évaluer la pertinance d'une recherche dans l'arbre (au lieu de simplement envisager un table-scan).

Non Clustered Index:
Fonctionne de façon identique au clustered index (B-Tree) A LA DIFFERENCE que les pages sont soit:

1. Stockées dans la heap
2. Soit déjà stockée dans un clustered index.
   

Chaque noeud du "Non Clustered Index" fait une référence à la page de donnée à l'aide d'une clé.

Note 1: Dans la cas d'une table ne disposant pas d'un Clustered Index, les pages sont stockées dans la heap. Il n'y a donc pas d'emplacement prédefinit pour créer de nouvelles les pages de données. Dans ce cas, les insertions sont plus rapides car la nouvelle page de donnée peut être placée arbitrairement.

Note 2: Dans le cas d'une table disposant d'un Clustered Index, pour accéder à l'information depuis un Non Cluster Index, SQL serveur doit faire beaucoup d'opérations en lecture.
A savoir:

1. La lecture du Non Clustered Index pour récupérer 'identification des pages data (DataPageID)
2. Parcours de l'arbre B-Tree pour localiser les pages (DataPageIDs) de données dans le Clustered Index. (il faut garder à l'esprit que dans ce cas, le clustered index n'est trié dans le même ordre).
   

Conditions de selection d'un index

1. Pertinence de l'index.
   Un index est utilisé par SQL serveur s'il permet d'exclure 95% (au moins) des records de la table (lors d'une selection).
   Pour ce faire, SQL serveur consulte les statistiques d'index qui permettent d'évaluer la pertinance de l'index pour certaine valeur (Si la table contient 10.000 records et que la statistique mentionne un range de 2.500 records pour une selection particulière alors l'index sera rejeter... un table scan sera plus performant ).
   Il est également important de savoir que lors d'index sur plusieurs colonnes, seul les statistiques de la première colonne de l'indexe sont utilisées.
   Par conséquent, la sélection d'un index couvrant plusieurs colonnes ne se fait que sur base de la pertinance de la première colonne de celui-ci.
   
2. Couverture de l'index.
3. Ordre de tri.
4. Les hints inclus dans les requêtes SQL pour modifier le comportement du moteur DB.
   

Gestion des indexes

En SQL2005 Enterprise, il est possible de faire des mise-à-jours d'indexes à la'ide de l'option WITH (ONLINE=ON). Cela évite de locker la table durant toute l'opération permattant ainsi aux applications de poursuivre leurs traitement sans interruption. Cette opération consomme néanmoins beaucoup de temps et de ressources.
Il est a noter qu'en SQL2000, le création d'un index place un Lock exclusif sur la table. Il ne faut donc jamais créer d'index sur les DB de production durant les heures de bureau.


En SQL2005, il est possible:

1. De modifier (ALTER) ou de reconstuire (REBUILD) un index. Sous SQL2000, la seule option est de détruire et recréer l'index.
2. d'indiquer le nbre maximum de processeur affecté à la modification d'un index. WITH( MAXDOP=3)
3. Il est possible de definir une granularité de locking plus fine sur les indexes (ALLOW_ROW_LOCKS). Par default le moteur SQL utilise des locks au niveau de la table!!!. 
4. D'inclure des colonnes dans l'index sans que ces dernières n'interviennent dans l'index lui-même. Cette dernière optimisation permet de tirer parti des index sur colonnes multiples sans en avoir les inconvénients. En général, les colonnes additionnelles sont ajoutées pour retrouver rapidement des information pertinantes depuis l'index sans lecture de data pages complémentaire. Avant SQL2005, ces colonnes faisaient partie intégrante de l'index... par conséquent, toute modification des colonnes complémentaires réclamaient la mise-à-jour des liens internes et une opération de re-balancing... alors même que ces informations ne participent pas activement à l'index... c'était donc des indexes couteux.
   
   Avec les "Included Columns", la modification des données complémentaires  n'implique pas les opérations de mise à jours de liens internes et de re-balancing.
   
   Les indexes en SQL2005 sont à ce point plus efficaces qu'il est possible d'éliminer jusqu'à 60% des indexes nécessaires en SQL2000 tout en gardant les mêmes performances
   
   
5. De créer des "Partitionned index" fonctionnant de façon similaire aux tables partitionnées.
6. D'indexer le contenu de champs XML afin d'améliorer les performances et cout de recherche de façon spectaculaire.
7. De désactiver/réactiver des indexes lors de l'exécution de gros batch. Cela permet de gagner du temps machine considérable en évitant à SQL server de constamment mettre à jour l'index. Lors de la réactivation de l'index, ce dernier est reconstruit.
   

Optimisation des indexes

Database Engine Tuning Advisor:
Cet outil de Microsoft est maintenant bien peaufiner et est un incontournable pour l'optimisation des indexes.
Afin d'effectuer une évaluation des indexes, le Database Engine Tuning Advisor utilise une série de requêtes SQL sensées représenter les cas d'utilisations pratique de la base de données. Ces informations peuvent être fournie depuis un fichier SQL, XML ou une trace collectée à l'aide du profiler SQL.
Malheureusement, ce cas de figure peut difficilement s'appliquer aux DB de production.

Exploiter les statistiques des DB:
Pour les DB de production, il faut savoir que SQL Serveur maintien des vues dynamiques reprenant les statistiques d'usage des différents indexes (dm_db_index_usage_stats).
Par ailleurs, le processus de plannification d'execution tiens des statistiques utiles à propos des indexes idéals répondant à certaines requêtes (dm_db_missing_index_details). Cette vue est utilisée par SQL Serveur lui-même pour éviter certaines conception de plan d'exécution inutiles.
Ces informations peuvent être exploitées avec IndexTuning.sql faisant des jointures sur sys.Indexes pour obtenir de précieux conseils... même en production.
From the result of indexTuning.sql, high cumulated_cost_reduction must be addressed!

Fragmentation des indexes:
Il existe deux types de fragmentations.
La fragmentation interne est due à SQL server lui même et nous ne pouvons rien y faire. Elle a d'ailleurs peu d'influence.
Par contre, la Fragmentation externe correspond à la distribution des pages de données sur le disque (espaces disques alloués par le système d'exploitation).
L'identification de la fragmentation se fait à l'aide de Fragmentation.sql (fichier de démonstration du module 4).
Pour une fragmentation inférieure à 30%, un simple ALTER INDEX ... REORGANIZE est suffisant.
Par contre, pour une fragmentation supérieur à 30% un ALTER INDEX.... REBUILD est absolument nécessaire. Cette dernière opération (couteuse) demande au système d'exploitation d'allouer un espace continu.

SQL Server Training (Jour 1)

Petite semaine de cours intensif en SQL Server 2005 chez U2U.
Au programme, le cours "Implementing a Microsoft SQL Server 2005 Database".
Le cours est très interessant, même pour un développeur expérimenté.
Il y a déjà a tellement raconter que je ne prendrais pas le temps de me relire avant la publication (soyez donc indulgents).
Que retenir de cette première journée:

OLAP et OLTP
Les bases de données peuvent être exploitées pour des applications OLTP (Online Transaction Processing) ou OLAP (Online Analytic Processing).
En fonctionnement OLTP les operations sont optimisées pour le traitement sécurisé d'un grand nombre de transactions.
OLTP met en place les systèmes de locking utilisés de façon intensives afin d'assurer l'intégrité des transactions.
C'est typiquement le cas des systèmes marchands ou des données sont fréquements ajoutées et/ou modifiées.
Les opérations sur une base de données OLTP sont généralement très courtes mais nécessite une grande réactivité.

Par contre, il est également possible d'exploiter une base de donnée en OLAP (Online Analytic Processing).
Le but de ce mode d'exploitation des informations est de fournir des réponses rapidement.
OLAP est indiqué pour la génération de rapports ou de longues requêtes brassent beaucoup d'informations.

Une erreur commune est de faire du reporting sur des bases de données OLTP.
En effet, les rapports executent des query qui prennent beaucoup de temps tout en maintenant des locks en lectures très étendus.
Le reporting n'est donc pas une opération à prévoir sur des bases de données de production au risque de bloquer (ou ralentir significativement) le traitement des transactions.
Pour éviter ce problème, il faut considérer:

1. Le miroring / DBRestore sur serveur de reporting.
2. La réplication
3. Le database snapshot.
   

Database Snapshot
Le database snapshot est une operation (disponible uniquement sur l'édition enterprise) permettant de faire une copie quasi instantanée d'une DB (même pour une DB de 8 Go).
Ce processus est relativement léger car il ne copie pas "vraiment" la DB de production. Au contraire, lorsque la DB de production est mise-à-jour, seule les  pages modifiées sont copiées (avant modification) dans la DB Snapshot (Copy-On-Write).
Une base de donnée Snapshot est read-only et n'a donc pas besoin de gérer des locks. Les DB Snapshots sont donc des victimes idéales pour des processus de reporting.

Modèle de gestion du Log file
Le modèle "Simple" fait une troncation du Log File dès que possible (idéal pour les environnement de développements).
Le modèle "Full" enregistre de nombreuses informations de transactions dans le transaction Log. Cela permet en autre de garantir un rollback ou restauration de DB a presque n'importe quel point dans le temps.
Ce modèle représente un grand désavantage losrque de larges opérations bulk-insert (insertion de records en lot) ou d'effacement de records prennent places.
En effet, dans ce cas, le log file est littéralement congestionné et grandit rapidement.
Le nouveau model "Bulk-Logged" est un équivalent du mode "full" ou l'enregistrement des opérations dans le log sont sommaire lors d'operations bulk. Dans ce cas, il ne sera possible de restorer l'état de la DB que juste avant (ou juste après) de telles opérations.

Checksum et Torn Page Detection
SQL serveur ne fait pas confiance au disque dur lorsque les informations sont écrites. Les erreurs d'écritures ne sont généralement pas détectée durant cette opération. Le disque dur, peut même ne pas savoir que l'information écrite n'est pas correcte si l'information est corrompue en amont par le matériel.
Pour s'assurer de la fiabilité des informations, SQL server stocke un checksum pour chaque data page. Lors de la lecture le checksum est comparé à celui recalculé sur la page chargée, les données sont corrompues s'ils ne correspondent pas.

Lors d'une migration depuis SQL 7, il est important de savoir que la vérification par checksum n'est pas activée. L'ancienne méthode de vérification (TORN_PAGE_DETECTION) est toujours active même si elle est moins fiable.

Type de donnée
Voici quelques précision relatif au nouveaux types de données (et certains types déjà connus).
Table: Les tables (ou RowSet) sont aussi des types de données. Il est possible de faire des query sur le résultat d'un ou plusieurs autres query.
GUID: Le type GUID permet d'assigner une valeur GUID réputée unique (worldwide unique value).
La fonction sql newGuid() permet d'obtenir un nouvel GUID.
Ce qu'il y a de nouveau, c'est la fonction newSequentialGuid() qui permet de générer des GUID sequentielles... franchement utile lorsque des records doivent être ordonnés.
NVarchar: Utilise 2 bytes pour stocker la longueur de la chaine de caractère.
C'est donc une erreur d'écrire Varchar(1) pour espérer gagner de la place.
TimeStamp: Assigne une valeur unique (dans la DB) au champs lorsqu'un record est ajouté ou modifier. Ce type de donnée est utilisé pour s'assurer que le record n'a pas été modifié depuis la dernière lecture (Ado en fait un usage intensif).
Xml: Permet de stocker nativement du contenu XML. Ce type de donnée permet en autre d'exécuter des methods manipulant l'information. Il est également possible de transformer des données XML en rowset (et inversement).

Schema
Une modification très importante depuis SQL2000 sont les schémas. et représente un virement à 180 degré d'une fonctionalité/syntaxe déja existante (dbo.tablename).
Contrairement à ma première idée, les schémas en SQL2005 n'ont rien à avoir avec les schéma graphique de DB.
Les schemas permettent de regrouper les objects SQL (table, stored proc, etc) de façon logique. C'est un peu comme des groupes ou des domaines.
Les schemas sont définis à l'aide d'instruction appropriée et doivent être référencés dans les divers objects aussi bien lors d'operations de création que d'écritures.
Par exemple, dans le schéma "Person", il serait opportun de créer les tables contactInfo, Address, PersonInfo, Affiliation, etc.
L'identification correct de la table se fait en la préfixant avec le schema adéquat.
Par exemple:

  select * from Person.PersonInfo

Ce qu'il est important de savoir, c'est que l'utilisation les schémas sont obligatoires!!!

L'utilisation des schemas permet en autre de grandement faciliter la gestion de la sécurité... puisque les droits d'accès peuvent être liés au schémas.
Il est aussi utile de noter que chaque utilisateur SQL dispose d'une configuration "default schéma" qui sera automatiquement utilisé pour les requêtes SQL ne précisant pas de schéma.

Attention à la migration des bases de données:
Pour des raisons de compatibilités ascendante, le schéma "dbo" (db owner) existe en SQL 2005 et est maintenu.
Ce dernier, totalement obsolète, ne devrait pas être utilisé pour la création de nouvelles bases de données.
Cependant, le schéma "dbo" existe pour faciliter la migration de DB plus anciennes.
Ainsi, lors d'une migration, les tables sont migrées en utilisant le schéma "dbo".
Lors des requêtes SQL d'anciennes applications (select * from PersonInfo), SQL server essaye d'abord de résoudre le nom de la table dans le "default schema" configuré  pour l'utilisateur. Si ce dernier n'existe pas, alors une tentative est faite sur le schéma "dbo".
Pour les anciennes application n'utilisant pas les schémas dans la notation SQL, il est facile de constater qu'une surcharge de traitement est nécessaire pour obtenir les même données.
Note: En raison de l'utilisation de "dbo", Une assignation arbitraire du "default schema" de l'utilisateur SQL peut avoir des conséquences catastrophiques pour des applications migrées.

Partitioning large table
Lorsqu'une large table content des données devenues "read-only" par l'usage ou tellement vieilles, il convient de partitionner la table (et les indexs liés).
Cela permet à SQL server de focaliser l'activité et usage du cache sur la partition active de la table (nb: les indexes sont partitionnés avec la table).
Le but de la partition est de garder une partie active de taille raisonnable... et donc performante.
Les partitions plus anciennes totalement inactive en écriture peuvent être stockées sur des file group read-only (et peuvent par conséquent être stockés sur des disques compressés) limitant l'implication de locks.
Finalement, la partition à l'avantage de stopper le "lock escalation". Ainsi, la lecture de vieille données n'engendrera pas de read-lock sur la partition active.
Il va de soit que l'accès aux différentes partitions est totalement transparente.

File-Groups et Log File
Il est possible de créer differents File-Group pour y stocker une partie des tables (ou des indexes).
Les file-groups permettent de répartir les tables dans différents fichiers et sur différents disques. Cela permet d'optimiser les performances des tables les plus sollicitées en les placants sur des disques rapides (évitant ainsi de pénaliser les applications transactionelles).
Les file-groups peuvent également êtres marqués comme Read-Only. C'est d'ailleurs conseillé pour les tables (ou partitions de tables) n'étant plus modifiées. Cela permet à Sql Server de ne plus avoir à gérer les locks et permet à l'administrateur de placer le file-group sur un lecteur compressé (seul cas d'utilisation toléré).
Note 2: Le stockage de File-Group read-only sur des lecteurs compressés peut devenir interessant lorsque les parties "inactives" contiennent des millions de records.


Par ailleurs, il est conseilé de stocker le Log file sur un disque séparé (et rapide).
Cela limite la surcharge IO qui devrait être partagé entre le stockage des données et celui du Log File lorsqu'un seul disque est utilisé (Disk Head Overheat situation).

Performances

Pour préserver les performances:

1. Eviter l'usage de curseur si le code peut être écrit en SQL relationnel. L'exécution des curseurs est jusque 30 fois plus lent.
2. Eviter l'utilisation des tables temporaires là ou cela est possible. Les tables temporaires ne sont pas optimisée pour la performance et consomment de la mémoire.
3. Garder le "Page Hit Ratio" a l'oeil. Il indique le nombre de fois que SQL server va directement retrouver l'information nécessaire depuis sa mémoire cache. Si le hit ratio tombe en dessous de 95%, il faut agir.

Sync Framework

Sync Framework de Microsoft permet de développer plus facilement des fonctionnalités de synchronisation au sein d'applications.
Ce framework permet en autre de faire du caching pour les applications destinées à fonctionner tout aussi bien online qu'offline.
Sync Framework permet de transformer une application locale en application distribuée.
Pour plus d'information, voir les liens ci-dessous.

Liens utiles:

• Syn Framework sur le site de Microsoft.
  Cette page contient quelques vidéos intéressantes.
• SyncToy V2.0 est un outil Microsoft utilisant la technologie du Sync Framework.
  

XML Notepad

XML Notepad 2007
XML Notepad est un outil d'édition XML distribué gratuitement par Microsoft.
XML notepad est décrit sur cet article de MSDN.
Simple éditeur XML disponible ici.

Outils XML
Le site MSDN de Microsoft propose aussi d'autres outils ici.
On y trouvera par exemple:

• XML Diff
• XML Schema Definition Tool
• XSD Sample Code Generator (XSDObjectgen)
  

Mono 2.0

Voila que j'apprends que Mono 2.0 vient d'être délivré.
Parmis les plus grandes avancées de cette version, il y a:

• L'arrivée tant attendue d'un débugger.
• Le support de C#3.0 avec LINQ to Objects LINQ to XML.
• Un compilateur Visual Basic 8. 

L'éco-système Mono s'agrandit de plus en plus.
En plus d'être un moteur de script dans Second Life, Mono est également inclus dans des produits tel que des lecteurs MP3 (voir ici l'initiative de SanDisk), sur la console de jeu Nintendo Wii ou encore sur iPhone d'Apple.
Pour encore plus d'application, allez donc visiter cette page reprenant des capture d'écrans d'applications GTK#, WinForm, Asp.Net (et autre) fonctionnant sous Mono.

Moins tape à l'oeil que l'intégration d'un débuggeur, l'environnement Mono 2 débarque avec une série de caractéristique non négligeable. A savoir:

• Le support d'autres compilateurs:
  
  
  • IronPython de Microsoft.
  • Phalanger (PHP fonctionnant sous CLI)
  • IronRuby de Microsoft.
  • Eiffel ISE
  • Microsoft C#, F# et VB.NET
  • RemObject d'Oxygene (Pascal Objet pour .Net qui supporte les Generics, Class Contrcts, Queries, etc)
• Les API.Net
  
  
  • Support du Core 2.0, System.Core (v3.5)
    
  • System & System.Xml
  • System.Drawing
  • System.Web.Services & System.DirectoryServuces
  • Windows.Forms 2.0 (en utilisant des drivers W32, OSX, X11 unix).
  • ASP.NET 2.0 (Core, Ajax)
  • Intégration Apache et Fast CGI
  • Ado.Net 2.0 pour SQL server mais également pour d'autres base de données.
    

Enfin, pour les vraiment curieux, il y a des APIs et greffons spécifiques à Mono:

• Mono.Cairo une interface de programmation pour rendu graphique en 2D
• Mono.Cecil une interface de programmation permettant de charger et manipuler des assemblies binaires.
  Avec Mono.Cecil, il est possible de naviguer dans tous les types d'un assembly, de les modifiers instantanément et sauver l'assembly modifiée sur le disque.
  Mono.Cecil va beaucoup plus loin que  Reflection & Reflection.Emit, c'est grâce à Mono.Cecil que le débugger de MonoDevelop pu être développé.
• Xml.Relaxng
• Bit# une librairie client.server Bittorent.
• Mono.Fuse pour manipuler des systèmes de fichiers dans l'espace utilisateur.
• Tao Framework - OpenGL, OpenAL, SDL and Cg

Pour finir, voici quelques liens:

• Télécharger un Live CF de Mono 2 (disponible chez Novel).
• La release note the Mono 2.0 
  

Note 1: Concernant l'intégration de Mono dans l'iPhone et la Wii, cette intégration se fait via le moteur de jeu Unity 3D lui même basé sur Mono. Un petit coup d'oeil sur Unity 3D ne vous laissera pas de glace.
Note 2:  Cette nouvelle release de mono est également l'occasion de prendre connaissance de deux nouveaux environnements de développement .Net sous Unix. Même s'ils sont payant, c'est néanmoins intéressant. Mon article à ce sujet sera donc mis-à-jour.

Liens utiles pour Ubuntu

Voici quelques logiciels plus ou moins utiles pour Ubuntu.
Traitement audio

• xcfa: X Convert File Audio est un outil d'extraction audio (permet même d'extraire des pistes audio de DVD).
  Lien vers un article décrivant comment installer XCFA sur Ubuntu et un autre vers le site officiel.
  
• Shorten: Format de compression sans perte.
• Musepack: encodeur, ne peut différencier la copie du fichier original (échantillonnage entre 160 et 180 kb/s).

Plus d'info ici sur Linux on the root

Gestion système

• PartImage: Sauvegarde système avec PartImage (article).
• lfpt: Synchroniser facilement un répertoire local et un site ftp (ici)
  
  

Machines virtuelles

Une machine virtuelle est une machine abstraite simulée au sein d'une autre machine (l'hôte) bien réelle celle-là.
La machine virtuelle est utilisée comme environnement d'exécution pour un système d'exploitation quelconque (Windows XP, Vista, Linux, etc) ou pour un langage de haut niveau (Java).
Les machines virtuelles sont isolées les unes des autres mais également isolés de l'hôte.
Les systèmes d'exploitation fonctionnant sur des machines virtuelles croient se trouver sur des machines réelles avec un vrai disque dur, une vraie carte graphique, des vrais périphériques, etc.
C'est l'hôte qui émule tous ces périphériques à l'aide d'un logiciel adéquat (appelé logiciel de virtualisation).
Il faut savoir que rien ne distincte une machine virtuelle d'une machine réelle.
La machine virtuelle:

• Démarre comme une machine réelle avec les beeps, le boot, etc (sauf qu'elle démarre pour l'utilisateur depuis l'hôte).
• Doit avoir un système d'exploitation qu'il faut installer comme sur une machine normale (et pour lequel il faut évidemment posséder la licence pour l'installer).
• Peut accéder aux réseaux... et naviguer sur internet.
• Peut être infectée par des virus... comme n'importe quelle machine.
  
• Peut également crasher.
• Sont forcement plus lente que des machines réelle (même si les performances restent bonnes). 
  

Le tutoriel de 01Net explique quelques avantages et cas d'utilisations de machines virtuelles.

Virtual PC 2007
Pour des raisons de formations chez U2U, je dois installer Microsoft Virtual PC  2007 sur mon PC.
Virtual PC 2007 est l'alternative gratuite  de Microsoft permettant de faire fonctionner des machines virtuelles.

Voici quelques liens utiles concernant Virtual PC 2007:

• Téléchargement de Virtual PC 2007 via 01Net (+/- 30Mb).
  
• Tutoriel d'installation sur 01Net.
  Ce article contient également quelques conseils pour améliorer les performances de la machine viruelle.
  

Wmware
Quelques autres liens concernant Wmware, un autre outil de virtualisation gratuit avec lequel je suis beaucoup plus famillier.
A noter que Wmware fonctionne également sous Ubuntu.

• Wmware sur wikipedia (en français).
  Cet article énumère les differentes solutions Wmware.
  
• Le site officiel

Regular expression

Les expressions régulières sont des expressions avec une syntaxe particulière.
Cette dernière syntaxe permet de décrire des masques/modèles de correspondance.

Dans l'exemple suivant, je dois supprimer les caractères [ et ] pour obtenir un colonne de chiffre.
Ce qui n'est pas visible dans l'exemple, c'est que chaque ligne se termine avec un caractère d'espacement inhabituel (un non-breakable space ou encore nbsp).
Il est difficile de remplacer ce caractère dans un éditeur de texte standard avec un outil de remplacement.
En effet, ce caractère nbsp ne correspond pas à la barre d'espacement du clavier.

Planned
[27]
[460]
[27]
[2]
[9]
[13]
[22]
[4] 

....

C'est ici qu'intervient la regular expressions.
Avec l'expression \D, il est possible de matcher tous les caractères non numérique.
PSPad est un super éditeur de texte qui permet, en autre, le remplacement de texte sur base d'une regular expression.
Un simple remplacement de \D par rien à résolu mon problème.

Quelques citations informatiques

Informatique : alliance d'une science inexacte et d'une activité humaine faillible.
(Luc Fayard)

Ma préférée...

Ce qui fonctionnait hier ne fonctionnera peut être pas demain
(Anonyme)

Ne devient pas informaticien qui veut...

L'informatique semble encore chercher la recette miracle qui permettra aux gens d'écrire des programmes corrects sans avoir à réfléchir. Au lieu de cela, nous devons apprendre aux gens comment réfléchir.
(Anonyme)

Heureusement, nous ne sommes pas tous pareil...

Si on construissait les bâtiments de la façon dont les programmeurs écrivent leurs programmes, le premier pivert venu détruirait la civilisation.
(Loi de Weinberg)

 J'adore!

Un langage de programmation est une convention pour donner des ordres à un ordinateur. Ce n'est pas censé être obscur, bizarre et plein de pièges subtils. Ca, ce sont les caractéristiques de la magie.
(Dave Small)

Source: ici

Expressions anglaises

Faire une gaffe
To drop a brick.
Tu as fais une gaffe en parlant de Camille. 
You dropped a brick when you spoke about Camille

Tirer les vers du nez de qqn
To worm secrets out of s.o.
Il est difficile de lui tirer les vers du nez.
It is difficult to worm secrets out of him.

La goutte qui fait déborder le vase
The straw that breaks the camel's back.
Ce dernier affront est la goutte qui fait déborder le vase.
This last insult is the straw that breaks the camel's back.

C'est du chinois
It's double dutch.

Conjugaison anglaise - Présent

I work at CS
Indique une action habituelle. L'action est en cours et destinée à poursuivre indéfiniment.
La phrase indique que "Je travaille chez CS"... et que les autres jours, j'y serai aussi.

I'm working at CS
Indique que l'action est temporaire et s'achèvera dans un moment.
La phrase indique que "Je travaille chez CS"... mais il est sous entendu que ce n'est plus pour longtemps :-).
Il faut donc éviter de dire à sa petite amie "I'm loving you".

I have worked at CS since 2001
Indique que l'action est entamée dans le passé et continuera dans le futur.
Cette formulation insiste sur le fait et non sur la durée.
La phrase indique "Je travaille chez CS depuis 2001". 

I have been work at CS for 7 years
Indique que l'action est entamée dans le passé et continuera dans le futur.
Cette formulation insiste sur la durée.
La phrase indique "Je travaille chez CS depuis 7 ans".

Le premier téléphone équipé d'Android OS

Il y a plus d'un an, Google a démarré le projet Android.
Android est un système d'exploitation libre et open-source pour GSM.
Paris tenu, le premier téléphone équipé de la platforme Android viens d'être commercialisé outre-atlantique par T-Mobile USA.
Le T-Mobile G1 est un GSM fabriqué par la société HTC réputée pour ses smart-phone fonctionnant avec Windows Mobile.
Ce GSM inclus un écran tactile, un clavier rétractable, une puce graphique accélérée (3D), un support Wi-Fi et 3G, un GPS et un acceleromètre.
Bien que n'ayant pas un design aussi ravageur que l'iPhone d'Appel, le G1 permettra de faire fonctionner une tonne d'application intéressantes.
Le fait d'avoir un système d'exploitation Open-Source devrait encourager bon nombre de développeur à s'impliquer dans cette nouvelle platforme. A l'instar de l'iPhone d'Apple, il ne sera pas nécessaire d'avoir l'autorisation de Google pour pouvoir distribuer une application pour Android.

Voici une démo commerciale du T-Mobile G1.



Par contre, la vidéo ci-dessous est beaucoup plus intéressante.
Elle présente les ingénieurs de Google décrivant deux des fonctionalités qu'ils préfèrents dans Android.
Cette video est basée sur le G1 de T-Mobile donne une bonne idée des performances et fonctionnalités d'Android.


Source: Google Operating System blog.