Journal Un wiki en 4K et en Java !

Posté par .
Tags : aucun
10
28
nov.
2008
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.
  • # Nourissage de trolls détecté !

    Posté par . Évalué à  3 .

    Pas mal la performance !

    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 (((-:
  • # Ah Confluence, JIRA....

    Posté par . Évalué à  7 .

    J'ai toujours trouvé ça étrange les projets OpenSource qui utilisent Confluence et JIRA... un produit propriétaire gracieusement fourni pour les projets libres... mais jusqu'à quand ? Il me semble que y a déjà des gens qui se sont mordus les doigts d'une telle pratique : BitKeeper n'a pas donné assez de leçons ? Bon, je ne connais pas les détails de la licence d'utilisation dans le cas OpenSource, et j'ai entendu dire que ces deux produits sont très bons.
    • [^] # Re: Ah Confluence, JIRA....

      Posté par . Évalué à  6 .

      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 :-)
      • [^] # Re: Ah Confluence, JIRA....

        Posté par . Évalué à  2 .

        Il se peut que le nouveau prix de revient soit justifié au regard du temps gagné.

        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 . Évalué à  3 .

          > 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.
          • [^] # Re: Ah Confluence, JIRA....

            Posté par (page perso) . Évalué à  1 .

            Intéressant, car justement nous avions Jira+Confluence, et nous avons migré vers Redmine.

            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 . Évalué à  10 .

    Et la VM Java, elle prend combien de Mo ? Non, parce que c'est bien la peine de faire un jar de 4K pour se taper 300 Mo de librairies...

    (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 . Évalué à  7 .

      Je trouve ta signature particulièrement adaptée pour le coup ! :)
    • [^] # Re: Génial !

      Posté par . Évalué à  2 .

      C'est justement ce qui rend l'idée si délicieuse !
    • [^] # Re: Génial !

      Posté par . Évalué à  1 .

      - La JVM ne charge que les bibliothèques utiles.
      - 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 . Évalué à  4 .

        Hu?!
        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 . Évalué à  5 .

          Ca veut dire quoi que tu bosses pour un hébergeur?
          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 . Évalué à  8 .

    En fait, c'est pas bandant du tout, sur un plan technique.

    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 . Évalué à  1 .

      "il faut aussi récupérer une JRE, dont l'archive fait quasiment 20 Mo ..." Oui mais non, si il aurait été au bout de son idée, il aurait pu livré une JVM basé sur OpenJDK où il aurait viré tout ce qui sert à rien (Swing & Co)...
    • [^] # Re: Mieux

      Posté par (page perso) . Évalué à  3 .

      Ouais c’est complètement ł4mΣ, avec E17 on peut se faire un lecteur DVD en seulement 17 lignes de code C : https://linuxfr.org//~JesusMacGod/14784.html
      • [^] # Re: Mieux

        Posté par . Évalué à  2 .

        Pas de bêtises s'il te plait... E17 est _juste_ un desktop shell...

        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 (page perso) . Évalué à  2 .

          Oui je sais !
          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: Mouais, c'est raté ...

      Posté par . Évalué à  6 .

      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: Mouais, c'est raté ...

        Posté par (page perso) . Évalué à  1 .

        Quand tu codes en C tu comptes le noyau et la libc dans tes 4K ?
        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 . Évalué à  4 .

        Je me trompe sans doute, mais la totalités des JRE ne reposent elles pas sur la libc ? Dans ce cas, pourquoi compter quelque chose dont on ne peut s'affranchir ?
    • [^] # Re: Mouais, c'est raté ...

      Posté par . Évalué à  8 .

      [mode troll]
      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 . Évalué à  -4 .

    Download les sources de java... décompress et regarde la taille et la complexité du code.
    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 (page perso) . Évalué à  2 .

    Je me souviens d'un petit jeu vidéo genre FPS avec quelques petits effet simpa qui prenait 10ko dans son binaire. Il était codé avec directX et appelé tout depuis l'exterrieur : bref si on comptait toute les dépendance il devait y avoir bien 200 ou 300Mo en réalité.
  • # Ca existe déjà, plus compact, dans d'autres langages

    Posté par (page perso) . Évalué à  3 .

    Voir le Shortest Wiki Contest http://c2.com/cgi/wiki?ShortestWikiContest

    Ca va de 4 lignes (222 caractères) à 40 lignes.
    En tout cas, visiblement bien plus dense que la version Jawa du journal.

    A+
  • # 4k ...

    Posté par . Évalué à  3 .

    La vraie prouesse cela aurait été un JRE de 4k !!

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.