Bruno Michel a écrit 3285 commentaires

<ironie>Oui, c'est sûr qu'avec un magazine distribué gratuitement, il va sûrement se faire plein de sous.</ironie>

Bonne idée, je vais tâcher de faire ça.

Dans le style magazine qui fait une compilation des meilleurs articles, j'aime bien Hacker Monthly [http://hackermonthly.com/] qui reprend les articles les mieux notés depuis Hacker News [http://news.ycombinator.com/].

Sinon, je salue l'initiative et je vais tâcher de proposer rapidement un ou deux articles.

C'est lourd ces insinuations. Je vais donc rappeler encore une fois que la position officielle est de ne pas récompenser les participants qui pompent une version pour y changer quelques lignes (pour reprendre ton expression).

> Se mettre en idle garde-t-il une connexion ouverte entre le client et le serveur ?

Oui, la connexion reste ouverte.

> N’y-a-t-il pas de risque de sur-charge à avoir un tel type de fonctionnalité ?

Ça consomme un petit peu de ressources, mais bien fait, ça reste négligeable.

> En idle comment fait le serveur pour savoir si le client est toujours en attente ou s’il est parti, y compris à cause d’un arrêt inopiné (donc sans avoir pu prévenir le serveur) ?

Il peut faire confiance à TCP pour s'occuper de ça ou envoyer de temps à autres un ping (genre une fois toutes les 10 minutes).

> Du coup les serveurs ne risquent-ils pas de placer un timeout assez réduit, forçant les clients à régulièrement notifier les serveurs de leur présence… que devient alors l’intérêt de la notification serveur→client ?

C'est relativement coûteux d'établir une connexion. Il y a d'abord le 3-way handshake de TCP, puis éventuellement l'établissement de la session SSL (dans le cas d'HTTPS ou d'IMAPS par exemple) et surtout, ça demande au serveur de retrouver le contexte associé à ce client (vérifier des crédentiels, aller chercher des informations en base de données ou dans un fichier, etc.).

> 1) Donne-moi un autre exemple alors, moi j'en vois pas.

Au hasard, recevoir les derniers messages de la tribune dans la seconde où ils sont postés.

C'est également très utile pour envoyer des notifications (penser à libnotify/growl mais sur une page web) : « Untel vous a assigné un ticket critique : "Websockets pas secures" » sur un outil de gestion de projets comme trac/redmine/retrospectiva.

Ça pourrait également servir à mettre à jour les stocks d'un produit sur un site d'ecommerce qui organiserait des ventes flash.

> Sinon, je tombe fréquemment sur l'argument "pas de typage fort => plein de bugs". Est-ce qu'il y a des études sérieuses qui montrent ce effet de cause à effet ?

Personne n'a de liens à ce sujet ? Ce serait juste une légende urbaine ?

> Toutefois tout n'est pas rose le langage est relativement jeune

Heu, c'est très relatif, D existe depuis plus de 10 ans et est presque aussi vieux que PHP ou Ruby.

> Ceci est toutefois rattrapé par une communauté proche a l'écoute

Mwais, ce n'était pas vraiment mon ressenti. Par exemple, il y a 2 bibliothèques standards en D, incompatibles entre elles.

C'est marrant cette manie dans le monde du typage statique de toujours considérer son langage comme ayant un typage fort, et celui des autres un typage mou.

Sinon, je tombe fréquemment sur l'argument "pas de typage fort => plein de bugs". Est-ce qu'il y a des études sérieuses qui montrent ce effet de cause à effet ?

Je connais des études qui montrent que le nombre de bugs est très fortement lié au nombre de lignes de code et d'autres qui montrent que l'écriture de tests permettent de réduire fortement le nombre de bugs, mais je n'ai pas trop creusé la question du typage statique fort. Est-ce qu'un lecteur de linuxFr.org aurait un lien vers une ou plusieurs études à ce sujet ?

