On peut évidemment faire sans :-)
En fait je crois que j'étais en train de réfléchir tout haut, mais rétrospectivement ça n'est pas aussi intéressant que je le pensais ce matin...
L'intérêt serait entre autre de se passer de sessions : on fonctionne de façon "stateless", ce qui facilite la répartition de charge par exemple.
...
Mouais bof, pas très convaincant comme argument.
Pfff je suis déçu je croyais avoir trouvé un truc intéressant. Ça m'apprendra à faire des journaux :-)
Merci pour le retour sur terre. Je retourne à l'étude !
Quelqu'un a-t-il déjà utilisé Celtx pour créer un scénario de jeux de rôles ?
Je suppose qu'il y a de nombreux points communs entre la préparation d'un film et celle d'un scénario, mais le vocabulaire employé sur le site de Celtx est un peu opaque pour le non initié que je suis :-)
Ça fait un moment déjà que je réfléchis à un outil pour aider les rôlistes, et il semble que je devrais chercher un peu plus du côté du cinéma et du théâtre...
C'est plus dangereux que ça : d'après leur page, il n'y a pas d'authentification, donc il suffit d'utiliser la même URL que toi et je me connecte avec ta non-identité.
En fait j'ai voté pour "c'est la mort de l'anonymat", mais il doit y avoir moyen de se créer autant d'identités virtuelles qu'on veut, sans liens les unes avec les autres, mais "sécurisées" (autant que les mots de passe et les serveurs OpenID le sont, bien sûr).
Ce que je trouve extrèmement dangereux, c'est les trucs à base d'empreintes digitales ou autres biométries. Avec ça, mes pitoyables tentatives de trolls me suivraient toute ma vie. Argh !
Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2
tout se passe bien. Peut-être un problème avec la version Linux ?
C'est bizarre quand même ces dates qui diffèrent. Les dev de Firefox utiliseraient des versions différentes de Gecko dans les builds Linux et Windows ?
PS: "Windows NT 5.1" => pas taper, je suis au boulot
est-ce que les performances de Ruby sont suffisantes pour de gros volumes de données ?
Aujourd'hui, il existe plusieurs implémentations de Ruby : l'interpréteur C "original" (écrit par Matz, Yukihiri Matsumoto), la machine virtuelle YARV/Ruby2, JRuby, Rubinius, ...
L'interpréteur est assez lent (un petit peu plus que Perl dans les benchmarks). YARV était environ 4 fois plus rapide il y a quelques mois pour mes scripts maison, mais est encore en développement. JRuby est une implémentation complète niveau fonctionnalités, les performances sont équivalentes à l'interprèteur C, et on peut compiler en bytecode JVM (ou utiliser le JIT, voir http://www.headius.com/jrubywiki/index.php/JRuby_Compiler pour plus d'info).
Est-ce que Ruby dispose de nombreux connecteurs ?
Si tu parles des bibliothèques d'accès aux SGBD écrites en C, c'est assez fournit ; Oracle, PostgreSQL, SQLite, ... Avec JRuby, je suppose qu'on peut utiliser JDBC, donc pas de soucis.
Est-ce possible en France de recruter des développeurs Ruby ?
Si l'on en croit http://rubyfr.org/ , ça doit exister... Il y a même une carte de France des rubyistes :-)
<publicité éhontée>Sinon ya moi :-))))</publicité éhontée>
Et surtout, est-ce qu'il y a des retombées commerciales potentielles ?
Je manque de stats sur le sujet, mais je pense que Ruby est un très bon complément au Java (via JRuby), par exemple pour des règles métier complexes et fréquemment mises-à-jour. Ce que je veux dire, c'est que c'est une solution peu utilisée, mais qui a toutes les fonctionnalités de Perl avec une syntaxe objet plutôt agréable, et qui gagnerait à être connue (Rails est l'arbre qui cache la forêt). Les perlistes ne devraient pas avoir trop de difficultés à comprendre un script Ruby (c'était un des buts du créateur du langage).
Pour résumer, je crois que si on peut le faire en Perl, on peut aussi le faire en Ruby : les langages sont assez similaires tant au niveau de l'implémentation (vitesse d'exécution) qu'en ce qui concerne les "cibles" potentielles. Après, c'est surtout une question de goûts (je trouve le Ruby plus lisible, au cas où vous ne l'auriez pas deviné ;-) )
Quand Perens a crée l'expression "open source", il l'a fait comme *synonyme* de logiciel libre mais sans la connotation (péjorative apparemment negative pour certains) politique qui lui était attachée.
Marrant, je viens de relire le Jargon File et c'est ce que j'en ai déduit aussi.
Il faut croire que vouloir éliminer la connotation négative (commercialement parlant) de "free software" n'était pas forcement une bonne idée... Z'ont qu'à parler français, on a pas cette ambiguité nous :-)
et hop la rustine qui perdure parce que "juste ça marche"
"Ok c'est moche mais promis-juré la semaine prochaine je réécris" ... qui ne l'a pas fait un jour ;-)
Mais je pensais plutôt à du code qui est nécessaire à cause d'une limitation technique de la plate-forme d'origine. Mmmmhh un exemple un peu extrême : porter une appli utilisant des fichiers plats vers une base de données ; si on porte "tel quel" un fichier -> une table, ça risque d'être un cauchemar pour le DBA (beaucoup de redondance de données, ...).
Si j'ai bien compris, le code Java est écrit par un "traducteur" Cobol vers Java. Le code généré est-il facilement maintenable ? La qualité de l'outil de traduction doit être fondamentale dans un projet comme celui-ci ; personnellement je pense que c'est un gros risque à prendre... Et puis, le Java et le COBOL sont assez différents pour qu'un bon algorithme COBOL soit parfois un mauvais algorithme Java. Le travail de refactoring doit être colossal.
Je travaille aussi sur un projet de migration mainframe -> Linux + Java/JEE (en tant que simple programmeur), mais l'approche est différente (et le nombre de lignes beaucoup plus réduit).
Nous avons profité de la nécessité de faire évoluer l'application pour effectuer le changement de plate forme. Le projet a démarré il y a trois ans, et l'échéance prévue est 2010. L'application originale était découpée en modules (très) indépendants (je vous passe les détails pénibles sur la reprise de données...). Ces modules sont réécrits un par un, et on implémente des moyens de communication entre les deux mondes.
Naturellement, c'est sur ces points de communications que les grincements des rouages se font entendre... Mais ce problème existe aussi dans la migration "automatique" décrite dans l'article.
L'avantage, c'est que nous avons une application développée dès le début pour l'architecture J2EE. En portant les fonctions un pour un de COBOL vers Java, le risque est gros de porter aussi du code servant à contourner un problème technique dans l'architecture d'origine (je ne sais pas si je me fais bien comprendre là :-)
Bref, je trouve cet article très intéressant car il parle d'un problème important mais rarement abordé dans la "communauté open-source". L'accent mis sur l'importance du "facteur humain" est très bien vu (je peux le confirmer au quotidien).
[^] # Re: euh, concrêtement ?
Posté par doupatex . En réponse au journal Éditer une ressource HTTP. Évalué à 3.
En fait je crois que j'étais en train de réfléchir tout haut, mais rétrospectivement ça n'est pas aussi intéressant que je le pensais ce matin...
L'intérêt serait entre autre de se passer de sessions : on fonctionne de façon "stateless", ce qui facilite la répartition de charge par exemple.
...
Mouais bof, pas très convaincant comme argument.
Pfff je suis déçu je croyais avoir trouvé un truc intéressant. Ça m'apprendra à faire des journaux :-)
Merci pour le retour sur terre. Je retourne à l'étude !
# grompf
Posté par doupatex . En réponse au journal Éditer une ressource HTTP. Évalué à 1.
# Utilisation pour les scénarios de jeux de rôles
Posté par doupatex . En réponse à la dépêche Celtx 1.0 : suite libre de préproduction media. Évalué à 1.
Je suppose qu'il y a de nombreux points communs entre la préparation d'un film et celle d'un scénario, mais le vocabulaire employé sur le site de Celtx est un peu opaque pour le non initié que je suis :-)
Ça fait un moment déjà que je réfléchis à un outil pour aider les rôlistes, et il semble que je devrais chercher un peu plus du côté du cinéma et du théâtre...
# Architecture matérielle
Posté par doupatex . En réponse à la dépêche Sortie de Syllable 0.6.5. Évalué à 1.
Dommage, j'aurais bien essayé :-)
[^] # Re: Pour plus de renseignements
Posté par doupatex . En réponse au sondage Linuxfr compatible OpenID ?. Évalué à 1.
En fait j'ai voté pour "c'est la mort de l'anonymat", mais il doit y avoir moyen de se créer autant d'identités virtuelles qu'on veut, sans liens les unes avec les autres, mais "sécurisées" (autant que les mots de passe et les serveurs OpenID le sont, bien sûr).
Ce que je trouve extrèmement dangereux, c'est les trucs à base d'empreintes digitales ou autres biométries. Avec ça, mes pitoyables tentatives de trolls me suivraient toute ma vie. Argh !
[^] # Re: JavaScript
Posté par doupatex . En réponse à la dépêche Matthew Szulik quitte Red Hat, tests de performance JavaScript et Valgrind 3.3.0. Évalué à 1.
Ici avec :
Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2
tout se passe bien. Peut-être un problème avec la version Linux ?
C'est bizarre quand même ces dates qui diffèrent. Les dev de Firefox utiliseraient des versions différentes de Gecko dans les builds Linux et Windows ?
PS: "Windows NT 5.1" => pas taper, je suis au boulot
[^] # Re: générer du Ruby
Posté par doupatex . En réponse à la dépêche Talend Open Studio 2.2.0. Évalué à 4.
Aujourd'hui, il existe plusieurs implémentations de Ruby : l'interpréteur C "original" (écrit par Matz, Yukihiri Matsumoto), la machine virtuelle YARV/Ruby2, JRuby, Rubinius, ...
L'interpréteur est assez lent (un petit peu plus que Perl dans les benchmarks). YARV était environ 4 fois plus rapide il y a quelques mois pour mes scripts maison, mais est encore en développement. JRuby est une implémentation complète niveau fonctionnalités, les performances sont équivalentes à l'interprèteur C, et on peut compiler en bytecode JVM (ou utiliser le JIT, voir http://www.headius.com/jrubywiki/index.php/JRuby_Compiler pour plus d'info).
Si tu parles des bibliothèques d'accès aux SGBD écrites en C, c'est assez fournit ; Oracle, PostgreSQL, SQLite, ... Avec JRuby, je suppose qu'on peut utiliser JDBC, donc pas de soucis.
Si l'on en croit http://rubyfr.org/ , ça doit exister... Il y a même une carte de France des rubyistes :-)
<publicité éhontée>Sinon ya moi :-))))</publicité éhontée>
Je manque de stats sur le sujet, mais je pense que Ruby est un très bon complément au Java (via JRuby), par exemple pour des règles métier complexes et fréquemment mises-à-jour. Ce que je veux dire, c'est que c'est une solution peu utilisée, mais qui a toutes les fonctionnalités de Perl avec une syntaxe objet plutôt agréable, et qui gagnerait à être connue (Rails est l'arbre qui cache la forêt). Les perlistes ne devraient pas avoir trop de difficultés à comprendre un script Ruby (c'était un des buts du créateur du langage).
Pour résumer, je crois que si on peut le faire en Perl, on peut aussi le faire en Ruby : les langages sont assez similaires tant au niveau de l'implémentation (vitesse d'exécution) qu'en ce qui concerne les "cibles" potentielles. Après, c'est surtout une question de goûts (je trouve le Ruby plus lisible, au cas où vous ne l'auriez pas deviné ;-) )
[^] # Re: Erreur déductive
Posté par doupatex . En réponse à la dépêche OpenSceneGraph 2.2 est disponible. Évalué à 5.
Marrant, je viens de relire le Jargon File et c'est ce que j'en ai déduit aussi.
Il faut croire que vouloir éliminer la connotation négative (commercialement parlant) de "free software" n'était pas forcement une bonne idée... Z'ont qu'à parler français, on a pas cette ambiguité nous :-)
[^] # Re: Maintenance du code Java ?
Posté par doupatex . En réponse à la dépêche Projet NACA : migration Mainframe IBM vers serveurs Intel/Linux. Évalué à 4.
"Ok c'est moche mais promis-juré la semaine prochaine je réécris" ... qui ne l'a pas fait un jour ;-)
Mais je pensais plutôt à du code qui est nécessaire à cause d'une limitation technique de la plate-forme d'origine. Mmmmhh un exemple un peu extrême : porter une appli utilisant des fichiers plats vers une base de données ; si on porte "tel quel" un fichier -> une table, ça risque d'être un cauchemar pour le DBA (beaucoup de redondance de données, ...).
# Maintenance du code Java ?
Posté par doupatex . En réponse à la dépêche Projet NACA : migration Mainframe IBM vers serveurs Intel/Linux. Évalué à 5.
Je travaille aussi sur un projet de migration mainframe -> Linux + Java/JEE (en tant que simple programmeur), mais l'approche est différente (et le nombre de lignes beaucoup plus réduit).
Nous avons profité de la nécessité de faire évoluer l'application pour effectuer le changement de plate forme. Le projet a démarré il y a trois ans, et l'échéance prévue est 2010. L'application originale était découpée en modules (très) indépendants (je vous passe les détails pénibles sur la reprise de données...). Ces modules sont réécrits un par un, et on implémente des moyens de communication entre les deux mondes.
Naturellement, c'est sur ces points de communications que les grincements des rouages se font entendre... Mais ce problème existe aussi dans la migration "automatique" décrite dans l'article.
L'avantage, c'est que nous avons une application développée dès le début pour l'architecture J2EE. En portant les fonctions un pour un de COBOL vers Java, le risque est gros de porter aussi du code servant à contourner un problème technique dans l'architecture d'origine (je ne sais pas si je me fais bien comprendre là :-)
Bref, je trouve cet article très intéressant car il parle d'un problème important mais rarement abordé dans la "communauté open-source". L'accent mis sur l'importance du "facteur humain" est très bien vu (je peux le confirmer au quotidien).
J'attends la suite avec impatience :-)