Avant hier, je pensais que Github était sur le point d’évoluer vers le Cloud IDE et j’avais tort.

Je pense toujours qu’ils le devraient mais ça ne semble en fait pas leur priorité. Leur nouveau projet, Atom, est certes plein de qualités, mais n’est finalement qu’un éditeur desktop de plus. Il ne semble pas avoir d’intégration Git particulièrement intéressante, et il ne sera pas Open Source !

Qu’est-ce qu’il nous manque ? Qu’est ce que j’aimerais là maintenant ?

Voici un scénario utilisateur correspondant à une petite correction de code sans utilisation de la ligne de commande. Je laisse de côté pour le moment les fonctions collaboratives, ainsi que les machines virtuelles pour exécuter le code.

1. Aller sur editeur.io et m’authentifier avec Github.
2. Choisir un dépôt Git que je souhaite cloner pour travailler dessus.
3. Au besoin, choisir une branche de travail en la créant éventuellement.
4. Faire mes modifications de code dans une interface aussi puissante que possible (syntaxe, autocomplétion) mais simple avant tout. Si possible, sans métaphore desktop (barre de menu), une interface web qui puisse s’utiliser convenablement en touch.
5. Relire mes modifications, les éditer et les valider (git add). Quelque chose de similaire à SourceTree ou GitX mais dans une interface web.
6. Enfin, commiter et synchroniser (git pull/push).

Il me semble que la plupart des briques existent déjà (librairies Git, Ace ou Codemirror pour l’édition). Seule la partie relecture (stage/discard hunk, stage/discard selected lines) me parait un peu challengeante.

Au premier abord, un service comme cela serait pratique pour des petites corrections sur tablette ou téléphone, mais aussi pour travailler rapidement sur des projets que l’on ne souhaite pas mettre en place sur sa propre machine.

En espérant que cela inspire quelqu’un !

Depuis quelques semaines, je réfléchis sur nos outils de développement, et j’essaie notamment d’imaginer quelle sera la prochaine (r)évolution après Git/Github.

La seule chose que je vois surpasser Github, c’est le “Cloud IDE”. L’idée est de faire en sorte de ne plus avoir besoin d’un éditeur de code desktop, ni d’un client Git, ni d’un environnement d’exécution local. Tout se passe dans le navigateur (édition et publication du code) et dans le “cloud” (exécution du code).

La chose la plus proche que j’ai vu jusqu’ici c’est Koding. C’est joli, et la machine virtuelle avec terminal dans le navigateur est top. Il y manque par contre aujourd’hui cruellement d’une intégration native de Git, et les fonctions de collaboration temps réel ne m’ont pas convaincues.

Pendant ce temps, les gens de Github ne sont pas des idiots et travaillent peut-être sur ce genre d’idée. C’est même sûr en fait, il a été révélé aujourd’hui qu’ils travaillaient sur Atom, un éditeur de code en ligne, un “Sublime Text in the browser”. Le code est open source et j’imagine tout à fait en faire mon futur éditeur.

Cependant, qu’en sera-t-il de l’intégration Git (diff, staging, commit). Et comment envisagent-ils de lier cela à un environnement capable d’exécuter le code (machine virtuelle) ? Deux fonctionnalités primordiales pour être autre chose qu’un éditeur que l’on n’utilise qu’en dépannage.

Voilà, je crois que j’ai bien réussi à me faire oublier.

C’est donc l’occasion de lancer la Saison 5 !

Suivant l’exemple de Sud Web, nous avons nous aussi décidé de créer une conférence dans la lignée de Paris Web mais près de là où l’on habite.

Parce qu’on ne parle pas correctement l’allemand, qu’on ne voit pas non plus pourquoi on céderait complètement à l’anglais, Berlin Web sera résolument une conférence 100% polyglotte, ou chacun parle la langue qu’il veut au moment qu’il veut. Nous ferons confiance à nos participants pour assurer la traduction simultanée par bouche à oreille.

Nous en profiterons également pour axer cette conférence sur les thématiques de l’internationalisation, de la localisation et de la collaboration internationale. Mais cela reste bien entendu très ouvert.

Berlin Web entends avoir son identité propre, et ne cédera à aucune mode. En particulier, pour prendre le contre pied de nos amis de Sud Web, nous pouvons d’ores et déjà annoncer que le Wifi sera disponible à Berlin Web pendant les conférences.

Enfin, parce tout le monde sait qu’à Berlin nous vivons dans des châteaux, nous aurons la chance de pouvoir accueillir la conférence dans notre salon, tout simplement. En cas de forte affluence, nous avons aussi mis une option sur la Festsaal Kreuzberg.

Réservez la date, Berlin Web 2011 aura lieu les 17 et 18 septembre 2011 !

