Month: January 2008

PuTTY, SSH et autologin

Posted by admin – January 30, 2008

Lorsqu’on est amené à gérer une dizaine de serveurs sous Linux (Debian), cela devient vite rébarbatif de devoir inscrire son login et son mot de passe pour ouvrir une session SSH, d’autant plus qu’on devra également s’authentifier pour utiliser sudo si nous le devons, autant le faire une fois de moins.

Les outils dont on a besoin

  • PuTTY : client SSH sous Windows
  • PuTTYgen pour la génération du certificat (normalement livré avec l’installeur PuTTY)
  • Pageant , un agent d’authentification sous Windows qui utilisera le certificat – sauvegarder l’exécutable dans un répertoire PATH (d:\\temp par exemple)
  • ssh-keygen côté serveur du package openssh-client de Debian (apt-get install openssh-client)

Procédure d’activation de l’auto-login

Générer une clé publique et privée avec PuTTYgen en 3 étapes : Generate, bouger la souris pour générer une séquence aléatoire, puis mettre un mot de passe (Key passphrase) puis sauvegarder les 2 clés (mykey.pub et mykey.priv par exemple).

Copier le fichier mykey.priv.ppk dans le répertoire de Pageant (dans le PATH d’installation, d:\\temp dans notre cas).

PuTTYgen

PuTTYgen

PuTTYgen

La clé publique (fichier mykey.pub) servira au serveur SSH, la clé privée (fichier mykey.priv.ppk) à l’agent pageant.

Sur le serveur sur lequel vous vous connectez en SSH :

  • créer sur le répertoire de travail du compte SSH utilisé un répertoire .ssh (par exemple, je me connecte avec le compte od, alors il existe /home/od/.ssh)
  • télécharger le fichier de la clé publique (mykey.pub) dans le répertoire créé précédemment (~/.ssh).
  • exécuter :

$ ssh-keygen -i -f ~/.ssh/mykey.pub > ~/.ssh/mykey2.pub

$ cat mykey2.pub >> authorized_keys2

  • sous windows, créer un fichier agentautologin.cmd avec comme contenu:

“d:\\temp\\pageant.exe” “d:\\temp\\mykey.priv.ppk”

  • puis exécuter le, l’agent se met en tâche de fond (icône dans la barre de tâche windows) – vous devrez entrer le mot de passe fixé lors de la génération des clés.

  • sous PuTTY, créer et configurer le serveur sur lequel vous souhaitez accéder, ainsi que le login d’accès (od dans notre cas), le serveur SSH mappera automatiquement sur le login et déclenchera l’authentification et l’ouverture de session, ceci à l’aide des 2 clés publique (ssh) et privée (pageant)

PuTTY

PuTTY

Logon

Il reste plus qu’à vous logguer sur le serveur, il s’authentifiera automatiquement.

Connexion SSH

Un sudo -s pour effectuer vos opérations de maintenance, et c’est parti.

IIS, recyclage et pool d’applications en .NET

Posted by admin – January 21, 2008

Le problème

Depuis quelques temps, nous avions par intermittence des timeout sur les accès pages, toutes les 3-4 heures, nous recevions une multitude (quelques centaines, sic) de notifications1 d’erreurs. En gros, certaines pages principales plantaient, puis tout redevenait normal après quelques minutes.

Qu’est ce qu’un Pool ?

Sous IIS 6.0, le serveur Web permet de créer des pools d’application (un peu comme apache 2 par site Web [virtual hosts]), cela a l’avantage d’isoler les applications entre elles (1 process w3wp.exe par pool est lancé, 1 pool = n applications).

process IIS

On peut également utiliser la commande en ligne de commande iisapp pour opérer quelques actions sur les pools : listage des pools, recyclage. Une page TechNet sur l’administration en ligne de commande d’IIS.

Un pool (qui peut héberger plusieurs applications) permet les avantages suivants, et il est bon de s’y pencher :

  • si une application d’un pool plante alors les autres applications des autres pool sont préservés,
  • d’avoir la possibilité de redémarrer une application Web sans impacter les autres,
  • de définir un compte d’exécution spécifique pour les applications hébergés, en définissant un utilisateur avec des droits contrôlés,
  • tout plein d’options (onglet Performance et Health) pour la vie des applications : relancer le pool si les applications ne répondent pas ou prend trop de CPU, de mémoire…ces options sont assez fines et très utiles pour préserver les applications Web d’une application qui serait mal développée.

