lundi 30 juillet 2012

C'est quoi un bon langage géneraliste ?

Suite à mon billet précédent, je me suis posé la question suivante : c'est quoi un bon langage de programmation ?

Pour moi, c'est clairement un langage qui me permet de faire un logiciel qui fait ce que je veux sans trop me fouler et même (si possible) en me faisant plaisir. Donc, si je trouve un langage qui fait ça, il est bien, il me va.

Sauf que tout le monde ne cherche pas à faire les mêmes logiciels, et surtout pas des logiciels qui font la même chose. Par exemple, moi, j'ai surtout besoin d'une bonne API réseau et, tant qu'à faire, une bonne API pour le système de fichiers. Mes logiciels n'ont pas forcément besoin d'une GUI, même si des fois ça aide...

Or donc, je me disais que pour évaluer un langage afin de voir si c'est un bon langage "généraliste", ça pourrait être intéressant de sélectionner quelques applications et de voir comment ces applis sont codées avec le langage à évaluer. Je me disais pas exemple qu'on pourrait se baser sur un client IRC, un serveur HTTP, un éditeur de fichier ? Mais là encore, on se rend bien compte que cette sélection est basée sur mes préoccupation...

Or donc, je m'en remets à vous, lecteurs programmeurs : qu'est-ce qui, pour vous, serait une bonne application pour juger de la généralité/versatilité d'un langage ?

Node.js réussira-t-il là où tant d'autres langages de script ont échoués ?

Les gens, je crois que je suis en train de tomber amoureux...

Vous le savez (ou pas), depuis des années, de nombreuses années, je suis à la recherche du langage de script idéal. Vous savez, ce langage à la fois générique, propre, élégant, multiplateformes, avec des bonnes bibliothèques, rapide (surtout, pas méga-lent), et qui permet de serrer...

Le choix d'un langage, c'est un peu comme l'entrée en religion. Chacun à son préféré, et les autres sont forcément plus moches. Hors Le Langage, point de salut...

J'ai essayé beaucoup de langages de script. Perl, tout d'abord. Désolé, mais je trouve la syntaxe vilaine. En plus, la philosophie de "TIMTOWTDI" (There Is More Than One Way To Do It) ne me plait pas du tout, et ce pour deux raisons. Primo, je pense qu'il y a en gros une seule manière de faire les choses, la bonne. Si un langage est bien gaulé, un programmeur même novice qui a compris l'esprit du langage a une bonne intuition de la bonne approche à suivre et ce quel que soit l'objectif. Secundo, "TIMTOWTDI", ça rend beaucoup plus difficile le fait de coder à plusieurs et surtout de maintenir un code commun. Donc, perl, non...

J'ai aussi essayé ruby... Alors ruby, c'est chouette, c'est joli, c'est élégant (quand c'est bien fait). J'ai été très amoureux de ruby. Et puis, après quelques temps, je me suis rendu compte qu'en pratique, ruby est souvent très lent. Ce que j'ai trouvé récemment plus gênant, c'est une tendance à partir un peu dans tous les sens, à la perl... Finalement, beaucoup de syntactic sugar était certes très joli, mais assez peu utile. Le coup des 5.times { ... } par exemple... Très joli, mais finalement, quel intérêt la plupart du temps ? Et puis quelle différence avec le for i in 1..5 ? Ce qui m'a le plus troublé, c'est le jour où j'ai appris que certaines méthodes à la syntaxe différente mais qui étaient censées faire la même chose (je pense concaténation là) le faisait de manière en fait si différentes que la variation de temps d’exécution pouvait aller de 1 à 10 entre deux méthodes...

Alors, évidemment, il y a python. Python, c'est nice, communauté hyper-active (et comptant certains hyperactifs aussi, d'ailleurs, salut les gens ;-) ), des bibliothèques pour tout, une approche assez rationnelle et globalement assez cohérente... Python avait tout pour me plaire. Sauf que j'aime pas la syntaxe. Les indentations, je les mets de moi même, j'essaye de faire du code propre, mais j'aime pas qu'on me force la main. Python, c'est un peu comme cette très jolie jeune fille très compétente qui me force à mettre un costard même si je me suis pas lavé depuis trois jours...

Je vous passe les trucs un peu plus exotiques qui m'avaient pourtant pas mal plu (lua notamment) parce que je me rend compte que faire un très très gros billet quand on avait rien posté depuis longtemps, c'est pas sérieux.

