• Langage fonctionnel.
• Tolérant à la panne.
• Supporte la mise à jour du code sans interruption du service.
• Open-source depuis 1998

Comme bien souvent le premier défi lorsque l’on veut commencer un nouveau langage c’est installer l’environnement de développement. Cet article a pour but de documenter l’ensemble des opérations nécessaires pour installer un environnement Erlang fonctionnel sous Mac OS X 10.5.6

Pré-requis

Afin de pouvoir lancer son premier programme Erlang et avant même d’installer le compilateur, l’environnement Erlang doit disposer de la librairie GD. Cette librairie a les dépendances suivantes :

• zlib
• libpng
• libjpeg
• FreeType

Heureusement un tutorial explique pas-à-pas la procédure pour installer GD.

Installation d’Erlang

Se rendre sur le site offciel et une fois le long téléchargement des sources terminé,  soit 1h30 pour 45 Mo. Suivre simplement les instructions de Tim Dysinger. On peut aussi installer Erlang depuis une version binaire MacPorts, DarwinPorts. Finalement, la Comprehensive Erlang Archive Network offre des versions binairess et une foule de documentations, un forum et une liste de packages disponibles.

Intégration dans XCode 3.1.1

XCode ne supporte par Erlang de base. Grâce au travail de Jon Gretar Borgthorsson on peut désormais écrire du code et le compiler directement dans XCode. L’article original vient de son blog, puis on aboutit à un googlecode et finalement sur github. Après avoir chercher pendant un moment à compiler l’ensemble du projet, la marche à suivre pour installer l’outil est la suivante :

1. Fermer XCode
2. Télécharger la version déjà compilée car celle du trunk ne semble pas fonctionnée.
3. Décompressez l’archive.
4. Déployer l’ensemble des dossiers dans /Developer/Library/Xcode/.
5. Rédemarrer XCode.

Et maintenant ?

Une fois l’ensemble installé, il est bon de commencer par la base soit la documentation officielle, notamment la section « Getting Started ». Pour ma part, j’ai commencé le livre de Joe Armstong, Programming Erlang (Merci Greg) et pour l’instant il semble parfait. La suite dans un prochain article.

La solution de facilité

Si on tente d’ajouter un W890i à iSync, l’appareil est bien reconnue mais on ne pas l’ajouter. Suite à diverses tentatives et recherches une solution se profile. Feisar.com qui fait autorité dans ce domaine propose un plug-in pour la modique somme de 3 USD. L’achetez serait la solution facile et certainement efficace.

La solution fait maison

Cependant, pourquoi ne pas essayer de le faire soi-même ? gratuitement ? Afin de débuter sur une base cohérente, il s’agissait de trouver un téléphone existant proche du W890 qui se synchronise avec iSync. Quelques recherches ont aboutit à cet article. L’auteur y explique comment installer un plug-in fait maison. Une fois ce plug-in télécharger on note qu’il ne s’agit que d’un « paquet » pour Mac OS X. En regarant à l’intérieur de celui ci (bouton de droite → afficher le contenu du paquet), l’architecture semble relativement simple et composé uniquement de fichier XML décrivant quelques paramètres. Ces fichiers de configurations s’ouvre par défaut avec l’utilitaire d’Apple, mais on peut aussi les ouvrir avec un éditeur de texte classique.

Le hack pour transformer le plug-in du W880 en celui du W890 est très simple. Chercher toutes les occurences de « W880″ et les remplacer par « W890″. Ensuite, reconstruire le « paquet », le déployer dans le bon répertoire (comme expliqué dans l’article cité précédemment) et voilà !

Ensuite lors du prochain lancement de iSync la recherche aboutira à la découverte d’un W890 qui cette fois sera supporté et fonctionnel.

Pour les plus paresseux

Le résultat de cette manipulation est disponible ici. Si vous le téléchargez merci de me laisser un commentaire ça fait toujours plaisir…et pour les moins fainénants, happy hacking…

Quelques solutions

Branché sur un réseau LAN avec un sniffeur tel que Wireshark on verra passer en clair tous les e-mails. On pourra aisément en extraire le contenu et exploité les informations. Comment se protéger contre ce problème ? en cryptant le contenu des messages. Pour ce faire plusieurs techniques existent notamment :

• S/MIME : Développé par RSA Data Security, basée sur l’échange de certificats approuvées par une instance supérieure. Cette alternative est payante et centralisée. Cependant depuis quelques années Thwate délivre des certificats gratuits.
• TLS : Il se place sur le protocole utilisé, dans le cas de l’email il se placera au-dessus de SMTP. Il utilise un système de certificats. il est très répandu et permet de sécuriser l’ensemble des transactions qui se passe sur un même protocole. On le retrouve souvanet couplé à http qui devient alors le fameux https.
• PGP : Logiciel de cryptage hybride (symétrique et asymétrique) commericale. Très fiable, de qualité militaire selon son développeur charismatique Phil Zimermann.

