Sécurité

Un navigateur web est un logiciel qui exécute du code auquel vous ne devez pas faire confiance. À la différence d'un logiciel que vous installez sur votre système de votre plein gré, le navigateur va télécharger des données provenant d'un serveur dont vous ne connaissez rien hormis un nom de domaine. Et un nom de domaine, ce n'est pas fiable, ça peut être facilement falsifié. Vous donnez donc autorisation à quiconque sur le réseau de placer des fichiers sur votre ordinateur et de les exécuter. C'est pourquoi les navigateurs web sont soumis à de strictes règles de sécurités. Parmi celles-ci, il est par exemple impossible pour un navigateur d'accéder au système de fichiers de l'utilisateur. Seule une intervention humaine de celui-ci peut donner un accès très limité à un seul fichier choisis exprésemment par l'utilisateur. Il est aussi impossible pour un site d'accéder à certaines données provenant d'un nom de domaine différent. Toute une batterie de règles qui permettent de surfer en toute sécurité.

Le prix de la sécurité

Toute sécurité se paye en sacrifiant une partie de sa liberté. Pour empecher l'accès à vos données aux sites web, il a été necessaire de brider l'expérience utilisateur :

• progression d'un téléversement,

• 3D, dessin vectoriel,

• requêtes entre domaines différents,

• accès aux données de l'utilisateur,

• accès à la webcam, micro…

Petit à petit, le web débride certains blocage au fur et à mesure que sont standardisés des moyens sécurisé d'y accéder. Mais c'est très récent et encore en pleine évolution.

Ouvrons les fenêtres !