Or donc, pourquoi tant de bruit ? Parce que j'ai rencontré node.js. Pourtant, a priori, pas beaucoup d'atouts à mes yeux. Déjà, c'est du javascript... Ouais, je sais, du javascript.. Moi non plus, a priori, j'aime pas... Sauf que ce que j'aimais surtout pas dans javascript, c'est que ca tournait dans un navigateur. Là, node.js, c'est server-side. Vous noterez que normalement, ça non plus, j'aime pas : node.js a au départ été conçu pour faire des serveurs web efficaces... Mais là ou ça s'améliore, c'est qu'il fait tout ce qu'un bon langage de script sait faire, et ce avec une API très cohérente. En tous cas, j'y trouve de la cohérence. La gestion de fichiers est cohérente, la gestion des comms réseaux est très cohérente, et la gestion des interfaces utilisateur est très cohérente aussi (CLI ou GUI via webapp). Bref, très chouette.

Autre point très chouette, node.js est, comme javascript, fonctionnel. C'est un langage fonctionnel, s'entend, comme caml (que j'ai beaucoup aimé, il y a longtemps). A moi le plaisir du map et du reduce. A moi le plaisir de demander à une structure de se faire des choses ! Et à moi le plaisir des callback (un gros fondamental de node.js, je reviendrai là dessus dans un prochain post, dans un an à vue de nez).

Bref, j'ai été séduit. Franchement, n'hésitez pas à tenter le coup, node.js pourrait bien vous plaire à vous aussi. Et concernant les langages, j'suis pas jaloux.

vendredi 18 novembre 2011

Monter un wiki pour une petite communauté à l'arrache [quick and dirty inside]

Dans certaines situations, c'est bien pratique d'avoir un espace d'échange qui permette à un petit nombre de personnes réparties aux quatre coins de l'Internet de partager des infos. Si on veut faire ça très bien, ça prend du temps... Récemment, on m'a demandé de monter ce genre d'espace. Contraintes :

  1. Les participants devaient pouvoir éditer des docs partagés.
  2. Ça ne devait pas être accessible à n'importe qui quand même.
  3. Ça devait être fait pour hier.
  4. J'avais un peu autre chose à faire :).

Du fait de la première contrainte, et vu que les participants connaissent un peu la technologie, je le suis dit let's wiki !.

Sur les hébergements mutualisés OVH (purée, plus ça va, plus je vous aime les gens), créer un wiki se fait en quelques minutes depuis le manager. On choisit Hébergement dans la colonne de gauche, Gestion des modules, Ajouter, MediaWiki. On renseigne les champs, on attend son e-mail de confirmation contenant le mot de passe admin (10 mins, plutôt rapide), "et voilà" comme ils disent Outre-Atlantique, le wiki est "up and running".

Contrainte 1 remplie !

Première chose, on change le mot de passe fournit dans l'e-mail (colonne de gauche, lien Pages spéciales, section Utilisateurs et droits rattachés, lien changer le mot de passe) . Il restait donc à bloquer l'accès aux gens de l'extérieur. Pour ce faire (merci la doc en ligne), il suffisait de modifier le fichier LocalSettings.php situé à la racine du MediaWiki et d'ajouter à la fin le code suivant :

$wgGroupPermissions['*']['read'] = false;
$wgWhitelistRead = array ("Special:Userlogin", "MediaWiki:Common.css", "MediaWiki:Common.js", "MediaWiki:Monobook.css", "MediaWiki:Monobook.js", "-");
$wgGroupPermissions['*']['edit'] = false;

Restait donc à créer les utilisateurs. Pour ce faire, logué en tant qu'admin, on va dans la colonne de gauche, lien Pages spéciales, section S'identifier/s'inscrire, lien Créer un compte ou se connecter, puis bouton Créer un compte. On remplit les champs, et...

Contrainte 2 remplie !

Et comme tout ceci ne m'a pas pris plus de 30 minutes, Contraintes 3 et 4 remplies aussi !

Flawless Victory !

Bien sûr, si vous connaissez des techniques plus rapides (ou plus sûres), n'hésitez pas à commenter !

vendredi 30 septembre 2011

SSD, ah ouais quand même...

Un post rapide pour partager cette info primordiale (ou pas) : je viens d'installer un SSD OCZ Vertex Agility 3... Et ben... Ca poutre... Ca boot vite, ca lance les applis vite, ca tout vite. Quand on rabache (ou qu'on nous rabache) que les accès disques c'est primordial pour l'expérience utilisateur, ben c'est pas que de la theorie...