Bien que reconnues ces techniques exploitent en partie ou totalement du logiciel propriétaire. C’est pourquoi cette article traite de GnuPG, une alternative open-source de PGP.

GnuPG

GnuPG est disponible sur toutes les plate-formes courantes notamment Free/Open/Net BSD, Mac OS X, Windows et quasiment toutes les architectures de Linux. L’installation consiste tout d’abord à la mise en place des source pour al compilation de la libraire GPG, ensuite vient quelques outils parfois graphiques comme le portes-clés qui permet de stocker les clés publiques échangées avec vos correspondants. Souvent un plug-in permet une intégration en douceur avec votre mailer favori (Thunderbird, Outlook, Mail, Eudora, etc.).

GnuPG sous Mac OS X 10.5.5

Ayant rencontré quelques difficultés pour installer GnuPG sous Mac OS X 10.5.5, il me semble utile de décrire ici la procédure suivie. Une version modifiée de GnuPG est disponible pour Mac. Elle offre une jolie intégration dans l’OS de base et permet de rendre le programme accessible aux allergiques à la ligne de commande.

Le tutorial de gbronner, n’est pas mis à jour depuis août 2006, mais il constitue une bonne base. Comme décrit dans ce document, télécharger et installer GNU Privacy Guard, PGP Keychain Access et GPGMail. L’ensemble de la procédure reste d’actualité, mais tout se corse avec l’installation de GPGMail. Ce dernier n’est pas disponible en version officelle pour la version 10.5.5 de Mac OS X. En date du 25 mai 08 est sortit la version beta annoncée sur le site du développeur principal.

Dans la l’installation décrite sur sente.ch, il faut procéder à la copie du fichier dans /Library/Mail/Bundles puis lancer deux commandes, attention la seconde commande doit être modifiée. La première permet d’enclencher la partie plug-in de Mail : defaults write com.apple.mail EnableBundles -bool true. La seconde permet de définir le mode de compatibilité :
defaults write com.apple.mail BundleCompatibilityVersion 3. Sans vraiment savoir ce que cela signifie, ce réglage permet d’afficher le plug-in dans mail et évite les message d’erreur et la désactivation du plug-in au démarrage.

Grâce cette armada de logiciel, vous pourrez donc communiquer de manière sûre et fiable avec l’ensemble de vos correspondant qui utilise la même technologie. Reste encore à convaincre certains de vos correspondants de l’utiliser…

Pas encore de standards

Plusieurs races de Widgets cohabitent. Sur PC, Konfabulator racheté par Yahoo avait sa place, il existe toujours bien que moins intéressant depuis la création de système de Widgets natifs, propre à l’OS. Vista à son propre type de Widget, les Gadgets. Quant à son concurrent direct, Mac OS X, cela fait bien longtemps (Mac OS X 10.4) qu’il intègre le fameux Dashboard qui permet par pression d’une touche d’afficher l’ensemble des « mini applications » déployées sur le système. Sous Linux, on notera que l’environnement graphique KDE offre lui aussi des Widgets appelé Plasmoid. La création d’un standard dans ce domaine ouvrirait de nouvelles ports au développeur du monde entier.

Les essentiels pour Mac OS X

Comme expliqué plus haut, certaines sont inutiles, notamment celle de Google, qui permet de faire une recherche. A l’heure de Firefox, tous les navigateurs web ont une barre de recherche intégrée.

Voici une sélection des Widgets que j’imagine comme les plus utiles, libre à vous d’en proposer d’autres :

• Delivery Status
  Monitore le status d’une livraison d’une commande que vous avez passé. Cela marche avec plus de 20 services, notamment UPS, Apple ou Amazon. Le tout dans un design sympa et efficace.
• Orange SMS
  Envoyé des SMS depuis un Mac. Disponible aussi pour les contrats GSM M-Budget. Fonctionne uniquement en Suisse.
• Google Analytics
  Les statistiques de Goolge Analytics directement dans accessible. Parfait pour les webmaster soucieux de leur popularité.
• EBay
  Ne jamais loupé une action sur EBay et effectuer directement des recherches.
• Azureus
  A distance ajouter des torrents et vérifier l’état de vos téléchargements.

Widgets, D-I-Y

Pour les développeurs sous Mac OS X, une lecture de cet article permettra de démarrer facilement le développement de de Widgets via le fameux XCode. On retrouvera le squelette d’un Widget, qui n’est autre qu’une portion de HTML. Sous Windows, cela semble un peu plus compliqué, mais un bon point de départ serait cette page consacrée au développement de Gadgets par Microsoft. Sous Linux, une documentation complète sur le site des développeurs KDE semble être une bonne base. Finalement, un forum semble avoir étudié de fond en comble le phénomène Widget bien que l’information date un peu.

