Mathieu Pillard a écrit 2873 commentaires

Je n'ai pas rédigé l'annonce (hélas), et je pense qu'on s'en fout: aucun des CVs recus jusqu'a présent n'avait de photo :-)

Cela dit, quand on a une dizaine de mecs à voir pour une demi douzaine de postes, la photo sur le CV, ca permet de mieux se souvenir du mec après, en tout cas c'est l'interet que moi je vois.

Tiens, j'ai le droit aussi? Si vous êtes sur Paris, que vous voulez faire du web, utiliser les standards, du libre, bosser sous l'os de votre choix, faire du php5/mysql (ou autre d'ailleurs, qui sait, ya même des bouts en ruby et python qui trainent), le tout pour des sites très, très fortement visités, n'hésitez plus, venez chez nous: http://fr.lolix.org/search/offre/offre.php3?id=6101 (non, ni sms ni rap dans les bureaux :)

En plus pour ne rien gacher on recherche plusieurs personnes donc ya de la place pour tout le monde, et c'est plutôt pas mal payé.

Je pense, à lire les commentaires faits au moment de sa sortie, que tu pourras attendre encore longtemps, hélas (ou pas, moi je m'en fous :)

Ou meme un nokia 770...

Euh, si la police assiste a un délit et n'intervient pas, on a un plus gros problème la je crois...

Un peu hors sujet, mais on reste sur le principe de la vidéo: En france, certaines villes se targuent d'etre "sous vidéo protection". On voit des panneaux a l'entrée, des caméras partout, c'est la fête.

Bon, maintenant, une question que je me suis toujours posé en voyant ces panneaux... quelqu'un peut m'expliquer comment la caméra me protège? Si je me fais agresser, elle va aller mordre le vilain concerné avec ses petites dents en métal, et lui courir après?

Je sais pas pour cette version, mais du temps ou j'avais testé True Combat pour Q3, une balle de AK47 tu faisais pas tellement le fier... Le tout étant de toucher le mec bien sur, c'est pas si simple :-)

Je me repete, mais ca arrivera 3 fois moins si quelqu'un m'aide a sortir la nouvelle version de la toolbar :-)

Le gros probleme de la version actuelle, c'est que tout a été développé par tranches, en rajoutant au fur et a mesure, et du coup ca parse le DOM plusieurs fois et pas de manière rapide...

pango plutot non ? La variable que tu cherches est MOZ_DISABLE_PANGO=1

Tout le probleme étant que pango apporte enormément d'avantages pour les langues non occidentales...

Un bon lien pour comprendre ces histoires de rapidité d'affichage, eventuelles "distortions" dues aux bidouilles des navigateurs pour donner l'impression d'aller vite : http://webkit.org/blog/?p=66

Notez que sur ma dernière version firefox explose tout le monde :-)

La toolbar est quand meme remplie de plein de petits hacks pour supporter divers navigateurs vu qu'elle fait des choses un peu compliquées avec le DOM. M'enfin si vous voulez me moinsser et moinsser Eric pour ca, allez y hein, moi je suis juste l'auteur du truc, j'y connais rien.

1. Installe Microsoft Script Editor (il est dans Office, je sais plus si il est dispo à part)
2. Active le mode debug (Tools->Internet Options…->Advanced->Disable Script Debugging)
3. Active la notification des erreurs (Tools->Internet Options…->Advanced->Display a notification about every script error)

A partir de la, à chaque erreur JavaScript, IE devrait te filer un message à la con te proposant de debugguer l'erreur. Accepte le, et voila! C'est lourd, lent, parfois chiant à utiliser, mais ca sauve la vie en cas de problème mystique DOM/JS dans IE :-) Voir aussi:

• http://blogs.msdn.com/ie/archive/2004/10/26/247912.aspx
• http://www.svay.com/blog/index/2006/09/12/413-developpement-(...)
• http://erik.eae.net/archives/2005/07/04/21.49.50/

Notons que l'interpréteur en lui même est loin d'être ce qui pose le plus de problèmes en JavaScript. Celui des versions de développement de Safari et celui de Firefox sont les plus évolués, mais sinon chez les autres il n'y a pas de problème majeur, juste des trucs manquants, des memory leaks dans IE, et 2/3 noms de variables/méthodes réservées dans certains navigateurs.