Les goroutines sont plus proches des threads que des coroutines. En particulier, plusieurs goroutines d'un même processus peuvent s'exécuter en parallèle sur plusieurs cores.

Attention, il n'y a pas de coroutines en Go, mais des Goroutines. Ce sont une sorte de threads légers qui peuvent communiquer entre eux via des channels.

Sinon, je n'ai pas fait de LISP depuis un bout de temps, mais il me semblait qu'il n'y avait rien dans Common Lisp pour gérer la programmation concurrente. Je me trompe ?

> Ben voilà, vous allez pas retourner dans le "silence et l'inaction" non plus ?

Dans l'inaction, non. Je vais me concentrer sur le développement en Rails, il y a du boulot de ce coté là. Par contre, pour le silence, on va voir.

> Proposez les CSS au vote des moules pour que la partialité ne puisse vous être reprochée.

Ça demanderait de modifier à nouveau le règlement. Donc, non merci, je n'ai pas envie de déclencher un nouveau troll.

Oui, les règles du concours étaient incomplètes et pas très précises. On n'est pas juristes, juste des amateurs.

Oui, le concours a été lancé rapidement. On a même bossé la nuit pour pouvoir le lancer rapidement.

Comme notre temps était limité, on a préféré se concentre sur avoir des lots sympas et faciliter la vie des participants plutôt que d'avoir un règlement en béton. Et même depuis le lancement du concours, on y passe encore beaucoup de temps.

Et en retour ? Le concours n'est pas encore fini que j'ai déjà reçu des mails pour me dire que j'étais partial, des commentaires pour dire que les organisateurs sont pas foutus d'organiser un concours, des messages pas forcément très polis pour me reprocher que la documentation pour l'installation ne concerne que Debian, etc.

Alors, vous avez gagné : il n'y aura plus de concours sur LinuxFr.org avec un règlement approximatif puisqu'il n'y aura plus de concours du tout. Moi, j'en ai vraiment marre et j'imagine que les autres AMR sont tout aussi dégoutés que moi.

> Et comment sauras-tu qui a fait le travail d'origine ?

Ce n'est pas très compliqué de suivre les dépôts git, les journaux sur linuxfr.org et les commentaires. Ça va prendre du temps, mais on le fera.

> Il y a une obligation à partir de 0 en utilisant le git du concours maintenant ?

Non, pas forcément. J'imagine très bien qu'une personne puisse vouloir partir de ta CSS maintenant que tu as abandonné et te propose de monter une équipe. Celui lui permet de ne pas partir de 0 et tu n'es pas lésé.

> C'est quoi le travail important ?

C'est effectivement le point sensible de mon argumentaire. Ça dépendra de l'humeur des modérateurs. Mais si tu as une proposition, je veux bien l'entendre.

> Alors je-ne-sais-plus-qui avait raison, pas besoin de savoir faire quoique se soit pour ce concours, faut juste attendre que les bons pigeons fassent le travail.

Encore une fois : NON. Reprendre le travail d'un autre et ne modifier que 2 ou 3 lignes ne permet pas de gagner. C'est la personne qui a fait le travail important à l'origine qui gagne le prix dans ce cas.

> Non mais là, c'est vraiment de la mauvaise foi, faire exprès de ne pas comprendre.

Il y a effectivement pas mal de mauvaise foi sur pas mal de commentaires, mais visiblement, toi aussi, tu fais exprès de ne pas comprendre que le concours ne permet de juste prendre la CSS d'un "pigeon" pour espérer gagner un prix.

