Vous avez déjà dû entendre parler de langages comme Haskell, Erlang, Clojure ou encore Scala (si ce n’est pas le cas, vous devez lire l’article encore plus que les autres). Twitter a refait son moteur de recherche en Scala et Facebook utilise Erlang pour son système de chat par exemple. Tous ces langages partagent un même paradigme (certains plus que d’autres, mais passons), et c’est en partie ce qui fait leur succès : le paradigme de programmation fonctionnelle. Je vais essayer de vous expliquer ici en quoi c’est plus qu’une mode ou une lubie d’universitaire barbu (ou non), et pourquoi donc vous devriez vous y intéresser.

Disclaimer : Je ne suis pas un expert en programmation fonctionnelle, je vous donne juste ici quelques raisons de s’y intéresser. Si les puristes y voient quelques absurdités, n’hésitez pas à me taper dessus.

Le bannissement des variables

Ça fait 10 ans que vous codez en impératif (vous avez bien fait un peu de prolog ou de OCaml à la fac mais ça ne compte pas vraiment), vous avez toujours fait des trucs dans le style i++ ou x = x + 1 et ça ne vous empêche pas de dormir, bien. C’est une honte (je fais style mais ça ne m’empêche toujours pas de dormir hein). Une des choses qui m’a le plus surpris quand j’ai appris le « pur » fonctionnel, c’est qu’on vous dit que vous ne pouvez ré-assigner une variable (qui n’est plus vraiment variable dans le coup).

Vous faites x = 1 et si vous essayez ensuite de faire x = 2 vous aurez une erreur, diantre. Et là vous vous dites : « Pourrrrrrrrquuuuuuuuuoooooooooooiiiiiiiiii est-il si méchant ? ». « Et mon for, je vais le faire comment moi ? ». Pas de panique, ça fait toujours ça la première fois.

Avant de vous dire pourquoi, juste une petite apartée vocabularistique. Vous entendrez parler de cette chose sous le terme de « données immutables ».

Pourquoi ?

Pourquoi est-ce que cette « restriction » est en fait une des clés du succès des langages fonctionnels ? Elle va permettre de faire des programmes concurrents (vous connaissez ça sous le terme multi-thread, mais il n’est pas adapté ici, car on n’utilise pas de thread dans le language) facilement, et donc de faire des programmes qui passent bien à l’échelle (scalable).

Si vous avez déjà essayé de faire joujou avec les threads, vous savez que l’accès aux données est problématique. Quand plusieurs threads veulent lire la même donnée en mémoire pas de soucis. Mais c’est quand plusieurs threads veulent modifier que ça pose problème. Qui doit avoir la priorité ? Comment fait-on quand une valeur a été modifiée par le thread 2 après que le thread 1 l’ait lue mais avant qu’il ait eu le temps de la ré-écrire ? Vos amis les sémaphores ne sont pas loin, et là c’est le drame de la complexité et des « dead locks ».

Et si on interdisait aux programmes de modifier une variable déjà affectée ? Nous y voilà. Avec cette restriction, les langages fonctionnels facilitent énormément le travail des développeurs.

Le gros mot du jour : transparence référentielle

Un des autres aspects qui différencie la programmation impérative de la programmation fonctionnelle est la transparence référentielle. En gros ça veut dire que si vous appelez 2 fois la même fonction avec les mêmes paramètres, elle doit toujours retourner la même valeur (et elle ne doit pas produire d’effets de bord, lisez le lien wikipédia).

C’est rarement le cas en programmation objet. Vous avez toujours des fonctions qui dépendent de l’état de l’objet. Si vous avez une fonction isEmpty() sur un objet et que vous l’appelez à plusieurs reprises sur un objet qui peut être plein ou vide, elle retournera un résultat différent en fonction de son état, à 2 moments différents du même programme. Elle n’est pas référentiellement transparente. Le fait de ne pas pouvoir modifier les variables aide clairement à avoir des fonctions transparentes référentiellement.

Pourquoi je vous parle de ça ? Imaginez vous avez des fonctions qui sont indépendantes les unes des autres, qui n’ont pas d’effets de bord, et qui ne partagent pas d’endroits en mémoire. Ça serait pas top de répartir tout ce petit monde sur des cœurs différents de votre processeur avec des systèmes tous prêts ? C’est notamment faisable par des modèles d’acteurs (en anglais dans le texte, la page française est un peu vide), disponibles directement en Scala ou Erlang.

Et mon for(i=0, …) alors ?

Certes vous allez devoir l’oublier (i est modifié à chaque itération). Mais vous apprendrez d’autres manières d’itérer sur vos collections (map et autres joyeusetés) qui vous semblerons finalement tout aussi naturelles. Ne prenez pas peur à la vue ces fonctions, elles vont vous permettre d’exprimer ce que vous souhaitez faire, au lieu de le décrire ligne par ligne ce que l’ordinateur doit faire en style impératif.

Voilà par exemple comment afficher les paroles de la chanson « Happy Birthday to You » en Scala sans boucle for.

(1 to 4).map { i => « Happy Birthday  » + (if (i == 3) « dear Vince » else « to You ») }.foreach { println }

Conclusion

Je cherchais depuis un bout de temps ce qui pourrait me redonner le goût d’apprendre, et la programmation fonctionnelle a été un déclic pour moi. Passer de PHP à Ruby, à Python c’est sympa, mais ça reste le même paradigme de programmation, ça ne me faisait plus rêver. Avec la programmation fonctionnelle vous trouverez au mieux un nouvel eldorado, au pire vous verrez votre façon de coder en impératif différemment. Aller hop, au boulot !

