Erwan a écrit 2844 commentaires

Ah, les erreurs, c'est pas forcément les tiennes :)

Exemple 1: les erreurs de serveurs extérieurs.
Tu fais un appel XML-RPC à un serveur qui te renvoie une page HTML pour te dire "en cours de maintenance". (ça m'est arrivé plusieurs fois avec Wordpress.com). Boum, le parser XML !

Exemple 2: les erreurs de tes collègues
Ton collègue Pierre vient te voir: "Y'a un bug dans ton module dans ton module foo". Après une heure de recherche, tu te rends compte que Pierre a appelé ton module avec un nombre négatif, alors que ça n'a de sens qu'avec des nombres positifs. Si tu avais utilisé un assert(), le programme aurait crashé simplement avec un message clair que tu as écrit à l'attention des collègues qui utilisent mal ton code.

Alors à part ça, pour le premier exemple : à Flock on a défini une classe flockIError adapté aux erreurs qui viennent du serveur. Ça nous permet de mettre un code d'erreur serveur, un message d'erreur serveur, un code d'erreur Flock (unifié entre les services), et un message d'erreur Flock. Le message d'erreur Flock est localisé, comme ça on peut le montrer à l'utilisateur ("mauvais mot de passe", "serveur indisponible", "permissions insuffisante"...).
http://lxr.flock.com/source/flock/mozilla/flock/base/common/(...)

Parallèlement à ça, on a un logger qui a différents niveaux : erreur, warning, info, debug.

Pour le deuxième exemple, l'astuce c'est de mettre tout tes assert() dans du code de préprocesseur. Comme ça quand tu développes le moindre bug provoque un crash (c'est mieux pour débugguer) mais pour les releases tu changes les options de compilation pour désactiver les assert() et les erreurs ne provoquent plus de crash.

Un peu dans cette idée, pour Flock les exceptions Javascript (Flock est principalement développé en Javascript) qui ne sont pas capturées provoquent une boite de dialogue alert(). C'est très agaçant, et ça donne envie de réparer l'exception très vite :).

Tu as raison. Même si la palourde a déjà 200 ans, et qu'il lui reste 200 ans à vivre... Bah les scientifiques n'a qu'à l'élever pendant ce temps, et se la passer de père en fils :)

Ca ne veut pas dire que les compagnies petrolieres paniquent. Ca veut dire que le prix du baril est suffisement haut pour justifier ca.

Moins il y a de petrole, plus il y a de demande, plus les prix augmentent : donc ce ne sont pas les producteurs de petrole qui vont avoir de bonnes raisons de paniquer. Ce sont les consommateurs.

Quand j'essaye de comparer un entier et une chaine de charactere, je préfère un langage qui me dit "types incompatibles" (du coup je sais que je dois convertir, et je sais comment) qu'un langage qui continue a fonctionner sans rien dire.

Le vrai problème c'est que l'erreur est humaine, mais sans message d'erreur clair pour mettre le doigt dessus et réparer, ça peut devenir un enfer.

Je connais bien l'un des deux devs de Twitter (je connais les deux en fait) et le principal problème de Rails c'est que quand tu fais un gros site web, d'une part le rendre "scalable" demande plus de boulot, et d'autre part tu dois ajouter des serveurs plus souvent qu'un site en PHP (ou en Ruby "pur").

