URL: https://linuxfr.org/news/de-tout-de-rien-des-bookmarks-du-bla-bla-44 Title: De tout, de rien, des bookmarks, du bla‐bla #44 Authors: CrEv Davy Defaud, baud123, Nÿco, Benoît et Bruno Michel Date: 2012年10月24日T21:56:34+02:00 License: CC By-SA Tags: veille_technologique, rob_pike, logstash et firefox Score: 46 _**NdM :** CrEv publiait cette série de veille technologique orientée Web dans ses journaux. Nous (modérateurs) lui avions demandé s’il souhaitait les publier en dépêches, ce qu’il a fait déjà à deux reprises. Voici donc le résultat de l’étape, CrEv a rédigé cette dépêche dans l’espace de rédaction. Merci donc à tous._ Comme à sa presque habitude, voici un petit condensé de ma veille. Il s’agit comme souvent (mes journaux et maintenant mes dépêches) essentiellement de _bookmarks_, très légèrement commentés. C’est plutôt orienté développement, essentiellement côté Web et JavaScript, mais j’essaie aussi de toujours avoir deux ou trois petites choses annexes. Le but étant juste de partager et d’initier discussions, débats, avis, tousckevouvoulez. Comme toujours, vous trouverez une liste des liens présentés en fin d’article, pour que les plus rapides puissent cliquer directement sans lire le bla‐bla qui traîne autour. Bonne lecture ! ---- [Tag « veille_technologique » sur LinuxFr.org](https://linuxfr.org/tags/veille_technologique/public) [Épisode précédent](http://linuxfr.org/news/de-tout-de-rien-des-bookmarks-du-bla-bla-43) ---- # Un peu de contenu ## Développement Pour bien commencer cette dépêche, voici un article résumant rapidement [pourquoi utiliser TypeScript](http://www.techhui.com/profiles/blogs/why-typescript). Je trouve l’article plutôt bien, assez objectif. Il compare TypeScript, Dart et CoffeeScript. D’ailleurs, j’aime bien la comparaison avec Coffee, en gros TypeScript et Coffee c’est un peu pareil, si vous venez de Ruby faites du Coffee, si vous venez de C# ou Java faites du TypeScript. Dans tous les cas, vous pouvez prendre le temps de lire cet article, il est plutôt court et facile à lire. Pour rester sur le même type de sujet, [CoffeeScript](http://jashkenas.github.com/coffee-script) vient de sortir en [version 1.4.0](http://www.h-online.com/open/news/item/CoffeeScript-1-4-0-released-1737269.html). Le [journal des modifications](http://jashkenas.github.com/coffee-script/#changelog) est plutôt limité pour le coup. Toujours côté JavaScript, voici une comparaison entre [Ajax et Socket.IO](http://www.cubrid.org/blog/cubrid-appstools/nodejs-speed-dilemma-ajax-or-socket-io) avec un serveur Node.js. Plutôt intéressant, il y a aussi pas mal de liens à suivre si le sujet vous intéresse, notamment côté performances. Vous noterez aussi que [_Google Web Toolkit_](https://developers.google.com/web-toolkit/) est sorti en [version 2.5](https://developers.google.com/web-toolkit/doc/latest/ReleaseNotes). L’une des premières choses qui peut marquer est que le [code est plus petit](http://www.h-online.com/open/news/item/Google-Web-Toolkit-2-5-with-leaner-code-1737591.html), environ 20 % de moins. Côté nouveautés, on trouve un mode de développement supplémentaire, qui ne nécessite pas de greffon navigateur, appelé [_Super Dev Mode_](https://developers.google.com/web-toolkit/articles/superdevmode) et [_Elemental_](https://developers.google.com/web-toolkit/articles/elemental), une nouvelle [API](http://fr.wikipedia.org/wiki/API "Définition Wikipédia") pour pouvoir utiliser directement les API JavaScript des navigateurs. À noter aussi l’utilisation (optionnelle) de [_Closure Compiler_](http://code.google.com/p/closure-compiler/) pour avoir des optimisations supplémentaires lors de la compilation du JavaScript. Pour ceux qui voudraient quelque chose d’un peu plus léger, vous pouvez peut‐être jeter un coup d’œil à [_Flask_](http://flask.pocoo.org/). Il s’agit d’un _microframework_ en Python sous licence BSD. Il est basé sur [_Jinja 2_](http://jinja.pocoo.org/) comme moteur de _template_ et [_Werkzeug_](http://werkzeug.pocoo.org/) comme interface entre serveurs et applications Web ([WSGI](http://en.wikipedia.org/wiki/Web_Server_Gateway_Interface)). Je ne l’ai pas testé (faut dire que je ne suis pas un fana de Fython), mais ça semble plutôt intéressant. Puisque je sais qu’il y a beaucoup de personnes qui apprécient les vrais programmes, le côté KISS, UNIX, toussa, en voici un parfait pour vous : [_bashttpd_](https://github.com/avleen/bashttpd). Comme son nom l’indique, il s’agit bien d’un serveur HTTP écrit en _bash_. En revanche, je ne sais pas si ça _« scale »_ correctement... Que serait cette dépêche sans quelques liens vers Go ? Tout d’abord, voici une [discussion](https://groups.google.com/d/topic/golang-nuts/BNUNbKSypE0/discussion) sur _golant-nuts_ annonçant l’utilisation de Go pour propulser . Voici également une [présentation de Go chez Google](http://talks.golang.org/2012/splash.slide) par Rob Pike. C’est plutôt intéressant, la présentation explique certaines motivations et indique également certains points sur lesquels il reste du travail. Moins technique que certaines, cette présentation est intéressante pour comprendre pourquoi ils se sont lancés dans ce langage. Toujours côté langage, Ruby a annoncé son [gel de fonctionnalités pour la version 2.0](http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/46258). Cette nouvelle version devrait être disponible pour le 24 février 2013. Je laisse les connaisseurs nous indiquer quelles seront les fabuleuses nouveautés de ce langage. :) Le développement c’est bien, mais il ne faut pas s’arrêter au code. Un bon code qui ne peut — ou difficilement — être mis en production est toujours problématique. Voici, par exemple, un [article d’un ingénieur de Facebook](http://gigaom.com/cloud/how-facebook-solves-the-it-culture-wars-and-scales-its-site/) expliquant comment ils cherchent à résoudre le problème, et surtout à quel point les hommes et les outils sont importants face aux serveurs, lorsqu’on veut avoir une architecture qui tient l’augmentation de la charge. Un exemple tiré de l’article indique qu’ils sont passés de 7 semaines à 7 jours pour mettre en route 10 000 serveurs. Et là, finalement, ça change tout. Pour continuer côté _ops_, voici une présentation (avec les commentaires) d’un employé de GitHub sur [l’état de la supervision _open source_](https://speakerdeck.com/obfuscurity/the-state-of-open-source-monitoring). Je trouve la présentation assez complète et bien réalisée. En tant que développeur, on a souvent tendance à oublier cette partie. OK, lorsqu’on est dans une grosse équipe, il y a quelqu’un pour le faire. Lorsqu’on est dans une plus petite, ce n’est plus le cas. Et d’ailleurs, le côté _devops_ devient obligatoire pour bien faire les choses (je code, rends opérationnel mon code et dois savoir si tout se passe bien ou pas). Et faut dire que la supervision, la surveillance lorsqu’on est dev à la base, ben c’est pas toujours ça. Mais on se soigne, on met un Nagios à l’interface... heu... horrible. Finalement, il y a pas mal d’autres solutions, dont certaines bien plus intéressantes, agréables, lisibles. Et vous les trouverez dans la [présentation](https://speakerdeck.com/obfuscurity/the-state-of-open-source-monitoring). Cette présentation m’a d’ailleurs fait connaître [logstash](http://logstash.net/) un outil qui collecte, analyse et présente des journaux tout en les stockant pour permettre leur recherche. Étant donné que c’est une des choses qui m’intéressent particulièrement en ce moment pour remplacer des outils maisons, quelqu’un l’aurait‐il déjà utilisé et pourrait‐il faire un petit retour d’expérience dessus ? Côté HTML 5, le W3C a publié une nouvelle [_push API_](http://www.w3.org/TR/push-api/) (il s’agit d’un brouillon — draft — pour le moment). Le but est donc de permettre au serveur de pousser des informations vers les clients Web. L’exemple typique est la notification de l’arrivée d’un nouveau courriel dans un _webmail_. Les possibilités sont vraiment vastes et, de mon point de vue, très importantes. Autre exemple tout bête, on lance un traitement côté serveur et on veut savoir lorsqu’il est terminé. Actuellement, pour faire ça, on fait du _pull_. Le client, à intervalle régulier, va appeler une méthode côté serveur qui va lui indiquer le statut. Mais c’est sous‐performant, inélégant et pas agréable. Et c’est consommateur de bande passante : combien d’appels inutiles (juste pour que le serveur lui réponde que rien n’a changé) ? En revanche, comme indiqué dans [cet article de _h-online_](http://www.h-online.com/open/news/item/W3C-publishes-Working-Draft-for-Push-API-1737314.html), _a priori_ cette API ne serait pas parfaite, il serait trop facile de faire des attaques de type [DDoS](http://fr.wikipedia.org/wiki/DDoS "Définition Wikipédia") et des problèmes d’extensibilité existeraient. ## Outillage Je pense que nombre d’entre vous utilisent SSH. Mais, connaissez‐vous et utilisez‐vous toutes les possibilités de configuration offertes ? Si ce n’est pas le cas, courrez lire [cet article](http://nerderati.com/2011/03/simplify-your-life-with-an-ssh-config-file/), ça risque de vous simplifier légèrement la vie ! Pour poursuivre dans le côté « utilitaire », voici un très intéressant [article](http://37signals.com/svn/posts/3264-automating-with-convention-introducing-sub) (et le [dépôt Git associé](https://github.com/37signals/sub)) sur la manière d’écrire des outils pour se faciliter la vie. Bon OK, c’est flou ce que je viens de dire. Mais prenons simplement un exemple : vous êtes sur votre poste de dev, et vous voulez simplement faire un petit traitement sur un serveur distant. Il faut chaîner un SSH, un ou plusieurs scripts, et un `scp` pour récupérer des données. Au début, en général, on commence à la main. Puis, ça devient un peu trop lourd, un peu trop fréquent. Alors, on fait un petit script (Shell, Ruby, etc.). Et, au final, chacun fait ses petits scripts, plus ou moins dans son coin. Et c’est là qu’intervient [_sub_](https://github.com/37signals/sub). C’est une manière d’organiser et exécuter des scripts, basés sur des conventions. Pas surprenant sur ce choix, ça vient quand même des créateurs de Rails (qui est fortement [convention plutôt que configuration](http://fr.wikipedia.org/wiki/convention plutôt que configuration "Définition Wikipédia")). Le gain de structurer tout ça est que ça permet d’avoir facilement du complètement et de la documentation. Ça devient aussi plus agréable à l’usage, ça encourage à rajouter des outils, etc. J’ai commencé à l’utiliser et, franchement, ça me plaît. Je vais probablement y rajouter pas mal de choses, pour en faire la petite boîte à outils accessible partout pour mon taf (par exemple, pour faire les clones des projets Git sans connaître les adresses URL, se connecter aux différentes machines de dev, pré‐prod, prod, etc.). Par exemple, pour me connecter sur le serveur de base de données, je peux faire : * `tea connect dev db`, pour le serveur de dev ; * `tea connect preprod db`, pour le serveur de pré‐prod. Le tout avec de le complètement automatique sur les commandes, par exemple. En tout cas, très bon ressenti de mon côté, allez l’essayer ça peut vous donner quelques idées. ## Misc Comme vous le savez probablement (ou pas) [IE 10](http://windows.microsoft.com/fr-FR/internet-explorer/download-ie) est sorti. Et, comme à son habitude (qui date en fait de la sortie de Firefox 2), les équipes IE et Mozilla en profitent pour s’échanger [des gâteaux](http://limpet.net/mbrubeck/2012/10/26/mozilla-ie10-cake.html). :) Voilà, aucune information supplémentaire, juste que je trouve ça _cool_. Un peu en marge du développement, voici une réflexion intéressante à laquelle j’adhère particulièrement : [ne soyez pas un développeur PHP, Python, Ruby, JavaScript... mais soyez un développeur Web](http://seancoates.com/blogs/web-developer). En fait, j’irais même plus loin, soyez un développeur. Pour ma part, j’ai (et pourtant, je n’ai pas non plus un max d’expérience) fait du _front_, du _back_, du lourd et du Web, du JS, du C#, du Java, du C++, du Ruby, etc. Et sans passer par des SSII, sinon ça ne serait pas drôle. Soyez juste des développeurs, apprenez des nouveaux langages, des nouveaux outils, des nouvelles méthodes, etc. C’est surtout de cette façon que ça vous permettra d’avoir un esprit ouvert et critique et vous permettra de mieux réfléchir sur les problèmes (et solutions) que vous rencontrerez. # Liste des liens présentés ## Développement * _Why TypeScript? _: ; * CoffeeScript : ; * CoffeeScript 1.4.0 : ; * journal des modifications de CoffeeScript: ; * _A Node.js dilemma: AJAX or Socket.IO _: ; * Google Web Toolkit : ; * notes de version de GWT 2.5 : ; * GWT 2.5 sur _h-online _: ; * GWT Super Dev Mode : ; * GWT Elemental : ; * Closure Compiler : ; * Flask : ; * Jinja 2 : ; * Werkzeug : ; * _bashttpd _: ; * Go propulse : ; * présentation de Go chez Google : ; * feature freeze de Ruby 2.0 : ; * _How Facebook solves the IT culture wars and scales its site _: ; * _push API _: ; * _The state of open source monitoring _: ; * _logstash _: ; * article de _h-online_ sur l’API _push _: . ## Outillage * _Simplify your life with an ssh config file _: ; * _Automating with convention: Introducing sub _: ; * _sub_ sur GitHub : . ## Misc * IE 10 : ; * Mozilla offre un gâteau à l’équipe IE : ; * ne soyez pas un développeur PHP, Python, Ruby, JavaScript... mais soyez un développeur Web : .

AltStyle によって変換されたページ (->オリジナル) /