Pour aller plus loin

Je vous ai mis l’eau à la bouche et vous avez vous aussi envie de découvir ce fabuleux monde. Voilà ce que je vous conseille (en anglais par contre, je vais pas pouvoir faire autrement) :

Haskell

C’est LE language purement fonctionnel. Si vous voulez vous y mettre pour de vrai (et souffrir pour de vrai), allez y pour celui-là. Pas sûr que vous ferez de vrais projets avec, mais c’est le langage vers lequel vous devriez tendre.
Il existe en plus un très bon livre, consultable sur internet (que je vous conseille d’acheter) : Learn You a Haskell For Great Good.

Erlang

Erlang est un langage fonctionel aussi, mais moins extrémiste qu’Haskell. Son système d’acteurs et sa philosophie « let it crash » sont très intéressants. Je ne l’ai pas encore assez approfondi pour pouvoir en dire plus pour l’instant.
Un petit livre accessible en ligne : Learn You Some Erlang For Great Good

Scala

C’est le moins fonctionnel de ma séléction. Et pour cause, vous pouvez utiliser des variables mutables (même si vous pouvez utiliser des immutables aussi) et de la programmation objet. C’est une sorte de langage hybride qui vous permet de faire du fonctionnel, tout en restant dans ce que vous connaissez (la POO). Il tourne en plus sur une JVM et est compatible avec les librairies Java déjà existantes … C’est à mon avis le plus pragmatique pour une utilisation en entreprise (compatibilité Java, possiblité de faire de l’OOP), mais le moins efficace pour apprendre le fonctionnel pour de vrai. C’est ce que nous utilisons dans ma boîte actuelle.
Des ressources sont disponibles sur le site, la référence restant le livre du fondateur du langage M. Odersky Programming in Scala, Second Edition ».

On pourra remercier Vince au passage qui lui trouve du temps à consacrer à ce modeste blog !

Mais je viens de réaliser que cela allait faire quasi un an que j’avais attaqué Ruby / Rails de manière plutôt intensive et qu’un petit bilan s’imposait donc ! Alors je me lance !

Contexte

Un petit coup de contexte, notre startup Autrement édite 2 sites web, Chambres à part et HotelHotel. Le premier est en symfony1.4 et le 2e est en Rails3 suite à une décision prise fin 2009. Pour ceux que ça intéresse, Jérémy avait écrit un billet à l’époque sur ce choix.

A l’époque je m’étais retrouvé un peu seul à tenter vainement de défendre symfony mais j’avais du me résoudre à me lancer dans le grand bain pour la conception d’HotelHotel à laquelle il fallait bien que je participe (bah oué on est un peu que 3 côté techos :p), c’était il y a quasi 1 an !

Je vous préviens, ceux qui me côtoient un peu s’y attendent surement ;), je n’ai pas vraiment changé d’avis : Ruby / Rails j’accroche pas, et de depuis quasi les premières lignes écrites. Et je vais essayer de retranscrire un peu mon ressenti et retour d’expérience.

No révolution

Déjà, aucune révolution, il faut le savoir. Les différences fondamentales sont assez « mineures » dans le sens où ca n’a pas changé grand chose dans ma manière de bosser. En fait, si vous avez fait du PHP et du symfony, vous saurez faire du Ruby et du Rails, mais vous (re)passerez par la case documentation les 6 premiers mois pour trouver les équivalents à vos connaissances PHP/symfony.

Et ça commence du coup mal. Apprendre un langage et un outil en essayant de tenir des « cadences » de production honorables pour son égo, c’est pas simple. C’est même assez compliqué et ça frustre !

Côté bilan, le langage il n’y a pas grand chose à redire si ce n’est ce côté implicite avec lequel j’ai encore maintenant beaucoup de mal, question de goût j’imagine. J’ai croisé un jour un gist avec 2 « versions » d’un même code, l’un en version totalement implicite, l’autre en version totalement explicite (je remets pas la main sur le lien) : pas photo pour moi, le 2e était clairement plus compréhensible sans même connaître Ruby !
Mais les Rubyistes ont choisi le premier… ;)

Après, il est plutôt bien construit, l’api est clairement plus aboutie que PHP, et permet de faire tout autant de chose, et plutôt vite et bien une fois qu’on s’est habitué à sa syntaxe. Il faut être honnête Ruby n’a rien a envier à PHP en tant que langage pur. Mais la réciproque est pas loin d’être vrai. PHP se traine beaucoup de boulet, mais personne nous oblige à les utiliser.

Pas de switch en vue

Du coup pas vraiment de changement suffisant pour me dire que cela vaut le coup de « switcher ». Au contraire même, le problème (oui c’est un problème pour moi) de l’implicite rend toute lecture de code un vrai cauchemar ce qui m’a certainement ralenti et un peu découragé de me plonger à 110% dans le code comme j’aime tant faire. Parcourir des lignes de code que j’ai encore du mal à déchiffrer me décourage un peu. (Et oui désolé, mais moi, j’aime voir mes fins de lignes avec des points virgules !!!)

Pour le framework c’est une autre histoire. A vrai dire, je ne lui trouve pas grand chose pour lui. Attention, il vaut bien symfony 1 qui était ma référence lors de mon lancement dans Rails. Il permet de faire (quasi) tout autant de chose.
Je précise quasi, parce que moi j’ai toujours la vague impression que je suis bridé, certainement parce que je suis encore loin de maitriser les rouages que j’avais pris le temps de décortiquer sur symfony.
Et pourtant c’est déjà sa version3 (qui va avoir un an aussi d’ailleurs). Quand on voit le gap franchi avec symfony1 et Symfony2, la comparaison avec le second ne serait certainement pas à son avantage :p (:troll:)

