Martius Web

Les articles

Les articles de cette catégorie sont des petites découvertes ou des sujets d'actualité ponctuels, bonne lecture !

Flash on Linux will only be available for Chrome

This announcement from Adobe here is pretty interesting. In a nutshell, Chrome guys built a new API (Pepper) which allows developers to execute stuff in the browser, using sandboxed native code. Now Google helps Adobe (I don’t know exactly how) and offers an easier integration of Flash in the browser. Then, Adobe choose to focus on integrating Flash in the browser using this API. For the Linux version of Flash plug-in, Adobe won’t support other APIs (hence, other browsers than Chrome).

Paul Rouget tweeted about a mail from Robert O’Callahan talking about the Pepper API. He says that there is already a “rich platform API to sandboxed code : the standards-based Web APIs”. This is mostly true : these APIs are in the making, people are working on it and there is less and less missing fundamental APIs (after all, they’re able to make Boot2Gecko… in Javascript).

Mozilla, and probably other vendors, don’t plan to work on Pepper, since they believe it’s a “duplication of effort”.

I believe that this is exactly why Adobe is doing this right now. They are gambling and trying to impose a dilemma to other browsers: vendors change their mind, allow native stuff in the browser and therefore let Flash live as an environment parallel to all the new web technologies (HTML5, Js new APIs, etc) or they impose the lack of Flash for Linux users, who won’t be able to play Cityville under Firefox anymore.

I believe Adobe couldn’t do this latter: the standard-based APIs are more and more used against Flash which is used as a last-resort solution. In a short time, authoring tools and stable API will convince developers to drop Flash and Adobe, unless Flash can compete with the standard APIs. That’s what brings Pepper: a better integration of native code into the browser.

Zsh for the shell nerds

Il y a quelques semaines mes amis Paul et Nicolas m’ont encouragé a essayé une alternative à Bash, le shell que nous utilisons généralement tous par défaut. Le changement s’est pratiquement fait directement (je suis un gros utilisateur de la console).

Changer de shell dans la console, c’est comme changer d’environnement de bureau (GNOME, Kde, etc) : globalement c’est la même chose, mais la manière dont ils sont présentés va varier. Alors Zsh, ça apporte quoi par rapport à Bash ?

Concrètement, on peut le voir comme une surcouche : la syntaxe des commandes ne change pas énormément. Les principales fonctionnalités qui vous feront basculer sont celles qui apparaissent en mode interactif :

  • l’auto-complétion/complétement (faites votre choix sur la terminologie) est vraiment puissant et paramétrable,
  • la correction des commandes est magique, et évite de retaper de longues commandes pour une faute de frappe,
  • une meilleure gestion de l’historique des commandes.

En plus, zsh supporte de nombreux plugins et supporte un mécanisme de thèmes, dont une impressionnante collection est maintenue sur un dépôt github dans un projet appelé Oh-My-Zsh. Il suffit de cloner le dépôt en local, de suivre le Readme, et de choisir son thème pour qu’en quelques minutes, Zsh soit adopté !

En plus, de nombreux thèmes supportent nativement le plug-in git qui offre la complétion/le complétement et affiche la branche de travail et si des données n’ont pas été archivées dans un commit.

En ce qui me concerne, j’ai choisi le thème “jreese”. Si vous avez le loisir de commenter et de me recommander des plug-ins ou docs pour encore améliorer ma productivité, je suis preneur !

Set up a Teeworlds server on Debian Lenny (or any other Gnu/Linux)

If you are reading this, I’m pretty sure you already know Teeworlds, an Open source 2D game between Worms (I mean Wormux) and Doom with graphics from Kirby. Today I’m trying to set up a server to host some sessions of this game.

As you will see, this is quite straightforward, and does not require tremendous skills in GNU/Linux systems administration.

Notice : This content is available in English and I’ll try to provide it in French as soon as possible. I decided to write it in English since I did not found a complete how-to on this -very important- topic.

Paris Web : Conclusion !

Voilà, j’ai publié tous mes comptes rendus sur Paris Web, il est temps d’en faire un petit pour tout résumer. Je remercie à nouveau Pascale et Stéphane, grâce à qui j’ai pu accéder à cet événement malgré ma situation d’étudiant.

Paris Web, c’était deux jours de conférences à l’IBM Forum à Bois-Colombes (au nord de Paris), suivie par 450 personnes (et une centaine d’autres en direct via le net) et une journée d’ateliers à Telecom-Paristech (Paris XIIIe) qui a réunit 250 personnes.

Je remercie également mon amie Mélanie pour m’avoir hébergé pendant ces quelques jours.

(Paris Web !) #8 Upgrading the frontend, encore un peu d'HTML5

Cette conférence était dirigée par Dave Shea,que l’on connait tous pour être le créateur de Css Zen Garden (même si il nous rappelle tous qu’il n’a pas fait que ça !). La conférence était en anglais.

C’est la dernière conférence pour laquelle j’ai pris des notes suffisamment complètes pour les résumer sur le blog. Je n’ai pas trop pris de notes sur les conférences orientées graphisme, car beaucoup en parleront mieux que moi.