Par exemple, (et là ça devient un peu polémique parce que Hansson affirme qu'ils ont tort et auraient pu grossir en gardant ActiveRecords) ils ont du arrêter d'utiliser ActiveRecords pour avoir une séparation claire entre un site web "stateless" et la couche de données. En gros, perdant un des principaux avantages de Rails.

Tiens, je viens de tomber sur un blog post qui illustre bien la propreté de PHP:
http://zestyping.livejournal.com/124503.html

Alors PHP, je l'utilise pour certains projets, ça a son utilité parfois, mais même quand tu programmes proprement tu peux tomber sur des aberrations qui peuvent rendent les bugs difficiles à identifier.

En l'occurrence, il n'analysent pas ma navigation. Il peuvent le faire s'ils analysent leurs logs http concernant Beacon, mais je sais qu'ils ne le font pas. Les craintes liés à Beacon sont tout-à-fait fondées; parce si j'ai de bonnes raisons de croire qu'ils ne rassemblent pas d'infos sur les personnes qui cliquent "non", rien ne le prouve. J'espère pour eux qu'ils vont corriger ça rapidement, par exemple en permettant de désactiver complètement Beacon pour les utilisateurs qui le veulent.

Concernant les infos que je donne à Facebook, en remplissant mon profile : non, ça ne me dérange pas qu'ils ciblent leurs publicités.

Ce qui se passe c'est que quand un vendeur de lecteurs MP3 dit a Facebook qu'ils veulent cibler les hommes de 25 à 30 ans qui ont dans leur profile des mots-clés qui se rapportent à des gadgets technologiques ("iPod", "Wii", "PS3", "Blackberry") il y a des chances pour que la pub arrive sur mon profile. Par contre, quand un vendeur de produits pour faire disparaître les boutons d'acné veut cibler les jeunes de 13 à 20 ans, je suis sûr de ne pas voir la pub. Et bien ça, non, franchement ça ne me dérange pas... D'autant plus qu'Adblock existe quand les pubs deviennent trop envahissantes.

À part ça, utilise NoScript si tu veux, mais si tu n'utilises pas Facebook tu n'as rien à craindre de Beacon.

Bon c'est vrai que leur Beacon c'est un peu discutable... Mais techniquement, comment tu ferais à leur place pour implémenter cette fonctionnalité ? (que je trouve très sympa, en ce qui me concerne).

Le principe, ce n'est pas "tu cliques non => les infos sont envoyées". Mais elles sont envoyées avant, justement pour pouvoir te montrer la boite de dialogue.

Quand quelqu'un fait une "action", comme acheter un livre sur Amazon :
* Il faut savoir si tu utilises Facebook ou pas
* Il faut te demander si tu veux publier l'action ou pas
Et à moins de déplacer une bonne partie de la logique sur Amazon, je ne vois pas comment faire. Mais si tu déplaces la logique sur Amazon, quelque part il faudrait qu'Amazon puisse identifier le cookie Facebook (c'est limite) et ensuite il faudrait que Facebook fasse confiance à Amazon (ou tout autre site) quand Amazon dit "oui oui, cet utilisateur a dit oui pour publier ça" (encore plus limite).

Je pense que toi (et peut-etre France 5, je sais) ne comprennent pas que Google, Facebook et les autres n'en ont rien a foutre (mais alors vraiment rien) de l'hegemonie des Etats-Unis sur le reste du monde. Ils n'ont absolument aucune raison de chercher à favoriser la CIA ou l'armee americaine.