Au passage on peut utiliser l'interpréteur de firefox à part, et pareil pour celui de safari, et encore pareil pour celui de konqueror je crois. Firefox en mode strict, avec firebug ou meme sans, ca permet de tres facilement et très rapidement identifier les problèmes, et pourvu qu'on se tienne à l'écart des quelques pièges que je cite plus haut, ca va.
J'en profite pour dire que si IE par défaut donne des messages d'erreurs completement inutiles en ne donnant meme pas la bonne ligne, on peut lui adjoindre un vrai debugger, Microsoft Script Editor, qui est chiant à utiliser mais au moins, il marche et donne la vraie ligne avec son contexte.

Pour moi, debugguer le js n'est vraiment pas ce qui pose probleme. Ce qui pose problème, c'est l'implémentation du DOM, et ca, c'est casse gueule à tester :-)

Je pertinentise.

Quelques liens:
http://www.sitepoint.com/blogs/2006/01/17/javascript-inherit(...)
http://www.crockford.com/javascript/private.html
http://dean.edwards.name/weblog/2006/03/base/

J'utilise le dernier au boulot et c'est un régal, c'est le seul "framework" que je m'autorise à utiliser (les autres sont trop lourds, trop fourre tout, etc), il est petit, léger, pratique, et ne fait que ce qu'il doit faire, et bien :-)

Je crois que c'est l'esprit de contradiction qui pousse tous ces gens à me tapper dessus, alors qu'eux même ont dû une fois au moins dans leur vie se prendre la tête avec JavaScript, que ce soit en le débuggant, ou en cherchant à le rendre compatible tout browser...

Je suis arrivé trop tard pour te taper dessus sur le contenu de ton journal, d'autres l'ont très bien fait des les premières réponses, je me contenterais donc de ton commentaire: il existe des outils pour debugguer du js, et les problèmes de compatibilité entre les navigateurs ne sont nullement dus au langage en lui même. Bref, tu te trompes de cible.

Le JavaScript, (ou EcmaScript si certains préferent, ca revient grosso modo au meme, le second étant regulierement synchro sur les avancées du premier), est loin de puer autant qu'on le dit (*). Par contre, ca nécessite de se doter des bons outils et d'avoir les bonnes compétences, comme avec tout le reste en fait. Le piège est de penser qu'on peut développer un truc complexe en js avec un éditeur de texte basique et sans bien connaitre le bousin.

(*) J'accorde le fait que le "DOM0" pue completement. Mais bon, techniquement ca ne fait pas partie du langage.

C'est jamais fiable un benchmark général :-)
Mais tu peux essayer de mesurer le temps passé dans la toolbar, c'est relativement simple. Je l'ai fait pour la nouvelle version d'ailleurs (regarde par exemple le dernier chiffre en bas de http://virgule.info/linuxfr/1.0-beta5/article_big.html - attention, ca peut prendre pas mal de temps c'est l'article le plus lourd possible :) , mais je me souviens plus si c'est pas un peu buggué, à verifier.

Marrant, sur mes tests de la nouvelle version de la toolbar, konqueror était pas utilisable vu qu'il implémentait pas plein de trucs, mais opera et firefox étaient kif kif. Par contre safari était completement a la ramasse, j'ai pas pigé pourquoi. Faudrait que je refasse des benchmarks tiens...

Tout a deja été dit lors de la depeche sur les évolutions de linuxfr: https://linuxfr.org/comments/745177,1.html

C'est vraiment pas grand chose, et j'ai encore quelques idées supplémentaires à implémenter, mais je n'ai plus le temps de le faire seul.

La derniere version se trouve ici: http://virgule.info/linuxfr/ et mes journaux sur le sujet résument la situation, ils sont trouvables sur https://linuxfr.org/~remat/ :-)

Fournis des données fiables la dessus, trouve ce qui est vraiment lent, aide à le corriger... En tout cas je n'ai pas constaté de lenteur coté JavaScript sous Linux, c'est completement kif kif.

