Moteurs de recherche #duckduckgo et #blekko

Des alternatives à Google commencent à se mettre en place. Je ne parlerai pas de bing , mais de deux autres moteurs DuckDuckGo et blekko

DuckDuckGO.

(lien ici).

Il met l'accent sur le respect de l'anonymat et sur la fourniture d'astuce pour des recherches plus rapides et plus pertinentes.




La combinaison du caractère '!' suivi d'un mot clé permet de spécifier le domaine de recherche:
!ruby class pour lancer une recherche sur une déclinaison (class) du sujet principal ( ruby) .
Ce moteur est en Perl , hébergé par des serveurs NGINX et du cache avec memcached.


blekko.

Lien ici.

c'est un nouveau moteur de recherche où une authentification est nécessaire (invitation sur demande) . Il permet d'utiliser des '/' slashtag pour affiner les recherches.
Ex : echec /jeux remontera les liens relatifs au jeu d'échec.

Chaque utilisateur maintient ses /shashtag (un peu comme dans twitter)

Mais le point extrèment interressant est la transparence appliquée au moteur de classement. L'algorithme est en opensource et pour mot donné , il sera possible de comprendre le classement des liens.

#python , #ruby : c'est presque pareil

En relisant un tutorial python en francais , j'ai été frappé par la ressemblance entre Ruby et Python.


Exemple en Ruby

#!/usr/bin/ruby
def dupont 
 print "dupont\n"
end
def suite(v) 
 puts v 
end
def encore(param1,param2)
 puts param1,param2 

end
# appel de la fonction
dupont

En Python :

#!/usr/bin/python
def dupond() :
 print "dupond"
 
def suite(chaine) : 
  print chaine

def encore(param1,param2) : 
  print param1,param2 
  
# appel de la fonction
dupond()



L'obligation d'utiliser les parenthèses dans l'appel d'une methode ou fonction Python a des conséquences étonnantes.

En Python , comme en 'c' , il est possible d'assigner une variable à une fonction
ex   :  data= suite   # sans les parenthèses !

Et de demander data('exemple') pour appeler en coulisse la fonction suite avec le parametre 'exemple'.

La même chose en Ruby est plus compliquée à faire :

data= self.method(:suite)
data.call("coucou") 

Ces mécanismes ne doivent pas être confondus avec le currying qui est un  procédé qui permet de
transformer une fonction qui a plusieurs parametre en une fonction qui ne prend qu'un paramètre.

Exemple en Haskell :


module Main where
 prod x y = x * y
 double= prod 2
 triple = prod 3


Prelude> :load currying.hs
[1 of 1] Compiling Main             ( currying.hs, interpreted )
Ok, modules loaded: Main.
*Main> double(6)
12
*Main> triple(4)
12

La signature de la fonction prod reflète ce phénomène
*Main> :t prod
prod :: (Num a) => a -> a -> a

(prod 2)4
Un appel à prod  retourne une fonction lambda \y = 2 * y
Puis un deuxième appel finalise le calcul en remplacant y par 4 => 8

C'est un système extrêmement important en programmation fonctionnelle.

Sicile

Souvenirs de Sicile en 4 photos:


Le site:



Les granites:



Le volcan ETNA:



Un cube au soleil:

jeux pc :audiosurf et pacman

Pendant que les jeunes passent des heures sur le nouveau jeu à la mode : audiosurf . Les vieux comme moi préfèrent un bon vieux PacMan sur plateau.
source (fluctuat.net)

Dioparama (Lien ici).

Le jeu audiosurf vous propose une course d'obstacle sur vos musiques. Ici la bande son ne sert pas qu'à rythmer ou à souligner l'action, elle est l'élément principal du jeu. Ce petit jeu à deux balles ( 9,9 dollars) connait un succès énorme et rivalise avec les poids lourds des éditeurs.
(Lien du jeu ici.)

Modifications à chaud d'un serveur #NGINX

Il est possible d'agir à chaud sur un serveur NGINX :

Au niveau de la configuration

Il faut trouver le numéro de PID du process master de nginx. L'information se trouve soit en ouvrant le fichier PID du daemon

# pid of nginx master process
pid /var/run/nginx.pid;

Soit en lançant la commande ps combinée à la commande grep 'master'.

Puis envoyer au processus le signal HUP (kill -HUP num_de_pid )

