• # Un peu tôt

    Posté par  . Évalué à 6.

    Presque trois mois nous séparent encore du premier avril :D

  • # Note

    Posté par  (site web personnel, Mastodon) . Évalué à 10.

    Pour la prochaine assemblée générale, ajouter ce point à l'ordre du jour:

    - vote pour l'achat de 2 serveurs supplémentaires afin de répondre aux exigences du nouveau site en matière de tenu en charge.


    (Hein ? comment ça on n'est pas vendredi ? ->[])

    • [^] # Re: Note

      Posté par  (site web personnel) . Évalué à 1.

      Non, la montée en charge est loin d'être ce qui m'inquiète le plus. Rails (et Django) ont des performances bien meilleures que les frameworks MVC en PHP. Par contre, d'autres défis m'attendent. Par exemple, je crains l'import des données existantes : le schéma de la base de données n'est pas des plus limpides, et on aura bientôt un million de commentaires, donc pas question de faire ça à la main.

      • [^] # Re: Note

        Posté par  . Évalué à 3.

        d'ailleurs à quand le millionième commentaire ? Il y a un cadeau de prévu ?

        Vous voulez pas la jouer soft ? Je suis pas contraignant... vous voulez la jouer hard ? On va la jouer hard

        • [^] # Re: Note

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          Si c'est un commentaire particulièrement utile et pertinent qui fait partie des contributions notables au site, alors oui. cf : https://linuxfr.org/comments/995420.html#995420

          Sinon, non, ca serait la déferlante de commentaires tous plus inutiles les uns que les autres pour atteindre le million.

          • [^] # Re: Note

            Posté par  . Évalué à 10.

            Sinon, non, ca serait la déferlante de commentaires tous plus inutiles les uns que les autres pour atteindre le million.

            C'est vraiment pas le genre de la maison !

      • [^] # Re: Note

        Posté par  (Mastodon) . Évalué à 1.

        > le schéma de la base de données n'est pas des plus limpides

        ça ne vaudrait pas le coup de refaire le schéma de la base proprement plutôt que de continuer à utiliser le schéma actuel ?

        • [^] # Re: Note

          Posté par  (site web personnel) . Évalué à 4.

          Si, mais il faudra quand même réimporter les données.

          • [^] # Re: Note

            Posté par  . Évalué à 3.

            Un ETL (Extract, Tansform, Load) comme Talend est l'outil indispensable. Les imports de données, c'est toujours casse-c...

      • [^] # Re: Note

        Posté par  (site web personnel) . Évalué à 3.

        > Rails (et Django) ont des performances bien meilleures que les frameworks MVC en PHP.

        Le bon gros troll des familles pour répondre à un autre. Pour la crainte au niveau de l'import des données, ce n'est jamais le nombre le problème, mais la qualité des données.

        • [^] # Re: Note

          Posté par  . Évalué à 2.

          Rien à voir avec un framework MVC en PHP, mais justement hier, j'ai comparé les perfs d'un blog entre sa version DotClear2 et Django (mod_python) (moteur de blog maison aucunement optimisé et plutôt 'bidouillé').

          J'avais justement peur à une baisse de performances sur machine équivalente... et bien je n'ai pas été déçu du voyage:

          - DotClear / 100 pages de garde = 1.819sec
          - Django / 100 pages de garde = 2.625sec

          Ça ne me gène pas à mon échelle... mais à d'autres, ça doit jouer j'imagine.

          • [^] # Re: Note

            Posté par  (site web personnel) . Évalué à 2.

            Essaye avec mod_wsgi tu y gagnera beaucoup...

            Sans parler du fait de bien d'optimiser tes objets/pages en cache + memcached

      • [^] # Re: Note

        Posté par  (Mastodon) . Évalué à 4.

        Par contre, d'autres défis m'attendent. Par exemple, je crains l'import des données existantes : le schéma de la base de données n'est pas des plus limpides

        Si je puis me permettre un conseil, ne considérez meme pas la possibilité de réutiliser la BdD telle quelle en utilisant les possibilité de Rails pour désigner les noms des tables, des clés etc... Sur la ML railsfrance, bcp trop s'y cassent les dents. Il vaut mieux réimporter la BdD dans un nouveau schéma spécialement conçu pour Rails.

        Et comme bcp, si je peux aider (notamment aux tests par exemple, ou meme à la relecture de code)...

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # Et voyages-sncf.com ?

    Posté par  . Évalué à 10.

    Il est aussi développé en Rails ?


    ===>[]

  • # Bah

    Posté par  (site web personnel) . Évalué à 7.

    Ca avait été décidé il y a un an, reste à le faire :)

    • [^] # Re: Bah

      Posté par  (site web personnel) . Évalué à 7.

      Bah je crois que les gens sont verts d'une telle résolution surtout, et vont blaguer dessus avec une fréquence élevée... Pas besoin de refaire le pitch ou de réexpliquer en longueur et en largeur l'intérêt d'une telle résolution, on s'en bat l'oeil. Que les gens voient donc ce qui se trame en fond, pas de raison de faire écran. :ppp

    • [^] # Re: Bah

      Posté par  (site web personnel) . Évalué à 6.

      Oui, mais là, c'est ma résolution pour 2009, donc je vais au moins commencer à écrire du code.

  • # Grillé

    Posté par  (site web personnel) . Évalué à 3.

    Bien vu :)

    Je pensais poster un journal aujourd'hui pour annoncer cela, mais j'ai été grillé. Ma résolution pour 2009 est donc de réécrire LinuxFr.org en Rails. Cela va prendre du temps (le code existant fait quelques dizaines de milliers de lignes de code/template/css). Ne vous attendez pas à ce que ce soit mis en ligne avant plusieurs mois.

    • [^] # Re: Grillé

      Posté par  (site web personnel) . Évalué à 3.

      Comme ça tu risques d'avoir des contributeurs ? Hein ? Qui pourront contribuer ? Plein de gens bien intentionnés qui pourront aider à coder et débugger ?

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 7.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Grillé

          Posté par  . Évalué à 1.

          Bah oui, non aussi fait tout alenvers, comme toi.

    • [^] # Re: Grillé

      Posté par  (site web personnel) . Évalué à 3.

      Dans quel but? La version actuelle n'est plus maintenable?

      • [^] # Re: Grillé

        Posté par  (site web personnel) . Évalué à 5.

        C'est du templeet ~~

        • [^] # Re: Grillé

          Posté par  . Évalué à 3.

          Ca ne peut pas être pire que du Rails :-)

          Troll à part, pourquoi changer un truc qui marche ?
          If it ain't broke, don't fix it!

          Au pire, que les nouveaux développements abandonnent Templeet, pourquoi pas (après tout, Apache peut utiliser toutes sortes de moteurs de scripts), mais j'espère qu'on ne va pas subir encore les affres du passage de DaCode à Templeet où on a retrouvé un site qui marchait moins bien (ça semble résolu maintenant) et avec moins de fonctionnalités au début.

          Et tant qu'à lancer le débat, pourquoi pas en Java maintenant que ça-sent-bon-c'est-libre ? Il y a d'excellents frameworks et c'est beaucoup plus mature que Grails. Le choix me semble plus un caprice de développeur (un peu comme templeet, d'ailleurs) qu'un truc réfléchi.

          Je suis d'accord que templeet est une horreur, à part ses performances. Oser mélanger le modèle, la vue, le contrôleur, le PHP, le SQL, le javascript, le HTML, la présentation, le business et la persistence, et d'autre horreurs dans un fichier unique en y collant une syntaxe abconse qui fait plus penser à un concours d'obfuscated LISP qu'à un design moderne, c'est du grand n'importe quoi qui mériterait de figurer sur http://thedailywtf.com/ mais c'est pas une raison pour faire n'importe quoi à la place.

          Enfin, tant qu'il y aura encore la tribune...

          • [^] # Re: Grillé

            Posté par  (site web personnel) . Évalué à 9.

            > Troll à part, pourquoi changer un truc qui marche ?
            > If it ain't broke, don't fix it!

            Mais c'est cassé. Tu ne t'en pas rends pas compte, mais nous avons des problèmes avec la version actuelle. Parfois, le cache fait n'importe quoi. Certaines pages sont générées avec un "/my" au début de chaque URL (nous n'avons pas réussir à trouver ce qui déclenche ce problème, mais nous en retrouvons de temps à autres dans le cache). Nous, admins, passons régulièrement du temps pour corriger des problèmes.

            > mais j'espère qu'on ne va pas subir encore les affres du passage de DaCode à Templeet où on a retrouvé un site qui marchait moins bien (ça semble résolu maintenant) et avec moins de fonctionnalités au début.

            Il faudra probablement s'attendre à avoir des fonctionnalités différentes. Certaines vont manquer aux débuts. Mais il y aura aussi des nouveautés.

            > Et tant qu'à lancer le débat, pourquoi pas en Java maintenant que ça-sent-bon-c'est-libre ? Le choix me semble plus un caprice de développeur (un peu comme templeet, d'ailleurs) qu'un truc réfléchi.

            C'est un choix personnel (même si les autres admins de LinuxFr.org sont d'accord avec lui). Cela n'en est pas moins un choix réfléchi. Je connais très bien Ruby on Rails, ses forces et ses faiblesses. Je connais d'autres frameworks, et je pense que RoR convient mieux.

            Par contre, il est vrai que je ne connais pas le monde Java. Il me semble donc plus prudent de ne pas se lancer dedans, car il faudra non seulement développer, mais aussi administrer tout cela (et je ne crois pas que les autres admins soient plus enthousiasmés que moi pour du java).

            • [^] # Re: Grillé

              Posté par  . Évalué à 2.

              Techniquement Java (enfin, J2EE) est une excellente solution technique (surtout pour encaisser le traffic conséquent de Linuxfr.org) et en plus on peut faire du 100% libre (OpenJDK, GlassFish, ...).

              Mais c'est hélas un choix qui serait loin d'emporter le consensus :-( Le plus (?) important, c'est d'avoir une communauté: des contributeurs, des victimes testeurs...

              • [^] # Re: Grillé

                Posté par  . Évalué à 4.

                "Le plus (?) important, c'est d'avoir une communauté: des contributeurs"
                Tu penses à Pierre Tramo ?

                • [^] # Re: Grillé

                  Posté par  . Évalué à 2.

                  Ha ha :-)

                  Plus sérieusement, avec la montée (lente mais réelle) en popularité de GlassFish, il va bien finir par avoir une armée de libristes J2EEiens. Par des architectes hautains mais des bon p'tits programmeurs qui tournent à la bière, la pizza et au résultat.

                  • [^] # Re: Grillé

                    Posté par  (site web personnel, Mastodon) . Évalué à 9.

                    Tu crois qu'il y aura un jour des gens pour faire du J2EE pour le plaisir ? Je veux dire, pour les libristes dans leur garage. Y'a Python, Ruby, Vala, Ou même Php. Pourquoi, ô pourquoi quelqu'un qui s'y connait en informatique voudrait choisir J2EE si il n'a pas un incompétent en cravate au dessus de lui pour lui imposer ? Même brainfuck me semble plus approprié à n'importe quoi que J2EE, non ?

                    (l'année commence bien, vive linuxfr)

                    Mes livres CC By-SA : https://ploum.net/livres.html

                    • [^] # Re: Grillé

                      Posté par  . Évalué à 10.

                      Oui, je le crois. Allez, trollons, en janvier, c'est autorisé :-)

                      Pourquoi J2EE sans masochiste? Par ce que c'est excellemment outillé, bien documenté, parce qu'il y a toujours une librairie de qualité pour répondre à un besoin, parce que depuis J2EE 1.6 c'est quand même beaucoup moins lourd (annotations, JPA, etc etc).

                      Oui, il n'y a pas le côté "fun" d'un Python 3K ou d'un Ror et il faut quand même encore écrire deux fois plus de ligne de code en Java pour obtenir un programme bien plus gourmand en RAM, mais au final, ce qui compte, c'est que ça marche, et bien (en particulier le clustering, ça a un côté magique). Plus chiant mais résultats prévisibles et stables sans perdre des jours entier à bidouiller pour contourner un obscure fonction non documentée, en résumé :-)

                      Pour infos, j'ai créé ma boite et au début, Java/J2EE, je ne pouvais pas le sentir. Mais à force de constater que "tiens, pour l'indexation, avec Lucene ça serait tellement mieux", "tiens, pour le déploiement JWS c'est quand même top"... ben au final, j'y suis passé. Et maintenant j'apprécie même certains points, comme les EJB stateless et remote.

                      Je vais me faire moisser, mois :-D Allez, encore un "vive J2EE" pour la route.

                      ---> []

                      • [^] # Re: Grillé

                        Posté par  . Évalué à 2.

                        Et en plus, Netbeans c'est super bien avec du Java !

                      • [^] # Re: Grillé

                        Posté par  (site web personnel) . Évalué à 5.

                        Tu vois, tu t'es pas fait moinsser. Maintenant que Java est libre, je crois qu'il y a beaucoup de gens qui, comme moi, se demandent si ce n'est pas une bonne plateforme après tout (d'autant qu'on est pas obligé de coder en Java pour en profiter!)

                    • [^] # Re: Grillé

                      Posté par  . Évalué à 7.

                      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 çà.

                      • [^] # Re: Grillé

                        Posté par  . Évalué à 3.

                        Les contraintes de ces grosses boites, c'est pas que les cravates, c'est aussi le nombre de développeurs qui y travaillent pour gagner leur croute. L'intérêt de java est de pouvoir bien cadrer tout ce petit monde quitte a sacrifier les ressources machines. Par contre pour des projets à taille plus humaine et a ressources restreintes où on a besoin de l'innovation et de la motivation des développeurs c'est plutôt un frein. Ce n'est pas pour rien non plus que ces même grosses boites dont tu parles utilisent aussi d'autres langages.

                        • [^] # Re: Grillé

                          Posté par  . Évalué à 6.

                          > 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...

                          • [^] # Re: Grillé

                            Posté par  (site web personnel, Mastodon) . Évalué à 0.

                            "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. J'en veux pour preuve que tu flaires un programme Java à 15km à son UI dégueulasse, ses bouttons partout et son anti-utilisabilité.

                            Mais les programmes Java, c'est comme le langage lui-même : une fois que tu as dépensé 6 mois de ta vie à apprendre des trucs sans aucune logique auxquels on a collé des noms abscons, alors, forcément, tu commences à trouver ça bien parce que bon, dire le contraire reviendrait à jeter 6 mois de sa vie (ou du moins, c'est perçu comme tel).

                            Java, c'est le Qwerty des langages de programmation : il ne fait rien de bien et il le fait de manière compliquée mais tout le monde l'utilise parce que... tout le monde l'utilise.

                            Enfin, il est vrai que connaître Java est un atout indéniable. C'est comme le Cobol. 3 programmeurs Java qui ont leur conception d'un EJBS et spring sur un jboss personnalisé buildé avec un script Maven de 2000 lignes peuvent, en 3 mois, te créer 2 Go de code que plus personne ne saura même comment faire fonctionner.

                            Mes livres CC By-SA : https://ploum.net/livres.html

                            • [^] # Re: Grillé

                              Posté par  . Évalué à 1.

                              >>"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 ?

                              • [^] # Re: Grillé

                                Posté par  (site web personnel, Mastodon) . Évalué à 5.

                                "Et au passage Eclipse et Netbeans ont une UI dégueulasse, des boutons partout et sont totalement inutilisables ?"

                                Ben.. je ne vois rien à ajouter, on est parfaitement d'accord :-)

                                Mes livres CC By-SA : https://ploum.net/livres.html

                              • [^] # Re: Grillé

                                Posté par  (site web personnel) . Évalué à 8.

                                t au passage Eclipse et Netbeans ont une UI dégueulasse, des boutons partout et sont totalement inutilisables ?

                                Je suis d'accord avec toi sur beaucoup de points, mais là... Il faut avouer que c'est dur d'utiliser eclipse quand on a gouté à vim...

                                • [^] # Re: Grillé

                                  Posté par  . Évalué à 4.

                                  D'ailleurs, par ces temps de froid, c'est cool d'être un vi-king!

                                • [^] # Re: Grillé

                                  Posté par  (site web personnel) . Évalué à 2.

                                  T'as essayé le plugin vim pour eclipse ? ou inversement ?

                                  Ça fait un moment que je me dis que je devrais le faire, j'en ai marre d'utiliser la souris :D.

                                  • [^] # Re: Grillé

                                    Posté par  (site web personnel) . Évalué à 5.

                                    Pour moi l'intérêt de vim, c'est sa légereté. Alors, un plugin vim pour eclipse, je vois pas trop l'intérêt...

                                    • [^] # Re: Grillé

                                      Posté par  (site web personnel) . Évalué à 3.

                                      Euh, permettre aux habitués de vim de garder leurs habitudes par rapport aux raccourcis claviers?

                                    • [^] # Re: Grillé

                                      Posté par  (site web personnel) . Évalué à 2.

                                      vim est très utile pour aller éditer des fichiers rapidement mais pas seulement ! Même s'il s'ouvrait 20 fois plus lentement, il resterait un très bon éditeur !

                                      Sous eclipse parfois je regrette certaines fonctions que l'on ne trouve pas dans des éditeurs classiques.

                            • [^] # Re: Grillé

                              Posté par  . Évalué à 7.

                              J'en veux pour preuve que tu flaires un programme Java à 15km à son UI dégueulasse, ses bouttons partout et son anti-utilisabilité.
                              Tu confonds, gnome, c'est fait en Mono.

                              Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

                              • [^] # Re: Grillé

                                Posté par  . Évalué à 5.

                                Il a parlé de boutons partout ! Donc ça peut pas être Gnome : y a plus que "valider", et ils envisagent déjà de le retirer...

                      • [^] # Commentaire supprimé

                        Posté par  . Évalué à 2.

                        Ce commentaire a été supprimé par l’équipe de modération.

                        • [^] # Re: Grillé

                          Posté par  . Évalué à 3.

                          Ce n'est pas le plus gros site du monde c'est vrai. Mais ce n'est pas le plus petit non plus. En journée, il y a en moyenne 30 hits par secondes. Avec du java, on partirait surement directement vers une architecture distribuée et toutes les complication que cela entraine. Ici, on a un seul serveur qui tient très bien la mesure.
                          J'adore ce genre d'affirmations sans preuves, sans chiffres, sans arguments...

                          • [^] # Commentaire supprimé

                            Posté par  . Évalué à 4.

                            Ce commentaire a été supprimé par l’équipe de modération.

                            • [^] # Re: Grillé

                              Posté par  . Évalué à 3.

                              Bien entendu, je demandais des preuves et des chiffres pour l'affirmation "Avec du java, on partirait surement directement vers une architecture distribuée et toutes les complication que cela entraine.", ce que tu n'as visiblement pas compris. Et dans ta réponse, toujours les mêmes affirmations débiles.

                        • [^] # Re: Grillé

                          Posté par  . Évalué à 5.

                          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.

                          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.

                          • [^] # Commentaire supprimé

                            Posté par  . Évalué à 4.

                            Ce commentaire a été supprimé par l’équipe de modération.

                            • [^] # Re: Grillé

                              Posté par  . Évalué à 2.

                              Loin de moi l'idée de vouloir défendre à tout prix java/J2EE mais je pense que tu as oublié que l'on est pas obligé de passer par struts/spring/hibernate/jmx/jms/les beans/whatever .. pour faire un site en Java/j2EE.

                              Ces technos sont à disposition et utilisables de manière indépendantes les unes des autres.

                              C'est comme partout, y'a du bon et du moins bon, de l'adapté à tes projets ou pas. Mais de là à qualifier les libs classiques java de bloatware ou de trouver qu'éditer un fichier de config (xml ou non) avec vim est compliqué je ne dirai qu'un mot : FUD

              • [^] # Re: linuxfr.org en Java + ruby => JRails

                Posté par  . Évalué à 1.

                Si Java est robuste et scalable, et que rails est expressif et puissant et convivial et ...
                Pourquoi ne pas tenter Jruby on Rails ?

                Ce n'est pas pour rien que sun paye plusieurs personnes à plein temps
                sur ce langage !)

                -- Maurice

          • [^] # Re: Grillé

            Posté par  . Évalué à 3.

            Et tant qu'à lancer le débat, pourquoi pas en Java

            Déja essayé... http://la.buvette.org/wikipics/linuxfr.org.1er-avril.html

            • [^] # Re: Grillé

              Posté par  . Évalué à 5.

              Sinon pour concilier les deux vous pouvez essayer JRuby (On rails).
              C'est du Ruby on rails mais exécuté par une JVM java. Avantage: meilleure performance puisque JRuby surclasse nettement l'implémentation officielle de Ruby.

            • [^] # Re: Grillé

              Posté par  . Évalué à 3.

              Déja essayé... http://la.buvette.org/wikipics/linuxfr.org.1er-avril.html

              Hahaha :

              500 Internal Server Error

              java.lang.NullPointerException
              at login.doGet(login.java:98)
              at javax.servlet.http.HttpServlet.service(HttpServlet.java:195)
              at javax.servlet.http.HttpServlet.service(HttpServlet.java:309)
              at javax.servlet.http.HttpServlet.service(HttpServlet.java:336)
              at com.evermind[Oracle9iAS (1.0.2.2.1) Containers for J2EE].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:508)
              at com.evermind[Oracle9iAS (1.0.2.2.1) Containers for J2EE].server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:177)
              at com.evermind[Oracle9iAS (1.0.2.2.1) Containers for J2EE].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:576)
              at com.evermind[Oracle9iAS (1.0.2.2.1) Containers for J2EE].server.http.HttpRequestHandler.run(HttpRequestHandler.java:189)
              at com.evermind[Oracle9iAS (1.0.2.2.1) Containers for J2EE].util.ThreadPoolThread.run(ThreadPoolThread.java:62)

          • [^] # Re: Grillé

            Posté par  (site web personnel, Mastodon) . Évalué à 2.

            > Et tant qu'à lancer le débat, pourquoi pas en Java maintenant que ça-sent-bon-c'est-libre ?

            Parce que peut-être y'a pas une ferme de mainframe avec 4 TB de Ram à disposition ?

            Mes livres CC By-SA : https://ploum.net/livres.html

            • [^] # Re: Grillé

              Posté par  . Évalué à 3.

              Rhooo le troll. 4Go pour la JVM c'est déjà pas mal :)

              • [^] # Re: Grillé

                Posté par  . Évalué à 1.

                Beaucoup de trop même, je préconise plutôt 4 jvm à 1 Go

          • [^] # Re: Grillé

            Posté par  (site web personnel) . Évalué à 6.

            fait plus penser à un concours d'obfuscated LISP qu'à un design moderne
            D'ailleurs pourquoi ne pas refaire le site en utilisant une seule et unique expression Lisp? C'est inutile donc indispensable. "je crois que le bug se trouve à la 3427ième parenthèse ouvrante"

        • [^] # Re: Grillé

          Posté par  (site web personnel) . Évalué à 6.

          > C'est du templeet ~~

          Oui, ça résume bien le problème.

          LinuxFr.org est le seul site avec un trafic conséquent qui utilise templeet. Cela pose des problèmes car nous sommes souvent les seuls à subir certains bugs. Par exemple, nous devons être les seuls à utiliser le système de cache de templeet, car celui-ci est régulièrement cassé, et nous avons dû le débugger par nous-mêmes.

          Templeet est également un frein à l'évolution du site, car l'absence de communauté et sa syntaxe proche du lisp font que nous avons très peu de contributions directes et très peu de modules disponibles. Un exemple parmi tant d'autres : il n'y a rien pour faire de l'OpenID avec templeet.

          Enfin, pour avoir utilisé régulièrement Ruby on Rails et templeet au cours des derniers mois/années, je vois le gouffre qui les sépare, et j'ai de plus en plus de mal à me plonger dans le code de LinuxFr.org.

          Allez, un dernier lien (pub) sur le sujet : http://blog.menfin.info/post/2007/09/23/SEPT-RAISONS-POUR-LE(...)

          • [^] # Re: Grillé

            Posté par  . Évalué à 2.

            J'avais fait un module openid pour templeet il y a un an pour rigoler.

          • [^] # Re: Grillé

            Posté par  (site web personnel, Mastodon) . Évalué à 4.

            Et pourquoi pas Django ? Parce que en plus, c'est en Python et c'est installable sur une Debian.

            Mes livres CC By-SA : https://ploum.net/livres.html

            • [^] # Re: Grillé

              Posté par  (site web personnel) . Évalué à 2.

              Peut-être pour la même raison que tu aura du mal à demander a une personne aimant et pratiquant Python/Django de refaire voyages-sncf.com en RoR :)

          • [^] # Re: Grillé

            Posté par  (site web personnel) . Évalué à 3.

            Templeet est également un frein à l'évolution du site, car l'absence de communauté et sa syntaxe proche du lisp font que nous avons très peu de contributions directes

            Vous avez demandé à Paul Graham ?

            • [^] # Re: Grillé

              Posté par  (site web personnel) . Évalué à 6.

              Non, mais templeet a juste une syntaxe proche du lisp, ce n'est pas un lisp (en gros, ca en a juste les inconvénients, pas les avantages).

    • [^] # Re: Grillé

      Posté par  . Évalué à 0.

      Question d'un ignorant : pourquoi abandonner aussi le PHP pour Ruby ?

      Il y a des raisons objective ou c'est juste par gout ou compétance (on ne peut pas tout connaitre, évidement) ?

      • [^] # Re: Grillé

        Posté par  . Évalué à 4.

        Parce que Ruby on Rails c'est :
        - plus beau
        - plus pratique
        - plus maintenable
        - plus orienté-objet et comportement

        Alors que PHP c'est comme le côté obscur, c'est juste plus "rapide" et plus "séduisant".

        Ah, non, mince, Ruby est aussi plus rapide et plus séduisant.

      • [^] # Re: Grillé

        Posté par  (site web personnel) . Évalué à 4.

        Par compétences : non. Je connais bien Ruby on Rails et PHP.

        Pour des raisons objectives : oui (mais on va m'accuser de troller) : les frameworks MVC en PHP sont un niveau en dessous de Rails (pour les meilleurs), ont des performances rarement à la hauteur. Et ne pas utiliser de frameworks ou en recoder un est une grosse perte de temps (sur le développement, mais aussi à maintenir dans le temps).

        Enfin, c'est également un choix par goût : je préfère Ruby à PHP. Je tiens également Django en haute estime, et je n'ai choisi Rails par rapport à Django principalement parce que je connais mieux Ruby que Python.

        • [^] # Re: Grillé

          Posté par  . Évalué à 1.

          C'est un projet personnel ou y en a d'autres sur le coup ?

          • [^] # Re: Grillé

            Posté par  (site web personnel) . Évalué à -6.

            surement tu connais pas le principe de git et github... Bon bah pour la peine je te l'expliquerai pas. google est ton ami.

  • # On peut aider ?

    Posté par  . Évalué à 4.

    On peut aider ? Pour mettre des css qui piquent les yeux dans la pure tradition par exemple ?

    Envoyé depuis mon lapin.

    • [^] # Re: On peut aider ?

      Posté par  (site web personnel) . Évalué à 3.

      Pour la CSS, c'est encore bien trop tôt. Pour le code, le développement se passe sur Github. Il est possible de forker, d'implémenter des fonctionnalités qui existent actuellement et de demander un merge.

  • # Si on peut aider

    Posté par  . Évalué à 3.

    pour code Ruby, ou autres. Je serais disponible (enfin a peu près comme tout le monde) et motivé.

  • # et pourquoi pas ...

    Posté par  (Mastodon) . Évalué à 3.

    Drupal ?

    je dit ça comme ça, mais c'est juste car il y a déjà une tribune en module ....

    \_o<

    poussez pas ... -->[]

    • [^] # Re: et pourquoi pas ...

      Posté par  (site web personnel) . Évalué à 2.

      Bonjour,

      Personnellement, Drupal, bien que un peu lent, n'est pas une si mauvaise idée :) . Il est déjà très développé, et très puissant.

      Par exemple, il propose un bon module de forum parfaitement intégré, un bon système d'articles (dans l'admin, ça prend 2 cliques pour crée un nouveau type d'articles (Journal, Dépêche, etc) et de définir ses propriétés), un excellentissime système de gestion des droits et des groupes, et plein d'autres choses.

      Bref, je n'estimais pas ce commentaire digne d'être moinssé, alors qu'il faut le prendre en compte :) .

      Ce n'est peut-être pas un exemple, mais ubuntu-fr.org utilise Drupal (ok, seulement la page d'accueil), et le site de Logram (voir ma signature ;-) ). Je crois qu'il doit y avoir plein d'autres sites intéressants qui l'utilisent aussi.

      Quoique vous fassiez, bonne chance :) .

      • [^] # Re: et pourquoi pas ...

        Posté par  . Évalué à 4.

        Heu, personnellement, je trouve que drupal est une très mauvaise idée.
        C'est vachement bien, mais quand tu tombes sur ses limites, d'un coup, tu pleures.
        J'ai eu à faire un site en Drupal pour une entreprise. Dans cette boîte, les logins des utilisateurs sont, pour des raisons pratiques, sous une forme numérique (exemple : 20001686).
        Le site que je devais faire aller devoir s'authentifier sur un annuaire LDAP. J'ai vu le module drupal pour le LDAP, je me suis dit que c'était bon... Que nenni...
        Dans drupal, il y a une supposition vraiment stupide : login == pseudo.
        C'est typiquement le genre d'anomalie qu'on doit contourner, et c'est hyper chiant à la longue d'accumuler des tonnes de changements comme ça.

      • [^] # Re: et pourquoi pas ...

        Posté par  (site web personnel) . Évalué à 3.

        Je ne connais pas super bien Drupal, mais j'aurais risqué de rencontrer deux gros problèmes avec Drupal :
        1) les performances,
        2) le schéma de la base de données est propre à Drupal, et il aurait été très difficile de réimporter les anciennes données.

  • # Et pourquoi pas en C (voir C++)

    Posté par  . Évalué à 1.

    Gains à tous les étages sauf pour le développement (et encore dans certains cas ça reste à prouver)

    • [^] # Re: Et pourquoi pas en C (voir C++)

      Posté par  . Évalué à 1.

      En termes de perf pour les cgi, cest pas vraiment mieu que du script (même pire), surtout à haute charge. A moin de tout faire dans un module apache.

      • [^] # Re: Et pourquoi pas en C (voir C++)

        Posté par  . Évalué à 2.

        D'où la création de FastCGI : http://en.wikipedia.org/wiki/FastCGI
        C'est notamment ce qui est utilisé avec lighttpd pour pouvoir faire du PHP : pas de mod_php qui va entraîner le serveur web dans sa chute (et je t'assure, c'est facile de planter mod_php sans droits particuliers, heureusement que les processus d'apache se relancent tout seul, mais c'est loin d'être "fluide")

    • [^] # Re: Et pourquoi pas en C (voir C++)

      Posté par  . Évalué à 5.

      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.

      Autrement tu pourras m'expliquer les gains ?

  • # Défi

    Posté par  . Évalué à 4.

    Vu la vitrine que représente linuxfr ce serait intéressant de faire du choix du framework et du langage une sorte de défi. On prendrait une partie critique du site à faire et on bencherait autant la vitesse de sortie que le nombre de ligne de code.

    • [^] # Re: Défi

      Posté par  (site web personnel) . Évalué à 8.

      Si des gens veulent coder ça dans d'autres langages, pourquoi pas. Moi, je vais avoir déjà bien assez de boulot avec la version Rails.

    • [^] # Re: Défi

      Posté par  . Évalué à 4.

      Au final, cela reviendrait surtout à "bencher" les système de cache et les performances de la base de données, non ?

      Memcached vs Terracotta, MySql vs PostgreSQL (nooooooo do not feed the troll)

      Après, derrière, que ce soit PHP/Django/Ror/J2EE, je doute que les écarts soit si importants si on reste sur un unique serveur Web+DB

      • [^] # Re: Défi

        Posté par  . Évalué à 2.

        Terracotta sur un seul serveur c'est que de l'overhead. Pas vraiment besoin de bench :-)

        Pour le reste je suis d'accord

Suivre le flux des commentaires

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