IIS Pools

Identité pool

Le diagnostique et sa résolution

Sur notre plateforme, nous avons défini un ensemble de pools d’applications, chacun couvrant soit une application Web, soit des services Web, soit des services transverses (annuaire, moteur de recherche, …).

Pour revenir à nos soucis de timeout, la configuration des pools faisait que ceux-là n’étaient pas recyclés (libération des ressources et relance) en même temps. Certains toutes les 3 heures, d’autres toutes les 24 h, etc…le recyclage peut mettre un certain temps, selon les caches qui sont chargés et autres opérations d’initialisation.

Aussi, si une application utilisait un service hébergé dans un pool qui était en train d’être recyclé (et de façon plus longue que prévue), l’application recevait un timeout, et le tout partait pour l’utilisateur en timeout, et donc un plantage sur la ou les pages demandées.

Nous avons donc décidé d’enlever le recyclage automatique des pools et de le remplacer par une planification de celui-ci à une heure fixe, le soir (hors des heures ouvrables). On contrôle ainsi chacun des pools, et le recyclage s’effectue en même temps, et ô miracle, les problèmes semblent jusqu’à présent être résolus, du moins le phénomène ne s’est pas reproduit, croisons les doigts.

recyclage pool

1 lorsqu’une erreur intervient (exception .NET), nous notifions par mail automatiquement l’équipe de cette dernière (utilisateur, navigateur, page, referer, message, et pile d’exécution), et affichons une belle page pour l’utilisateur au lieu de la page d’erreur par défaut d’ASP.NET. C’est une bonne pratique pour préserver l’utilisateur d’une ignoble technique, voir l’évènement Error de la Page, par exemple : this.Error += new EventHandler(Common.Error.WebErrorManager.Page_Error);, où Page_Error compile les informations techniques (page en erreur, id, message, …) pour les envoyer, et redirige l’utilisateur sur une page plus propre.

LightTPD, FastCGI, Rails, et accessoirement cache APC

Posted by admin – January 18, 2008

changement de serveur Web : Mongrel vers LightTPD

Peu convaincu à force par Mongrel (serveur Web pour rails), en raison de l’excès de mémoire consommée (leak ?) voire du CPU par moment, le blog a été transféré vers LightTPD + FastCGI + Rails (Typo) afin de tenter de diminuer la consommation des ressources (primordial sur un serveur avec 377 Mo !).

La configuration /etc/lighttpd/lighttpd.conf, extrait de la partie spécifique pour Rails (Typo) :

server.modules = (
            "mod_access",
            "mod_alias",
            "mod_accesslog",
            "mod_fastcgi" 
)

$HTTP["host"] == "192.168.1.150" {
 server.document-root = "/var/www/typo/public" 
 server.error-handler-404 = "/dispatch.fcgi" 
 server.indexfiles = ("dispatch.fcgi")
 accesslog.filename     = "/var/log/lighttpd/blog.access.log" 
 fastcgi.server = (".fcgi" =>
       ("localhost" =>
       ("socket" => "/var/www/typo/tmp/typo.socket",
        "min-procs" => 1,
        "max-procs" => 2,
        "bin-path" => "/var/www/typo/public/dispatch.fcgi",
        "bin-environment" => ("RAILS_ENV" => "production")
 )))
}

Le reste n’ayant pas été changé de la configuration par défaut. L’IP 192.168.1.150 a été mise au lieu du nom du site (blog.olivier-duval.info), car il existe un frontal Apache (voir l’architecture du zorky lan) pour le reverse proxy (qui redirige vers le blog, les photos, …selon le nom du site demandé), et celui-ci passe uniquement l’IP au serveur hébergé derrière.

cache APC

En plus de Google Analytics, le blog est marqué par Phpmyvisites qui se trouve sur un autre serveur virtuel, dédié au PHP. Sur ce dernier, un cache APC a été installé, cache qui permet d’accélérer les pages PHP, tout gain, même minime, reste appréciable. Un tutoriel pour l’installation (et compilation) d’APC.

quid LightTPD