Si tu viens dans la Silicon Valley, (d'abord viens prendre un cafe a Red Rock a Mountain View) mais ensuite regarde un peu la population qui y habite. C'est tres cosmopolite, il y a des immigrés et des étrangers partout. Ensuite la Bay Area est la zone la plus à gauche des États-Unis. C'est à San Francisco que sont nés les Hippies, et aujourd'hui il y a pas mal de Toyota Prius sur l'autoroute 101. Il y a plus d'écolos chez les geeks qu'ailleurs.

Ce que recherchent les habitants de la Silicon Valley, c'est le succès pour leur boite. Rien à foutre de l'hégémonie du pays : ce qui compte c'est de faire mieux que le concurrent... qui bien souvent est à quelques blocs de chez toi.

Alors bien sûr on s'entend bien entre employés d'entreprises différentes (pas plus tard que ce midi j'ai déjeuné avec un copain de... Facebook tiens :) mais pas au point d'aller comploter ensemble pour que les USA aient un contrôle encore plus fort sur le monde (encore une fois : on s'en fout !).

Bien sûr, pas mal de boites rassemblent des infos personnelles. Généralement, elles n'en font pas grand chose, a part les utiliser pour montrer des pubs cibles. Ben oui, faut les comprendre : espionner les citoyens pour le compte de la CIA ca rapporte pas enorme, d'autant plus que la CIA n'est pas forcement interesse par le fait que je suis fan de John Lennon et que je recommande le ptit restau francais de San Carlos. A chacun d'etre prudent sur le niveau des infos qu'il veut partager avec Facebook, ou Google, ou autre.

Alors bon... Tu peux enlever ton chapeau en papier alu.

En l'occurrence, la plupart des modèles dont j'ai entendu parler se contentent d'émettre du bruit à grosse amplitude, sur une large bande de fréquence. Simple et efficace, sauf que :
1. C'est clair que les numéros d'urgence ne passeront pas non plus
2. Ça dérègle les pacemakers et autres appareils, qui sont déjà mis à mal par les téléphones mobiles eux-même (tant pis pour papy)
3. Si les téléphones mobiles ont une quelconque influence sur notre santé, ils sont ridicules en comparaison avec les brouilleurs

J'ai bien entendu parler d'un modèle un peu plus intelligent, qui dialogue avec le téléphone en se faisant passer pour le serveur et vice-versa, mais ça m'étonnerai que ce soit le genre d'appareil qu'on trouve facilement à pas cher.

Sinon, les brouilleurs, c'est pas neuf, et si vraiment vous en voulez un profitez d'un pote passant à Tokyo parce qu'à Akihabara on en trouve à la pelle.

En tout cas, mon conseil : quand quelqu'un utilise son téléphone de façon intempestive, dites-le lui poliment. Ça vaut mieux qu'une guerre silencieuse.

Si elle parle francais et chinois (peut-être même anglais) elle est polyglotte, non ? Bon, d'accord, ça n'a rien d'exceptionnel pour une étudiante chinoise en France...

* Regarde du coté de kanjidic. C'est une dictionnaire de kanji au format texte (une entree par ligne, champs separes par des /). Ca inclut la prononciation en hiranagana. Je te conseille fortement de classer par hiragana (あ、か、さ、た、な・・・) plutot que par ordre alphabetique. Il faut savoir se debarrasser du romaji dans les premieres semaines de l'apprentissage sinon on prends de mauvaises habitudes.

* Si tu veux vraiment avoir les romaji, convertir automatiquement depuis les hiragna est facile a faire. Il y a des bibliotheques dans la plupart des langages (Ruby, Python...)

Ah tiens? Leur site web dit pas ca clairement. Je vais l'essayer alors.

En fait OpenKomodo c'est pas un IDE (contrairement a ce que dit l'annonce) c'est une plate-forme qui permet de creer des editeurs de texte (pour les developpeurs) et des IDE. C'est a la base des deux principaux produits d'ActiveState:
* KomodoEdit (gratuit mais pas libre)
* KomodoIDE (ni libre ni gratuit)

En ce qui me concerne j'utilise Komodo Edit pour développer Flock, et j'aime beaucoup, grace entre autres a:
* Mode VI (pas aussi complet que VIM, mais c'est deja ca)
* La facon tres discrete de montrer les espaces et la ligne des 80 colonnes (ca fait partie de nos regles de style et celles de Mozilla de de pas depasser 80 colonnes)
* Completion Javascript
* Montre les erreurs de warning de Javascript; y compris les "warning stricts", tels que les mots "theoriquement mots reserves mais ca marche quand meme quand on les utilise", la virgule juste avant l'acolade/crochet, les fonctions qui ne retournent pas toujours un valeur...

Justement, je voulais réagir la-dessus. Facebook n'impose pas FBML. Pour les pages "canvas" vous pouvez utiliser une iframe a la place de code FBML inclus.

FBML propose plein de tags tres pratiques tels que fb:friend-selector pour avoir une belle zone de saisie auto-complete dans les amis. Le fb:dashboard ou fb:tabs permet de creer facilement des elements de navigation qui sont homogene avec le reste de Facebook. En plus, c'est fait d'une facon respecteuse des standards puisque c'est a la base du HTML + le namespace "fb".

FBJS est un ensemble de bibliotheques Javascript qui permettent, par exemple, d'abstraire les appels AJAX ou d'ouvrir des genre de boites de dialogues HTML, toujours tres consistent avec le look&feel Facebook.

En contrepartie, il y a des limitations puisque le code est inclus dans la page; il ne faudrait pas qu'un widget puisse reecrire tous les liens de Facebook !

Donc, si vous ne voulez pas des limitations d'une page FBML, vous pouvez tout-a-faire creer une page dans une iframe au lieu de FBML. Mettre du Flash dedans, tout ce que vous voulez...

Il reste le widget sur le profile, destine aux visiteurs. La effectivement Facebook impose le FBML (encore que, ca peut etre du HTML tout bete sans tag fb:) et limite le Javascript et le Flash puisque l'un comme l'autre ne s'executent que sur une action du visiteur (un click, quoi). De plus, le code est en cache, les images sont en cache, donc quand on visite un profile Facebook tout les infos viennent de Facebook donc il n'y a ni ralentissement ni morceaux de la pages cassés ("serveur kaput!")

OpenSocial propose juste de mettre une iframe pour le profile aussi, et basta. Ca veut dire que:
* Quand je visite une page Orkut ou autre, si le gars a 10 widgets installe, d'un coup j'ai 10 iframes qui pointent vers des sites differents qui vont se charger
* Si quelqu'un a la bonne idee de mettre un widget qui lance une musique disco des que quelqu'un visite la page, je vais devoir ecouter ca
* Il va falloir que les fournisseurs de contenu soient tres vigilants pour eviter les hacks XSS

http://www.techcrunch.com/2007/11/02/first-opensocial-applic(...)

Bon voila, alors je défends beaucoup Facebook mais en fait je suis très content de OpenSocial. C'est neuf, pas tout-à-fait au point et devrait plutot s'appeller "OpenWidget", mais c'est un bon debut. C'est juste qu'aller taper sur Facebook alors que c'est eux qui ont ouvert la voie et ont implemente leur truc d'une facon fort bien faite. OpenSocial n'aurait jamais existe si la plate-forme de Facebook n'avait pas existe, ou n'avait pas eu le succes qu'elle a.

Mais vu que la base utilisée est SQLite, ne serait-il pas possible d'imaginer un partage de base entre Amarok et Songbird (voire par le biais de Mysql)?

Ça m'etonnerai! Une base de données sqlite ne peut être utilisée que par un processus à la fois. En plus, ils utilisent probablement un schema tres different.

Bref, si tu veux avoir une bibliotheque partagee, il faudrait soit avoir un processus serveur qui se charge d'abstraire la couche DB, soit avoir un des deux logiciel qui fasse office de serveur pour l'autre qui s'y connecterait (un peu comme iTunes permet aux logiciels tiers d'acceder a sa BD).

A part ça Songbird c'est des gars bien, ils font des soirées très sympa à San Francisco. Ils ont un genre de vélo d'appartement qui fait mixeur (faut pédaler pour faire tourner les lames) et ça fait de très bons milk shakes.

Et est-ce que ca tient bien la montee en charge ?

C'est-a-dire - est-ce facile d'avoir plusieurs serveurs web, plusieurs serveurs de bases de données ou est-ce que tout ca est tout melangé ?

La premiere difficulte c'est de reussir a ouvrir la boite. Un copain en ayant une (ben oui, faut bien qu'on teste notre soft multi-plateforme sous celle-ci) j'ai essaye, et pas reussi.

La seule solution, c'est du lire le tutoriel sur l'ouverture de boite sur le site de Microsoft... Eh oui.
http://windowshelp.microsoft.com/Windows/fr-FR/Help/2e680b8d(...)

Ceci me rappelle cela, tiens:
http://xkcd.com/327/

Je ne pense pas que ce soit ce genre de fonctionalites geeky qui va leur faire gagner du terrain sur Hotmail et Yahoo! mail. J'adore l'IMAP, mais je ne pense pas etre representatif de l'ensemble des utilisateurs de webmail.

Pour info, debut 2007, c'etait environ:
MSN Hotmail: 228 Millions
Yahoo! Mail: 250 Millions
Gmail: 51 Millions

Oui, Python est un tres bon langage pour faire des sites web scalables. Le probleme de la "scalability" est d'ailleurs assez different du probleme des performances.

Je disais plutot ca par rapport a des langages plus jeunes, ou moins courament utilises, ou encore certains frameworks qui permettent d'impressionner ses amis en quelques minutes mais sont difficile a faire monter en charge. Par exemple, si tu fais un site avec Rails, c'est tres sympa les active records mais le jour ou tu dois avoir plusieurs machines front-end et plusieurs machines DB, c'est nettement moins trivial a faire que si tu avais ecrit toi-meme ta couche de stockage de donnees en attaquant directement un SGDB.

Evidement il n'y a pas une seul langage magique qui sert a tout. J'aime beaucoup Python, et quand je peux l'utiliser je le fais; mais recement j'ai eu une appli Facebook a developper. J'aurais pu utiliser Python mais la seule bibliotheque Facebook en Python est non-officielle, incomplete et pas vraiment maintenue. Alors j'ai choisi en PHP, langage de la bibliotheque officielle et qui est reference dans toutes leurs docs. Ben oui, Facebook est ecrit en Python alors ils sont capables d'ecrire une bonne bibliotheque!

Tout ca pour dire que quand on demarre un projet il faut savoir regarder toutes les possibilites, et eviter de choisir le langage "qu'on aime bien" ou qui est a la mode. Pour ca il faut garder l'esprit ouvert, et ne pas se cantonner a son langage prefere.

C'est vrai que dans la pratique PHP est facile pour les debutants (pour les raisons que tu donnes), mais a mon avis c'est plus adapte pour les developpeurs qui savent ce qu'ils font.

Un debutant qui passe du temps sur PHP va attraper de tres mauvaises habitudes (genre ca marche pas, j'essaye de bidouiller ici et la et quand ca marche je suis content). Au contraire, quelqu'un d'experimente pourra se forcer a la rigueur (avec du code bien organise et des tests unitaires) et pourra profiter des avantages de PHP:
- un bon nombre de bibliotheques
- le probleme de faire passer un site PHP a l'echelle ("scalability") a ete resolu par beaucoup de gens, donc on sait comment faire.

C'est probablement pour ca que de gros sites comme Flickr, Facebook, et la plupart des sites de Yahoo sont codes en PHP.

Le principal probleme de PHP c'est que c'est pas un "langage cool", mais c'est un petit langage pas beau qui permet de faire ce qu'il y a a faire ("gets the job done").

Tout le contraire ? OK, Gecko n'est peut-etre pas ce qui se fait de plus leger mais il respecte les standards et (va) suivre le toolkit natif pour les pages web. Alors tu as faux à 2 sur 3 !

Webkit c'est très bien, mais c'est pas une raison pour cracher sur Gecko non plus.

Oui, enfin ca m'etonnerai que cette frange de la population soit en mesure de repondre a une offre d'emploi comme celle-ci, qui necessite un diplome en informatique ou des competences equivalentes.

Si c'est le cas, j'ai bien peur de devoir rester expat plus longtemps que prevu !

...c'est parce que le Ministere des Affaires Etrangeres est partiellement decentralise a Nantes.