> (comme ça, une heure avant la fin, je propose une version "modifié" de la CSS de l'auteur du journal et comme je suis le seul à pas avoir boycotté, à moi la gloire et le flouze !!

Non, à lui la gloire et le flouze. Piquer une CSS ne suffit pas à gagner.

> Donc en bref, si vous participez au concours et que vous vous sentez capable de produire quelque chose d'intéressant et susceptible de gagner, gardez votre projet secret jusqu'à la fin du concours.

Non, ce n'est pas le message. Vous, participants au concours, avez le choix : vous pouvez le garder secret ou vous communiquer dessus. Si vous l'ouvrez, vous ne perdez pas vos chances de gagner. Ça vous permet d'avoir des retours d'autres personnes.

Et si quelqu'un fait 2 ou 3 petites modifications à partir de votre travail, vous gardez de biens meilleures chances de gagner que lui. Ça va demander à l'équipe des AMR de fouiller dans les dépôts git pour voir qui a fait quoi, mais nous ferons attention à ne pas léser un auteur de CSS.

> Le 29 décembre, je vais pomper tout les thèmes, je vais passer 24h non-stop dessus pour apporter ma touche. Je vais en parler à des amis pour qu'ils fassent la même chose. Et croyez-moi, on peut changer la gueule d'une feuille de style de 30ko rapidement.

Si vous voulez... mais bon, je doute fort que vous gagniez avec cette méthode.

L'équipe des AMR essaye de faire ça avec du bon sens. On ne va pas récompenser une personne qui aura juste modifier 2 lignes de CSS.

Le concours impose une licence libre pour les CSS. on peut donc copier sur son voisin pour participer au concours, ça n'a rien de choquant de reprendre ce que d'autres ont fait dans le Libre.

Maintenant, ça ne veut pas dire que "piquer les sources du voisin, enlever son nom de la CSS, ajouter 2 ou 3 petits trucs" est la recette magique pour gagner. L'équipe des AMR de LinuxFr.org e va sûrement pas récompenser une feuille de style faite de cette façon.

Plus généralement, la question du concours avec les sources publiques a été débutée entre AMR juste avant le lancement du concours, avec des partisans des 2 cotés. Baud123 souhaitait privilégier un développement, d'autres trouvaient qu'un concours ne se prête pas forcément à cela. Nous sommes arrivés à la position où l'on laisse le choix au candidat de publier ou non leurs sources. Les forges sont privées par défaut mais on encourage les participants à les ouvrir.

Et je sens que nous, équipe des AMR, allons bien nous amuser quand il va falloir récompenser les gagnants à la fin (mais bon, c'est notre problème et on l'assume).

> Qu’est-ce que ça donne quoi en terme de nombre de visiteurs la version Alpha du site?

Les stats ne sont pas encore en place, mais au vu des fichiers de logs, je dirais quelques centaines de pages vues par jour. Donc, sans google bot & co , il ne doit pas y avoir plus d'une dizaine de visiteurs par jour.

Oui, c'est prévu mais pas tout de suite. Pour le moment, la priorité est de sortir le site web.

> Pourquoi ne pas avoir gardé le style actuel, histoire de ne pas accumuler les bugs lors de la migration?

Parce que la structure HTML a changé.

Je pense que je n'arriverais pas à te convaincre et inversement.

Pour moi, la réponse à ton problème de fiabilité du code est l'écriture de tests. J'aurais tendance à voir le typage statique comme une forme particulière de tests, avec 2 spécificités :
- on est obligé que ces tests passent pour lancer le programme
- un effet de bord très sympathique est que cela améliore les performances.

Mais le typage statique ne remplace pas entièrement les tests. Il reste bien trop de cas d'erreurs où le typage est respecté (off-by-one, erreurs de logique, variables mal initialisées, la liste est longue).

> est-ce qu'on a déjà une proposition pour adapter la CSS par défaut ?

À ma connaissance, plusieurs personnes ont dit être intéressés par cette CSS mais personne ne s'était encore proposé pour le faire.

Ça dépend. Est-ce qu'il y a une relation d'héritage entre A et B ? Est-ce que la méthode test de A est publique ou privée ? Et celle de B ?

J'imagine que tu veux parler du cas où A et B n'ont rien à voir et où les deux méthodes test sont publiques. Dans ce cas, on fait le remplacement à la main puis on lance les tests unitaires pour vérifier que l'on n'a rien cassé.