Ici c'est la toolbar qui est en cause (je suis bien placé pour le savoir, c'est moi qui l'ai codée :), pas JavaScript ou son implémentation dans Firefox. Pour info, firefox a probablement l'une des meilleures implémentations sur le marché, et en tout cas c'est clairement la plus complete, et de loin.

Pour ce qui est de la toolbar, j'attends toujours des contributeurs pour m'aider a sortir la prochaine version, qui est 3 fois plus rapide et moins gourmande en CPU...

Je n'ai pas répondu a une remarque sur l'attitude de Daniel, je vois donc pas pourquoi tu rebondis la dessus... Je répondais a Guillaume sur ta remarque, qui est completement stupide et hors sujet (moins que cette réponse la, cela dit).

Encore une fois, on se fout du contexte: mon post se bornait à dire que, pour moi en tout cas, et quelquesoit la situation, faire un fork sans prevenir l'auteur, c'est contre productif, pas du tout dans l'esprit du libre et clairement manquer de politesse.

Exactement. Je ne suis pas tout le temps d'accord avec Daniel, mais la, franchement, en admettant qu'il n'ait effectivement pas été prévenu directement, c'est pas tres sympa. Evidemment, c'est autorisé, légal, tout ca, mais la politesse (et l'esprit du libre, tiens, justement :-) voudrait qu'on prévienne l'auteur original. Enfin bon, cette discussion revient à peu pres a chaque fork qu'on voit passer :-)

C'est justement sur l'environnement que je bloque. Le language, on cherche de toutes facons des gens opérationels dès maintenant, pas le temps de les former (même si ca ne sera pas toujours le cas, c'est pas tellement grave, on peut étendre ca a d'autres languages, de toutes facons on fait du web, entre ce qu'on connait et ce qu'on peut utiliser, ca se limite a python, php, ruby et perl :-).

En revanche, je sais toujours pas trop comment faire sur l'OS et les outils. D'un autre coté, on demande pas qu'il nous code un super truc super rapidement, juste un petit truc pour en discuter ensuite, il devrait pouvoir faire ca dans à peu pres n'importe quel environnement, et au pire faut juste installer un dual boot avec plein de trucs dessus, ca devrait couvrir la plupart des cas...

Vraiment, si quelqu'un a de l'experience sur ce genre de trucs, je suis preneur. Ou alors, un detecteur de mensonges choppé sur ebay?

Je précise que dans mon idée de test, il n'était absolumment pas question de test papier, ne serait ce que pour les raisons que tu cites (et pour plein d'autres). Non, je pensais fournir un vrai environnement de test, y compris avec une connexion internet ou alors toute la doc nécessaire en local, serveur pour tester (vu que c'est pour du ouaibe), etc.

L'entretien technique entre un ingénieur et un candidat, le probleme que j'ai avec ca, c'est ce que je disais: comment peut on vraiment s'assurer des compétences du gars? On peut lui demander de parler de ses experiences, mais si ca se trouve il n'a quasimment rien fait avant et est pourtant tres qualifié... Et je ne veux pas non plus qu'on tombe dans ce que tu dis, le mec qui bloque ou qui sait pas trop quoi dire, alors qu'il est compétent... A mon avis un test simple sur machine + discussion ensuite permettrait de résoudre ce probleme.

Je deteste les tests à l'embauche... Mais comment s'assurer des compétences de quelqu'un, autrement? Honnetement, pour avoir assisté a plusieurs entretiens dans ma boite, et aussi vu le résultat de certaines embauches ici ou ailleurs avec juste le CV et le feeling, je me demande si ca serait pas mieux.

On y réfléchit de loin en ce moment parceque on doit embaucher plusieurs personnes, je ne parle pas d'un quiz a la con qui demanderait de connaitre un language par coeur, non, un tout petit truc qui mettrait en pratique quelques concepts de base, notamment en sécu par exemple. L'idée serait d'en discuter ensuite avec le candidat pour voir un peu comment il code, si il a les bons reflexes, etc. Si quelqu'un a une meilleure solution, ca m'interesse...