goeb a écrit 502 commentaires

Non, il n'est pas qualifié.
Il y a un test unitaire, mais c'est tout.

Les 3 arguments que tu donnes sont aussi vrais pour des logs texte.

parfaitement adapté au besoin : trouver ce qui nous intéresse via des options

Avec des logs texte, on peut utiliser 'grep' avec des options, ou tout autre outil mieux adapté.

performant : ça ne réécrit pas la date du jour à chaque ligne

Les logs texte ne sont pas obligés de répéter la date à chaque fois. Mais je t'accorde que c'est souvent répété afin de pouvoir 'greper' facilement.

pratique à utiliser : possibilité de "switcher" les logs, ie créer un nouveau fichier pour analyser tranquillement le précédent.

Pareil pour les logs texte.

… logs java avec leurs lignes de 3km de long

Si tes logs en binaire contiennent 3km de ligne, tu auras le même problème.

le nombre faible d'acteurs de l'internet au niveau mondial (et quand je dis internet, je parle bien du transport de bits, pas de création/hébergement de contenu).

Faible nombre d'acteurs ? Je pense qu'il y en a au moins une dizaine en France : Orange, Renater, OVH, Bouygues, SFR, etc. (je suppose qu'il y en a d'autres que je ne connais pas).
Donc en extrapolant à l'international, ça donne pas mal de fournisseurs de tuyaux.

Je me trompe peut-être. Pourrais-tu préciser ?

Si j'ai bien compris :
- les entreprises auraient le droit d’accélérer le transport de leurs contenus, tout en ralentissant ou en bloquant tous les autres
- cela entrave donc notre liberté d'information

Question : le terme "bloquant" est-il réel ou imaginaire ? Le texte mentionne-t-il vraiment le droit de "bloquer" ?

Je pense que l'article d'Avaaz dramatise. Les multiples entreprises qui possèdent les tuyaux de l'internet ne sont pas celles qui fabriquent le contenu. Il y aura donc des négociations commerciales, et même si certains contenus sont favorisés (télévision, vidéo à la demande, etc.) je ne crois pas que l'internet public en pâtira trop, car les publicités continueront de soutenir une partie gratuite de l'internet. Et finalement si notre liberté d'information dépend d'articles textuels ou de photos, ils ne seront quasiment pas ralentis dans les tuyaux, car leur taille sera ridicule en comparaison des vidéos.

Ensuite, sauf erreur de ma part, bcrypt ne protège vraiment bien que les mots de passe bien foutu. Avec une rainbow-table, 95 % des passes sont cassés pareillement.

Mais si tu veux casser un mot de passe salé, tu dois d'abord calculer ta rainbow table avec ce sel. Ça prend combien de temps de calculer une rainbow table ? Je pense que c'est long.
Donc le concept de rainbow table ne peut pas être utilisé avec les mots de passe salés unitairement (chaque mot-de-passe est salé avec un sel dédié).

Et concrètement, là, comment as-tu fait ?
Quel commentaire as-tu tapé ?

dans les deux sens, petite et grande échelle

Je ne crois pas que le sens vers la petite échelle soit concerné.
Aurais-tu un exemple ou ça serait employé dans le sens petite échelle ?

J'ai trouvé ceci :
http://dictionary.cambridge.org/dictionary/british/scalability?q=scalability

the ability of a business or system to grow larger

Donc uniquement dans le sens vers la grande échelle.

D'ailleurs en français, "passage à l'échelle", sans spécifier "grande" ni "petite", ça n'a pas de sens.

Je propose :
scalability = "possibilité de déploiement à grande échelle"

Un truc « dont le succès réside », ça veut dire que ça n'a pas d'utilité intrinsèque …

Non, l'intérêt et le succès sont deux choses différentes.
On peut avoir un truc utile, mais qui n'a pas de succès parce que mal présenté.
On peut avoir un truc inutile, mais qui a du succès parce que bien présenté (effet de mode ou de bulle).

Il y a un Hello World sur la page des downloads.
http://www.evenja.org/evenja/downloads

Je ne le trouve pas. Une recherche de "hello" dans cette page ne trouve rien.

N'y aurait-il pas un petit "Hello World!" pour illustrer le paradigme ?

Les trois meilleures explications gagneront …

Ça c'est fort : le concept est si abscons qu'on cherche encore une manière de l'expliquer ;)