Et c’est sans doute là que le bas blesse, je me suis retrouvé à repartir de zéro, en me disant que ça je saurais le faire de suite sur symfony, que Rails doit le faire aussi, mais qu’il fallait repasser par la case google. Et au final il le fait mais il ne fait guère plus. Donc peu de vrai « découvertes » et forcément, une petite déception…
Je me retrouve avec 2 couteaux, pas la même forme/couleur, mais le rendu est bien le même, j’arrive à couper mon saucisson sans problème (j’étais à l’apéro au moment d’écrire ces lignes…).
J’aurais préféré me retrouver avec un nouvel outil un peu différent, genre des ciseaux.

Bien sûr, je peux sans doute m’en prendre en grande partie à moi même, je n’ai jamais remis la même énergie que pendant mes 3 années passées sur symfony. Peut-être que je passe à côté de quelque chose ! Jémémy me dirait (et me dira ;)) certainement que oui…

Et puis la communauté me manque ! Je suivais (suit encore en fait ;)) l’actualité, blog, twitter qui tournent autour de symfony. Celle de Rails et même de Ruby est beaucoup plus petite en France et j’ai finalement très vite lâché l’affaire une fois de plus, un peu découragé.

Rajouter à cela, les gems, qui sont très sexy sur le papier mais qui compliquent un peu le côté, je vais mater dans le code comment c’est foutu de ce petit plugin qui rox, bien sûr le fameux RVM qui ne m’aime définitivement pas. On ne parlera pas de Passenger qui a lui aussi ses petits caprices de temps en temps, ou bien le fait qu’il faille redémarrer l’appli pour qu’un changement dans une lib soit pris en compte (mais apparemment que sur ma machine :( )

Des détails me direz vous ! Oui c’est clair, des broutilles auquel on est confronté tous les jours dans notre métier de développeur. Et le changement forcé de mes petites habitudes de bidouilleur PHP n’a pas du arranger les choses.

Je ne rentre volontairement pas dans le côté technique à comparer deux outils qui font leur job. Parce que pour le coup, la différence ne se fait pas là pour moi à mon avis.

Bilan

Au final on peut dire que c’est plus un mauvais feeling et le fait que je sois ravi de symfony et PHP qui font que j’accroche pas. J’ai passé et donné beaucoup de mon temps sur symfony et PHP et je n’ai pas été déçu, finalement je me dis que quelque part, je les trompe un peu … ;)

Et puis Symfony2 est arrivé… J’ai décortiqué les bétas, testé et retesté, lu le code. Et l’excitation de m’en servir grandit chaque jour ! Définitivement, une question de feeling donc. Et aussi parce que j’ai eu l’impression de progresser dans mon métier avec symfony1, et cette même sensation m’envahit quand je vois Symfony2. Ruby / Rails ne m’ont permis que de me diversifier…

Attention, je reste quand même ravi d’avoir pu goûter à ce changement. Ça aura au moins eu le mérite me confronter à autre chose justement, un environnement quasi entier qui diffère ! Je rajoute aussi une corde à mon arc, sait-on jamais hein…

Et ça m’aura permis aussi de me conforter, malgré toute la mauvaise presse qu’il se traine, dans l’idée que moi je l’aime bien mon PHP :p

Vim : et la lumière fut

S’il y a bien un outil qui a changé la façon dont j’utilisais mon ordinateur, c’est bien Vim. Il s’inscrit tout à fait dans la façon dont je vois les choses : prendre du temps pour apprendre les choses, de manière à gagner du temps pour en réaliser. Tout argument consistant à dire que « du temps vous n’en n’avez pas » est nul et non avenu : le temps vous l’avez, il faut juste le prendre.
Tout d’abord avec Vim, la souris devient inutile. Et c’est beaucoup plus confortable qu’on ne le croit : passer constamment de la souris au clavier est plus fatiguant qu’on ne le pense. Ensuite Vim est certes un éditeur de texte, mais c’est aussi un Framework à part entière: on peut le programmer pour en faire ce que l’on veut.

Pour finir, Vim (et ses raccourcis clavier) s’utilisent partout : vous pouvez l’utiliser pour naviguer dans vos lignes de commande shell, pour administrer votre serveur sans interface graphique, pour vous déplacer dans les applis Google (essayez de jouer avec hjkl vous verrez) ou pour naviguer dans votre Window Manager (personnellement j’utilise Awesome qui fournit par défaut des raccourcis similaires à Vim). En résumé : One Vim to rule them all.
Je vous recommande chaudemment ces deux tutoriaux vidéo de chez PeepCode (en anglais) : Smash into Vim I et Smash into Vim II

Git : un gestionnaire de versions décentralisé

La chose qui a changé la façon dont je travaillais c’est Git. Vous voyez SVN, ce truc qui essayait de faire bien ce que CVS n’aurait pas du faire ? Eh bien Git c’est tout sauf ça. Leur seul point commun, c’est que ce sont tous les deux des gestionnaires de versions de code source. Git est décentralisé, vous pouvez donc avoir un repo Git en local, sans avoir besoin d’avoir un serveur sur lequel commiter quelque part. À vous les commit dans le train ! ll permet aussi de contribuer de manière beaucoup plus facile à des projets OpenSource, notamment grâce à Github (que je décris dans cet article).