(Paris Web !) #7 HTML5 maintenant... et même avec IE 6

Conférence dirigée par Jean Pierre Vincent, que je lis avec assiduité dans les transports en commun ou pendant les pauses déjeuner.

Cette conférence parle comme beaucoup d’HTML5 et des nouvelles fonctionnalités qui arrivent avec. Jean-Pierre Vincent en utilise quelques unes, et cherche (ou réalise) des fallbacks utilisés en production.

Les slides de la présentation sont disponibles sur le site de l’orateur.

(Paris Web !) #5 Reusable Code : For Good or For Awesome

Une conférence qui s’appelle “reusable code”, je sais d’avance que ça va me plaire. En plus, Jake utilisait une wiimote pour contrôler sa présentation, c’était forcément génial.

Une excellente conférence, mais qui s’adresse essentiellement aux développeurs. L’orateur présente des bonnes pratiques pour réaliser des API réutilisables en Javascript. Bien sûr, bon nombre de conseils s’appliquent dans d’autres cas. C’est la deuxième conférence que j’ai suivi en anglais.

Conférence dirigée par Jake Archibald, qui fait de belles APIs Javascript pour la BBC.

L’une de ses grosses missions, c’est de produire du Javascript réutilisable.

Les slides de la présentation sont disponibles sur slideshare.

(Paris Web !) #3 Let's interface !

Cette conférence est la première en anglais, j’ai essayé de la suivre sans traduction pour pouvoir prendre des notes. Je pense que ces notes ne seront pas très utiles car la conférence est très visuelle et interactive. La vidéo sera certainement disponible d’ici quelques semaines.

Conférence dirigée par Chris Heilmann (Tech evangelist chez Yahoo !). Vous pouvez retrouver les slides de la présentation.

(Paris Web !) #2 Javascript Server Side (ssJS), par où commencer ?

OK, là je m’y retrouve un peu mieux, et je me sens en terrain familier, ou presque : on parle d’exécuter du javascript côté serveur. Ma dernière tentative… ah oui ! Un module PHP expérimental qui embarquait Tracemonkey !

On va faire un point sur l’état de l’utilisation de JS côté serveur. Javascript est-il destiné au client-side ?

Conférence dirigée par Quentin Adam.

(Paris Web !) #1 La conception universelle : ou votre site web s'adaptera à tous les besoins.

Je suis à Paris Web pour trois jours, je vais essayer de raconter ce que je vois au mieux. Tout est posé brut en fonction de ce que j’entends (j’essaierais de faire une relecture clean quand je serais un peu plus reposé). Soyez indulgent, il est possible (voir probable) que je n’ai pas tout suivi !

Retrouvez tous les billets sous le tag ParisWeb.

Cette première conférence est dirigée par Matt May, Responsable accessibilité chez Adobe (rien que ça). Sa conférence est en français bien qu’il soit anglophone, ce qui rendait le tout parfois un peu difficile à suivre.

Utiliser Bayes pour développer un filtre anti-spam

En révisant mes cours de probabilités, je me suis dit qu’un bon petit exercice pour une application concrète à l’informatique pourrait être de réaliser un filtre anti-spam utilisant une méthode désormais courante : le filtre de Bayes (dans une version naïve). Je vais essayer d’expliquer la théorie, et qui sait, peut-être proposer une implémentation… un peu plus tard !

Ne sacrifiez pas votre code !

Google vient d’exciter les fous-furieux de la SEO (ces gens qui veulent toujours optimiser une page web pour la faire grimper dans les résultats de recherches). Les ingénieurs de la firme ont annoncé qu’à partir de maintenant, l’algorithme de calcul de pertinence, choisissant l’ordre dans lequel les résultats sont affichés, allait tenir compte de la “vitesse de la page”. Tout de suite, tout le monde s’emballe, on annonce tout et surtout n’importe quoi. Faisons un peu de tri…

Nouveaux brouillons pour HTML 5 publiés par le W3C

Le W3C, organisme de définition et de normalisation des langages qui font le web, a publié aujourd’hui sept documents sur HTML 5.

Ceux-ci sont toujours à l’état de “brouillons” (drafts), qui ont pour objectif, notamment, de permettre aux navigateurs de se préparer à implémenter les nouvelles fonctionnalités et de recueillir des commentaires de la part des contributeurs/utilisateurs.

Les principaux documents sont le brouillon de la spécification HTML 5, les différences entre HTML 4 et HTML 5, ou encore le document de spécification du langage HTML, se voulant être la référence du langage pour les intégrateurs souhaitant se conformer aux standards HTML. Contrairement à la spécification HTML 5, celui-ci ne vise pas a détailler le comportement prévu des navigateurs vis à vis des balises.

On apprend également que les canevas 2D et micro-données, jusqu’alors intégrés à HTML 5 ont maintenant leurs propres spécifications :

Enfin, les deux derniers documents concernent l’intégration du framework RDF en HTML 5 et la réalisation de pages bi-directionnelles (dont le texte va de gauche à droite et droite à gauche).

L’information vient bien sûr du W3C.