L’efficacité maximum de LightTPD est obtenue sur les fichiers statiques : 17 000 req/s contre 7 000 req/s pour Apache 2, chiffres obtenus avec ab (ab -k -n 50 http://monsite/page.htm).

Egalement LightTPD s’avère efficace pour des applications Web PHP (en mode php-cgi) ou Perl, pour l’avoir mis en place et testé.

A voir à termes si ce changement de serveur Web sera profitable.

Debian, FreeTDS et SQL Server

Posted by admin – January 17, 2008

Contexte

Lorsqu’on travaille dans un environnement hétérogène composé de plateformes Windows et Linux, il peut s’avérer utile d’accéder à partir d’un serveur Unix à un serveur de base de données de type SQL Server (2000, 2005, …), j’aime l’interop…

Le développement de SQL Server est notamment né à l’origine de la collaboration entre Microsoft et Sybase. Le protocole de communication utilisé pour les échanges clients/serveur se nomme TDS, et sa version Opensource FreeTDS, avec une communauté toujours active.

Dans notre environnement, nous utilisons le serveur de listes SYMPA. Ce dernier permet de synchroniser les [emails des] membres des listes qu’il gère avec une base externe (synchro automatique toutes les n minutes, ou lors de l’envoi d’un message). Dans notre système d’information, celle-ci est une base SQL Server qui est utilisé par la plateforme d’applications mais aussi par le serveur de listes (en consultation ou en insertion).

Debian, installation

Sous Debian, le paquetage à installer est libct3 :

apt-get install libct3

Le paquetage installe le tout dans le répertoire /etc/freetds.

Configuration

Le fichier freetds.conf est une base de départ. Parmi les paramétrages intéressants, nous avons la section globale ([global]), où l’on peut varier la version du protocole à utiliser (selon le serveur SQL Server en face), fixer explicitement l’encodage à utiliser pour la communication client/serveur, ou créer des sections (de la forme [masection]) spécifiques à vos serveurs SGBD (IP d’accès, protocole, port, …).

Pour un dialogue avec un SQL Server 2000, en UTF, ci-après, un exemple de configuration freetds.conf :

$ less /etc/freetds.conf

[global]
        # TDS protocol version
        tds version = 8.0
        client charset = UTF-8
        # si besoin de traces
;       dump file = /var/log/freetds.log
;       debug level = 10

        # si besoin de gérer les timeout d'exécution des commandes SQL et du timeout de connexion
;       timeout = 10
;       connect timeout = 10

[monserveur-sql]
host = 10.75.40.31
port = 1433
tds version = 8.0

Dans le client (Perl, PHP, …) qui utilisera FreeTDS, celui-ci fera appelle au libellé du serveur défini dans freetds.conf, ici monserveur-sql, cela a l’avantage d’abstraire l’IP réelle.

Exemple de client en Perl

Le but de ce programme est de lire un mail stocké sur le disque, de le parser, et d’inscrire les divers éléments (entêtes, corps, …) qui le composent dans une table en base SQL Server.

 use DBI; use Encode; use lib '/home/sympa/bin'; use Log; # infos. sql # le nom du serveur du freetds.conf my $server = "monserveur-sql"; my $user = "loginsql"; my $pwd = "pwdsql"; my $bdd = "mabase"; sub encoding { my $body = shift; &Encode::encode_utf8($body); } sub msgtosql { my $file = $ENV{'PATHMSG'}; my $adrlist = $ENV{'LISTADDR'}; my $listname=''; my $domain=''; my $bodyencode=''; if ($adrlist =~ /^(.*)\\@(.*)$/) { $listname = $1; $domain = $2; } else { &do_log('err',"Match of list address '$adrlist' failed"); return undef; } # lecture du message (fichier texte) # et prise en compte des champs a inserer dans la base my $parser = new MIME::Parser; $parser -> output_to_core(1); my $msg = $parser -> parse_open("$file"); my $head = $msg -> head; my $body = $msg -> body_as_string; my $hdrall = $msg -> header_as_string; my $hdrdate = $head->get('Date'); my $hdrfrom = $head->get('From'); my $hdrsubject = $head->get('Subject'); my $hdrto = $head->get('To'); my $messageid = $head->get('Message-Id'); $bodyencode = $body; $dbh = DBI->connect("dbi:Sybase:$server","$user","$pwd") or die 'connect'; $dbh->do("use $bdd"); # insertion du message en base $SQL = sprintf "INSERT INTO msgs (body,creatstamp,hdrall,hdrdate,hdrfrom,hdrfromspc,hdrsubject,hdrto,list) VALUES (%s,getdate(),%s,%s,%s,%s,%s,%s,%s)", $dbh->quote($bodyencode),$dbh->quote($hdrall), $dbh->quote($hdrdate), $dbh->quote($hdrfrom), $dbh->quote($hdrfrom),$dbh->quote($hdrsubject),$dbh->quote($hdrto),$dbh->quote($listname); # on test l'insert, si catch alors on force l'encodage a utf-8 # l'erreur vient de freeTDS qui ne pt encoder (via iconv) directement en UTF-8, ne connaissant pas parfois l'encodage origine # pas d'encoding automatique car des msgs peuvent etre deja en utf-8 { # trap die pour logguer l'erreur SQL local $SIG{'__DIE__'} = sub { do_log('err',$_[0]); die $_[0]; }; eval { $dbh->do($SQL) || die "Error SQL $DBI::errstr"; }; if($@) { do_log('notice',"[catch sql] try to encode in utf-8..."); $bodyencode = &Encode::encode_utf8($body); $SQL = sprintf "INSERT INTO msgs (body,creatstamp,hdrall,hdrdate,hdrfrom,hdrfromspc,hdrsubject,hdrto,list) VALUES (%s,getdate(),%s,%s,%s,%s,%s,%s,%s)", $dbh->quote($bodyencode),$dbh->quote($hdrall), $dbh->quote($hdrdate), $dbh->quote($hdrfrom), $dbh->quote($hdrfrom),$dbh->quote($hdrsubject),$dbh->quote($hdrto),$dbh->quote($listname); unless($dbh->do($SQL)) { do_log('err',"Error $DBI::errstr for $SQL"); } } } $dbh->disconnect; return 1; } do_openlog("LOCAL2", "unix", 'archivetosql'); &msgtosql();

Au passage, un excellent site sur Perl, sur tous les sujets du langage.

Conclusion

Lorsque dans un système d’information, il cohabite un grand nombre de serveurs hétérogènes, le portage de protocoles peut-être un moyen de faire communiquer les systèmes. Une autre solution, de plus en plus répandue, est l’utilisation des services Web (SOAP, REST, …), dans une approche SOA.

Ressources

Quelques ressources sur le sujet.

Google analytics et RIA : application AIR pour accéder à vos statistiques Google analytics

Posted by admin – January 16, 2008

Vous aurez besoin de la version AIR Bêta 2, téléchargeable ici

Téléchargez ensuite Google Analytics AIR beta 2, installez le, configurez le tout avec votre compte GMail, sélectionnez vos sites et le tour est joué.

Une bien belle application prometteuse, la copie de Google Analytics, avec l’avantage de ne plus avoir besoin de vous connecter. Toujours en version Bêta, donc des bugs sont présents.

Vu sur le blog qui a toujours pleins d’astuces : Korben

SQL Log Rescue : analyser et annuler les opérations SQL de mise à jour (INSERT, …)

Posted by admin – January 15, 2008

Vous backupez les logs de transactions1 de SQL Server 2000/2005, alors SQL Log Rescue pourra vous être utile. Mon [talentueux] collègue a commencé à le tester en complément du SQL Profiler, afin d’analyser les requêtes SQL (INSERT,UPDATE,DELETE,DROP,TRUNCATE) qui s’étaient exécutées dans l’heure, tout ça pour trouver un éventuel lock un peu trop long. Pour l’instant c’est gratuit, alors il faut en profiter !

SQL Log Rescue vous permettra les opérations suivantes, soit sur les transactions en mémoire, soit sur les fichiers de transactions sauvegardés sur disque :

  • annuler uniquement les opérations que vous souhaitez : UPDATE, INSERT, DELETE, ce qui peut-être pratique.
  • afficher les transactions en filtrant sur le type d’opérations (UPDATE, …)

Red-Gate édite également l’excellent SQL Prompt, malheureusement devenu payant depuis la V3. J’utilise la V2 depuis quelques années, cela permet d’avoir l’intellisense dans le SQL Query Analyser, très pratique pour les SELECT, les WHERE et les jointures qu’il détermine automatiquement. Si vous souhaitez la V2, je pourrais vous la fournir, laisser un message sur zorky00 AT gmail.com.

1 il est conseillé, en plus des sauvegardes complètes de base, de sauvegarder par exemple toutes les heures les transactions, cela sera plus facile de remonter une sauvegarde le cas échéant (granularité plus faible).

Google Reader

Posted by admin – January 15, 2008

Je me mets à utiliser de plus en plus Google reader comme lecteur de RSS, pour remplacer à termes Netvibes. Ce dernier étant de plus en plus gourmand au fur et à mesure du nombre de flux qu’il aggrége.

Ce qui me plait sur Google Reader :

  • légèreté et l’expérience utilisateur, grâce notamment à l’usage bien pensé d’Ajax
  • l’option d’affichage “mis à jour” : n’affiche que les nouveaux éléments des flux

MAJ

  • avoir une liste de partage : si un article me plait, je le marque à partager, et je place un extrait de cette liste de partage sur le blog

Partage d’un billet

Liste de partage

  • proposition de flux selon vos intérêts, voir “Découvrir”

Proposition de flux

Le monde se googleise…futur maître du monde ?

Mise en ligne : méthode pour (semi-)industrialiser ses développements

Posted by admin – January 13, 2008

En fin de semaine dernière, ce fut la mise en ligne de la V8 de notre [superbe] plateforme d’applications. Nous éditons/développons sur cette dernière plusieurs applications Web en mode extranet pour quelques milliers d’utilisateurs.

Ce qui peut-être intéressant, c’est d’expliquer les différentes étapes du développement d’une nouvelle version d’un logiciel à son déploiement le jour J, pas LA méthode, mais au moins une qui est utilisée depuis quelques années et qui s’avère efficace.

En préambule, le délai entre 2 versions est dans la mesure court (2, max 3 mois) afin de réduire au maximum le taux de bugs1 et de faciliter la mise en ligne2. Egalement, un gestionnaire de sources (VSS, SVN) est hautement recommandé lors de développements en équipe. Idéalement, la plateforme de validation/recette est à l’identique de la plateforme d’exploitation : si cette dernière a 3 serveurs alors la validation en aura 3, etc.

Phases entre une version V, et une version V+1 :

développement de la V+1

Le développement des évolutions d’effectue sur la branche de développement (plateforme de développement). Cette branche est continue, et elle est juste flaggué ou libellée (étiquette sous VSS) à chaque nouvelle version. La dernière étiquette est par exemple v7.3 (version V). On peut ainsi retrouver les sources d’une version d’il y a 5 ans si on le souhaite.

Chaque chantier ou projet est bien évidemment mené en mode projet.

Chaque développeur qui est chargé d’un chantier doit remplir au moins 2 fichiers :

  • chaque modification de configuration est noté dans un fichier : ajout de clé, suppression, …
  • chaque modification du schéma de base est scripté (ALTER, CREATE, DELETE, …)

phase de validation, recette – tests

Cette phase permet de valider les nouveaux développements, d’un point de vue fonctionnel (est-ce le besoin attendu a bien été développé), et technique (en gros…les bugs).

Une fois la planification d’un mise en ligne (mise en exploitation de la version V+1), les développements sont arrêtés au moins 2 semaines avant : plus d’ajout de code n’est toléré, la correction de bugs (pannes franches, performances) est la seule possibilité.

La plateforme de validation-recette est préparée à l’identique de ce que sera l’exploitation V+1. Plusieurs itérations peuvent être nécessaires, cette validation sert non seulement à recetter les applications mais aussi la mise en ligne qui aura lieu le jour J :

  • on part d’une base de données à l’identique de l’exploitation (backup exploitation, restore sur validation), avec certaines données modifiées pour la validation (principalement les e-mails).
  • déroulement du script SQL sur cette base
  • déploiement des sources sur la plateforme de validation : utilisation d’un script avec des commandes XCOPY afin de recopier dans un répertoire de déploiement les application (web ou pas) à installer
  • modification des configurations par application

Une fois la plateforme en place, la recette peut commencer.

A chaque ensemble de dysfonctionnements, bugs corrigés, un nouveau déploiement des applications devra être effectué, et recetter ce qui a été corrigé. Cette phase de validation est itérative, jusqu’à ne plus trouver…de bugs, même si le 0 défaut reste utopique.

mise en ligne

Les applications sont recettées, prêtes à être déployées sur la plateforme d’exploitation. Le jour J à telle heure est le jour de la mise en ligne de la nouvelle version.

Avant le jour J, nous établissons une todo list qui énumère de façon la plus exhaustive possible toutes les opérations qui seront à effectuer sur chacun de serveurs pour la mise en ligne le jour J. Par exemple :

frontal :

  1. sauvegarde des configurations
  2. sauvegarde des répertoires sources des applications Web (typiquement c:\\inetpub\\wwwroot)
  3. pages de maintenance
  4. mise en place des applications : copie manuelle dans les répertoires idoines ou exécution des setup pour les applications packagées
  5. modification des configurations selon le fichier tenu lors des développements
  6. etc.

sql :

  1. backup des bases
  2. déroulement du script de modification de schéma de base
  3. copie des procédures stockées
  4. etc.

serveur y :

  1. tâche 1
  2. tâche 2
  3. etc.

Les tâches ne sont pas forcément linéaires, certaines seront effectuées en parallèle, certaines sont subordonnées à d’autres (page de maintenance avant les backups par exemple) : plusieurs membres de l’équipe participent au déploiement.

Cette todo list sert notamment à réduire au maximum la réflexion (ie : que dois-je faire précisément) durant la mise en exploitation, que celle-ci soit dirigée par des tâches à dérouler simplement. En effet, toute mise en ligne reste toujours stressant (je vous assure que d’arrêter une plateforme pour des milliers d’utilisateurs reste toujours impressionnant), donc elle doit être très préparée.

L’improvisation est anecdotique et doit être limitée. Cela évite d’entrer dans une routine qui conduit forcément à faire des erreurs : malgré des dizaines de mises en ligne, le stress est toujours présent et doit le rester pour garder toute vigilance lors d’une mise en ligne.

L’heure arrêtée pour la mise en production, nous déroulons les grandes phases pour une mise en ligne réussie.

  • upload des sources (script de déploiement xcopy + FTP) sur le serveur
  • page(s) de maintenance (‘le site XY est en cours de maintenance, veuillez nous excuser de la gêne occasionnée, bla bla’), un fichier App_offline.htm vous sera bien utile pour une plateforme .NET.
  • déroulement de la todo list (backup bases, sites, scripts, …).

Une fois toutes les opérations effectuées, nous pouvons remettre en ligne l’ensemble de la plateforme, et allumer un cierge ;)

