En parcourant mes flux RSS dans mon agrégateur je suis tombé sur un article très geeky d'un développeur d'Atlassian. Atlassian c'est une petite boite, plus si petite que ça d'ailleurs, qui fait de très bon produits pour la gestion de projet (bug tracker, wiki, integration continue, revue de code etc.). C'est pas libre, mais ils donnent des licences et du support gratos aux projets Open Source. Bon la n'est pas mon propos, mais je ne saurais résister au plaisir de provoquer moult commentaires rien que grâce à cette introduction.
L'article en question parle d'écrire un wiki en Java... dont le JAR final doit faire moins de 4K. Oui ça à un bon petit goût de Demoscene totalement anachronique !
Le résultat c'est un serveur HTTP pseudo HTTP/1.1, le support du gras, italique, souligné, barré, exposant, indice, commentaire sur les pages, flux RSS, macro et quelques autres trucs.
C'est tellement inutile que ça méritait d'être signalé. L'article est très agréable à lire et disponible en anglaisaustralien dans le texte: http://blogs.atlassian.com/developer/2008/11/wiki4k.html . Le code est bien sur disponible et se lit plutôt vite.
Journal Un wiki en 4K et en Java !
28
nov.
2008
# Nourissage de trolls détecté !
Posté par gUI (Mastodon) . Évalué à 3.
Bon ensuite ça servira à "démontrer que Java c'est mieux que xxx la preuve c'est que tu peux faire un wiki en 4k", mais en attendant, c'est toujours joli de voir ces espèces de prouesses techniques pas forcément très utiles : je ne vois pas qui a interêt à monter un wiki en 4k (pour mettre dans un PIC ?)
Reste à faire une vidéo montrant comment faire un wiki en 4k et en 10 minutes, et là, oui, t'as le top du nourrissage de troll (((-:
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Nourissage de trolls détecté !
Posté par Amand Tihon (site web personnel) . Évalué à 10.
Et tu connectes le PIC à un ARM pour y faire tourner la JVM ? :)
[^] # Re: Nourissage de trolls détecté !
Posté par B16F4RV4RD1N . Évalué à -4.
(désolé...)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Nourissage de trolls détecté !
Posté par B16F4RV4RD1N . Évalué à 1.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
# Ah Confluence, JIRA....
Posté par icyfemur . Évalué à 7.
[^] # Re: Ah Confluence, JIRA....
Posté par ckyl . É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: Ah Confluence, JIRA....
Posté par Bozo_le_clown . Évalué à 2.
Oui c'est ce qu'ont du se dire les gras de Bitkeeper en tentant de forcer la main.
Et pourtant des BTS java potable et libre il y en a.
As-tu essayé itracker par ex ?
J'ai plutôt l'impression que Jira est un phénomène de mode.
Sinon tu devrais utilser "Perforce" à la place d'un SCM libre. ils ont la même philosophie alors autant aller au bout du raisonnement
[^] # Re: Ah Confluence, JIRA....
Posté par ckyl . É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 Ludo . Évalué à 1.
Sur le plan fonctionnel, y'a très certainement des éléments dont tu te sers qui ne sont pas dans Redmine, mais pour nous, cela nous as permis d'avoir un outil plus simple à utiliser au quotidien, plus ergonomique, notamment pour les clients.
De mon point de vue, Jira+Confluence, c'est un porte-avion pour traverser la Meuse, Redmine est suffisant pour la plupart des besoins de ce type.
# Génial !
Posté par zebra3 . Évalué à 10.
(Malgré tout, belle performance)
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Génial !
Posté par Frédéric Heulin . Évalué à 7.
[^] # Re: Génial !
Posté par ckyl . Évalué à 2.
[^] # Re: Génial !
Posté par smc . Évalué à 1.
- La grande majorité des "serveurs Linux" ont une instance de la JVM lancée donc ça ne rajoute pas d'overhead.
Il faut se réveiller les gens, la JVM aujourd'hui c'est plus celle d'avant. Elle est libre et beaucoup plus efficace. Et 95% des serveurs d'entreprise font tourner un environnement Java (J2EE, Tomcat, etc).
[^] # Re: Génial !
Posté par Romeo . Évalué à 4.
Je bosse pour un hébergeur, nombre de serveur possédant une instance de jvm : à la louche 1/60.
De plus, quand tu regardes les perfs de ces serveurs ... (mais bon ça je le mettrais plutot sur le compte des devs)
[^] # Re: Génial !
Posté par smc . Évalué à 5.
C'est pour des particuliers? C'est de l'hébergement mutualisé?
Si c'est des professionnels, ils louent des baies ou des unités et je ne vois pas comment tu peux déterminer ce qui tourne sur leurs serveurs, à moins qu'ils sous-louent l'administration aussi (quelle entreprise fait ça?)
Les serveurs d'application Java sont omniprésents : si dans le monde du logiciel libre "traditionnel" ils n'ont pas autant percé car Java n'était pas libre, ça n'a pas empêché un environnement très riche de se développer.
Par exemple, une énorme partie des projets de la Fondation Apache c'est des applications Java pour le serveur : Tomcat, Jakarta, JDO, Cocoon, Struts, Geronimo, Felix (OSGi), et j'en passe.
A coté de ça y'a toutes les solutions IBM (WebSphere) et Sun (Glassfish qui est libre).
Alors les serveurs que tu administres, je ne crois pas qu'il s'agisse d'un échantillon représentatif des serveurs tu vois; il me semble que tu parles de serveurs d'infrastructure car c'est la dessus que tu bosses (hebergement sites web), alors qu'une énorme partie des serveurs (et la majorité des systèmes utiles) sont des serveurs d'application métier et qu'une énorme part est basée sur Java.
Ajoutons à ça que l'environnement Java va entrer dans la prochaine révision de LSB et là je t'assure que tous les serveurs GNU/Linux auront une JVM, au moins par défaut, et dans l'environnement actuel les développeurs libristes vont sans doute moins rechigner à se mettre à développer pour la JVM.
Le premier point est bien sûr la libération de Java. Ensuite un nombre exemplaire de bibliothèques (généralement décemment conçues et plutot uniformes comparées à C/C++). Et pour ceux qui n'aiment pas le langage Java (et j'en fais partie), l'activité incroyable des nouveaux langages qui ciblent la JVM, aussi bien statiques (Java, Scala) que dynamiques (Clojure, Groovy, Jython et JRuby).
Pour résumer, je prévois plus d'utilisation dans Java auprès des libristes sur le serveur et sur le bureau, mais c'est notamment parce que le milieu de l'entreprise, poussé par l'incroyable contribution d'IBM et d'Apache, a déjà développé une immense pile logicielle, majoritairement libre, qui ne demande qu'à être utilisée par les développeurs.
Après, si les développeurs veulent continuer à faire du C, à se taper des buffer overflows et faire plus d'intégration que de logique métier, je comprends, j'ai été dans ce délire.
Quant aux les développeurs PHP ... je pense qu'il y a une différence d'échelle entre le type d'application qu'on peut faire entre PHP et Java; c'est toujours possible en PHP mais il faut accepter de refaire une bonne partie de la roue.
# Mouais, c'est raté ...
Posté par pipo_molo . Évalué à 8.
Les seules optimisations dont il parle, c'est écrire une seule classe, limiter le nombre de méthodes, et utiliser un outil "tout prêt" qui fait toutes les optimisations pour lui ... supaire.
Ensuite, la limite des 4k en java, c'est du grand n'importe quoi étant donné que le jar est compressé, son bytecode fait en réalité 6 887 octets.
Enfin il oublie de préciser que pour exécuter son super code de presque moins de 4 ko, il faut aussi récupérer une JRE, dont l'archive fait quasiment 20 Mo ...
Bref, on est bien loin de l'aspect "demoscene" revendiqué, où alors faut que je me dépêche d'écrire un article sur "un fond d'écran en jpeg de mon chien de moins de 4ko", ub3rl33t !
Bon, il me reste plus qu'à relire http://www.muppetlabs.com/~breadbox/software/tiny/teensy.htm(...) pour me calmer.
[^] # Re: Mouais, c'est raté ...
Posté par Loic Dreux . Évalué à 1.
[^] # Re: Mouais, c'est raté ...
Posté par Jolidragon . Évalué à 4.
[^] # Re: Mieux
Posté par foulmetal canette (site web personnel) . Évalué à 3.
[^] # Re: Mieux
Posté par Elfir3 . Évalué à 2.
Le dvorak ça aide peut être à taper plus vite, mais malheureusement pas encore à réfléchir ;)
Pour les intéressés, ce sont les EFL qui le permettent, qui sont à la base de E17, c'est vrai, mais en sont totalement indépendantes.
[^] # Re: Mieux
Posté par foulmetal canette (site web personnel) . Évalué à 2.
Désolé de ne pas avoir de balise .
D’ailleurs c’est écrit dans le journal auquel je fais référence, pour le EFL.
Bon trolledi…
[^] # Re: Mieux
Posté par foulmetal canette (site web personnel) . Évalué à 2.
[^] # Re: Mouais, c'est raté ...
Posté par ckyl . É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...
[^] # Re: Mouais, c'est raté ...
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 1.
Pas si je code sous Linux mais avec des trucs comme eCos, RTEMS voire MarteOS, 4K, c'est faisable.
Tout ça pour dire que la taille d'un exécutable n'est lié qu'à la cible sur laquelle il est censé tourner.
[^] # Re: Mouais, c'est raté ...
Posté par Elfir3 . Évalué à 4.
[^] # Re: Mouais, c'est raté ...
Posté par _alex . Évalué à 8.
Les démos sous DOS s'occupaient de passer en protégé, de gérer leurs mémoires, le driver son (Gravis Ultrasound, SoundBlaster souvent), le driver vidéo (mode VGA torturé) etc...
Quand les premières démos sous Windows sont apparues, je me souviens de remarques similaires : le code faisait toujours 4ko mais pouvait utiliser DirectX et toutes l'API Windows au contraire des démos sous DOS qui faisaient tout à la mano.
Alors ou situer la limite ?
[/mode troll]
# Et java? Ça fait 4K?
Posté par blubliblo . Évalué à -4.
Ta pile logicielle est la suivante:
kernel+toolchain(C/C++)+java, est-ce bien raisonnable?
Mes limites s'arrêtent à kernel+toolchain(C), au delà, je considère que c'est du bloat... car le kernel et une toolchain optimisant le C est déjà extrêment couteuse en termes logiciels. Alors un front-end C++ (un truc de taré car le C++) et grosso-modo 80Mo de code source C++ complexe (java)... non merci, pas pour moi.
Le vrai minimaliste considère l'ensemble de la pile logicielle et certainement pas uniquement un petit programme dépendant d'un méga-bloat... un peu de bon sens.
# Ca me rappel un truc ...
Posté par Mr Kapouik (site web personnel) . Évalué à 2.
# Ca existe déjà, plus compact, dans d'autres langages
Posté par lolop (site web personnel) . Évalué à 3.
Ca va de 4 lignes (222 caractères) à 40 lignes.
En tout cas, visiblement bien plus dense que la version Jawa du journal.
A+
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# 4k ...
Posté par Guillaume D. . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.