• L’équipe de développement maîtrise déjà tel ou tel langage.
• L’entreprise est sous contrat avec un éditeur de logiciels.
• Le projet doit s’intégrer avec un système d’exploitation ou un logiciel existant.
• Le personnel de maintenance n’est pas capable de supporter un nouvel environnement d’éxécution lors de la mise en production finale.

Idéalement il faut prendre cette décision sur des critères plus technique tel que :

• Temps d’exécution. Le logiciel final sera ainsi plus efficace. Moins de temps CPU siginifie que sur la même machine d’autre programmes peuvent être exécuter en parallèle.
• Le framework de base du langage. Un framework complet et testé évite le développement de fonctionnalités de base, diminuant ainsi les sources d’erreurs et le paradoxe de la « ré-invention de la roue ».
• La taille mémoire utilisée lors de l’exécution. Même sur les machines actuelles un programme prenant une plus petite taille mémoire permet de rentabiliser la plate-forme. Sur un même serveur on pourra faire tourner d’autres applications.

A la lecture de ses quelques points, il semble évident que le choix d’un langage ne peut se faire sans démarches préalables.

Des outils pour faire le bon choix

Le projet shootout hébergé dans l’environnement Alioth supporté par la communauté Debian tente d’amener quelques outils afin de prendre cette décision. Le but est simple : plutôt que de comparer des langages sur des critères politiques, commerciaux ou complètement ésotériques pourquoi ne pas les comparer en fonctionnement ?

L’idée est de comparer chaque langages dans des implémentations d’algorithmes fondamentaux. Parmi les algorithmes choisi on notera quelques classiques tel que :

• Le fractal de Mandelbrot.
• La manipulation d’arbres binaires.
• La lecture d’un ADN et le calcul de son complément inverse.

Faire partie de la compétition

Les résultats de ce projet sont rassemblés dans une interface claire, graphique à l’appui. De plus, si le code proposé pour un des algorithmes dans un langage que vous maîtrisez ne vous plaît pas, postez votre version. Cette compétition inter-language permet de mettre en évidence les défauts et les qualités et surtout de provoquer de longues réflexions…

Le cas Microsoft

L’exemple le plus connu est le projet Windows qui a porté plusieurs noms selon la version, en voici quelques un :

• Janus pour la version 3.1.
• Chicago pour le fameux Windows 95.
• Longhorn pour Vista.

Chez Microsoft, même les services packs ont des noms de codes. Trainyard pour le SP1 de XP ou Springboard pour le SP2. Il est vrai qu’un service pack et parfois un tel saut technologique qu’il peut être un projet à part entière.

Du côté de chez Debian

Dans le monde du libre, la communauté Debian s’illustre par une thématique sympathique et une rigueur sans possible comparaison avec le monde Microsoft. La version 1.1 de Debian s’appelait buzz, puis est venu rex, bo hamm, slink, potato, woody, sarge, et dernièrement etch pour la version 4.0. Quel est le point commun de tous ses noms ? Il s’agit de personnages de Toy Story ! Cette réflexion a été documentée dans la FAQ du projet Debian.

Si des noms comme Buzz ou Woody paraissent évidents, seuls les fans se rappellent que le tyrannosaure s’appelle Rex que Bo est la bergère amoureuse de Woody, Hamm est le cochon fan de jeux vidéos, Slinky le chien à ressort, Potato, Monsieur Patate, Sarge est le sergent des soldats en plastique et que finalement Etch est le nom d’un jeu de dessins illustré ci-dessous.

Amusant, le projet Debian a gardé deux noms pour la version de tests qui s’appelle lenny, comme les lunettes d’approches sur pattes du film et sid pour la version unstable de Debian. Sid, c’est le garçon qui massacrent les jouets voisin de Buzz et de ses amis. Plein de symboles…

Engouement populaire

A l’image d’un quotidien romand orange le produit serait phénoménal, mais les faits sont là : jamais un téléphone portable n’avait autant de bruit avant sa sortie. On en parle dans tous les médias populaires, et la plupart en disent le plus grand bien. Au delà de ce point de vue, il y a quelques considérations techniques à prendre en compte.

Un SDK payant et un contrôle total potentiel