Normalement, avec les itérations de recette sur la plateforme de validation (test applications, test mise en ligne), nous avons jamais eu à revenir en arrière. Les seuls dysfonctionnements sont souvent liés à des questions d’optimisations3 (services Web, ORM, moteur de recherche, …) qui se révèlent bien souvent qu’en exploitation (nombre de connexions plus élevées qu’en validation). Pour éviter cela, nous pourrions stresser la plateforme de validation, c’est à dire de simuler un grand nombre d’accès (avec ab) afin de relever les problèmes à ce stade le cas échéant.

La plateforme étant rouverte, nous effectuons des tests unitaires (manuels) sur les différentes applications, sur les grandes fonctionnalités, et sur les nouvelles. Certains batchs sont également lancés en mode simulation.

l’après mise en ligne

Nous laissons au moins 2 jours avant de flagguer, voir si nous avons des retours de dysfonctionnements de l’application (notifications des erreurs d’applications) ou directement par le support. Pendant cette durée, les développements restent figés (ie : personne n’écrit de code).

Une fois que nous estimons que la version est stable, ou du moins qu’il n’y a pas de pannes franches qui font tout planter, nous finalisons la version :

  1. libellé (flag) de la version courante sur le gestionnaire de sources (VSS) : on libelle la racine de la version mise en exploitation (v8 par exemple, branche d’exploitation) : cela a pour but de créer une branche à l’identique de l’exploitation : à ce stade, les développements peuvent reprendre sur la branche historique de développement.
  2. mise en place d’une station avec l’extraction (grâce au libellé précédent) des sources à l’identique de l’exploitation (branche exploitation), et de la solution Visual studio prête. Cette image de la plateforme d’exploitation (sources, bases de données) servira uniquement à la correction de bugs (fix), correctifs déployés sur l’exploitation. On y gagne en efficacité d’avoir une station dédiée à la correction. Les correctifs sont bien sûr répercutés sur la branche de développement.
  3. rapatriement d’une image de la base de données d’exploitation : servira à la station précédente.