Je ne vais pas vous décrire de façon exhaustive pourquoi Git est bien, si vous voulez en savoir d’avantage vous avez le livre OpenSource Pro Git ou cette suite d’articles Git pour les nuls. Vous pouvez aussi vous référer à cet article très bien réalisé A successful Git branching model. Quoiqu’il en soit, si vous utilisez encore SVN, passez à un gestionnaire décentralisé (DCVS) style Git ou Mercurial, ça urge les gens. D’autant plus que migrer un repo SVN existant sur Github est un jeu d’enfant.

De Mac OS X à ArchLinux

Cela faisait maintenant 8 ans que j’étais exclusivement sous Mac, et j’en étais plutôt content. J’étais passé par divers BSD et autre linux avant, pour m’arrêter sur l’Unix que je trouvais le plus convivial : Mac OS X. Car en effet dans mon utilisation quotidienne je voyais plutôt Mac OS X comme un Unix avec lequel je pouvais ouvrir des fichiers Photoshop (je caricature mais l’idée est là). Étant un barbu stallmanien refoulé, mon subconscient vivait de plus en plus mal les orientations prises par Apple : c’était le moment de changer d’OS.

Depuis je suis passé sous ArchLinux, et là ça a été la révélation : toujours la dernière version des logiciels et un wiki d’installation très bien fait qui en plus de vous guider vous permet d’apprendre ce que les autres vous cachent par des interfaces graphiques. Photoshop n’est plus un problème, puisque virtualiser un autre OS sous Linux s’effectue maintenant sans souci (pour le peu de fois que je m’en sers …). Si vous voulez apprendre linux par vous même, essayez ArchLinux, ça vaut le coup. Vous pourrez en plus utiliser des logiciels comme Terminator (gestion de plusieurs terminaux), Synapse/Gnome Do (lanceurs d’applications), Hotot (client Twitter) ou Awesome Window Manager (gestionnaire de fenêtres) dont il est difficile de se passer ensuite.

Firefox4

J’étais sous Firefox depuis un bon nombre d’années, et en fin d’année dernière c’est le drame : je l’abandonne pour Google Chrome. À contre coeur, mais il fallait se rendre à l’évidence, sur mon mac, Firefox devenait inutilisable quand on avait goûté à Chrome. Et puis en milieu d’année, j’ai fait le switch inverse de Chromium/Google Chrome à Firefox4 par idéologie : c’est Firefox qui a permis d’améliorer mes conditions de travail journalières (j’ai assez mal vécu la guerre IE 5 /Netscape 4 ;-) ), et il est maintenant très rapide (en tout cas comparable à Chromium). Je n’irai pas jusqu’à dire qu’il bat Chromium sur tous les fronts, mais il lui tient la dragée haute. Si comme moi vous préférez les actions de la fondation Mozilla à celle de Google, vous devriez essayer une béta de Firefox4 (avec Firebug 1.7), vous pourriez être surpris.

Conclusion

N’hésitez pas à essayer, échouer, réessayer, échouer de nouveau pour réussir de belle manière ensuite. Vous pensez que Vim est trop compliqué pour vous ? Qu’avec Linux on a l’air de pouvoir faire des choses bien, mais que clicker sur un .exe ça vous rassure ? Que neni ! Jetez vous à l’eau, et quoiqu’il en soit, faites tout pour améliorer votre quotidien avec des outils adaptés. Si vous n’essayez pas, vous ne risquez pas d’échouer, mais si vous n’échouez pas, vous ne risquez pas d’apprendre ;)

Et vous, quels outils vont ont fait évoluer dans votre métier ?

Crédit photo : http://www.flickr.com/photos/kinregerp/4457001909/

[s|S]ymfony : un homme

[s|S]ymfony c’est un homme, une vision : Fabien Potencier. Il y a certes une belle communauté autour, Kris qui s’occupe des release de la 1.4 notamment, Jon qui était embauché par Sensio pour Doctrine, mais c’est Fabien qui a toujours dirigé le développement du Framework. Depuis quelques temps déjà, Fabien est passé sur le développement de Symfony2, et a donc arrêté tout nouveau développement sur symfony 1. La conséquence immédiate est l’absence de quelconque nouveauté depuis plus d’un an sur symfony 1, et ce encore pour plusieurs mois.
Alors oui on nous explique que symfony 1.4 marche, certes, mais il continuera donc de se trainer ses défauts jusqu’à la fin de sa vie : Admin generator qui est là pour faire bien, forms imbriqués qui sont le cauchemard de tout développeur symfony, … On va aussi vous dire : mais t’as qu’à contribuer (oui vous savez, la réponse ultime de toute discussion open source non constructive) ! Le souci c’est que généralement quand on utilise un Framework, c’est pour gagner du temps, pas pour passer son temps à le développer (je me place du point de vue utilisateur, le cas spécial du contributeur core n’est pas traité ici). On peut contribuer avec des plugins certes (je suis le premier à le faire dès que je peux), mais pour moi la gestion des forms imbriqués devrait relever du Framework, pas de plugins.

Ma vision des choses

Donc si on dresse le tableau après plus d’un an de stagnation de symfony 1 :

• symfony 1 va stagner pendant toute la durée de sa future vie (officiellement novembre 2012)
• pour avoir des nouveautés Symfony, il faudra attendre Symfony2 qui est prévu, au plus tôt, Mars 2011
• Symfony2 en mars ne sera qu’une première version, donc loin de toutes les subtilités et fonctionnalités que peut avoir symfony 1

