DerekSagan a écrit 609 commentaires

L'objet de mon commentaire est bien de parler des "tâches longues et gourmandes".

Je ne discute pas du bien fondé d'avoir un démon pour exécuter les tâches courtes et fréquentes, je trouve ça pertinent pour tous les arguments que tu développe et même probablement pour d'autres encore.

Je discute le fait d'imposer ce mode de fonctionnement aux traitements lourds, car je pense que c'est une hypothèque sur la robustesse. En effet, les traitements lourds, à un moment ou un autre du cycle de vie des applications, explosent (mémoire/gc, nombre de file descriptors, nombre de connexions base de données, etc.) donc je préfère en terme d'exploitation que quand ils explosent ils n'emportent pas leur petits copains avec eux.

Après, c'est possible dans une certaine mesure d'isoler les traitements lourds mis dans la même JVM mais d'une part c'est dur (affecter des JVM d'exec à certains modules applicatifs, dédiés certaines aux traitements légers et d'autres aux traitements lourds, voire limiter à 1 traitement lourd à la fois dans une JVM, dès que t'as des équipes de dev qui ne se parlent pas ou des versions différentes d'une même appli il faut des class loaders différents par batch, etc.) d'autre part ce n'est pas complètement possible (le nombre de file descriptors et le tas java sont globaux, même avec des class loaders différents et des gestionnaires de sécurité). Du coup la seule façon d'être tranquille c'est de dédier une JVM à un traitement lourd et la façon la plus simple de le faire c'est de lancer la JVM à chaque traitement lourd.

Ça n'empêche pas de traiter les petits/moyens traitements très répétitifs autrement, je ne cherche aucunement à dire le contraire.

Bah depuis Java 5 tu peux killer, avoir les 3 flux (in, out, err) séparément et en nio, et poller ou attendre un fils. Si t'arrives pas à faire du reporting d'avancement et du kill avec ça, c'est que t'as pas lu la doc… ;-)

En fait je n'ai pas trouvé une seule fonctionnalité du module subprocess Python qui ne soit supporté par Java 5. Ce qui n'est d'ailleurs pas bien surprenant, Python comme Java offrant grosso modo 100% des possibilités systèmes communes aux différents OS sur lesquels ils tournent, du coup à part ne pas occulter des fonctionnalités (comme le faisait Java < 5) je ne vois pas bien ce qu'ils peuvent proposer.

