hermenegilde a écrit 48 commentaires

Et on pourrait savoir pourquoi?

j'ai pas assez de contrôle dessus

Voilà, un problème de contrôle. Quand tu es tout seul sur ton serveur pour faire 2/3 trucs, c'est sympa. Quand tu dois déployer 500 applis sur 200 serveurs, tu t'amuses pas à faire des trucs à la main. Docker, c'est sympa dans ce cas, même si ça apporte d'autres problèmes.

Je vois bien l'intérêt d'utiliser un docker avec Apache Mesos par exemple.

Envlève ton masque, Super Premier Degré Man, on t'a reconnu!

schema dynamique, scalabilité, la percolation, les agrégations, les documents nested ou complexes, le query DSL qui semble faire plus de choses.

ça marche, mais il ne faut pas faire comme cela. L'attachment mapper n'est pas la méthode recommandé:

https://groups.google.com/forum/#!msg/elasticsearch-fr/7zmr6oG58lI/v5DYGE_4r0MJ

Ah ok, c'était dans les cookies, merci.

Pour le reste, je suis resté le plus neutre possible sans partir sur le troll (récurent) du certificat, j'enchainerai donc pas plus sur le mdp en clair.

Problème résolu (même si c'est pas super super user friendly), merci.

Tiens, c'est marrant, je m'en sers pour exactement l'inverse: rediriger le linuxfr en https vers le site en http. La conf est pas triviale, mais ça marche bien.

Il serait bien de dire pourquoi le certificat CACert n'est pas inclus dans Mozilla: http://wiki.cacert.org/InclusionStatus et https://bugzilla.mozilla.org/show_bug.cgi?id=215243#c158 . L'histoire a maintenant une dizaine d'année.

Au passage, d'autres boites comme http://www.startssl.com/ permettent d'avoir des certificats gratuits, dont l'autorité est reconnue pas Mozilla et les autres. Pourquoi continuer à rester sur CACert ?

Cela réussi bien pour Scala, qui est un joyeux mélange des deux également, même si le langage pousse fortement à préférer les solutions fonctionnelles partout où c'est possible.

Je ne sais pas si tu peux faire ça avec Kibana, qui me semble plus orienté tableau de bord que requêtage précis (comme l'est plus Graylog) dans la mine présente dans ElasticSearch.

Il va falloir sortir le curl pour lancer les requêtes à la main!

En fait, logstash est principalement développé en Ruby. Il doit tourner sur un JVM car il utilise le runtime JRuby, et il se base donc sur des libs Java (pour éviter de réinventer la roue ou pour aller plus vite).

Il est finalement assez facile d'avoir le même résultat avec un rsyslog et un Solr

le même résultat que logstash? Je demande à voir. rsyslogd est pas du tout comparable à logstash (ça a déjà carrément moins de transports in/out et de transformation possibles). Par contre, tu peux faire discuter un rsyslog avec un logstash.

Quitte à vouloir préciser, Lucene n'est pas limité au full text, c'est un moteur d'indexation et de recherche de données.

Elasticsearch peut tout à fait être vu comme un moteur nosql, après tout c'est pas comme si la définition de nosql était gravée dans le marbre.

mais j'ai perdu 7 kilos en un mois

T'as pensé à consulter un oncologue?

Il y a plein d'autres projets intéressants mais pour moi XMPP c'est :
…
- pas dépendant d'un seul acteur, du coup, donc pérennisé.

C'est juste dommage qu'en dehors de 3 projets libres, xmpp soit inutilisé. Il avait un bel avenir, des vrais supporters (enfin, google surtout), mais n'a pas eu le succès escompté.

Au final, on se retrouve avec un protocole super verbeux, du beau XML comme c'était à la mode il y a 10 ans, tout ça pour envoyer un message et une notification de présence, même les trucs les plus intéressants du proto, comme le pubsub, sont pas supportés par les clients. On a également deux utilisations bien distinctes de xmpp, la messagerie instantanée d'un côté, le machine to machine de l'autre, tout ça rendu possible par la couverture large du protocole qui du coup est complexe.

J'y croyais à mort à xmpp, j'ai encore un serveur pour usage restreint, mais l'usage baisse, sans possibilité de s2s avec google, et j'ai peu d'espoir.

XMPP est peut-être pérennisé, mais ce n'est peut-être pas forcément là le proto d'avenir tel qu'on nous le présente depuis 10 ans.

Le bot de gestion des fortunes est en cours de réécriture par claudex: https://github.com/claudex/tobyweb

Vu la vitesse de dév, un coup de main serait certainement le bienvenu.

le bot est censé trouver ça tout seul sur le net?

Super, merci!

Alors je proposerais bien un pull request pour virer le gsub dans la ligne idoine mais je me dis que s'il est là, à cet endroit, doit y avoir une raison.

Certainement pour les & dans les url, ce qui devrait être normalement supporté par les brouteurs divers et variés.

C'est beau comme un discours de Frigide Barjot.

J'ai donc de la chance d'avoir un FAI non belge qui me fourni une adresse publique ipv4.

Vive la République et vive la France.

C'est pourtant une mauvaise idée. Les environnements de développement n'ont pas les contraintes de la production, et heureusement.

Les IDE ou les environnements de dév sont souvent lourds, les moteurs de tests bouffent pas mal, et surtout, le framework ou le serveur d'appli qui tourne différencie souvent bien les environnements dév/prod (bon, php je sais pas, mais…:)

Pour RoR par exemple, les classes ne sont pas mises en cache sur le dév. Ça évite de redémarrer le serveur à chaque modif d'un fichier. Le gestionnaire de resource statiques (l'asset pipeline) est activé en dév et pas en prod (où les .js et .css doivent être pré-générés pour la prod). C'est pratique, mais ça nécessite du CPU. En Java sur les serveurs d'application, il y a le même principe.

Brider le développeur sur son environnement, c'est je pense l'emmerder un peu trop alors qu'au contraire il devrait pouvoir travailler le plus vite possible. Son but n'est pas de faire des tests de perfs sur son appli (qui ne voudraient de toutes façons rien dire par rapport à la réalité de le prod). Le "on va le faire développer sur une machine lente avec peu de mémoire" pour éviter les bugs en prod, j'y crois pas une seconde.

https://github.com/ryanb/govsgo qui fait tourner http://govsgo.com/