Au niveau du binaire.

Il est aussi possible de recompiler nginx et de remplacer le binaire en cours d'exécution

Suivre les instructions suivantes:

1. Copier le nouvel exécutable nginx à la place de l'ancien
2. Trouver le numéro de PID (voir ci-dessus)
3. Envoyer un signal USR2 au processus
4. Envoyer un signal WINCH au processus
5. Vérifier l'arrêt des processus worker de l'ancien daemon
6. Envoyer un signal QUIT au processus.

Le service n'aura pas été interrompu

Deux signaux arrêtent le serveur : QUIT et TERM

QUIT arrête le serveur délicatement alors que TERM l'arrête brutalement

#Ruby , #Erlang , #Haskell et les autres

J'ai profité de mes vacances pour lire l'ouvrage suivant:



Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages. (Lien vers l'editeur ici).

Les langages présentés sont :

IO : (lien ici) io est un langage orienté objet inspiré par smaltalk. Son originalité réside dans l'utilisation comme dans javascript d'objets basés sur les prototypes plutôt que sur des classes.
Un objet io (ou javascript) est un simple tableau associatif. Une clé du tableau peut contenir une donnée , une fonction ou une référence vers une fonction d'un prototype. L'instanciation d'un objet se fait par clonage et non pas à partir d'un modèle (template) comme dans le cas des langages basés sur les classes.

Ruby (le top du top)

Prolog.

Scala : (lien ici ) scala est un langage développé par les ingénieurs de twitter basé sur la JVM. Il permet d'utiliser les librairies Java. L'intérêt de scala est de fournir une ouverture vers les langages fonctionnels avec en plus la possibilité de mettre en place des traitements parallèles (concurrents)

Erlang. (lien ici) c'est le langage qui à mon sens permet de débuter avec les langages fonctionnels.


Clojure. (lien ici ) Ce langage est une implémentation de Lisp destinée à utiliser une JVM. Il se présente comme une évolution possible de java.

Haskell. (lien ici) Haskell est le langage fonctionnel par excellence, qui est le fruit d'un travail collectif d'un groupe de chercheurs et non pas une construction d'une personne isolée. Un bon livre de référence est

La lecture de ce livre est difficile, aussi il est possible de lire cet ouvrage collectivement sur le forum suivant: (lien ici )
Une version gratuite et commentée du livre est disponible ici.




Pour chacun de ces langages, l'auteur propose des points à approfondir sur une semaine. Et il interroge les concepteurs de ces langages sur leurs motivations et les perspectives d'évolutions. C'est un très bon livre.

Pour ceux qui sont passionnés de langage et qui veulent se lancer dans l'écriture d'un nouveau langage : le livre à avoir est :(lien ici)
Create Your Own Programming Language de Marc-André Cournoyer

A system to achieve every programmer’s dream.
Learn how to create a simple programming language in a few days with this easy step-by-step guide.

Evaluation de charge : jouez au poker avec les points de fonction

( Stefen Hawking jouant au poker avec Einstein (Jim Norton) et Newton (John Neville). Extrait de la série "Star Trek, The Next Generation", au début de l'épisode "Descent", Part I. Documents Paramount Pictures, 1993.)


Question lancinante, récurrente , incontournable , posée aux développeurs, responsables de projet et autres: A combien de jour/homme estimez vous cette tâche ?.
Cette question universelle contient les deux incongruités qui pèseront lourdement sur la justesse de la réponse: jour/homme et tâche.

Le contexte.

Imaginons 3 chauffeurs engagés pour conduire un client de Paris à Marseille.

Concernant les Jours/hommes:

La question sur l'estimation serait traduite en :

Combien de temps il vous faut pour faire Paris Marseille . ?
Avec 3 chauffeurs , vous obtiendrez 3 réponses DIFFÉRENTES et elles seront toutes justes... (un chauffeur va rouler à 120 km/h , un autre s'arrête toute les heures etc.)

En revanche à la question suivante : Combien de kilomètre entre Paris et Marseille ? Les trois chauffeurs vont arriver à un chiffre proche.

Ainsi avec les jours/hommes on cumule deux approximations: La quantité de ce qui est à faire et la vitesse de réalisation.






Concernant l'unité utilisée.

L'unité jour/homme est elle même une aberration : qu'est ce qu'une journée idéale ?

Gardons en tête cet exemple plein de bon sens :

1 femme peut faire un enfant en 9 mois mais jamais 9 femmes feront un enfant en 1 mois.

Quand les chiffres annoncés sont du type 300 j/h pour réaliser une tache , j'ai toujours envie de dire : ok on va embaucher 300 personnes et le truc sera terminé après-demain.
Réponse immuable à cette remarque: Ce ne sont pas des mêmes j/h (Pourquoi les additionner alors ?)




Concernant les tâches
La commande passée au chauffeur serait:
a) Aller chercher la voiture au garage
b) Vérifier la pression des pneus
c) Faire le plein
d) rouler 700 km
etc..