Évidemment, pour rendre le web intéressant, il a fallu trouver des solutions pour débrider ces fonctionnalités sans attendre les avancées des fabricants de navigateurs, au point mort entre la fin des années 90 et la moitié des années 2000 à cause de Microsoft et de son Internet Explorer 6 abandonné après avoir tué toute concurrence. Pour cela, les webmasters (c'est comme ça qu'on appellait les développeurs web avant qu'on ne leur reconnaisse des compétences en développement) ont eu besoin d'utiliser des plugins :

• ActiveX,

• Java Web Start,

• Flash

Ces composants se présentant sous forme de plugin sont en fait des logiciels dans le logiciels. Il permettent d'éxécuter du code (différent du HTML/CSS/Javascript) à l'intérieur d'une page web. On sort donc totalement du contexte du navigateur quand on utilise ces outils. Le seul lien, c'est que les fichiers à exécuter sont téléchargés au moyen d'une connexion HTTP. Et là, c'est la fiesta ! Le serveur auquel vous êtes connectés se retrouve dans la même situtation où il prendrait le contrôle de votre machine, installerait et lancerait les logiciels de son choix, et donc aurait accès à toutes vos données.

Pour faire une anologie pas trop foireuse : vous installez une borte blindée dans votre maison. Mais comme c'est pas très pratique de devoir sortir son gros trousseau de clés et de déverrouiller les trois serrures à chaque fois que vous sortez ou entrez chez vous, vous décidez de laisser la porte fenêtre ouverte. C'est plus user friendly : on peut même rentrer les courses sans poser les sac par terre.

Mais vous vous faites cambrioler 3 fois par semaines avant de vous faire squatter votre maison.

Le futur

Les temps ont changés. L'évolution du web a été relancé par Firefox, et accéléré exponentiellement par Safari, puis Chrome. La plupart des fonctionnalités qui avaient besoin de plugins en tant que fallback dont aujourd'hui disponibles directement depuis le navigateur de façon sécurisée. Quasiment tout ce qui necessitait Flash, Java ou ActiveX est faisable aujourd'hui directement en javascript dans une page web. À condition bien sur d'utiliser un navigateur moderne (exit Internet Explorer 6, 7 ou 8). Il est donc peut être temps de fermer la porte fenêtre et de reprendre possession de vos quartiers non ?

Ouvrez les vannes !

Si vous vous rendez dans la configuration de la seedbox et que vous essayer de modifier la valeur de Limite du débit descendant (Ko/s), vous ne pourrez pas descendre en dessous de 100Kbs ni monter plus haut que 2500kbs. Pour une ligne ADSL ça ne devrait pas poser trop de problème. Cependant, avec une fibre à 100Mbs, c'est assez frustrant. Heureusement, seule l'interface est bridée. Le serveur de la freebox accepte n'importe quelle valeur qu'on lui envoie. Il suffit donc de lui envoyer une requete AJAX contenant la valeur supérieure à 2500 qu'on veut appliquer.

Voici la requête à coller dans votre console de debug de Chrome une fois loggué à votre admin :

Il faudra changer la valeur du csrf_token. Pour obtenir la bonne valeur, ouvrez votre console à l'onglet Network, filtrez par XHR, et changez un réglage (passez à 2400 par exemple). Consultez ensuite les détails de la requête qui vient d'être envoyée et dans la partie Form Data, trouvez la valeur correspondante.

Executez alors votre requete après avoir choisi la bonne valeur pour max_dl, et rechargez la page. La nouvelle valeur devrait être affichée et vos débits devrait s'envoler.

Petit disclaimer avant d'entrer dans le vif du sujet : je vais dorénavant rédiger quelques articles en français plutôt qu'en anglais. Simplement parce que je ne suis pas très à l'aise en anglais et que je perds beaucoup de temps et de flexibilité dans la rédaction, et puis aussi car il existe très peu de ressources javascript en français.

Fond ou forme

La première question à se poser quand on va choisir les technologies pour développer un site web concerne son contenu. Chaque site est composé à proportion différente de fond et de forme. Le fond, ça sera l'information affichée à l'utilisateur, le contenu du document, ce qui se lit (ou visionne) uniquement. La forme, c'est l'interface. C'est la partie du site qui permet d'intéragir avec celui-ci afin d'envoyer des commandes à un serveur ou simplement modifier le contenu.

Un blog ou un site d'actualité aura une proportion de fond bien plus élevé que de forme. On se rend sur une page d'article pour le lire. On y fait rarement d'autre type d'actions.

Au contraire, sur un backoffice tel qu'une administration de blog ou un CMS, on va utiliser le site en tant qu'interface graphique pour modifier des données sur un serveur. Ce sera cette fois la forme qui primera.

Site de contenu

Que cherche l'utilisateur qui consulte la première catégorie de site, un site de contenu ?

Il veut que le contenu s'affiche rapidement, qu'il soit accessible, lisible, récupérable. Généralement, il va très peu intéragir avec son interface. Il va naviguer dans les différents liens du site, mais c'est tout. Voici donc les points à mettre en avant :

• vitesse d'affichage du contenu

• mise en évidence du contenu

• éviter de distraire le visiteur avec une interface complexe

Site interactif

Pour le second type de site, l'utilisateur aura d'autres besoin. Il voudra une interface riche avec des éléments d'interface pratique qui lui facilite la tâche dans la manipulation de ses données, il voudra un rendu graphique agréable et ergonomique, une grande fluidité d'animation. Les points suivants seront les plus importants :

• design, images

• interface riche, visuelle, animée, adaptative

• données affichées fraiches

Servir du contenu HTML

Le gros intérêt de faire générer des pages HTML par le serveur, c'est qu'on peut très simplement faire usage d'un cache qui permet de renvoyer la page en quelques dizaines de millisecondes au lieu des centaines nécessaires lorsqu'on interroge la base de données. L'inconvénient, c'est que si on veut que le cache serve à quelquechose, il faut garder une version de la page dans un état statique pendant un temps conséquent (de plusieurs minutes à plusieurs heures). Ça ne peut donc fonctionner qu'avec des pages affichant du contenu qui ne change que très peu.

Générer du HTML sur le client

Générer le contenu depuis le client grâce à une webapp javascript a l'avantage d'accélérer les requêtes entre le client et le serveur. Les données, fraiches car non cachées, s'affichent très rapidement car le serveur n'a qu'à faire une simple requête en base de données, formatter le résultat en JSON et c'est le client qui se débrouille pour transformer ça en HTML. Le prix à payer est un chargement initial relativement long selon la taille du site qui peut décourager le visiteur de rester sur le site.

Le choix

Par ce principe, on fera le bon choix en sélectionnant une solution de génération de pages par le serveur avec un cache. On pourra par contre choisir une webapp javascript pour un backoffice pour profiter d'une interface riche tout en économisant du traffic entre le client et le serveur.

Cependant, il arrive que la distinction entre les deux types de sites ne soit pas si simple à déterminer et qu'on ait besoin d'un mix des deux mondes. C'est le cas de Twitter par exemple, dont le site est un mélange assez équilibré d'affichage de contenu et d'interface de publication et d'interaction et qui a su intelligemment profiter des deux solutions. La première page chargée est générée par le serveur et peut donc être consultée immédiament par le visiteur. La webapp est chargée dans un second temps et exécutée de façon transparente. Elle prend la main pour les requêtes suivantes, soulageant alors le serveur et améliorant l'expérience utilisateur.

C'est donc à vous de peser votre site sur cette balance avant d'affirmer quelle choix est le meilleur !

Mais où se cache la large avenue Alsace lorraine ???

C'est ce trait de un pixel là -_-

La preuve chez Apple.

Le web avec Internet Explorer 8

C'était carré, c'était des applats de couleurs, ça manquait de relief… Un peu comme Metro Modern UI finalement :o

Le web avec Internet Explorer 9

Des formes arrondies apparaissent, des ombres ajoutent un peu de relief, on sent la vie venir, c'est encourageant !

Le web avec Internet Explorer 10

Et voilà enfin les dégradés ! Nous voici enfin en 2006 !

oh wait…

IE 10 sait enfin indiquer des erreurs de script de façon précise, au caractère près ! Là où jusqu'à IE9, il se vautrait lamentablement en indiquant une erreur au caractère 1 de la ligne 1 du fichier index.html, ce qui valait de parsemer son code de console.log('kikoo 1'), console.log('kikoo 2'), etc afin de voir jusqu'où IE se plantait, et bien dorénavant, on sait immédiatement quelle est la ligne qui pose problème.

Je dois avouer que cette fonctionnalité digne d'un navigateur moderne des années 2004 m'a permis de multiplier par 10 ma productivité en terme de debug pour IE. Et évidemment, ça marche avec tous les modes de compatiblité !

Installez donc Windows 8 pour débugger sous IE ! C'est une question de santé mentale !

Hi !

We just released a very cool feature on Overblog! Repost! Yeah! You can now repost the posts you read on other blogs with only one click! Just try it!

When you are connected to Overblog, you also will see a new button on the toolbar up right.

Yesterday, I was to a javascript developers conference in Toulouse and I saw a presentation of Ember.js and Backbone.js. Two frameworks I don't know a lot about, and I can compare with Yoshioka. And all that I listened reinforced the fact that the choices I made for the architecture of my framework were not so stupid.

Ember.js

Ember.js is the new name of Sproutcore 2.0. I didn't know and it is very interesting because Sproutcore was the seed in my mind that helped me build Yoshioka. Here's the story.

In 2010, a new real MVC framework is announced, from Apple! Sproutcore. I jumped on it to discover the Grail I was waiting for. Sproutcore was made with a ruby server which live build project files to javascripts loaded on your browser. It provides a MVC pattern and a sort of ORM to communicate with the server. But the bad side was it was very very inspired from Objective-C Cocoa framework from Apple which is very difficult to comprehend. So I gave up quickly, but keeping in mind to retry it quickly.

Then, some months later, YUI3 published some MVC modules in experimental state. This modules was very easiest to use when you have habbit to work with YUI, so I started to work with it immediately. And then, I decided to apply all the great ideas I learn from Sproutcore into YUI3 MVC : live compilation, separation of template files, localizations, fixtures, etc.

Bad sides

The bad sides of this framework is the Cocoa approach and the very closed framework. It is very difficult not to walk into the path. That was the feeling I had 3 years ago and it was the same thing that told Raphaël Rougeron who was talking about Ember.js. With Yoshioka and YUI, you are free and invited to rewrite the wheel every time you need it. I love rewriting the wheel because the wheels never fit perfectly for what I want.

Another bad point is a memory leak. I used to have similar issues on Yoshioka with dynamical locales. Ember comes with a cool feature wich is able to update a variable into a template without full re-render it. It's the same behavior I chose for locales : an element (a span for Yoshioka) with an ID, and an observer which update the value of the node when the attribute of the model change. The problem is this node and observers are very difficult to clean and they are never free to be removed by garbage collector. With a workaround in the way Yoshioka locales are updated, I gain some hundred MBits of RAM. Overblog was able to occupy 600MB of RAM with a eavy use of the app. Now, it rarely jumps over 150MB. Raphaël talked about 2Go of memory on their apps.

Backbone.js

Then, Jean-Christophe Queval talk about Backbone.js. I have not a lot to say about it because Barebones is the inspiration of YUI3 MVC modules. So it must be cool :)