Vous allez me dire que ce tableau n’est pas très réjouissant, j’en conviens. Ça n’empêche nullement de démarrer des projets sur symfony 1.4, je le fais encore moi même, mais je pense que ça encourage à se poser les bonnes questions. Tiens, peut être qu’il existerait quelquechose qui pourrait combler mon manque, ma frustration en attendant Symfony2 ? Peut être que je pourrais avoir tout ce que symfony 1 m’apporte autre part, tout en utilisant quelquechose qui n’est pas voué à stagner ? Et si en plus je pouvais apprendre de nouvelles choses, ça serait top !

Django, une ouverture d’esprit ?

On aime tous évoluer, apprendre (enfin j’espère), se remettre en question … Mais beaucoup d’entre vous ont aussi des objectifs de rentabilité, de sureté vis-à-vis du client. C’est pourquoi utiliser votre client comme « même-pas-alpha-testeur » de Symfony2, ça reste encore très risqué et difficile à faire passer à votre direction.
Il existe d’autres Frameworks, d’autres langages que le PHP, c’est peut être l’occasion, en attendant Symfony2, de les tester sur des projets à faible risque ? En voici quelques un que j’aimerais tester personnellement : Play Framework en Java, Django en Python et Rails en Ruby. Si vous voulez vraiment avoir un avant goût de Symfony2 et que vous êtes prêts à vous attaquer à la bête, allez voir du côté de Spring en Java. Même si vous ne les testez que sur un projet, prenez le temps de le faire. Croyez moi, ça vous permettra de prendre du recul, et ça c’est toujours bon !

Pour ma part, je l’ai fait pour Django, et j’en suis très content. On retrouve vite ses petits par rapport à symfony et ça permet de faire un contrastif très intéressant avec symfony. C’est là qu’on se rend compte qu’il arrive, des fois, que l’herbe soit aussi verte ailleurs (mais pour ça, il faut aller voir).

Crédit photo : http://www.flickr.com/photos/clementlivolsi/4566165441/

Matériel et connectivité

Au moment où j’écris ces lignes, les caractéristiques principales de la dedibox sont :

• Serveur : Dell XS11-VX8
• CPU : Nano U2250 1,6Ghz
• Disque dur : 160Go SATA2
• RAM : 2 Go DDR2
• Réseau : 1 Gbit/s

En ce qui concerne le kimsufi voilà ce à quoi on a le droit :

• Serveur : certainement un assemblage maison, aucune info
• CPU : Celeron D/215/220 1,2 Ghz
• Disque dur : 250 Go (non précisé)
• RAM : 2 Go (non précisé)
• Réseau : 100 Mbit/s

Pour le côté matériel, j’aurais un petit faible pour la Dedibox. Même si le disque dur est moins important, le processeur Nano est au dessus du Celeron. De plus, les serveurs étant fournis par Dell, on peut espérer une relative qualité du produit. Idem pour la connectivité, la Dedibox dispose d’un débit 10 fois supérieur au Kimsufi.

Les services

Les deux sont plutôt bien fournies en services. Elles disposent chacune d’une console d’administration riche en fonctionnalités où vous pourrez réinstaller le serveur, le monitorer, configurer vos options (reverse DNS notamment), démarrer sur un système de secours, j’en passe et des meilleurs. À vrai dire, il y a tellement de trucs dans l’une et dans l’autre qu’il est bien difficile de les départager sur ce terrain là. L’essentiel y est.

En revanche, Kimsufi propose un espace de sauvegarde FTP de 100 Go, contre 5 Go (extensible à 200 Go via un abonnement) pour la Dedibox. De plus Kimsufi propose une connectivité IPv6 alors que Dedibox ne le précise pas (si vous avez des infos je suis preneur).

La fiabilité

Ça va faire plus d’un an et demi que j’ai ma Kimsufi, je n’ai jamais eu une coupure dessus. Donc niveau fiabilité rien à redire.
Pour la Dedibox, j’ai eu la V2 pendant plusieurs années aussi sans avoir à m’en plaindre. Pour la V3, j’ai du malheureusement la remplacer au bout de quelques semaines (alors qu’elle ne servait même pas) car il m’était impossible d’y accéder, et impossible de démarrer avec le système de secours. Le remplacement est d’ailleurs automatique via la console d’administration. Un défaut de jeunesse ou un coup de pas de chance ? Toujours est-il que je n’ai pas eu d’autres soucis depuis.

Les frais et conditions

Alors certes il faut lire entre les petites lignes, mais vous avez des frais d’installation pour les deux. Ils sont de 49,99 € HT (59.79€ TTC) pour Kimsufi et de 39.99€ HT (soit 47.83€ TTC) pour la Dedibox. À noter qu’ils sont offerts chez OVH si vous vous abonnez à l’année.
Car c’est aussi une des caractéristiques de ces offres, vous pouvez résilier votre serveur quand vous le souhaitez, c’est « sans engagement ». Pour les deux, cela se fait relativement facilement via la console d’administration.

Bon bah et alors ?

Malgré ce que pourraient laisser penser les caractéristiques techniques de la Dedibox, je pense que si j’avais un autre serveur dédié à prendre, je prendrai le Kimsufi. Je n’ai pas besoin de grosses performances, mais plutôt d’un espace disque conséquent. J’aime aussi la sauvegarde 100 Go par défaut. Et je crois que mon problème avec la Dedibox m’a plutôt refroidi.
Pour finir, avec Kimsufi vous pouvez payer par CB tous les mois (et non par virement comme avec la Dedibox), et arrêter quand vous voulez sans ne faire aucune démarche : vous avez juste à arrêter de payer, et la résiliation se fera automatiquement.