conclusion

Comme on peut le voir, le développement logiciel est affaire de rigueur et de professionnalisme, peu de place ici à l’improvisation sauf cas d’urgence (correction d’un gros bug bloquant par exemple). Un seul objectif : descendre au maximum le risque de dysfonctionnements, et d’arrêt des services, pour la plus grande satisfaction des utilisateurs, enfin, nous l’espérons.

Et comme j’aime bien quantifié, depuis le dernier décompte du nombre de lignes de code, nous passons de 219 000 à 221 000, soit +2 000 lignes de code (C# + HTML (aspx) + JS). Cela reste négligeable en regard des nouvelles fonctionnalités apportées. Ceci peut s’expliquer par le refactoring automatiquement fait sur le code existant, en plus de développer de nouvelles fonctionnalités. Le refactoring consiste à revoir le code, en le factorisant, en fédérant toujours plus les services (approche SOA), et éviter ainsi la répétition de code (principe DRY).

1 très lié au nombre de nouvelles fonctionnalités (fonctionnelles, ou techniques)

2 du changement des schémas de base de données, à la modification des configurations, ou tout simplement au déploiement des applications.

3 ou plus récemment, d’un problème lié au composant RssToolkit et à sa méthode de cache qui semble poser problème en exploitation (vraisemblablement un effet de bord de l’anti-virus).

Debian publie un benchmark de plus de 30 langages : choisis ton camp !

Posted by admin – January 11, 2008

Debian diffuse un benchmark d’une trentaine de langages, sur un ensemble de tests (regex, récursion, fractal, …), avec comme critères d’évaluation le CPU et la mémoire utilisés. Le classement est déterminé par rapport au 1er, de combien de fois est moins performant le langage suivant.

Le vainqueur (CPU + mémoire) : Pascal Free Pascal, suivi de GCC (pas étonnant ;-) ). Les langages de plus haut niveau du type C# (mono) ou Java se classent respectivement à la 15è (x4.7) et 16è (x5.4) place. Enfin, ce n’est pas une surprise, les langages de scripting (ie : sans machine virtuelle), se classent en bas de tableau : Python : 23è (x9.7) et Perl (x9.8) : 24è, les spécialistes du Web : PHP : 29è (x17), Ruby1 : 31è (x19, sic)