But as he said, Backbone is more a toolbox than a framework. YUI3 will give the same design pattern with all the foundations of their framework and all the free available modules. It would be very easier to quickly create a web app compatible with suckin'browsers.

Socket.io

Finally, Cyrille Bogaert showed us a demo of a web video game using web socket to make multi players sync their positions in a game. This demo gave me an idea for trying improving performances on Overblog. I hope I will have some time to experiment the replacement of Ajax JSON-RPC by a theorically very quicker web socket between client and server wich will directly communicate with internal API by using Thrift.

Bon, le problème, c'est que ça chauffe pas mal. Il arrive, lors de trop long transferts sur le NAS que celui s'éteigne par précaution.

VPN ou proxy ?

Beaucoup proposent de passer par un VPN pour pallier à ce problème. Mais un VPN, c'est vachement lourd et très contraignant. Il est tellement plus simple d'installer un petit squid et de le configurer en tant que proxy http. Seules les connexions http seront impactées par celui-ci au lieu du réseau dans son intégralité quand on passe par un VPN.

Installation

Je pars du principe que vous avez une Debian ou une Ubuntu parce que vous êtes des gens bien. Alors il suffit de demander à aptitude d'installer squid :

Une fois fait, il faudra allez éditer la conf située sur /etc/squid/squid.conf avec l'éditeur de votrez choix, genre vi parce que vous êtes des gens bien.

Avant de l'éditer, on va installer apache2-utils si ce n'est fait afin d'avoir la commande htpasswd qui nous sera utile pour générer un fichier d'utilisateurs.

Après avoir tapé deux fois votre mot de passe, vous vous retrouvez donc avec un fichier utilisateur prêt à l'emploi. Nous pouvons maintenant éditer le fichier de conf de squid.

Configuration

Dans la partie auth_params, ajoutez cette ligne :

auth_param basic program /usr/lib/squid/ncsa_auth /etc/squid/squid_passwd

Ça indique que l'authentification se fait à l'aide de cette commande et de ce fichier.

Dans la partie acl, ajoutez ceci :

acl ncsa_users proxy_auth REQUIRED

Ça crée une permission nommée ncsa_users et qui correspond à un utilisateur authentifié.

Pour finir, dans la partie http_access, tapez ça :

http_access allow ncsa_users

Qui dit que les connexions correspondant à la permission ncsa_users ont le droit d'accéder au proxy.

On sauvegarde et on relance squid :

Ah vous êtes sur une Debian…

Sur le client

Il ne reste plus qu'à configurer votre ordinateur pour lui dire de passer par ce proxy. Démerdez vous avec la doc de votre OS, je sais utiliser que OSX. Voir le screenshot.