Crédit photo : http://www.flickr.com/photos/johnseb/3425464/

SVN vs Git

Tout d’abord, Sourceforge utilise un système de gestion de code source appelé SVN (j’espère ne rien vous apprendre ici) alors que Github utilise un système de gestion de code source décentralisé appelé Git.

Vous voyez la préhistoire ? Vous voyez les temps modernes ? Vous voyez donc la différence entre SVN et Git. Je ne vais pas vous faire un cours sur Git ici, ce n’est pas le propos (et d’autres le font très bien dans le Pro Git book). Mais une fois que vous aurez goûté à Git, vous trouverez SVN « so 2 thousand ».

Si vous utilisez encore SVN, ça ne peut être que parce que vous n’avez pas encore pris le temps d’apprendre à utiliser un système de gestion de code source décentralisé (Git ou Mercurial par exemple). Un conseil : prenez ce temps, ça vous rendra bien des services.

Github : mes amis les codeurs

Comme je le laissais entrevoir habilement dans le titre de cet article, Github c’est un peu le Facebook des codeurs. Vous ne pouvez pas vraiment demander aux personnes d’être vos amis, mais vous pouvez suivre leur activité (un peu à la Twitter). Vous avez donc une page récapitulative qui vous permet de suivre l’activité des personnes ou des projets que vous souhaitez.

Vous aurez aussi la possibilité de voir les projets que vos « amis » se mettent à suivre. Je n’ai jamais autant découvert de projets que depuis que j’utilise Github. Si vous souhaitez être au courant des dernières évolutions, des projets en vogue, Github est fait pour vous.

La collaboration c’est bon, mangez en

Puisque vous êtes sages et disciplinés, vous avez été lire le livre « Pro Git » et vous savez maintenant tout sur Git.

Github utilise pleinement les capacités de Git et va permettre de « forker » un projet via le site. En gros ça va vous créer une branche du projet dans votre compte. Vous pourrez faire des modifications dans votre branche et ensuite demander un « pull request » au responsable du projet : il verra vos modifications et pourra en un click les intégrer au projet principal. C’est du jamais vu ma bonne dame !

Tout le monde peut forker tous les projets et essayer de contribuer à la hauteur de ses compétences. Vous pouvez même commenter les lignes du code source directement sur le site, de manière à échanger avec les autres codeurs.

La cerise sur le gâteau

Je viens de vous dire que Git c’était l’avenir, que Github vous permettait de suivre et de découvrir plein de projets intéressants et qu’en plus il facilitait la collaboration entre les codeurs. Pour finir de vous convaincre, voici en vrac quelques petits « plus Periglioni » :

• Import automatique d’un projet sous SVN avec conservation de l’historique des commits
• Lecture et écriture possible via un client SVN sur les repos Github (alors si même avec ça vous passez pas à Git, je peux plus rien pour vous)
• Possibilité de créer des projets privés (moyennant une modique somme)

Alors, hop hop hop, on s’y met et plus vite que ça !

Il est parfois aisé d’oublier à quel point le « World Wide Web » est international.

Des centaines de millions de personnes surfent sur la toile à n’importe quelle heure. Aux États-Unis, et dans tous les pays anglophones, nous avons tendance à croire que tout le monde parle notre langue.

Même si c’est le cas de beaucoup de personnes, ce n’est pas un avantage si évident. Les clients du monde entier ont une probabilité cinq fois supérieure d’acheter sur un site dont le contenu est rédigé dans leur langue natale.

L’Internet en langue étrangère, dans le sens où l’intégralité du contenu du site n’est pas en anglais, est une formidable occasion pour les entreprises d’accroître leurs revenus, mais elle est paradoxalement une des solutions les plus ignorées. De ce fait, les sociétés ne perdent pas seulement de l’argent, elles encouragent également leurs concurrents.

Lancer une page Internet en anglais vous met immédiatement en concurrence avec des milliards d’autres pages sur les moteurs de recherche. Créer votre page dans une autre langue peut vous faciliter grandement l’accès à une position dominante.

Par exemple, Lingo24 a lancé un microsite danois pour un coût inférieur à 100 livres sterling (160 dollars) au début de l’année dernière. En septembre, nos ventes avaient atteint un niveau qui nous permettait d’employer un gestionnaire de compte à plein temps, et le marché danois représente aujourd’hui une part significative et croissante de notre chiffre d’affaires. Nos revenus internationaux cumulés représentent désormais 64 % de nos ventes.

Il est bien évident qu’il ne s’agit pas d’ignorer le marché intérieur, mais l’arrivée de votre société dans un territoire mal desservi peut attirer l’attention des observateurs à l’échelle locale. Cela peut se traduire par une attention médiatique, un meilleur positionnement sur les moteurs de recherche et une clientèle accrue. Il est donc important d’identifier les médias pertinents au sein des marchés que vous ciblez.

La valeur cumulée des marchés en langues étrangères peut être nettement supérieure à celle de votre marché intérieur. Vous en voulez la preuve ? Regardez Google. Moteur de recherche dominant dans quasiment tous les pays, Google tire 52 pourcent de ses revenus de l’Internet en langue étrangère.

Élaborer un site Internet dans une autre langue peut être intimidant. Il faut donc garder à l’esprit ces quelques points lorsque vous prévoyez votre stratégie.