Reste à voir la fiabilité...

samedi 17 septembre 2011

Accès au NAS mutualisé chez OVH

OVH, j'aime beaucoup. J'ai récemment souscrit à leur offre d'hébergement perso, et c'est vraiment pas mal fait... La seule limite, parfois, c'est la doc en ligne, pas toujours très claire et surtout pas très complète.

Or donc, parmi les services fournis dans l'offre d’hébergement perso, il y a l'option NAS mutualisé. Plein de place en ligne, monté directement via VPN sur mon Mac, partageable avec mes petits camarades, je trouvais ça plutôt séduisant. Or donc, je me rends sur la page d'info et je suis les instructions pas à pas. Et là...

Ca marche pas... Echec d'authentification.

L'ennui des pages OVH, c'est qu'elles sont très bien référencées. Autrement dit, difficile d'accéder à une page d'info qui ne soit pas OVH... Après quelques recherches, je me rends sur le forum, et plus particulièrement . En suivant un chouette lien, j'apprends donc qu'il ne faut pas oublier d'activer le "Stockage en ligne (VPN+SAMBA)" pour l'adresse e-mail avec laquelle on souhaite se connecter.

Or donc, pour qui ça pourrait intéresser, voici un petit rewriting de la marche à suivre pour bénéficier à partir de votre Mac de l'accès NAS mutualisé sur votre offre d'hébergement mutualisé OVH :

  1. Identifier quel est votre type d'offre, a priori, "start", "perso", "pro", "business" ou "premium". Notez que si vous êtes passé par une offre "start1m" avant de passer à une offre supplémentaire, vous devez utiliser retenir "start".
  2. Avoir un compte e-mail valide sur le domaine lié à cette offre d'hébergement. Par défaut, il y a postmaster, mais n'importe quel compte e-mail semble utilisable.
  3. Aller sur votre manager, Hébergement, Communiquer et partager, et cocher pour l'addresse e-mail utilisée la "Stockage en ligne (VPN + Samba)".

Là, vous en avez fini avec la configuration spécifique OVH. Il semble qu'il faille attendre entre 5 et 10 minutes pour que le services soit activé. Remarquez que vous aller recevoir un mail vous confirmant l'ouverture du service et contenant plein d'informations utiles.

Maintenant, sur votre Mac,

  1. Cliquez sur Pomme, Préférences Système..., bouton Réseau.
  2. Dans la fenêtre qui s'affiche, créez une nouvelle connexion VPN. Pour ce faire, cliquez sur le petit plus en bas à gauche. Si celui-ci est désactivé, cela signifie que, conformément à votre configuration de sécurité (c'est bien, d'ailleurs, de protéger ça :-) ), vous devez cliquer d'abord sur le petit cadenas et rentrer votre mot de passe. Bref, cliquez sur "+" maintenant. Dans la petite fenêtre, choisissez l'interface "VPN", "PPTP" pour le type de VPN, et donnez au service le nom que vous souhaitez. Puis cliquez sur "Créer".
  3. Dans la feuille de configuration qui s'affiche, mettez "vpn."votre_offre".ovh.net" où votre_offre peut être "start", "perso", "pro", "business" ou "premium" comme indiqué précédemment.
  4. Dans Nom du compte, mettez votre adresse e-mail. Cliquez sur "Appliquer".
  5. Cliquez enfin sur connecter, et rentrez votre mot de passe.

Normalement, vous devriez être connecté au VPN d'ici quelques seconde. Reste à se connecter au serveur samba. Pour ça :

  1. Cliquez sur votre fond d'écran pour accéder aux menu du Finder.
  2. Dans le menu "Aller", cliquez sur "Se connecter au serveur..."
  3. Dans la fenêtre qui s'affiche, entrez smb://10.8.0.1 comme adresse du serveur. Cliquez sur + si vous souhaitez conserver ce serveur dans vos serveurs favoris (a priori, vu le temps de config, c'est le cas non ? ;-) ).
  4. Cliquez enfin sur "Se connecter".

"Et voilà" comme on dirait outre atlantique. A vous le stockage distant !