Les résultats ont déjà changé depuis quelques jours, les tests ayant évolués (optimisation du code) selon les retours des développeurs spécialisés dans leur langage.

Les benchmarks sont toujours à prendre avec des pincettes, tout dépend des conditions des tests en toute indépendance bien entendu2. Personnellement, l’usage de tel ou tel langage est principalement guidé par le besoin et le contexte d’utilisation de ce dernier : travail en solo ou en équipe, « simple » application Web ou plateforme d’applications, projet éphémère ou pérenne, etc, etc. Il vaut toujours mieux un bon développeur PHP qu’un mauvais développeur Java par exemple, c’est l’ingénieur derrière son clavier qui fera que le langage sera bon ou pas. Facebook est en PHP, Youtube en Python, MySpace en .NET, Twitter en Ruby, etc (exemples de gros sites)

Un 1er tableau du classement (CPU et mémoire comme critères d’évaluation), ou un 2è tableau (CPU uniquement comme critère)

Ca va troller…;)

1 la version testée n’est pas la v1.9, cette dernière embarque maintenant une machine virtuelle (YARV), qui améliora sans doute nettement les performances de Ruby.

2 nombre de fois qu’une société commerciale a effectué des benchs très orientés en leur faveur…sans compter les guerres de clochers voire des idéologies où tout débat est dès lors biaisé, restons toujours méfiant

Google charts API

Posted by admin – January 5, 2008

Parmi toute la roadmap 2008, il faudra y ajouter Google maps qui donne pas mal d’idées, mais aussi Google charts API. Ce dernier permet de faire des graphes à l’aide d’une simple URL qui transporte toute l’information nécessaire à la création du graphique. Nous utilisons jusqu’à présent Dundas, Google charts pourrait être une alternative intéressante.

Quelques ressources :

Bons graphes…