Nous nous réjouissons à l’avance de vous accueillir dans notre ville et de partager avec vous quelques bières et saucisses.

Nous attendons maintenant avec impatience vos propositions de conférence !

François, Julie et toute l’équipe de Berlin Web.

Quelques billets sont parus ces derniers jours pour rappeler pourquoi les shebang dans les URLs par défaut c’était pas terrible.

• isolani: Breaking the Web with hash-bangs
• Jeremy Keith: Going Postel
• Tim Bray: Broken Links

There is no piece of dynamic AJAXy magic that requires beating the Web to a bloody pulp with a sharp-edged hashbang. Please stop doing it.

Quelques réflexions.

L’architecture frontend du “new Twitter” est vraiment loupée non ? Et celle des ex-blogs comme Lifehacker du réseau Gawker, n’en parlons même pas ? Comment en 2011 a pu t-on décider de faire cela ?

On peut lire dans certains commentaires que nous, défenseurs du web à papa, défendons un modèle dépassé de document, alors que ces sites sont passés à un modèle applicatif. Allo ?

Heureusement, HTML5 le sauveur vient à notre secours et devrait réconcilier tout le monde avec l’history API et pushState. Ouf !

Donc Google a décidé de retirer le support h264 de son navigateur Chrome.

Et Google a aussi décide de fournir un plugin WebM pour Safari sous OS X.

Et pour IE9 sous Windows 7.

Et Microsoft a décidé de fournir un plugin h264 pour Chrome sous Windows 7.

Et pour Firefox aussi.

Et rapidement, il y aura un plugin pour jouer du h264 dans Firefox sur OS X.

Et 95% des utilisateurs seront capable de lire l’un ou l’autre des formats.

Et ne comptez pas sur les éditeurs et plate-formes pour trancher entre les deux formats.

Les deux cohabiteront, tels gif et png.

Et les grands oubliés seront comme toujours les utilisateurs d’Opera ou de Linux.

Ils ont l’habitude.

Je dirais même qu’ils aiment ça !

Désolé, mais après le fiasco OpenID, encore un billet où c’est 37 Signals qui lance un pavé dans la marre.

Au lieu de continuer à suivre l’industrie, et de coder une application iPhone pour Basecamp, ils ont décidé de tout miser sur HTML5 et de proposer à leurs clients une simple web app.

Continue reading →

OpenID est depuis quelques années déjà vu comme le système d’authentification du futur, le système qui permettra à tous les utilisateurs d’enfin s’affranchir des mots de passe.

Le seul problème, c’est qu’au delà d’un cercle fermé d’enthousiastes de technologie, personne n’y comprends rien, et la plupart des business internet ne voient pas vraiment l’intérêt de le supporter.

Ça va s’arranger avec le temps pensait-on, les interfaces utilisateurs vont s’améliorer, les utilisateurs vont être éduqués, et de plus en plus de services vont le proposer en standard.

Il n’y avait qu’à attendre …

Continue reading →

Le mot HTML5 ayant été progressivement approprié de fait par Google, Apple et consorts, le W3C a décidé de reprendre la main aujourd’hui en lançant une campagne et un logo.

Bonne idée peut-on penser, on ne peut que prédire un grand succès à cette opération, imaginant déjà le logo posé sur une multitude de pages, mettant en avant leur formidable l’avancée technologique:

Yeah !

Cependant, ce sera un succès au goût un peu amer. Le mot valise HTML5 est définitivement adoubé, et on peut désormais y mettre un peu de tout, selon le menu du jour:

The logo is a general-purpose visual identity for a broad set of open web technologies, including HTML5, CSS, SVG, WOFF, and others.

So long pour la clarté scientifique.

On pense bien sûr à la prédiction 2011 de Mark Pilgrim:

I’m not big on predictions, but I do have one for 2011: HTML5 will continue to be popular, because anything popular will get labeled “HTML5.”

Et ensuite, on se demande comment appeler HTML5 si HTML5 ne veut plus vraiment dire HTML5.

Jeremy Keith donne quelques pistes, dans son billet Badge of shame:

The term HTML5 has, with the support of the W3C, been pushed into the linguistic sewer of buzzwordland. Instead, I will try using phrases:

• “HTML5, no really”,
• “The parts of HTML5 that are documented in the specification labelled HTML5”,
• “Actual HTML5”

But I think the term that’s going to be most accurate is:

• “HTML”

En conclusion, si HTML5 n’est plus vraiment HTML5, appelons donc HTML5 désormais HTML, et laissons le terme HTML5 à la grande famille de technologies gravitant autour de HTML5 HTML. C’est clair ?

Ce n’est pas grand chose,

Une citation, trois paragraphes, cinq liens.

Pourtant, au moment d’appuyer sur le bouton publier,

Cette sensation de crier à la face du monde,

J’existe !