Une fois fait, la première connexion http vous demandera un login/mot de passe. Il suffira de taper celui que vous avez choisi précedemment, et zou ! Allez immédiatement sur whatismyip.com et constatez qu'un proxy fait transiter vos données. Allez zou ! Sur Youtube en 1080p !!

Mais non… rien à faire… il ne réagit pas… je suppose que mes émulateurs sont pédicodé, et j'essaie GamepadCompanion, un utilitaire permettant de mapper les boutons d'un gamepad à une touche de clavier afin de le rendre compatible avec toutes les applications. Mais non… Rien de plus : "No gamepads found". J'en conclus que ça vient de Mountain Lion, fraichement installé.

Aujourd'hui, il me revient l'envie d'essayer mon gamepad : j'ai découvert que Chrome gérait l'API javascript gamepad permettant d'utiliser un gamepad dans une page web. Et en plus, la première mise à jour 10.8.1 de Mountain Lion est de sortie !

Après la mise à jour, je rebranche, je constate que ça ne fonctionne toujours pas :(

Bon… je fais quelques recherche sur Internet. Et là, stupéfaction. Sur les forum d'Apple, un mec parle d'une incompatibilité entre les gamepad et Chrome depuis ML. Et en effet, une fois Chrome quitté, le gamepad est enfin reconnu et fonctionnel.

Si vous voulez jouer sous Mountain Lion, il faudra donc quitter Chrome avant de brancher votre gamepad. Vous pourrez le relancer ensuite, le gamepad sera toujours disponible. Vivement une mise à jour de la part de Google !

C'est simple

Il suffit d'avoir un système à jour qui installe un netatalk en version 2.2. Les dernières Debian et Ubuntu la proposent. Et la subtilité se trouve dans la configuration de vos partages via le fichier /etc/netatalk/AppleVolumes.default. Il faut simplement ajouter l'option "tm" comme TimeMachine. C'est écrit dans les commentaires du fichier de conf. Mais il fallait le lire.

Et voilà ! Un serveur TimeMachine sur mon Raspberry Pi (35€) et un serveur TimeMachine sur mon serveur dédié Kimsufi (on voit pas la différence avec la fibre optique !). Me voilà bien équipé : mon Macbook Pro Retina peut se sauvegarder à la fois sur le réseau local, et sur un serveur distant. Et ça marche sur Mountain Lion !

Astuce !

Si vous n'avez pas pensé à partionner votre disque avant d'installer votre système, voici un paramètre à ajouter à votre volume Time Machine si vous souhaitez stocker d'autres fichier sur la meme partition. En effet, Time Machine va remplir la partition jusqu'à ce qu'il n'y ait plus de place disponible. La seule façon de garder quelques Go de libre pour stocker autre chose est de limiter l'espace du volume, soit en choisissant une partition dès le début, soit en limitant la taille du volume partagé dans Netatalk grace à l'option volsizelimit :

iPhoto

Contexte : j'ai une photothèque sur iPhoto assez conséquente qui date de 2002. Elle ne contenait au début que de petits clichés de compact à 2Mpx, puis petit à petit, les fichiers ont grossis. Jusqu'à ce que je me mettes à la photo pour de vrai, et que je fasse du raw, donc des fichiers pesant leur bonne dizaine de Mo chacun. iPhoto s'est retrouvé totalement inadéquat, non seulement pour traiter ces raws, mais surtout pour les stocker.

J'ai donc cherché un remplaçant. Après avoir pas mal utilisé Adobe Bridge + Camera Raw, puis rapidement LightRoom, je suis finalement tombé amoureux de Aperture. Cependant, à cette époque, l'importation de la phototèque iPhoto n'était pas aussi aisée qu'aujourd'hui, et la problématique du stockage n'était pas réglée : je voulais garder toutes mes photos sur mon laptop, mais à 10Mo la photo, c'était impossible.

Hybride

J'ai donc fonctionné pendant pas mal de temps avec les deux logiciels côte à côte. Je créais une photothèque chaque mois dans laquelle je déchargeais mon reflex. À la fin du mois, j'exportais les raws en jpeg que j'importais dans iPhoto. La photothèque Aperture était ensuite archivée sur un disque dur externe.

C'était particulièrement lourd, ça rendait difficile la recherche d'un vieux raw, et ça m'empêchait d'utiliser des fonctionnalités de Aperture telles que Visages et Lieux, heureusement présentes sur iPhoto, mais disponible uniquement après l'exportation jpeg.

Industrialisation

Puis j'ai reçu mon MacBook Pro Retina… et ses ridicules petits 256Go d'espace de stockage. Ridicule par la taille, mais pas par la puissance : SSD ! Bref. Ma photothèque iPhoto de 130Go ne me laissait que peu de place. Il fallait trouver une solution. Après quelques recherches, j'ai donc appris que Aperture était capable de transférer ses fichiers originaux (les raws) sur un volume distant, ne laissant alors dans la photothèque que les aperçus et les réglages !! Parfait !

J'ai donc choisi ma photothèque iPhoto, transféré tous les originaux sur mon NAS, puis importé chacune de mes photothèques, une par une, en prenant le soin de les transférer à leur tour. Une fois fait, je pourrais utiliser une banque Aperture pour sauvegarder l'ensemble photothèque + raw sur un disque externe.

Je me retrouve donc avec Aperture contenant toutes mes photos depuis 2002 toujours disponible sur mon laptop, tout en prenant 5 fois moins de place qu'avant, et un accès direct aux originaux quand je suis connecté à mon NAS. Même plus besoin d'aller fouiller dans l'un de mes disques de sauvegarde.

How to

Pour transférer vos originaux, sélectionner les photos concernées (pomme+A quoi ;), puis choisissez le menu Fichier > Déplacer les originaux. Ça prends pas mal de temps selon la taille des fichiers et la vitesse d'écriture sur le support de stockage. Ça doit aller plus vite quand on déplace vers un disque dur USB3. Vers mon NAS en wifi, c'est long.

Vous avez aussi la possibilité de choisir l'option Consolider les originaux si vous avez besoin de vous déplacer loin de votre sauvegarde mais que vous devez retoucher vos photos.

Dropbox propose une fonctionnalité générant une url pour chacun des fichiers que vous placez dans votre dossier public. L'idée est donc de d'indiquer à Mac OS X de générer les screenshots non pas sur le bureau mais dans un dossier situé dans la partie publique de Dropbox.

Secrets

Il est possible de modifier cet emplacement grâce à une commande cachée du système. Cette commande, ainsi que beaucoup d'autres, est disponible dans une interface graphique sous forme de panneau de préférence : Secrets (télécharger).

Après avoir installé ce prefpane, vous trouverez dans les Préférences Système un nouveau panel donnant accès à de nombreux réglages secrets.

Celui qui nous intéresse est rangé dans l'onglet "Grab" et s'appelle "Screen capture folder". Choisissez le dossier que vous avez créé dans votre dossier ~/Dropbox/Public/ et rouvrez votre session (ou redémarrez votre Mac)

Dorénavant, quand vous prendrez une capture d'écran à l'aide des raccourcis ⌘+⇧+3 ou ⌘+⇧+4, le fichier sera créé dans votre Dropbox. Il ne vous restera plus qu'à vous y rendre, cliquez droit, récupérer son adresse publique, et la donner à votre correspondant.

Deux Macs

Prenons deux Macs et un logiciel. Dans mon cas, il s'agissait de TextMate. C'est un exemple intéressant car il stocke des plugins (bundles) dans le dossier ~/Library/Application Support et que ce sont ces plugins qu'on souhaite avoir toujours synchronisé entre les différentes machines. Ainsi, si j'installes un nouveau bundle sur mon Mac au bureau, je le retrouve présent sur ma machine perso le soir en rentrant chez moi. On reproduit la synchronisation de Google Chrome, mais pour toutes les applications de votre Mac.

Liens symboliques

Dropbox est un dossier sur votre Mac qui contient une copie des documents stockés sur le nuage. Quand vous copiez ou supprimez un document dans ce dossier Dropbox, il est alors modifié sur le nuage et toutes les machines synchronisées avec votre compte mettrins à jour leur propre dossier afin de refléter le contenu de celui-ci. Partant de ce principe, l'idée est de déplacer le dossier contenant les réglages de votre application dans ce dossier Dropbox sur vos différentes machines afin qu'elles pointent sur un emplacement mis à jour en temps réel par Dropbox.

Pour cela, nous allons utiliser des liens symboliques. Ouvrons un terminal (/Application/Utilitaires/Terminal) sur la machine qui contient les paramètres que vous voulez garder et tapez les commandes suivantes :

Explications

1. On crée d'abord un dossier spécifique dans la Dropbox. On lui donne le même nom que dans la Library pour des questions de lisibilité, mais vous auriez pu l'appeller n'importe comment.

2. On se déplace dans le dossier contenant les fichiers de composants de chaque application.

3. On copie le dossier de l'application qu'on veut synchroniser (ici, TextMate, mais vous pouvez choisir n'importe quelle autre application) dans la Dropbox.

4. On supprime l'original.

5. On crée un lien symbolique du dossier situé sur la Dropbox.

Quand l'application ira chercher le fichier situé sur ~/Library/Application Support/TextMate/foo.bar, il sera redirigé de façon transparente vers /Dropbox//Application Support/TextMate/foo.bar. S'il écrit dans ce dossier, les nouveaux fichiers seront alors copiés sur le nuage.

Sur les autres machines

On fait la même chose, mais on s'abstient juste de copier le dossier original. On fait donc les étapes 1, 2, 4 et 5 uniquement.

Radical

On peut aussi faire un lien directement sur ~/Library/Application Support si on veut synchroniser toutes les applications. Cependant, vous risquez de rapidement dépasser votre quota de stockage : certaines applications stockent plusieurs Go de données dans cet emplacement.

Tabs View

Habituellement, un éditeur propose d'afficher un fichier dans un onglet. Certains permettent d'afficher deux onglets à la fois en split view. Mais dans tous les cas, on se retrouve rapidement submergés par le nombre d'onglet ouverts. Chocolat apporte une nouvelle approche très intéressante : un onglet est un groupe de fichiers actifs.

Cela signifie que quand je suis dans un onglet, je choisi un fichier dans le filesystem en double cliquant dessus, son contenu s'affiche et il apparait dans un bloc nommé "Actives". Si je double clique sur un nouveau fichier, il s'affiche à la place du précédent, mais s'empile dans le bloc des actifs. Je peux ensuite switcher de l'un à l'autre depuis cette liste. On peut voir ça comme un sous niveau d'onglets.

Split View

Le truc en plus qui justifie cette interface, ce sont les split views. Une fois que vous avez sélectionné les fichiers dont vous avez besoin pour travailler sur la user story en cours, vous pouvez donc passer de l'un à l'autre, ou, mieux, en sélectionner plusieurs grâce à la commande standard click + maj ou cmd. Les fichiers se verront alors afficher dans le même onglet, placés côte à côte.

Vous pouvez ainsi ranger vos fichiers actifs dans des onglets hermétiques. Quand vous passez d'un onglet à l'autre, vous changez vraiment d'environnement. Dans le premier, j'ai ouvert les fichiers relatif à l'interface de rédaction d'Overblog, dans le second, il faut que je fasse un debug rapide sur la timeline, j'ouvre ses fichiers sans les mélanger avec les précédents.

Web View

Je ne vais pas m'étendre sur les fonctionnalités du logiciel telle que la compatibilité avec les thèmes et bundles TextMate : elles sont très bien présentées sur leur page d'accueil et vous vous ferez un plaisir de les découvrir par vous même. Je vais juste en montrer une qui plaira à tout développeurs front comme moi qui pourront gagner quelques secondes entre chaque modification de fichier.

On a donc vu qu'on pouvait mettre plusieurs fichiers cote à coté, mais on peut aussi mettre d'autres trucs : de la documentation, ou un live preview. Le live preview est somme toute classique, mais quand on travaille sur une application MVC en javascript ou PHP, prévisualiser le fichier en cours n'a aucun intérêt. Ici, on peut changer l'url du browser afin de pointer sur l'application. On se retrouve en fait avec un browser classique (une webview webkit avec l'inspecteur accessible par le bouton i) intégré à coté du code. Ainsi, j'édite mon code, je tape cmd+S, cmd+R et la page de droite est immédiatement rechargée. J'évite un cmd+Tab + la transition d'écran quand je bosse en plein écran et la tentation de jeter un œil aux notifications Facebook ;)

Et cerise sur le gateau, si j'en crois le nom des fichiers en @2x dans les ressources de l'application, l'application est Retina ready ! Vivement que je reçoives mon MacBookPro Retina dans deux semaines !

Les mails de tous les clients de cette clé, dans le champ CC… -_-

Et bien, hop, un petit mail en reply-all pour prendre des news :

S'en sont suivis une foule de réponses des dits-clients, appuyant ma demande. Et une réponse du service clientèle de notre fournisseur dans un français de niveau 6° :

Soit ! Patientons…

Jusqu'au lendemain, où, en lisant la newsletter KGB Deals du jour, je tombe sur exactement la même offre, mot pour mot, mais vendu par une autre société sur un autre site.

S'en est suivi un mail de demande d'explication destiné à Showroom, et un mail d'avertissement destiné à KGB Deals. J'attends encore des réponses de leur part.

Pour conclure, KGB Deals ne vaut pas mieux que Groupon. Il est temps de boycotter toutes ces sociétés de vente de bons qui font du mal autant aux clients qu'aux vendeurs.

Mise à jour (13/06/2012 à 14h) : J'ai reçu une réponse de KGB Deals qui confirme avoir bien reçu mon mail…

Mise à jour (14/06/2012) : J'ai reçu ma clé !!

Serveur, client

Traditionnellement, une page web est générée par un serveur. Ce serveur contient des applications sous forme de script PHP par exemple, qui, selon l'URL demandée, construira un fichier HTML afin de l'envoyer à votre navigateur. Celui-ci se contentera d'afficher un rendu à partir des balises HTML du dit fichier et des CSS et Javascripts liés. Quand le client (vous, le visiteur) cliquera sur un lien, l'URL du navigateur changera, ce qui provoquera une requête vers le serveur indiquant que vous désirez le contenu de la page située à cette nouvelle adresse. Et ainsi, une nouvelle page est chargée, détruisant (dans la mémoire du navigateur) la précédente.

Ressources

Twitter a conçu son site web sous forme de WebApp. Beaucoup d'autres ont fait ce choix : Facebook, Google+, Deezer, Overblog… Le but est de déporter une partie du calcul des pages sur le client. Quand on regarde de plus prêt le contenu d'un site web généré par le serveur, on se rend compte qu'une énorme partie des pages sont identiques : le header, le footer, les liens de navigation… entre chaque page générée, peut etre seulement 10% du contenu diffère avec la page précédente. Cependant, 100% doit etre recalculé par le serveur. Certes, on peut économiser des ressources en utlisant un cache. Cependant, sur un backoffice où on veut avoir des données constamment rafraichies, cette solution est loin d'etre efficace.

Pendant ce temps, les clients (vous) sont dotés de machines de plus en plus performantes dont les capacités sont sous exploitées. Ce que ça signifie, c'est qu'on peut exécuter de lourds scripts Javascript sans que cela n'ait d'impact sur votre expérience utilisateur. Donc, profitons de ces ressources inexploitées en faisant construire une partie des pages web par le client.

WebApp

Quand vous chargez une première page d'une webapp, celle-ci est accompagnée de fichiers javascript qui vont construire le site web à la place du serveur. Ce javascript va constuire et assembler des morceaux d'interface et saura faire des requetes simples et rapides vers le serveur pour ne lui demander que des données unitaires à afficher. Par exemple, sur la page des derniers tweets, au lieu de demander au serveur de renvoyer 10 fois un gros pavé de tags HTML contenant le tweet, son auteur, la date formatée dans la bonne langue, les liens des retweets, le tout dans une soupe de tag suffisement complexe pour etre joliment mis en page, le serveur ne renverra qu'un objet JSON décrivant les données brute. Et la web app, le client, ira placer ces données dans les templates adéquats pour afficher le contenu dans la page web.

Dièse

C'est bien beau tout ça, mais ça ne réponds pas à la question de départ ! Ce dièse, il sert à quoi ??

Une webapp, vous l'avez compris, c'est beaucoup de javascript. C'est lourd à charger la première fois. Les fois suivantes, les fichiers sont mis dans le cache du navigateur et ne sont pas rechargés, cependant, le navigateur nécessite un peu de temps pour lire et exécuter ces scripts. Dans un fonctionnement classique comme expliqué dans la première section de cet article, nous serions dans la meme situation que si vous quittiez et relanciez Word à chaque nouveau paragraphe. Il fallait donc trouver une solution à ça !

Le but est donc de permettre à l'uilisateur de changer d'URL, donc de page web, sans recharger le navigateur. Et c'est là que le dièse entre en jeu. Le dièse est utilisé pour faire un lien interne vers une ancre de la page. Cela veut dire que si je me contente de rajouter un #quelquechose à l'URL courante (http://www.alt-i.fr/diese.html#kikoo par exemple), le navigateur ne va pas demander au serveur cette nouvelle URL, mais va se contenter de chercher dans la page courante un élément possédant un ID identique au texte situé à la droite du dièse. La webapp est capable de regarder régulièrement (toutes les 10ms par exemple) quel est l'état de l'URL courante et elle est donc capable de savoir qu'à un moment donné, le hash, de son vrai nom, donc le dièse et son texte associé, a changé, et peut ainsi exécuter une fonction particulière, comme charger une nouvelle vue à afficher au visiteur.

Si vous avez tout suivi correctement, le dièse permet donc d'indiquer à la webapp un changement de contexte sans pour autant recharger la page.

Suppression

Ok, mais… pourquoi on l'enlève alors ??

HTML5 arrive avec pléthaure d'API extrement pratiques. Parmi celles-ci vient l'API History. Cette API permet, en javascript, de changer l'URL courante sans provoquer de rechargement de la page. Et oui, ça fait exactement la meme chose que le dièse, mais de façon dédiée. Nous avons enfin une procédure conçue pour ça au lieu de devoir utiliser un workaround. Cette API permet de lire l'URL courante, de modifier celle-ci et d'envoyer un évènement quand elle change. Ansi, il suffit de modifier les liens pour que, au lieu de suivre leur adresse associée, il fasse appel à History pour lui demander de créer une entrée nouvelle dans l'historique. Un évènement est envoyé, et la webapp, avertie du changement d'URL peut exécuter le script qui va bien, demander les bonnes données au serveur et afficher la nouvelle vue sans avoir à recharger complètement la page.

Hybride

Pour finir, il faut encore expliquer pourquoi cette API History accélèrerait l'affichage des pages.

Le hash de l'URL n'est jamais envoyé au serveur. Donc quand vous demandez twitter.com/#!hadrienl ou twitter.com/#!search/alt-i, pour le serveur, la page demandée, c'est toujours twitter.com/. C'est donc toujours la même page qui est renvoyée, et c'est le javascript qui va, une fois chargé, lire le hash et aller chercher le bon contenu. Ce qui rallonge le temps nécessaire à l'affichage de la page de départ.

Avec History, les URL n'ont plus de hash. Le serveur prends donc connaissance de l'intégralité de l'URL : twitter.com/hadrienl ou twitter.com/search/alt-i. Ainsi, le serveur peut générer la page demandée, qui va s'afficher avant que le javascript de la web app ne soit chargé et exécuté. Puis celui-ci prendra la suite pour générer les pages suivantes.

TL;DR

Twitter propose donc le meilleur des deux mondes : un site web généré à la fois par le serveur et le client. C'est une gymastique très difficile mais qui tends à se démocratiser grâce aux nombreux frameworks qui apparaissent depuis quelques mois.

Le résultat

Commencons par le résultat. Quoiqu'il arrive, l'UMP ou le PS l'emportera. Meme si un challenger apparait, comme en 2002, la peur du changement poussera la majorité à écarter le nouveau venu. Ainsi, Chirac a pu l'emporter avec 80% des voix contre Le Pen, résultat totalement surréaliste qui sous entendrait que 60% des français votent UMP, et 80% à droite (j'enlève les abstentions et blancs). Non, c'est juste que notre système de scrutin binaire nous impose de voter contre un candidat. Ce n'est pas une hérésie, c'est une obligation qui fait partie des règles (très sommaires) de notre système de vote.

L'image

En ce qui concerne l'image, c'est totalement différent. Selon les bons score d'un parti, "les français" seront qualifiés différemment.

Par exemple, au premier tour 2012, 20% de voix pour le FN : "les français sont des fachos".

Si l'absention dépasse les 20%, "les français sont totalement indifférent à la politique et se foutent de l'avenir de leur pays".

Si c'est de l'extreme gauche qu'il s'agit, "les français sont des cocos !"

Comprenez bien que meme avec 40% d'absention/blancs ou d'extremes il est quasiment improbable de voir un second tour sans l'UMP ou le PS. Et comme expliqué précédemment, le second tour sera forcémment remporté par l'un de ces deux partis.

Alors où veux-je en venir ??? Simplement que ne pas voter UMPS sert à faire passer un message fort. J'ai exposé trois exemples, mais j'en ai oublié un. Le plus important mais malheureusement le moins utilisé. Le vote blanc.

Si 20% des français votaient blancs, ça ne changerait toujours rien au résultat, cependant le message qui passerait serait : "les français sont concernés par leur avenir mais leurs candidats sont nuls." Avec 20% de blancs, donc 20% de personnes se déplaçant aux urnes avec la ferme intention de dire que ce scrutin est une plaisanterie, les choses pourraient commencer à bouger.

Illustration

Premier tour 2012, 20% d'abstention, 20% de FN, 10% de FDG, et… seulement 1,5% de votes blancs ou nuls.

Sur ces abstentionnistes, on doit pouvoir estimer que plus de 80% ne sont pas anarchistes. Chez le FDG, le message est clair : il faut changer le système. Pour FN, la moitié doivent etre des votes contestataires. Si tout ce monde avait voté blanc au lieu de voter "utile" ou par "défaut", nous aurions eu 40% de blancs. Pas d'abstention !! De votes BLANC ! Pret d'un français sur deux qui se lève et va déclarer à ses hommes politique que le système est à chier !

Face à ça, si l'UMPS élu ne change rien et continue de n'écouter que les 30% (la moitié des 60% de votants restant), alors nous n'aurons plus aucune réticence à nous lever pour changer cette Ve république vieillissante, définie dans le seul but de garder les memes éllites au pouvoir.

Aujourd'hui, 7 ans plus tard, un grand jour est arrivé. Après six ans d'attente, Alt-I change enfin de moteur de blog.

Non parce que franchement… Le nouvel Overblog, il déchire grave ! Alors voilà. Fini Dotclear, fini l'auto hébergement, il est temps de commencer à manger sa propre bouffe pour chien !

Je vous présente donc Alt-i.fr, hébergé avec fierté par Overblog !

Reste plus qu'à faire un nouveau design plus actuel.

Et à recommencer à rédiger des posts.

J'ai donc pris les photos en même temps, un appareil dans chaque main, orienté de la même façon vers le sujet. Ils disposent donc de la même quantité de lumière. Première chose étrange que je remarque avant de montrer les photos, la taille des fichiers. Les photos prisent avec l'iPhone, en 5MPixel, soit 2592x1936 pèsent en moyenne 2,4Mo. Celles du Nokia, 8MPixel, 3264x2448 pèsent 1,5Mo en moyenne. Hm… Plus de pixels, moins de données ? Ça sent la bonne grosse compression ça…

Passons maintenant au comparatif photos. En haut la photo prise avec l'iPhone, en bas, celle avec le Nokia. Chacune étant liée à son originale en pleine résolution. Encore en dessous, mon commentaire sarcastique.

En miniature, la photo Nokia, plus chaude, a l'air plus agréable. Cependant, zoomez pour avoir l'originale, et admirer ce flou artistique. L'iPhone est clairement plus net, et ses couleurs plus naturelles.

Même photo en mode portrait. Mêmes remarques. Vu de loin, la photo Nokia parait plus jolie. Vu de près, elle ressemble à rien.

Photo de magnifique paysage… de mon balcon. Avec du soleil en face, manière de corser le jeu. Le Nokia s'en sort mieux : l'image est mieux contrastée est moins bruitée. Bravo. On pourra donc prendre des cités à contre jour sans aucun problème.

Voici une photo de mon radiateur qui me tient au chaud par ces temps polaires. Berk, que c'est moche sur iPhone ! Que de bruit *vomit*. Sur Nokia, c'est beau !! Bravo Nokia !!

…

…

oh wait…

OBJECTION !

Le Nokia a activé le flash… l'iPhone non… Reprenons une photo avec l'iPhone en forçant le flash !

no comment.

Vous aurait donc compris que si vous voulez prendre des photos, il ne faut surtout pas choisir ce Nokia. Vous pouvez vous contenter d'un vieil iPhone de deux ans d'âge. Et en plus vous aurez un vrai OS avec plein d'applications. Que reste-t-il à Nokia ?

PS : On me fait remarquer sur Google+ que les photos sont nettes en général avec le Lumia. En effet, je viens de prendre une photo normalement et il s'avère qu'il y'a un lag entre l'appui sur le bouton et la prise de la photo. Donc, ayant les deux appareils dans chaque main pour les tests, les deux mains étant instables, le Nokia a du flou de bougé à cause de sa lenteur, tandis que l'iPhone, plus véloce, s'en sort parfaitement bien.

Voici donc le comparatif au calme, en prenant bien la pose et en se pressant pas :

Le Nokia gagne ! Wouhou ! C'est plus net, la balance des blancs est plus naturelle, bravo ! Bon. Faudra donc veiller à ne pas bouger quand vous prenez vos photos hein ! Ne pensez même pas à prendre des scènes en mouvement !