• Développez votre compréhension du marché. Si vous avez des clients à l’étranger ou des clients locaux ayant des connections à l’étranger, demandez-leur s’ils pensent que votre offre peut être attrayante à l’échelle internationale. Établissez une liste de contacts susceptibles de valider vos idées, voire de devenir vos premiers clients.
• Analysez la concurrence. Les outils de traduction automatique de Google peuvent vous aider à déterminer rapidement où en sont vos concurrents.
• Évaluez la demande. Utilisez les outils Google et Yahoo pour identifier les phrases-clés qu’il faut cibler sur vos marchés étrangers.
• Faites traduire votre site par des professionnels. Les traductions automatiques de Google sont suffisantes pour comprendre un contenu, mais absolument pas fiables pour le site Internet d’une société. Choisissez une entreprise de traduction professionnelle pour communiquer clairement votre message à vos clients.
• Commercialisez votre site en ligne. Les principes sont les mêmes que pour l’anglais. Forgez des liens par l’intermédiaire de partenaires, adoptez le « paiement au clic » (cpc) et essayez d’apparaître sur les sites que vos clients potentiels fréquentent.

Ces quelques étapes à suivre (et à renouveler dans d’autres langues) peuvent vous permettre d’élargir et de diversifier votre activité.

J’aimerai du coup, qu’il plaise à la majorité et donc, c’est l’occasion pour prendre votre clavier à 2 mains et de me dire, ce qu’il manque, vous plaît pas, ce que vous aimeriez différemment pour ne pas reproduire le même genre de schéma sur le prochain!

Hésitez pas, je suis très ouvert d’esprit en ce qui concerne mes oeuvres. Le but c’est que je continue à prendre du plaisir à bloguer par ici, mais que vous preniez aussi du plaisir à lire.

Voilà, c’est dit, même si je sais que vous êtes timides, je suis sûr qu’il y aura bien 2 ou 3 courageux pour se jeter à l’eau! Surtout qu’il va falloir faire vite, la mise en ligne est prévu mardi!

Alors dites-moi, qu’est-ce que vous aimeriez changer sur ce blog?

Il y a un peu plus d’un mois de ça, je me lançais dans l’aventure Twitter histoire d’approfondir mon opinion sur ce sujet qui retient l’attention de toute la blogosphère. Mes premières impressions de simple utilisateur n’ont pas été très positives et je comptais faire un billet dessus.

On vous propose de suivre des personnes aléatoirement

Une interface à l’époque plutôt pauvre et peu intuitive en plus d’être seulement en anglais et en japonais, certainement le plus gros frein à sa percée en France quant on sait comme nous aimons notre belle langue. Une page d’accueil qui dit pas grand chose, si quelqu’un ne connaissant pas Twitter tombe dessus, je doute qu’il sache de quoi il retourne. Et un process d’inscription qui poursuit sur cette lancée.

Mais j’ai laissé la chance au produit finalement. En lisant à droite à gauche, j’ai vite compris qu’il me fallait un client parce que l’interface de base ne fait pas rêver. Je me suis mis en quête d’un spécimen Mac exclusivement (oui quand on est sur un mac, on aime bien avoir de jolis softs :D) et la après des premiers essais peu convaincant, je suis tombé sur un des logiciels mac les plus abouti que j’ai pu voir: Nambu. Une interface dans l’esprit mac et très modulable qui m’a de suite séduite et qui a contribué à mon approfondissement du sujet.

Interface Nambu

Une fois équipé, je me suis lancé avec la première question: « Mais qui je vais bien pouvoir suivre?! ». Alors on suit les copains en premier, puis les gars dont on aime bien le blog, quelques pointures de notre domaine de prédilection, Symfony pour moi et on commence à lire ce qui défile maintenant devant nos yeux, sans trop savoir quoi dire. Puis on reçoit, un petit mail, « quelqu’un à décidé de vous suivre ». Pourtant j’ai encore rien écrit… Oh du spam, c’est donc comme partout.

Puis on se lance, on raconte un peu nos humeurs, on ReTweet ce qui nous semble intéressant, on lit, on clic, on balance un lien sympa mais très vite on tourne en rond et la question de qui suivre revient. Car s’il faut arpenter tous les couloirs de twitter pour cliquer sur « follow » dès que quelqu’un nous semble intéressant, on a pas fini.

Et oui du spam même sur twitter

Et là, grâce à Nambu, je découvre la vrai dimension de Twitter pour moi, les Trends, ces petits mots précédés de # qui permettent de donner un « thème » à vos tweets et qui sont alors recherchables facilement. Et là je me lance, je « m’abonne » au trend #symfony, et là bingo, plein de gens qui parlent d’un thème que vous appréciez sans rien faire. Et grâce à votre client, il vous refresh automatiquement ce trend. On se croirait dans un salon IRC! Le bon vieux temps. La mayonnaise prend enfin, et je me dis que finalement on peut trouver une utilité à ce service.

Aujourd’hui, je survole donc une dizaine de trends chaque jour, de #symfony à #jquery en passant par #webdev, qui m’offre sur un plateau toute l’actualité du web sur ces sujets. Il n’y a plus qu’à cliquer.

Si on m’avait expliquer les choses comme ça dès le début, peut-être que j’aurais été moins réticent. En tout cas, maintenant, je suis seulement les personnes qui m’intéressent réellement, et je parcours les trends pour suivre l’actu du web développement, et je dois avouer que je n’aurais pas soupçonner cette dimension au premier abord.

Voilà, maintenant, je suis encore en phase de nouveauté et de découverte, on verra si sur une plus longue période, je ne me lasse pas.

En bonus, un petit guide tout frais (entendre par là, que je l’avais pas il y a un mois) pour débuter sur Twitter:

• Twitter pour les novives