Afin de permettre aux utilisateurs de son produit d’étendre les fonctionnalités de leur téléphone Apple à sortit kit de développement (SDK) payant. Cela permet aux développeurs du monde entier de se mettre à coder de nouvelles applications pour l’iPhone. Ceci dans le but de trouver de nouvelles utilisations du téléphone avec notamment une intégration avec les services web les plus populaires. Pourtant, il en existait déjà un, illégal celui-ci ou plutôt non contrôlé par Apple. Désormais tout développeurs désirant mettre à disposition son application au monde entier devront utiliser l’App Store sortent de iTunes Music Store des applications iPhone. La question qui faut se poser, est-ce que Apple va inspecter les applications mise en ligne ? Prendre des idées pour les intégrer dans la prochaine release du firmware officiel de l’iPhone ?

Google toujours présent

Dans tous les cas, Apple devra contrer un adversaire de choix tout bientôt, Google Android. Sur cette plate-forme logicielle, le SDK est gratuit et le système sera indépendant du matériel. A la vue des membres du consortium le projet semblable partit sur de solides bases. HTC a déjà annoncé un téléphone tournant sous Android avant la fin de l’année. L’engouement populaire risque d’être moindre que pour le téléphone de la firme de Cupertino mais techniquement cela vaudra certainement le détour.

Open-source rulez !

Reste pour ceux qui sont dans l’open-source jusqu’au bout des ongles essayez l’alternative OpenMoko. Le dernier né de ce projet est le nouveau Neo Free Runner. Il a tout pour réussir : connexions sans-fil, GPS, Micro-SD et bien sûr il tourne sur OpenMoko, l’OS libre et ouvert. Comme c’est des puristes, ils sont allés jusqu’à livrer une version du téléphone avec plan complet, kit de démontage et carte externe pour le développement.

Conclusion, les alternatives à l’iPhone existent déjà à l’image du N95 de Nokia, dans le futur il faudra compter avec des systèmes plus ouverts que celui d’Apple. L’expérience des systèmes ouverts à montrés que si les projets sont bien gérés et encadrés, ils peuvent dépasser en terme de qualité les produits fermés.

Si vous voulez écouter de la musique au bureau ou lors d’une fête chez des amis vous avez le choix de vous balader avec un ordinateur portable, un disque dur externe ou encore de brancher un lecteur MP3 sur une chaîne Hi-Fi. A plus petite échelle on peut rencontrer le même problème à la maison. Comment écouter au salon les fichiers musicaux stockés sur le portable de madame ?

Cet article a pour but de démontrer quelques moyens simples et gratuits pour mettre en place une diffusion de fichiers musicaux à travers d’un réseau LAN ou WAN.

La manière iTunes

Disponible sur Mac comme sur Windows, le fameux iTunes de Apple permet de partager sa musique sur un réseau local. Pour ce faire il utilise le port 3689 en TCP et le protocole DAAP. Cependant ce partage se limite au sous-réseau local. Comment faire pour contourner cette limitation ?

Le serveur DAAP

Comme expliqué plus haut, iTunes utilise un service sur le port 3689. Il s’agit de DAAP, Digital Audio Access Protocol. Il existe plusieurs logiciels permettant de réaliser à moindre frais un serveur DAAP. Ce protocole bien que propriétaire et mis au point par Apple connaît plusieurs implémentations gratuites et open-source :

• FireFly media server pour les systèmes Linux et Mac OS X. Plutôt compliquer à installer, il faut quelques connaissances avant de pouvoir en profiter.
• Basé sur FireFly, Roku a recompilé FireFly media server et propose des jolis exécutables tout prêt à installer pour Windows et Mac OS X.
• Pour les puristes, mt-daapd qui est à la base du projet FireFly media server est disponible sous la forme d’un paquet pour Debian.

Une fois installé, il faut encore scanner son répertoires de fichiers musicaux. Ensuite, en démarrant n’importe quel client DAAP (iTunes pour Mac et Windows ou Rhythmbox sous Linux/Gnome) lié par le réseau au serveur on peut écouter la musique stocker à distance.

Le pourquoi d’un serveur

La limitation au réseau local reste vrai même lorsqu’on utilise un serveur tel que FireFly media server. L’avantage sur un simple partage via iTunes c’est le transcodage. C’est-à-dire que le serveur permet de transcoder le morceau joué afin de s’adapter à la bande passante disponible. D’où l’idée de l’utiliser à distance.

Le partage sur un réseau distant

Pour que iTunes ou Rhythmbox affiche la musique partagée malgrès l’accès distant, il faut simuler le lien dans un réseau local. C’est à dire que le port 3689 en réseau local sera redirigé vers le port 3689 du serveur distant. Pour effectuer cette opération il existe deux applications :

• Network Beacon de Chatic Software uniquement pour Mac OS X.
• Rendez-vous Proxy pour Windows, Mac OS X et Java en général.

Bien sûr avant que cela fonctionne parfaitement, il faudra avoir ouvert le port 3689 des différents firewall et éventuellement mettre en place une redirection de port afin que le service aboutisse à la machine cliente.