C'est moins lisible sorti de son contexte. Par contre à l'utilisation et dans le temps c'est beaucoup plus lisible et moins casse gueule. Même si c'est moins joli graphiquement et plus rébarbatif à lire.
Si ma fonction retourne une liste alors je déclare que ma fonction retourne une liste... Sinon c'est un objet ou un tuple. Maintenant se pose la question quelles sont les objets retournés par ma fonction. De quels types sont-ils ?
Moi plus je sais ce que je manipule, plus c'est agréable à coder même si ca demande plus de lignes "inutiles" dans des exemples triviaux. Dans la vie de tout les jours, 80% du code que je manipule n'a pas été écrit par moi. Je préfère ne pas passer ma vie à essayer de deviner ce que les fonctions que j'appelle sont censées retourner.
Alors quand on parle de Perl, qui ne déclare ni ses arguments si ses types de retour... Ca peut péter (et ca le fera) quand on changera le moindre type d'un argument ou d'un valeur de retour, quand le nombre/ordre des paramètres changera, quand le nombre/ordre des valeurs de retour changera. Vous refactorez jamais ? Vous faites jamais d'erreur dans votre code ? Vous attendez que ça pète à l'exécution pour découvrir que le code est dans un état totalement incohérent ?
Comme toujours c'est marrant sur 100 lignes de code maintenu par une personne.
> Mais ces erreurs là, je les trouve aussi en Python en lançant mon code
Bha non tu ne trouves que *certaines* de ces errreurs. En gros tout ce que tu sais c'est que ton code tourne pour le flow d'exécution que tu as pris. On se retrouve toujours avec des flows d'exécution bizarres et merdiques en prod un fois qu'il y a un crétinutilisateur à l'autre bout.
Note que même si tu avais une couverture de code à 100% ça ne prouverait rien.
Si tu tiens vraiment à ne pas builder ton projet, tu noteras que les utilisateurs d'IDE en Java (il faut être très bête pour s'en priver) se retrouvent avec exactement le même comportement que python puisque seuls les classes modifiées sont recompilées. Cela dit, tu apprends assez vite que tu as tout intérêt à *toujours* tourner ton soft dans les *mêmes* conditions que tes utilisateurs.
On pourrait aussi parler des gros refactoring en typage dynamique, c'est toujours un grand moment de joie et de sérénité. C'est assez passionnant de passer son temps à chercher des canards boiteux.
Quand tu vois ce qui arrive encore à merder en ayant formatage de code/build/packaging automatique, une grosse suite de test unitaire/fonctionnel/intégration et un build après chaque commit. Bien je me dis que soit y'a des surdoués qui ne font jamais d'erreur soit y'a un paquet de c0wb0yz...
En pyton tu passes ton temps à lancer des execs pour voir si ton truc marchouille. Quand je lance un projet java en synchrone c'est par ce que les tests ont foiré, que les logs ne disent rien et qu'il est temps de brancher un debugger. Autrement tu lances les tests fonctionnels sur une autre machines et tu bosses sur autre chose. 12 secondes de compilation (32Mo de source) pour 40 minutes de tests... Quand tu n'es qu'au stade du test unitaire sur une nouvelle classe, avec un IDE c'est exactement comme python !
Ca permet d'encrypter et de signer les archives avant de les envoyer sur le serveur distant. Tu peux utiliser rsync/ftp/scp pour envoyer les données. Et comme tout le monde n'a pas un dédié hors de prix avec 500Go de disque sous la main, il est possible d'utiliser Amazon S3 comme stockage. Et ca revient entre pas cher et vraiment pas cher selon le volume de données.
Autrement tu prends un hébergement mutualisé à pas cher avec 100Go de disque et tu fais itou en uploadant en FTP.
On part sur un mode d'exécution interprété. On exécute le bytecode dans la JVM, à chaque instruction correspond une translation sur la machine cible. Quand une instruction à été exécutée on passe à la suivante.
Si Hotspot détecte que ça en vaut le coup, alors on produit du langage machine qui correspond, à peu près, au bytecode (si ca répond à ta question ce qu'on appel assembleur ce sont des symbole mnémoniques qui seront ensuite traduit en langage machine, une suite de bits). On se passera donc de l'étape de translation pour les prochaines exécutions. On peut faire des optims assez malines grâce au fait que l'on a accès à beaucoup d'informations: stats des exécutions précédentes, proco cible etc. Dans Hotspot il y a deux compilateurs qui sont plus ou moins agressifs.
Je disais à peu près car Hotspot est capable de faire de la désoptimisation. C'est à dire qu'il se permet de générer des optimisations non sûres reposant sur des hypothèses qui peuvent devenir fausses. Si il se rend compte à l'exécution que les hypothèses qu'il avait fait deviennent erronées, alors il remplace la frame optimisée par une autre moins optimisée et c'est reparti. Il se passe la même chose si entre la première moitié et la seconde de programme les prédiction de branches changent du tout au tout.
C'est un sujet à part entière tellement les limites sont flous.
> Mais sinon, pourquoi vous voulez absolument compiler ?
Dans un contexte de langage statiquement et fortement typé, un code qui compile est un code qui peut s'exécuter (ça ne dit pas qu'il est correct). Ton code python tu n'as aucune certitude qu'il est capable de s'exécuter dans n'importe quel cas. Il faut connaître tout les flow d'exécution possibles sur le bout des doigts, toutes les variables par cœur et ne jamais faire de typo ou tu le découvrira... un jour.
Ça n'a peut être pas d'importance pour toi, mais quand tu bosses sur un projet avec une équipe ça devient vite très difficile à gérer. Ouai c'est très agréable sur des petits trucs ou si tu bosses tout seul. J'aime bien scripter en Python
Si tu passes la phase de compilation à l'exécution (ou simplement que tu es en typage dynamique) ça peut péter n'importe quand à runtime pour des milliers de raisons.
Si tout les devs qui sont passés de Java 4 à Java 5 ne reviendraient pas en arrière ce n'est pas pour les caractères de cast gagnés ou l'introduction du printf. Les codes sont beaucoup plus robustes (CAML est une merveille dans ce domaine).
> pour des raisons de performances mais dans ce cas là on n'utilise pas Java.
Il y a énormément de raisons de ne pas utiliser Java mais là non. Si tu ne mets pas des mongoliens derrières le clavier, Java à des perfs très respectables. L'assembleur produit par hotspot est vraiment de bonne qualité, et je t'invite à comparer les sorties d'hotspot (voir http://weblogs.java.net/blog/kohsuke/archive/2008/03/deep_di(...) pour savoir comment activer le mode verbose) à celles de gcc fortran ou C. Le gagnant est assez rapide à trouver. Au dessus de ça, J2SE n'est pas un veau et les performances augmentent de manière significatives à chaque release. Le tableau de Java 1.[0-2] était totalement différent.
C'est sur qu'un langage interprété tu n'as pas besoin de le compiler. Tu n'enfonces pas une porte ouverte la ?
Tu passes de la compilation au lancement de l'application comme si c'était la même chose (en python c'est le cas).
Python est effectivement un très bon langage qui à lui aussi ses contraintes... Y'a pas de miracle ce que tu gagnes en souplesse tu le perds ailleurs...
Tu préfères faire du C et te taper 300 lignes d'autoconf/automake/m4/libtools et passer le prochain mois à essayer de faire marcher le bouzin ?
On peut critiquer plein de choses, mais la ca devient vraiment ridicule... Ant c'est laid, c'est moche si on veut. Mais t'y passe une journée sur 2 ans de dev ! Lire ce code et comprendre chaque action ça m'a pas pris plus d'une minute.
C'est quoi ton environnement de dev si parfait ou tout est génial et y'a rien de chiant à faire ? Faut bien le compiler à un moment ton code, et personnellement entre ant, cmake, scons, make ou les autotools y'a rien qui me fait vraiment bander... En l'occurrence dans le fichier qu'ils donnent il n'y a pas d'information redondantes, je vois pas bien comment tu veux faire plus court. C'est juste le XML qui te gène ?
Pour les gros sites tu peux me faire confiance si je les ai cité c'est qu'ils ont au moins un portail significatif en Java. Évidement sur une grosse entreprise plusieurs technos sont utilisées selon les besoins et les équipes. Par exemple chez yahoo, flickr est en PHP (même leur système de batch asynchrone est en PHP) mais Q/R à son backend en Java.
Pour linked in, tout est en Java sauf les moteurs de graphes qui sont en C++ sur de grosses machines (le graphe prenait 12Go il y a un ou deux ans). D'ailleurs leurs présentations techniques valent généralement le coup d'œil.
Pour les 30 *hits*/secondes ce n'est vraiment pas gros.
Par exemple un Jira ( http://www.atlassian.com/software/jira/ ) dans un tomcat 6 sur une veille machine (PIV 3.6Ghz, 2Go de RAM dont seulement 512 pour tomcat) tient facilement 30 *pages*/secondes. Au niveau backend et génération de page, Jira et linuxfr doivent être assez similaire. C'est juste de la présentation de données simples en DB.
Note que la conf de tomcat est vraiment de base et pourrie pour les perfs (un max de logs), qu'il n'y a aucune optimisation que l'on pourrait faire pour linux-fr (aucun cache par exemple), que la conf de mysql est celle par défaut et que les clients HTTP attaquent directement le serveur d'appli. Bref je pense pas qu'on puisse faire plus défavorable pour un test.
Je ne dis pas que linux-fr est ridicule. Je dis qu'avec un serveur moderne il n'y a pas de gros exploit à faire tenir le tout sur une machine. De plus java n'est pas si à la ramasse que ca niveau perfs, et sa valeur ajoutée est son écosystème. Pourquoi linuxfr utilise google pour les recherche plutôt qu'un moteur interne par exemple ?
Après linuxfr est "tellement simple" (une seule source de donnée: la DB, pas d'appels à des services externes) qu'au final toutes les solutions me semblent plus ou moins équivalentes.
>>"Note aussi que faire du Java ne rend pas neuneu et ne m'empêche pas de coder dans d'autres langages."
> Je n'en doute pas. Mais par contre "Ne faire que du Java", oui, on est pas loin
Tu viens de prouver que ne faire que du java implique de ne faire que du java. Ne change rien ploum tu es un dieu.
Note: J'aime bien comment tu passes d'une critique de Java pour du dev web à Java pour des applis clientes. Et au passage Eclipse et Netbeans ont une UI dégueulasse, des boutons partout et sont totalement inutilisables ?
> L'intérêt de java est de pouvoir bien cadrer tout ce petit monde quitte a sacrifier les ressources machines.
Je ne suis pas sur que ce soit sacrifier les ressources machines dont il est question. Mais peut être plus de performances brutes contre scalabilité. Les deux sont importants mais ce n'est pas du tout la même chose. Dans tout les cas je ne suis pas convaincu que ce soit plus lourd/lent (non un contenu statique n'est pas géré par un serveur d'application mais par un CDN ou un lighthttpd, oui un niveau de cache memcached/ehcache/squid est utile et oui pas mal de choses peuvent être fait en asynchrone après la requête).
Il y a évidement un compris entre les coûts de développement, d'opérationnel, de maintenance etc. De plus LE bon choix n'existe pas. Il y a de nombreux moyens d'arriver à une archi fiable, évolutive et "cost-effective".
> besoin de l'innovation et de la motivation des développeurs c'est plutôt un frein
Je ne me sens pas freiné personnellement, c'est même une plate-forme plutôt marrante avec des outils hors du commun si on oublie le langage froid. Si tu cherches trois hackers fous pour pondre du code qu'eux seul pourront peut être maintenir dans une techno qui à un mois à la limite...
Note aussi que faire du Java ne rend pas neuneu et ne m'empêche pas de coder dans d'autres langages.
> Ce n'est pas pour rien non plus que ces même grosses boites dont tu parles utilisent aussi d'autres langages.
Évidement il n'y a pas de solution parfaite et je n'ai surtout pas dit que Java/J2EE l'était. Il faut savoir tirer parti des différentes technos selon les besoins. On peut même les combiner en fonction des besoins (linked in est un très bon exemple). Mon message était juste pour souligner que le message de ploum était encore plus idiot que tout les mecs incompétents en costards réunis...
C'est sur que le C dans une appli web est un énorme gain en sécurité et en productivité. Si on ajoute à l'écosystème extraordinairement riche de bibliothèque pour le web. Ca en fait vraiment une solution de choix.
Tu veux dire que c'est des incompétents en cravate qui ont imposés à ebay, yahoo, linked in, amazon, google, par exemple ?
Y'a un moment faut arrêter de se pignoler sur comment gagner trois lignes de codes ou utiliser les dernier modules ouinouin beta pas documenté et pas testé en prod.
La JVM, Java et J2EE sont de très bons environnements si bien utilisés. Pour les c0d3rz tu peux jouer avec Ruby, Python, Scala ou JS sur la JVM selon tes besoins. Tu n'es pas non plus obligé d'utiliser toute la stack J2EE. Par contre tu es autorisé à tirer parti des excellents frameworks qui existent.
Je dis pas que c'est adapté à linuxfr* hein. Mais si on pouvait arrêter de dire des anneries deux minutes...
* Qui n'est somme toute vraiment pas si gros que çà.
Le support des derniers nano est fonctionnel dans la version SVN (d'après les commits logs j'ai envie de dire que oui)? Si oui il serait peut être bon de faire une nouvelle release non ?
Par ce que pour le moment, fedora livre toujours la libgpod 0.6.0 sans patch pour le support des derniers nano. Du coup ton assertion "sur une distro récente ça marchera sans problème" est un peu fausse. Je viens de vérifier c'est la même chose sous debian (cf http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509672 ) et ubuntu.
Merci pour le travail que vous faites mais c'est encore mieux quand les utilisateurs peuvent en profiter. Pour un utilisateur le constat actuel est que ca ne marche PAS. Pour le moment j'ai une iBrique...
Ce n'est pas par ce que toi ca ne te gène pas que ca ne gène personne. Et sur la masse des utilisateurs je suis pas sur que les utilisateurs de flac sur du 4 ou 8GB soient vraiment majoritaires...
Avoir un player tout petit, insensible aux chocs qui permet d'embarquer 2000+ chansons c'est super pratique. Avec les 16GB tu as presque tout les avantages des lecteurs à HD et tout les avantages des petits lecteurs. Pourquoi se priver ?
Par ce que le firmware est merdique et à une limitation sur le nombre de fichiers ? Ce problème est connu depuis longtemps et n'a jamais été résolu par meizu.
La plupart des boîtes d'informatique qui sont créées n'innovent pas beaucoup, sauf peut-être dans la communication.
Peux tu étayer ta conclusion ?
Et puis leur but c'est le bénéfice, pas le chiffre d'affaire, et ça change tout.
Pas forcement. Avec un énorme CA mais un résultat d'exploitation nul, si tu vends à des particuliers l'état empoche 20% de TVA... Un des buts à long terme c'est aussi de faire rentrer de l'impots et de garder des emplois.
On peut aussi simplement publier les résultats et laisser utiliser par tout le monde...
Tu peux le faire évidement oui.
Il n'en reste pas moins que les instituts publiques poussent vers l'exploitation de ce qui est découvert par le biais de création d'entreprises à partir des équipes de recherche ou collaboration. Et ca n'a rien d'illogique ni de mal.
Comme je l'ai dit plus haut le but de la recherche financé par le public c'est de transférer les technos développées dans le privée. Les brevets sont vu comme un des moyens pour y arriver.
Quelques exemples des plus gros instituts de recherche en france:
1- CNRS
En 2004, j'ai pas de chiffre plus récents, le CNRS disposait d'un portefeuille de plus de 2000 brevets (et autant posé par des partenaires puisque les équipes sont très souvent mixtes).
Le portefeuille est plus petit que le CNRS et ne doit pas dépasser les 100. La politique est la même que le CNRS pour ce qui concerne la valorisation de la recherche.
Et on pourrait continuer avec tout les instituts. On ne finance pas la recherche pour la beauté de passer un papier dans une conf. Le but est de mettre au point des technologies/idées innovantes pour pouvoir les valoriser dans le privé ensuite. Ça passe par une étape ou on donne beaucoup d'argent à des entreprises qui se créées. Par le biais de brevet, de transfert de techno et de subvention etc. On peut aussi passer des accords avec des sociétés déjà existantes. L'espoir est que ces entreprises grossissent suffisamment pour que l'investissement initial soit plus que remboursé.
- [page 76] les 10 plus grand salaires étaient, en l'an 2000, de 94000 euros par ans (brute).
Je ne sais pas qui était payé 94 K€/an, mais ca n'a rien de déraisonnable. Si tu veux recruter des gens pointus il faut s'aligner avec les valeurs du marché. Je connais pas du tout les salaires dans ces domaines mais dans l'informatique ça n'aurait vraiment rien de choquant. 6000€/mois y'a un gros paquet d'ingénieurs qui les rentrent ! À vu de nez je dirais que le médical est plus rémunérateur...
Restons dans l'informatique, un directeur de recherche à l'INRIA en fin de carrière c'est 74 K€/an avec pas mal d'extras et d'avantages.
Après tu peux fixer les salaires à 1500€/mois, mais tu risques de pas avoir beaucoup de candidats. Qui est motivé pour diviser par 2 ou 3 son salaire ici ? Aller c'est pour sauver le monde, un peu d'entrain !
Puisque tu fais le parallèle avec l'informatique...
La recherche en info en France n'a clairement pas pour but de faire de l'open source mais de servir de vivier pour créer des sociétés pointues... Exactement comme ce que tu critiques dans le médicale ! La réussite, c'est protéger les innovations pour lancer des entreprises qui feront du CA et sauveront le PIB et feront rentrer des impôts. Bienvenue dans le monde réel, et ca ne date pas des dernières élections.
> Oui c'est ce qu'ont du se dire les gras de Bitkeeper en tentant de forcer la main.
Libre à Atlassian de choisir son business modèle. Il a été pris en compte lors du choix et on sait qu'il est possible de revenir en arrière si leur tarifs deviennent prohibitifs.
> Et pourtant des BTS java potable et libre il y en a.
Tu ne connais pas mes critères de choix pour valider les solutions. J'ai jugé que JIRA répondait le mieux à nos besoins. C'est vrai que des BTS il y en a beaucoup. J'ai posé des contraintes techniques et ergonomique. C'est mon choix, je ne dis pas que c'est LE bon choix. Je n'ai pas non plus testé tout les BTS du monde.
> As-tu essayé itracker par ex ?
Non.
Répond t'il a ma liste (partielle) de besoins:
- Intégration SVN git
- Remote API
- Role/Workflow modifiables par projet
- Notification modifiables par projet
- Possibilité d'ajouter des champs proprios (par projet)
- Tickets imbriqués
- Possibilité d'intégration dans les IDE
- Adaptable pour gérer des itération Scrum
- Visualisation pratique des dépendances entre les bugs et imbrications
- Charting
- Notification Jabber/IRC
Après il reste le côté ergonomique et le confort d'utilisation. Et le temps que ca prend de mettre tout cela en place.
> Sinon tu devrais utilser "Perforce" à la place d'un SCM libre. ils ont la même philosophie alors autant aller au bout du raisonnement
Je choisi un outil pour ce qu'il apporte. Mon boulot c'est de développer un produit (libre) et je m'outille pour pouvoir le faire de manière la plus efficace possible. Si deux solutions sont équivalentes, je préfère la solution libre. Mais si un outil proprio est au dessus du lot et qu'il reste une porte de sortie si ca se passe mal je ne vois pas de raison de m'en priver.
Pour les SCM, Git + Subversion répondent très bien à nos besoin.
Je peux te donner une explication de mon choix. C'est moi qui ai fait le choix de Jira et Confluence.
Un BTS et un wiki sont fait pour aider ton équipe de développement; lui faire gagner du temps et mieux gérer ton projet. Tes processus de développement sont fortement basés sur quator SCM, BTS, Moteur d'intégration continue, Wiki. Il est donc important d'avoir des outils les plus aboutis et pratiques possible.
Il convient donc de prendre en compte trois paramètres: l'utilisabilité pour les devs, le coût de maintenance et de configuration, et le prix de revient.
Après avoir tester pas mal de solution Jira sort haut la main (pour nos besoins) en ce qui concerne les deux premiers besoins. La conf par défaut est très bonne, tu peux tout configurer et très rapidemen; des écrans aux worflows en passant par les champs customs. Tu as aussi de très bon plugins comme greenhopper si tu utilises un méthodologie Scrum de dev, mais il y en a beaucoup d'autres. Pour le prix il se trouve que pour le moment c'est gratuit (avec le support inclus).
Si un jour ils arrêtent les licences gratuites alors il faudra revoir le jugement. Il se peut que le nouveau prix de revient soit justifié au regard du temps gagné. Sinon tu peux très facilement rebasculer sur une solution libre via une moulinette. Ton projet n'est pas bloqué, il faudra juste retrouver une configuration correcte avec le nouvelle outil.
Même chose pour confluence. Là, la compétition était plus serrée, notamment avec XWiki. Au final confluence s'est avéré beaucoup moins configurable mais plus fonctionnel, stable et facile à administrer. Ici encore une migration ne coûte pas si cher que ca tant que tu n'as pas trop de plugin/macro perso.
Après je t'assure que j'aurais préféré prendre des solutions libres, mais ce qui m'importe avant tout c'est que ca soit facile à utiliser par les devs et que ca ne prenne pas trop de temps en maintenance.
Pour l'intégration continue, Hudson remporte la compétition très loin devant Bamboo ou Cruise Control.
J'espère avoir répondu à tes questions. Maintenant vous pouvez troller :-)
Pour l'outil "tout prêt", à la base il est pas du tout concu pour ca, il fallait y penser.
Et a peu prêt toutes les demos ont toujours été compressées de la sorte (beaucoup plus même).
C'est écrit en Java évidement que tu as le JRE en dép. Quand tu codes en C tu comptes le noyau et la libc dans tes 4K ?
Il me semble que tu as raté le mot anachronique dans le journal. C'est juste marrant de la part d'un dev de confluence d'avoir eu l'idée de faire un wiki en 4k. Après ça sert à rien et effectivement, et il n'y a rien de révolutionnaire dans le code. Fallait juste le faire...
[^] # Re: javascript
Posté par ckyl . En réponse au journal Perl, Javouille, Lisaac|(Ruby|SmallTalk|etc..). Évalué à 4.
Si ma fonction retourne une liste alors je déclare que ma fonction retourne une liste... Sinon c'est un objet ou un tuple. Maintenant se pose la question quelles sont les objets retournés par ma fonction. De quels types sont-ils ?
Moi plus je sais ce que je manipule, plus c'est agréable à coder même si ca demande plus de lignes "inutiles" dans des exemples triviaux. Dans la vie de tout les jours, 80% du code que je manipule n'a pas été écrit par moi. Je préfère ne pas passer ma vie à essayer de deviner ce que les fonctions que j'appelle sont censées retourner.
Alors quand on parle de Perl, qui ne déclare ni ses arguments si ses types de retour... Ca peut péter (et ca le fera) quand on changera le moindre type d'un argument ou d'un valeur de retour, quand le nombre/ordre des paramètres changera, quand le nombre/ordre des valeurs de retour changera. Vous refactorez jamais ? Vous faites jamais d'erreur dans votre code ? Vous attendez que ça pète à l'exécution pour découvrir que le code est dans un état totalement incohérent ?
Comme toujours c'est marrant sur 100 lignes de code maintenu par une personne.
[^] # Re: Grandiose
Posté par ckyl . En réponse au journal Linuxfr en J2EE. Évalué à 6.
Bha non tu ne trouves que *certaines* de ces errreurs. En gros tout ce que tu sais c'est que ton code tourne pour le flow d'exécution que tu as pris. On se retrouve toujours avec des flows d'exécution bizarres et merdiques en prod un fois qu'il y a un crétinutilisateur à l'autre bout.
Note que même si tu avais une couverture de code à 100% ça ne prouverait rien.
Si tu tiens vraiment à ne pas builder ton projet, tu noteras que les utilisateurs d'IDE en Java (il faut être très bête pour s'en priver) se retrouvent avec exactement le même comportement que python puisque seuls les classes modifiées sont recompilées. Cela dit, tu apprends assez vite que tu as tout intérêt à *toujours* tourner ton soft dans les *mêmes* conditions que tes utilisateurs.
On pourrait aussi parler des gros refactoring en typage dynamique, c'est toujours un grand moment de joie et de sérénité. C'est assez passionnant de passer son temps à chercher des canards boiteux.
Quand tu vois ce qui arrive encore à merder en ayant formatage de code/build/packaging automatique, une grosse suite de test unitaire/fonctionnel/intégration et un build après chaque commit. Bien je me dis que soit y'a des surdoués qui ne font jamais d'erreur soit y'a un paquet de c0wb0yz...
En pyton tu passes ton temps à lancer des execs pour voir si ton truc marchouille. Quand je lance un projet java en synchrone c'est par ce que les tests ont foiré, que les logs ne disent rien et qu'il est temps de brancher un debugger. Autrement tu lances les tests fonctionnels sur une autre machines et tu bosses sur autre chose. 12 secondes de compilation (32Mo de source) pour 40 minutes de tests... Quand tu n'es qu'au stade du test unitaire sur une nouvelle classe, avec un IDE c'est exactement comme python !
[^] # Re: "confier une copie de toutes mes données à un serveur extérieur"
Posté par ckyl . En réponse au journal Service de synchronisation : dropbox. Évalué à 3.
Ca permet d'encrypter et de signer les archives avant de les envoyer sur le serveur distant. Tu peux utiliser rsync/ftp/scp pour envoyer les données. Et comme tout le monde n'a pas un dédié hors de prix avec 500Go de disque sous la main, il est possible d'utiliser Amazon S3 comme stockage. Et ca revient entre pas cher et vraiment pas cher selon le volume de données.
Autrement tu prends un hébergement mutualisé à pas cher avec 100Go de disque et tu fais itou en uploadant en FTP.
[^] # Re: Grandiose
Posté par ckyl . En réponse au journal Linuxfr en J2EE. Évalué à 10.
http://en.wikipedia.org/wiki/Java_performance#Just-In-Time_c(...)
Voici un résumé très grossier:
On part sur un mode d'exécution interprété. On exécute le bytecode dans la JVM, à chaque instruction correspond une translation sur la machine cible. Quand une instruction à été exécutée on passe à la suivante.
Si Hotspot détecte que ça en vaut le coup, alors on produit du langage machine qui correspond, à peu près, au bytecode (si ca répond à ta question ce qu'on appel assembleur ce sont des symbole mnémoniques qui seront ensuite traduit en langage machine, une suite de bits). On se passera donc de l'étape de translation pour les prochaines exécutions. On peut faire des optims assez malines grâce au fait que l'on a accès à beaucoup d'informations: stats des exécutions précédentes, proco cible etc. Dans Hotspot il y a deux compilateurs qui sont plus ou moins agressifs.
Je disais à peu près car Hotspot est capable de faire de la désoptimisation. C'est à dire qu'il se permet de générer des optimisations non sûres reposant sur des hypothèses qui peuvent devenir fausses. Si il se rend compte à l'exécution que les hypothèses qu'il avait fait deviennent erronées, alors il remplace la frame optimisée par une autre moins optimisée et c'est reparti. Il se passe la même chose si entre la première moitié et la seconde de programme les prédiction de branches changent du tout au tout.
La JVM est vraiment une merveille d'optimisations (qu'on aime ou pas ce qui se trouve dessus). Les travaux sur le locking , les optimisations du compilateur, ou le garbage collector sont assez impressionnants. Voir: http://java.sun.com/products/hotspot/whitepaper.html
et http://java.sun.com/javase/technologies/hotspot/publications(...)
[^] # Re: Grandiose
Posté par ckyl . En réponse au journal Linuxfr en J2EE. Évalué à 10.
C'est un sujet à part entière tellement les limites sont flous.
> Mais sinon, pourquoi vous voulez absolument compiler ?
Dans un contexte de langage statiquement et fortement typé, un code qui compile est un code qui peut s'exécuter (ça ne dit pas qu'il est correct). Ton code python tu n'as aucune certitude qu'il est capable de s'exécuter dans n'importe quel cas. Il faut connaître tout les flow d'exécution possibles sur le bout des doigts, toutes les variables par cœur et ne jamais faire de typo ou tu le découvrira... un jour.
Ça n'a peut être pas d'importance pour toi, mais quand tu bosses sur un projet avec une équipe ça devient vite très difficile à gérer. Ouai c'est très agréable sur des petits trucs ou si tu bosses tout seul. J'aime bien scripter en Python
Si tu passes la phase de compilation à l'exécution (ou simplement que tu es en typage dynamique) ça peut péter n'importe quand à runtime pour des milliers de raisons.
Si tout les devs qui sont passés de Java 4 à Java 5 ne reviendraient pas en arrière ce n'est pas pour les caractères de cast gagnés ou l'introduction du printf. Les codes sont beaucoup plus robustes (CAML est une merveille dans ce domaine).
> pour des raisons de performances mais dans ce cas là on n'utilise pas Java.
Il y a énormément de raisons de ne pas utiliser Java mais là non. Si tu ne mets pas des mongoliens derrières le clavier, Java à des perfs très respectables. L'assembleur produit par hotspot est vraiment de bonne qualité, et je t'invite à comparer les sorties d'hotspot (voir http://weblogs.java.net/blog/kohsuke/archive/2008/03/deep_di(...) pour savoir comment activer le mode verbose) à celles de gcc fortran ou C. Le gagnant est assez rapide à trouver. Au dessus de ça, J2SE n'est pas un veau et les performances augmentent de manière significatives à chaque release. Le tableau de Java 1.[0-2] était totalement différent.
Je t'invite aussi à lire http://hal.inria.fr/docs/00/31/20/39/PDF/RT-0353.pdf . Tu peux implémenter les benchs en python, ça ne devrait pas te prendre plus d'un à deux mois.
Après tu peux rentrer dans un autre monde en tapant beaucoup plus bas niveau mais ce n'est pas le sujet ici.
[^] # Re: Grandiose
Posté par ckyl . En réponse au journal Linuxfr en J2EE. Évalué à 1.
Tu passes de la compilation au lancement de l'application comme si c'était la même chose (en python c'est le cas).
Python est effectivement un très bon langage qui à lui aussi ses contraintes... Y'a pas de miracle ce que tu gagnes en souplesse tu le perds ailleurs...
[^] # Re: Grandiose
Posté par ckyl . En réponse au journal Linuxfr en J2EE. Évalué à 5.
On peut critiquer plein de choses, mais la ca devient vraiment ridicule... Ant c'est laid, c'est moche si on veut. Mais t'y passe une journée sur 2 ans de dev ! Lire ce code et comprendre chaque action ça m'a pas pris plus d'une minute.
C'est quoi ton environnement de dev si parfait ou tout est génial et y'a rien de chiant à faire ? Faut bien le compiler à un moment ton code, et personnellement entre ant, cmake, scons, make ou les autotools y'a rien qui me fait vraiment bander... En l'occurrence dans le fichier qu'ils donnent il n'y a pas d'information redondantes, je vois pas bien comment tu veux faire plus court. C'est juste le XML qui te gène ?
[^] # Re: Grillé
Posté par ckyl . En réponse au journal LinuxFR en rails ?. Évalué à 5.
Pour linked in, tout est en Java sauf les moteurs de graphes qui sont en C++ sur de grosses machines (le graphe prenait 12Go il y a un ou deux ans). D'ailleurs leurs présentations techniques valent généralement le coup d'œil.
Pour les 30 *hits*/secondes ce n'est vraiment pas gros.
Par exemple un Jira ( http://www.atlassian.com/software/jira/ ) dans un tomcat 6 sur une veille machine (PIV 3.6Ghz, 2Go de RAM dont seulement 512 pour tomcat) tient facilement 30 *pages*/secondes. Au niveau backend et génération de page, Jira et linuxfr doivent être assez similaire. C'est juste de la présentation de données simples en DB.
La page de test utilisée était similaire à celle là: https://issues.apache.org/activemq/browse/AMQ .Il y a évidement des pages plus coûteuses à générer, mais elle doit être dans la moyenne. Un page plus complexe comme https://issues.apache.org/activemq/secure/IssueNavigator.jsp(...) supporte plus de 20 *pages*/secondes.
Note que la conf de tomcat est vraiment de base et pourrie pour les perfs (un max de logs), qu'il n'y a aucune optimisation que l'on pourrait faire pour linux-fr (aucun cache par exemple), que la conf de mysql est celle par défaut et que les clients HTTP attaquent directement le serveur d'appli. Bref je pense pas qu'on puisse faire plus défavorable pour un test.
Je ne dis pas que linux-fr est ridicule. Je dis qu'avec un serveur moderne il n'y a pas de gros exploit à faire tenir le tout sur une machine. De plus java n'est pas si à la ramasse que ca niveau perfs, et sa valeur ajoutée est son écosystème. Pourquoi linuxfr utilise google pour les recherche plutôt qu'un moteur interne par exemple ?
Après linuxfr est "tellement simple" (une seule source de donnée: la DB, pas d'appels à des services externes) qu'au final toutes les solutions me semblent plus ou moins équivalentes.
[^] # Re: Grillé
Posté par ckyl . En réponse au journal LinuxFR en rails ?. Évalué à 1.
> Je n'en doute pas. Mais par contre "Ne faire que du Java", oui, on est pas loin
Tu viens de prouver que ne faire que du java implique de ne faire que du java. Ne change rien ploum tu es un dieu.
Note: J'aime bien comment tu passes d'une critique de Java pour du dev web à Java pour des applis clientes. Et au passage Eclipse et Netbeans ont une UI dégueulasse, des boutons partout et sont totalement inutilisables ?
[^] # Re: Défi
Posté par ckyl . En réponse au journal LinuxFR en rails ?. Évalué à 2.
Pour le reste je suis d'accord
[^] # Re: Grillé
Posté par ckyl . En réponse au journal LinuxFR en rails ?. Évalué à 6.
Je ne suis pas sur que ce soit sacrifier les ressources machines dont il est question. Mais peut être plus de performances brutes contre scalabilité. Les deux sont importants mais ce n'est pas du tout la même chose. Dans tout les cas je ne suis pas convaincu que ce soit plus lourd/lent (non un contenu statique n'est pas géré par un serveur d'application mais par un CDN ou un lighthttpd, oui un niveau de cache memcached/ehcache/squid est utile et oui pas mal de choses peuvent être fait en asynchrone après la requête).
Il y a évidement un compris entre les coûts de développement, d'opérationnel, de maintenance etc. De plus LE bon choix n'existe pas. Il y a de nombreux moyens d'arriver à une archi fiable, évolutive et "cost-effective".
> besoin de l'innovation et de la motivation des développeurs c'est plutôt un frein
Je ne me sens pas freiné personnellement, c'est même une plate-forme plutôt marrante avec des outils hors du commun si on oublie le langage froid. Si tu cherches trois hackers fous pour pondre du code qu'eux seul pourront peut être maintenir dans une techno qui à un mois à la limite...
Note aussi que faire du Java ne rend pas neuneu et ne m'empêche pas de coder dans d'autres langages.
> Ce n'est pas pour rien non plus que ces même grosses boites dont tu parles utilisent aussi d'autres langages.
Évidement il n'y a pas de solution parfaite et je n'ai surtout pas dit que Java/J2EE l'était. Il faut savoir tirer parti des différentes technos selon les besoins. On peut même les combiner en fonction des besoins (linked in est un très bon exemple). Mon message était juste pour souligner que le message de ploum était encore plus idiot que tout les mecs incompétents en costards réunis...
[^] # Re: Et pourquoi pas en C (voir C++)
Posté par ckyl . En réponse au journal LinuxFR en rails ?. Évalué à 5.
Autrement tu pourras m'expliquer les gains ?
[^] # Re: Grillé
Posté par ckyl . En réponse au journal LinuxFR en rails ?. Évalué à 7.
Y'a un moment faut arrêter de se pignoler sur comment gagner trois lignes de codes ou utiliser les dernier modules ouinouin beta pas documenté et pas testé en prod.
La JVM, Java et J2EE sont de très bons environnements si bien utilisés. Pour les c0d3rz tu peux jouer avec Ruby, Python, Scala ou JS sur la JVM selon tes besoins. Tu n'es pas non plus obligé d'utiliser toute la stack J2EE. Par contre tu es autorisé à tirer parti des excellents frameworks qui existent.
Je dis pas que c'est adapté à linuxfr* hein. Mais si on pouvait arrêter de dire des anneries deux minutes...
* Qui n'est somme toute vraiment pas si gros que çà.
[^] # Re: FUD et TROLL sont dans un bateau
Posté par ckyl . En réponse à la dépêche iPod : sept ans de « progrès » dans l'emprisonnement numérique. Évalué à 3.
Par ce que pour le moment, fedora livre toujours la libgpod 0.6.0 sans patch pour le support des derniers nano. Du coup ton assertion "sur une distro récente ça marchera sans problème" est un peu fausse. Je viens de vérifier c'est la même chose sous debian (cf http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509672 ) et ubuntu.
Merci pour le travail que vous faites mais c'est encore mieux quand les utilisateurs peuvent en profiter. Pour un utilisateur le constat actuel est que ca ne marche PAS. Pour le moment j'ai une iBrique...
[^] # Re: Apple , think different : My design is important not Your freedom
Posté par ckyl . En réponse à la dépêche iPod : sept ans de « progrès » dans l'emprisonnement numérique. Évalué à 4.
Avoir un player tout petit, insensible aux chocs qui permet d'embarquer 2000+ chansons c'est super pratique. Avec les 16GB tu as presque tout les avantages des lecteurs à HD et tout les avantages des petits lecteurs. Pourquoi se priver ?
[^] # Re: Apple , think different : My design is important not Your freedom
Posté par ckyl . En réponse à la dépêche iPod : sept ans de « progrès » dans l'emprisonnement numérique. Évalué à 2.
http://www.meizume.com/music-card-m3/2476-m3-firmware-2-003-(...)
Si on part sur une base de 3Mo par fichier on pourrait mettre plus de 2500 fichiers sur un 8Go mais le firmware n'en voit que 1500...
[^] # Re: Et si on veut aider, on fait quoi ?Si
Posté par ckyl . En réponse au journal téléthon qui croyait tondre. Évalué à 2.
Peux tu étayer ta conclusion ?
Et puis leur but c'est le bénéfice, pas le chiffre d'affaire, et ça change tout.
Pas forcement. Avec un énorme CA mais un résultat d'exploitation nul, si tu vends à des particuliers l'état empoche 20% de TVA... Un des buts à long terme c'est aussi de faire rentrer de l'impots et de garder des emplois.
[^] # Re: Pour l'information comme pour le code, j'aime bien connaitre les sou
Posté par ckyl . En réponse au journal téléthon qui croyait tondre. Évalué à 2.
Tu peux le faire évidement oui.
Il n'en reste pas moins que les instituts publiques poussent vers l'exploitation de ce qui est découvert par le biais de création d'entreprises à partir des équipes de recherche ou collaboration. Et ca n'a rien d'illogique ni de mal.
[^] # Re: Pour l'information comme pour le code, j'aime bien connaitre les sou
Posté par ckyl . En réponse au journal téléthon qui croyait tondre. Évalué à 5.
Quelques exemples des plus gros instituts de recherche en france:
1- CNRS
En 2004, j'ai pas de chiffre plus récents, le CNRS disposait d'un portefeuille de plus de 2000 brevets (et autant posé par des partenaires puisque les équipes sont très souvent mixtes).
http://www.cnrs.fr/dpi/politique_industrielle/presentation.h(...)
http://www.cnrs.fr/dpi/politique_industrielle/chiffres-cles.(...)
2- INRIA
Le portefeuille est plus petit que le CNRS et ne doit pas dépasser les 100. La politique est la même que le CNRS pour ce qui concerne la valorisation de la recherche.
http://www.inria.fr/valorisation/
http://www.inria.fr/valorisation/brevets/index.fr.html
3- INSERM
Idem que CNRS et INRIA. Inserm-transfert est en charge de la valorisation. 700 brevets (dont plus de 100 déposés en 2007)
http://www.inserm-transfert.fr/index.php?option=com_content&(...)
4- INRA
208 brevets déposés à ce jour
http://www.inra.fr/l_institut/l_inra_en_bref/les_chiffres_cl(...)
Et on pourrait continuer avec tout les instituts. On ne finance pas la recherche pour la beauté de passer un papier dans une conf. Le but est de mettre au point des technologies/idées innovantes pour pouvoir les valoriser dans le privé ensuite. Ça passe par une étape ou on donne beaucoup d'argent à des entreprises qui se créées. Par le biais de brevet, de transfert de techno et de subvention etc. On peut aussi passer des accords avec des sociétés déjà existantes. L'espoir est que ces entreprises grossissent suffisamment pour que l'investissement initial soit plus que remboursé.
[^] # Re: Pour plus de renseignements...
Posté par ckyl . En réponse au journal téléthon qui croyait tondre. Évalué à 6.
Je ne sais pas qui était payé 94 K€/an, mais ca n'a rien de déraisonnable. Si tu veux recruter des gens pointus il faut s'aligner avec les valeurs du marché. Je connais pas du tout les salaires dans ces domaines mais dans l'informatique ça n'aurait vraiment rien de choquant. 6000€/mois y'a un gros paquet d'ingénieurs qui les rentrent ! À vu de nez je dirais que le médical est plus rémunérateur...
Restons dans l'informatique, un directeur de recherche à l'INRIA en fin de carrière c'est 74 K€/an avec pas mal d'extras et d'avantages.
Après tu peux fixer les salaires à 1500€/mois, mais tu risques de pas avoir beaucoup de candidats. Qui est motivé pour diviser par 2 ou 3 son salaire ici ? Aller c'est pour sauver le monde, un peu d'entrain !
[^] # Re: Et si on veut aider, on fait quoi ?
Posté par ckyl . En réponse au journal téléthon qui croyait tondre. Évalué à 1.
La recherche en info en France n'a clairement pas pour but de faire de l'open source mais de servir de vivier pour créer des sociétés pointues... Exactement comme ce que tu critiques dans le médicale ! La réussite, c'est protéger les innovations pour lancer des entreprises qui feront du CA et sauveront le PIB et feront rentrer des impôts. Bienvenue dans le monde réel, et ca ne date pas des dernières élections.
[^] # Re: Ah Confluence, JIRA....
Posté par ckyl . En réponse au journal Un wiki en 4K et en Java !. Évalué à 3.
Libre à Atlassian de choisir son business modèle. Il a été pris en compte lors du choix et on sait qu'il est possible de revenir en arrière si leur tarifs deviennent prohibitifs.
> Et pourtant des BTS java potable et libre il y en a.
Tu ne connais pas mes critères de choix pour valider les solutions. J'ai jugé que JIRA répondait le mieux à nos besoins. C'est vrai que des BTS il y en a beaucoup. J'ai posé des contraintes techniques et ergonomique. C'est mon choix, je ne dis pas que c'est LE bon choix. Je n'ai pas non plus testé tout les BTS du monde.
> As-tu essayé itracker par ex ?
Non.
Répond t'il a ma liste (partielle) de besoins:
- Intégration SVN git
- Remote API
- Role/Workflow modifiables par projet
- Notification modifiables par projet
- Possibilité d'ajouter des champs proprios (par projet)
- Tickets imbriqués
- Possibilité d'intégration dans les IDE
- Adaptable pour gérer des itération Scrum
- Visualisation pratique des dépendances entre les bugs et imbrications
- Charting
- Notification Jabber/IRC
Après il reste le côté ergonomique et le confort d'utilisation. Et le temps que ca prend de mettre tout cela en place.
> Sinon tu devrais utilser "Perforce" à la place d'un SCM libre. ils ont la même philosophie alors autant aller au bout du raisonnement
Je choisi un outil pour ce qu'il apporte. Mon boulot c'est de développer un produit (libre) et je m'outille pour pouvoir le faire de manière la plus efficace possible. Si deux solutions sont équivalentes, je préfère la solution libre. Mais si un outil proprio est au dessus du lot et qu'il reste une porte de sortie si ca se passe mal je ne vois pas de raison de m'en priver.
Pour les SCM, Git + Subversion répondent très bien à nos besoin.
[^] # Re: Ah Confluence, JIRA....
Posté par ckyl . En réponse au journal Un wiki en 4K et en Java !. Évalué à 6.
Un BTS et un wiki sont fait pour aider ton équipe de développement; lui faire gagner du temps et mieux gérer ton projet. Tes processus de développement sont fortement basés sur quator SCM, BTS, Moteur d'intégration continue, Wiki. Il est donc important d'avoir des outils les plus aboutis et pratiques possible.
Il convient donc de prendre en compte trois paramètres: l'utilisabilité pour les devs, le coût de maintenance et de configuration, et le prix de revient.
Après avoir tester pas mal de solution Jira sort haut la main (pour nos besoins) en ce qui concerne les deux premiers besoins. La conf par défaut est très bonne, tu peux tout configurer et très rapidemen; des écrans aux worflows en passant par les champs customs. Tu as aussi de très bon plugins comme greenhopper si tu utilises un méthodologie Scrum de dev, mais il y en a beaucoup d'autres. Pour le prix il se trouve que pour le moment c'est gratuit (avec le support inclus).
Si un jour ils arrêtent les licences gratuites alors il faudra revoir le jugement. Il se peut que le nouveau prix de revient soit justifié au regard du temps gagné. Sinon tu peux très facilement rebasculer sur une solution libre via une moulinette. Ton projet n'est pas bloqué, il faudra juste retrouver une configuration correcte avec le nouvelle outil.
Même chose pour confluence. Là, la compétition était plus serrée, notamment avec XWiki. Au final confluence s'est avéré beaucoup moins configurable mais plus fonctionnel, stable et facile à administrer. Ici encore une migration ne coûte pas si cher que ca tant que tu n'as pas trop de plugin/macro perso.
Après je t'assure que j'aurais préféré prendre des solutions libres, mais ce qui m'importe avant tout c'est que ca soit facile à utiliser par les devs et que ca ne prenne pas trop de temps en maintenance.
Pour l'intégration continue, Hudson remporte la compétition très loin devant Bamboo ou Cruise Control.
J'espère avoir répondu à tes questions. Maintenant vous pouvez troller :-)
[^] # Re: Génial !
Posté par ckyl . En réponse au journal Un wiki en 4K et en Java !. Évalué à 2.
[^] # Re: Mouais, c'est raté ...
Posté par ckyl . En réponse au journal Un wiki en 4K et en Java !. Évalué à 6.
Et a peu prêt toutes les demos ont toujours été compressées de la sorte (beaucoup plus même).
C'est écrit en Java évidement que tu as le JRE en dép. Quand tu codes en C tu comptes le noyau et la libc dans tes 4K ?
Il me semble que tu as raté le mot anachronique dans le journal. C'est juste marrant de la part d'un dev de confluence d'avoir eu l'idée de faire un wiki en 4k. Après ça sert à rien et effectivement, et il n'y a rien de révolutionnaire dans le code. Fallait juste le faire...