En tant que petit blogueur du dimanche (bon du mardi en fait), Wikio ne m’apporte quasi aucun trafic et du coup son top me passe vraiment de très loin (j’ai d’ailleurs perdu 2000 places ce mois-ci apparemment \o/), mais je me dis que pour que tout le monde en parle, il devait quand même être un bon reflet de la qualité d’un blog. J’ai donc balayé le top hightech de juin, catégorie de blog que je lis le plus après les blogs (anglais) sur le web développement, selon mes critères pour voir s’ils faisaient tous parti de mes lectures et si j’en avais loupé des intéressants.

Évidemment, c’est juste mes goûts, tout le monde s’en fout, mais bon je fais bien ce que je veux ici:

1. Presse-citron: Je ne lis pas
   Le leader incontestable apparemment, il faut lui reconnaitre une actu plutôt fraîche mais trop concentrée à mon goût, tout ne m’intéressant pas, je ne lis pas et attend que d’autres fassent le tri :D
2. Korben: Je lis souvent
   Un vrai style dans ses billets, de l’actu qui m’intéresse dans la grande majorité, un de mes blogs préférés
3. TechCrunch France: Je lis à l’occasion
   Je lis plus la version anglaise, mais je fais un tour régulièrement, parce qu’un peu de français ça fait du bien parfois dans ce monde d’anglophone
4. Le Journal du Geek: Je ne lis pas
   Bon, les goûts et les couleurs hein, mais déjà je n’ai jamais adhéré au design du site, on se sent à l’étroit quand on lis et une actu qui ne m’intéresse que très peu
5. AccessOWeb: Je lis souvent
   Un blog que j’ai découvert récemment, mais qui m’a séduit principalement par le style de rédaction de Philippe (je peux t’appeler Philippe?) que j’apprécie beaucoup et certaines « exclusivités » qu’il couvre qu’on ne retrouve pas dans 36 autres blogs
6. Fubiz: Je ne lis pas
   Une ligne éditoriale qui ne m’intéresse tout simplement pas, mais un blog de qualité dont il m’arrive à l’occasion de balayer la home pour voir les images
7. Nowhere Else: Je lis souvent
   Un des rares blogs de ce type que je suis principalement par RSS, une actu un peu buzz dont le style me plait assez
8. ReadWriteWeb: Je lis à l’occasion
   Un peu le même topo que pour techcrunch
9. BienBienBien: Je ne lis pas
   Bon bah là, un blog à mille lieux de ce que je recherche comme lecture, goûts, couleurs, toussa toussa
10. GizModo: Je lis à l’occasion
    Une actu un peu trop riche et trop peu personnelle (rarement des avis sur le sujet du billet) qui font que je n’y viens que quelques fois pour faire un rapide tour, histoire de voir si une actu serait passé entre les mailles du filet
11. Le blog du modérateur: Je lis à l’occasion
    Quelques billets originaux et bien sympa de temps en temps, qui font que j’y vais à l’occasion survoler un peu la home
12. Gonzague Dambricourt: Je lis à l’occasion
    Un style très sympa, une ligne éditoriale qui change de la majorité, j’y fais un saut de temps en temps
13. GuiM: Je ne lis pas
    Pareil que pour BienBienBien, je me retrouve pas vraiment dans la ligne éditoriale
14. Vincent Abry: Je lis souvent
    Un personnage que j’apprécie, une plume qui se lit bien et une actu qui me tente, j’ai découvert assez récemment, mais je suis séduit
15. PPC’s: Je découvre
    Je n’en avais jamais entendu parler, je découvre mais la première impression n’est pas terrible autant niveau contenu que niveau design. A voir
16. Partageons le reste: Je découvre
    Une autre découverte! Celle ci semble plus prometteuse, un style, des idées et un design assez classique pour se faire oublier.
17. Framablog: Je lis souvent
    En bon libriste, je suis framablog régulièrement, des billets tous intéressants dans un secteur que j’apprécie beaucoup, il en faut pas plus
18. Cocktail de Web News: Je lis souvent
    Beaucoup d’énergie et d’idées de la part de Thierry (je peux t’appeler Thierry?), il couvre un domaine que j’aime beaucoup, les services web et ses billets se laissent lire.
19. Transnets: Je lis à l’occasion
    Certainement la plus belle plume de ce top, des billets très complets mais parfois trop et malheureusement pas toujours assez de temps pour en profiter, donc je sélectionne sur le critère très subjectif du titre. Une très bonne lecture néanmoins
20. Vendeesign: Je lis à l’occasion
    Une actu qui recoupe beaucoup d’autres blogs mais quelques billets sortent du lot et du coup j’y fais un saut de temps en temps
21. Fredzone: Je lis souvent
    Oui j’avais dit le top20, mais il le sera très certainement le mois prochain grâce à mon backlink! Un de mes coups de coeur, un blog que j’aime en tout point. Fred semble en plus prendre beaucoup de plaisir à faire vivre ce blog en y donnant son avis (avec un style qui lui est propre). Bref, je le recommande, mais vous devez déjà tous connaitre!

A noter qu’effectivement le design prend une part dans mes choix car je lis ces blogs sur leur support initial, car ils ne font pas forcément parti de ma veille et donc c’est plus pour le plaisir : )

Alors, oui tout ça est très subjectif et les blogs que je lis pas, bah je pense qu’ils s’en balancent pas mal hein, eux ils sont lus au moins… (nan mais 2000 visites ici! ok par mois certes…).

Voilà, et oui j’ai fait tout le top21 histoire de pas biaiser le classement, un backlink chacun!