ldr r0, [r0, #masuperstructure_t.champ_magique]

Ça c'est quand tu as le code source ou les symboles de debug, je suppose. Sinon, comment fait IDA ?

Précision : GTA n'est pas "Grand Theft Auto".
Mais je n'ai pas trouvé ce que ça signifie.

Comment se lance un programme Go ? Est-il structuré en ELF ? Est-il compatible avec ldconfig ? Est-ce qu'il utilise la libc ou a-t-il sa propre libc ?
Comment se fait l'interface d'un programme en Go avec des bibliothèques telles que libc ? ou d'autres bibliothèques écrites en C ?

J'ai corrigé le tri en supprimant mon implémentation en O(n² ) et en utilisant std::sort().
C'est beaucoup mieux : 0.3 seconde (au lieu des 49s).

Les 49s c'est pour trier selon status d'abord et mtime ensuite. Tous les status sont identiques, donc on fait la comparaison des status, puis des mtime. Mais maintenant que tu fais la remarque, je me rend compte que ça ne s'explique pas par un (n.log(n))² car ça devrait rester en n.log(n) tout court.

Le profiling montre que le temps est passé dans le tri, dans Issue::lessThan().
Il faudrait que je vérifie si mon heap sort est bien implémenté…

Il y a probablement des copies de std::string à optimiser…

J'ai fait un test en local avec 10055 tickets (n'ayant chacun qu'un seul message) :

• tout afficher est long, mais c'est firefox qui traine (les tests suivants sont faits en ligne de commande > /dev/null)
• une recherche textuelle (qui parcourt tous les tickets et n'en retourne que quelques uns) se fait en 70 ms
• mais si je demande tous les tickets avec tri sur 1 colonne, ça prend 4 secondes (optimisation -O2)
• et trier tous les tickets selon 2 colonnes dans le pire des cas, ça prend 49s (optimisation -O2)

J'aurai du mal à optimiser davantage le dernier cas. Je vais considérer que c'est acceptable.

Je ne me souviens plus bien… Pour les recherches textuelles, c'était assez compliqué. Les requêtes MatchSpec, compilées via je-ne-sais-plus-quelle-fonction étaient mal documentées.
Bref, je souffrais de mon manque d'expérience là-dessus, et ça m'a paru vraiment compliqué.

Comment garanti tu la cohérence des fichiers ?

Comme ceci :

• Un mutex garantit qu'un seul est écrit à la fois. Si 2 utilisateurs postent un message en même temps, on traite d'abord l'un, puis l'autre ensuite.
• Quand on écrit un fichier on garantit son intégrité comme ceci :

fopen("fichier.tmp",...);
fwrite(...);
rename("fichier.tmp", "fichier");

• Un mécanisme de réparation est prévu pour le pointeur de tête des messages (c'est relativement simple, mais pas encore fait), car s'il y a un ctrl-C ou une coupure de la machine, ça peut nécessiter de recalculer ce pointeur de tête .

Un ticket est éclaté en plusieurs fichiers : un pour chaque message.
Donc l'ajout d'un nouveau message ajoute un nouveau fichier. C'est tout.

HS : Ce serait bien de pouvoir éditer ses messages même longtemps après…

En l'état actuel on peut supprimer un message, par exemple dans le but d'en mettre une nouvelle version corrigée, avec les limitations suivantes :

• impossible de supprimer le premier commentaire d'un ticket
• seul l'auteur d'un message peut le supprimer
• impossible de le supprimer si un autre message a été rajouté en dessous
• impossible de supprimer après 10 minutes.

Je peux allonger les 10 minutes à 24h, mais je ne pense pas qu'au-delà soit raisonnable. Il faut quand même être sûr de ne pas perdre les infos en les effaçant.

et oblige à faire des allers-retours de haut en bas dans le fichier pour sa lecture

Je pense que c'est normal pour un code source. Ce n'est pas un roman. Les éditeurs (IDE) savent faciliter la navigation dans les fichiers.

méthode ? fonction ?

Pour moi méthode et fonction c'est du pareil au même. C'est aussi pareil que procédure, helper, subroutine, etc. qu'on entend dans d'autres langages.

Ok, je vais réfléchir pour tenir compte de tous ces commentaires.

Pour simplifier et concilier les remarques, je pourrais numéroter les tickets avec des nombres qui se suivent en base 16 :
1, 2, 3, …, 9, a, b, c, d, e, f, 10, 11, …

On atteindrait les 4 chiffres plus tard (4096 tickets au lieu de 1000), et l'incrémentation naturelle serait conservée.

Et lors d'un merge, si par exemple 2 tickets 123 ont été créés en parallèle, on indiquera que l'un des deux est renuméroté 124. Ça peut se faire.

As-tu essayé "Simple defects ?".

J'en ai aussi entendu parler dans GNU/Linux Magazine (je l'ai parcouru rapidement chez le marchand de journaux). Mais comme j'étais déjà avancé, je n'ai pas creusé plus. "Simple defects" a-t-il aussi un serveur web ? J'irai jeter un coup d'oeil.

ré-implémenter un serveur HTTP

Mongoose fournit la partie serveur HTTP (acceptation des requêtes) et moi je code simplement les "callbacks" qui les traitent.

Par curiosité, combien de temps as-tu mis pour développer l'application ?

10 mois pour le prototype en Erlang, qui m'a permis de structurer mes idées, et 4 mois pour le C++, au rythme de 5 à 10h par semaine (à la louche).