Or quelle est la demande du client ? : se rendre de Paris à Marseille tout simplement . En se focalisant sur les tâches et non pas sur les fonctions (vision client) , notre pauvre client se retrouvera soit largué en pleine campagne bretonne soit coincé sur le périphérique.


Les points de fonctions et les méthodes agiles

Au commencement ..

Il existe d'autres unités de mesure des taches, comme les points de fonction utilisés par la méthode éponyme : (ici un très bon lien sur le sujet) . Ici, l'évaluation se place du coté de l'utilisateur. Peu importe si la fonction est réalisée par une usine à gaz (SOA, machine de Rude GOLBERG ) ou un progiciel.

Cette méthode du siècle dernier a été détournée et remise à la mode pour les besoins des méthodes agiles.

La métrique.
On utilise une suite numérique discontinue pour quantifier des charges.

On va s'attacher à évaluer des 'fonctions utilisateurs' et non pas des taches.

Un exemple de bonne suite est celle de Fibonacci :

0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55 ...

Étrangement: en demandant moins de précision, on va en obtenir plus.

• Paradoxe 1: La précision d'une évaluation est une fonction en forme de cloche. A partir d'un certain stade, plus on cherche à affiner les évaluations ( plus on passe de temps dessus) et moins on sera efficace dans les estimations.

• Paradoxe 2: Une personne isolée estimera mieux qu'un groupe.

• Paradoxe 3: Un expert relevant du domaine à estimer est le plus à même à faire une bonne estimation. Ainsi,il faut préférer les dires d'experts aux pseudo-méthodes d'évaluation basées sur le nombre d'écran, le nombre de contrôle etc. (§machine de Rude GOLBERG )

L'évaluation par le Poker:


Cette technique arrive à concilier toutes les contraintes de l'évaluation.
Chaque membre de l'équipe dispose d'une série de carte, chaque carte reprenant un nombre de la suite.

Le maitre du jeu détaille la fonction à évaluer (maximum 15 minutes) , puis chaque joueur compose son estimation avec ses cartes. Au signal tout le monde retourne ses cartes.

Une discussion s'engage sur les écarts des estimations (max 15 minutes)

Ainsi , on obtient une liste de fonctionnalité avec leur poids.

Voir le lien wikipedia planning poker.

Détermination de la vitesse de réalisation de l'équipe.

L'itération initiale va donner une première estimation de la vitesse de l'équipe. Plus on réalisera des itérations et plus cette vitesse sera affinée.

Ainsi dans des méthodes agiles, ce qui est important c'est la planification en elle même plus que le plan. La planification est réalisée a chaque itération et non pas de façon macro en début de projet.

Au départ, on peut dire que l'estimation par point est aussi imprécise qu'en jour homme. En revanche par le mécanisme des itérations courtes, l'estimation sera de plus proche de la réalité. L'estimation devient même marginale par rapport au projet. L'équipe ne s'engage que pour des courtes périodes.

Un client voulant aller de Paris à Pékin , se verra proposer avec les méthodes agiles une série d'étape l'amenant vers son point d'arrivée. A tout moment en fin d'étape, le client peut dire stop. Il ne sera pas obligé de rebrousser chemin.

En informatique , le client s'engage pour 1 mois , il pose sa mise sur la table. L'équipe informatique livre en fin d'itération un produit avec une fonctionnalité de base. Le client peut décider de continuer sur un autre cycle avec une nouvelle fonction ou simplement d'arrêter les frais.
Si au bout d'un mois le client n'est pas satisfait, il ne perdra que sa mise de départ, mais il aura une application minimale en état de marche..