Surtout juste pour lancer une JVM depuis une autre JVM et savoir où elle en est (on n'est pas en train de parler de faire du calcul parallèle à la MPI/PVM avec, non plus).

une JVM qui lance une JVM heu… Par ailleurs, il est plus facile de manager un thread qu'un process en java

Je suppose que tu veux dire avant java.lang.ProcessBuilder qui a été introduit en Java 5, c'est bien ça ?

Le coût de démarrage a certes réduit, mais il n'est pas négligeable pour autant

Euh…. Tu dis pas ça sérieusement pour un batch ?

$ cat Hello.java
public class Hello {
  public static void main(String[] args) {
    System.out.println("Hello");
  }
}
$ javac Hello.java
$ time java Hello
Hello
real    0m0.137s
user    0m0.062s
sys     0m0.028s
$ java -version
java version "1.6.0_18"
OpenJDK Runtime Environment (IcedTea6 1.8.8) (fedora-51.1.8.8.fc13-i386)
OpenJDK Client VM (build 14.0-b16, mixed mode)
$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 37
model name      : Intel(R) Core(TM) i5 CPU       M 560  @ 2.67GHz
stepping        : 5
cpu MHz         : 2667.000
cache size      : 3072 KB
(...)

Oui enfin c'est juste parce que sur mainframe quand on faisait du français on faisait pas du franglais (éditer ça peut vouloir dire imprimer, mais pas modifier, justement).

Je trouve assez discutable techniquement le fait de faire tourner une JVM serveur/démon/serveur d'appli pour y faire tourner des batches lourds alors qu'il est beaucoup plus sûr techniquement de lancer une JVM pour chaque instance de batch lourd (pas de risque d'exploser le tas ou une autre ressource) et que le coût de démarrage d'une JVM en 2013 est juste ridicule (au regard d'un batch de plusieurs secondes ou plusieurs heures).

Sans parler de la souplesse que peut donner au développeur le fait d'être seul dans sa JVM (un commentateur parlait de SpringBatch plus haut, faire un batch avec SpringBatch dans une JVM dédiée c'est facile, ne pas se marcher sur les pieds quand plusieurs sont dans la JVM il faut réfléchir et se parler entre développeurs voire équipes).

Sinon bravo c'est super intéressant de gérer ce parent pauvre du monde Java qu'est le batch !

Mais vous n'y pensez-pas ? Le clavier c'est hasbeen, il faut leur apprendre à utiliser un écran tactile !

Et de moins chiant à proxifiant (ftp passif, ftp actif, toussa)

Les autres ne sont pas assez ambitieux.
Il faut pouvoir présenter en NNTP une mailbox SMTP ou en SFTP un serveur FTP ou HTTP, sinon c'est pas un reverse proxy c'est un jouet.
http://delegate.org/delegate/

(oui bon je trolle un peu c'est vrai)

arrêter de penser qu'on vie tous à Paris où il est plus simple d'avoir un boulot dans l'informatique

Tu veux dire que là, tu postes ton commentaire depuis ailleurs que Paris ?
Et t'as Internet là-bas ?
En France ? (parce que la Californie ça compte pas, même si c'est pas Paris)
T'as piraté un câble sous-marin ?
Non en fait j'y crois pas. Si tu nous postes pas un twitpic pour prouver que c'est vrai je pense que ton commentaire est un fake.

J'ai pris le boulot qu'on voulait bien me donner, à 500 km de chez moi

Et sinon, pourquoi tu viens pas à Paris au fait, puisque c'est plus simple d'avoir un boulot ?
Plutôt que de faire 500 km (elle est grande ta province, pour faire 500 bornes sans passer par Paris).

Perso j'ai rien contre les végétariens, et je n'ai qu'un seul argument pour le fait de manger des animaux, tu vas être déçu il n'est pas dans ton loto:

J'aime le goût de la viande et je compte bien continuer à en manger.

(mais accessoirement pas à tous les repas ni même tous les jours, c'est pas nécessaire ni même bon biologiquement, et j'aime bien aussi les autres aliments)

Merci à l'équipe de modération, c'était effectivement pénible à lire.

Mouaih, le lien que tu pointes (et beaucoup de règles de style du même genre) tiens plus du grammar nazi ou de l'opinion subjective que de la vraie bonne pratique de programmation objective.

Tiens d'ailleurs à deux pages de la tienne il est aussi dit qu'il ne faut jamais avoir plus de 2 "return" dans la même fonction. C'est rigolo aussi.

Eh non, car induire d'erreur c'est pas français.
:-p

C'est rigolo, mais bon c'est quand même très connu, et tous les IDE qui se respectent (y compris vim) font la coloration syntaxique en conséquence.

En plus compiler avec -Wall c'est pas hyper original non plus, voire c'est une très bonne pratique, au besoin assorti de quelques -Wno-xxx si le code a des spécificités qui rendent -Wall illisible, mais sans -Wno-comment dont je ne vois vraiment pas à quoi elle peut servir à part à rendre cette mésaventure possible.

Tu peux essayer #\ dans un makefile aussi, ça fait pareil (et les IDE le savent aussi).

Bref, c'est pas un commentaire qui influe sur le code, c'est une subtilité des priorités des tokens dans la syntaxe C, qui attire des ennuis au néophyte mal outillé.

Accessoirement appeler "commentaire" un gros ascii-art utilisant des backslash en fin de ligne reste quand même un peu osé. En tout cas c'est sûr que c'est pas un commentaire à visée documentaire.

Oui, je sais, le sujet du commentaire est de la provoc.

Mais qui n'a jamais eu à modifier un code de 10 ans dans lequel les commentaires sont trompeurs car une partie des gens qui ont modifié le code n'ont modifié que le code et pas les commentaires ?

Oui, alors qu'elle aurait été tout aussi compréhensible s'il l'avait commentée, par exemple:

grep -c pat file # compter le nombre d'occurrences de pat dans file

(désolé, pas pu résister)

Peut-être était-ce du second degré. C'est plausible, non ?

À ton service.
La réponse est ici: http://lmgtfy.com/?q=bronsoniser
De rien.

et c'est pas sain pour un croyant…

Kibana, qui me semble plus orienté tableau de bord que requêtage précis

Comme le tableau de bord est filtrable par une requête, tu tape un numéro de transaction ou n'importe quel identifiant présent dans les logs et hop t'as le joli tableau avec les camemberts et les histogrammes mais filtré avec cet identifiant, ainsi que la liste des traces correspondantes. Et dans les traces en question t'as juste à cliquer sur tel ou tel champs pour restreindre la recherche sur un critère supplémentaire.

Des outils pas fait pour requêter précisément comme ça, j'en veux bien quelques uns ;-)

Je suis en train de jouer avec logstash, c'est carrément cool pour chercher quelque chose dans whatmille fichiers sur whatmille serveurs.

Par contre… une fois qu'on a une entrée/ligne de log je vois pas du tout comment la visualiser dans son contexte = avec les entrées qui suivent et qui précédent dans le même fichier de log ou avec les entrées qui suivent et qui précèdent pour un même type de serveur.

Je dis pas que c'est pas possible, juste que je trouve pas.

Pour dire ça tu dois pas vraiment avoir développé avec Qt.

Juste 3 exemples du fait que Nokia n'a "rien fait":

• QtCreator est une vraie tuerie et un compromis assez unique sur le marché entre ergonomie productive et simplicité.

• Le travail de modularisation qui a abouti à Qt5 a rendu possible le fait qu'on soit maintenant en support Windows + MacOSX + Linux + Android + iOS. Certes ça a surtout été fait parce que Nokia avait une stratégie multi-OS sur ses téléphones qui n'a pas été payante du tout (du coup je cite pas comme un grand gain les OS Nokia en train de s'éteindre, ni Blackberry 10), mais la contribution à Qt elle reste même quand la stratégie est partie.

• QML comme le disait Albert, mais aussi ce qui a été nécessaire pour y aboutir (perso je suis pas fan QML mais je vois ce qui est venu avec), comme la fort sympathique intégration C++/Navigateur apportée par QtWebkit.

Je continue à préférer noyau plombé. ;-)

J'ai trouvé la même erreur sur ce site d'ayatollahs de passionés: http://www.additifs-alimentaires.net/E131.php

Si c'est ta source, il est possible que ce soit en partie vrai car en 2001 la Norvège est entrée dans l'EEE à défaut de l'UE et ça l'a peut-être amené à autorisé cet additif alimentaire.

Cela dit l'interdiction par les USA et le Canada d'un produit nommé "machin patenté" sent quand même la guerre commerciale. Il y aurait pas par hasard une production uniquement en Europe, genre comme la carte à puce tant que les Américains n'ont pas eu racheté Gemplus ?

(je dis ça sans avoir cherché, si c'est faux, je suis désolé pour le FUD)