Journal Pourquoi réécrire LinuxFr.org ?

Posté par (page perso) .
Tags :
43
25
nov.
2010
LinuxFr.org tourne actuellement avec un moteur qui s 'appelle templeet et, à dire vrai, ça tourne plutôt bien. Et pourtant, je suis en train de réécrire le site avec Ruby on Rails parce que je pense que c'est indispensable pour que le site puisse continuer à vivre. J'ai déjà pu donner quelques explications, notamment dans les commentaires, mais je ne crois pas avoir déjà fourni une explication complète.

Alors, pourquoi cette réécriture ? 2 raisons : maintenance et évolutions.

Pour la maintenance, je ne connais plus personne prêt à contribuer à LinuxFr.org qui connaisse templeet en profondeur. Je ne parle pas seulement de savoir utiliser templeet, mais également être capable de corriger des bugs dans les entrailles de templeet. En fait, même le développeur actuel de templeet n'est probablement plus en mesure de nous aider. Nous utilisons la version 3 de templeet et lui se concentre sur la version 4. Ces 2 versions sont très éloignées, à tel point qu'il ne nous paraît pas envisageable de migrer vers la nouvelle version.

À titre d'exemple, nous avons un bug connu sur le système de cache qui insère des 'my' dans tous les URL. Le bug n'arrive pas très fréquemment et il suffit de purger le cache à ce moment là pour réparer, mais nous préférerions ne pas avoir à faire ça. Nous avons essayé de corriger le bug, mais nous n'en avons pas été capable. Pire, quand on trace l'exécution du module de cache de templeet, on se rend compte qu'il ne passe jamais par le même chemin.

Ce problème n'est pas très gênant, mais si nous devions mettre à jour PHP pour des raisons de sécurité et que cela introduisait une régression dans templeet, nous serions bien en peine pour la corriger. Il est donc très dangereux de continuer à fonctionner avec un moteur non maîtrisé.

L'autre raison est l'évolution. Quand on regarde les statistiques, on se rend compte que le nombre de visiteurs reste stable mais que le nombre de contenus (aussi bien dépêches que journaux, forums ou commentaires) diminue un peu chaque année. Le site doit donc évoluer pour permettre à plus de personnes de contribuer.

Or, pour évoluer, cela demande des personnes qui codent. Idéalement, nous souhaiterions que les lecteurs puissent proposer des patchs pour le faire évoluer et intégrer dans l'équipe les personnes contribuant régulièrement. À défaut, le site peut évoluer avec juste un ou deux développeurs si ceux-ci sont efficaces.

Dans les deux cas, cela demande d'avoir une documentation à jour, des modules/bibliothèques et un moyen de pouvoir discuter avec d'autres développeurs (forums, mailing-lists, IRC). Pour templeet, les 3 manquent. Essayez donc d'aller lire la doc du module session (le lien pointe vers la doc en français qui est plus complète que celle en anglais), de trouver un composant de coloration syntaxique du code ou de trouver un développeur templeet. Vous allez voir, c'est très compliqué.

Dans ces conditions, la survie du site à moyen terme me semblait (et me semble toujours) passer obligatoirement par une réécriture. Cette réécriture ne résoudra pas magiquement tous les problèmes comme la baisse des contributions, mais en tout cas, c'est un pas en avant qui devrait bien aider.
  • # Et le choix de Ruby on Rails ?

    Posté par . Évalué à  10 .

    Merci pour cette explication de l'abandon de Templeet... Ça fait des années qu'on nous dit que Templeet pour Linuxfr pose des problèmes, il est clair qu'il faut migrer un jour ou l'autre.
    Par contre, pourquoi choisir Ruby on Rails ?
    Est-ce un choix justifié techniquement, ou juste une préférence personnelle ?
    J'ai souvent lu des critiques concernant les performances souvent mauvaises de Ruby on Rails, et pour un site comme LinuxFR je pense que les performances ça compte énormément. Actuellement, la navigation est très fluide, le site ne rame pas du tout, c'est un plaisir à utiliser. Si demain le site devenait plus lent, ce serait une réelle régression...
    À titre personnel, je ne contribuerai pas à un LinuxFR en Ruby on Rails tout simplement parce que je n'aime pas le développement web et que je ne connais ni Ruby ni Ruby On Rails.
    • [^] # Re: Et le choix de Ruby on Rails ?

      Posté par . Évalué à  3 .

      Parce que ...
      le site peut évoluer avec juste un ou deux développeurs si ceux-ci sont efficaces.
      Ruby on Rails est parfait pour ça. La structure même du framework fait qu'un développeur habitué à Rails s'y retrouvera vite dans l'organisation du code.
      • [^] # Re: Et le choix de Ruby on Rails ?

        Posté par . Évalué à  10 .

        Pareil pour Django.
        Pareil pour Synphony.
        Pareil pour tout framework bien foutu quoi...
        • [^] # Re: Et le choix de Ruby on Rails ?

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

          Django et Rails se valent. Le choix entre les deux s'est fait principalement parce que je connais bien mieux Rails et que je préfère le Ruby au Python.

          Pour les frameworks PHP, quand j'ai commencé la nouvelle version (il y a 2 ans), ils étaient loin d'avoir le même niveau que Rails et Django. Aujourd'hui, je ne sais pas ce que valent les frameworks PHP comme Symfony, mais les dernières discussions que j'ai pu avoir à ce sujet me laissent penser qu'il reste encore du travail avant qu'il n'arrive au niveau de Rails ou Django.

          Il existe aussi de bons frameworks dans des langages moins connus, mais je voulais rester avec un framework connu pour attirer des contributeurs et être sur qu'il soit maintenu pendant encore un paquet d'années.
          • [^] # Re: Et le choix de Ruby on Rails ?

            Posté par (page perso) . Évalué à  -4 .

            Ne faite surtout pas du PHP ! Pour la charge d'un site comme linuxFR, on va pas reparser tout les fichiers à chaques requêtes. PHP est un langage de template et puis c'est tout.

            Suffit de voir les logiciels PHP bien foutu (wordpress, piwik, mediawiki). C'est super lourd !

            Comment atteindre le niveau d'un SQLAlchemy ou ActiveRecord avec un langage de template comme PHP ? …

            Étienne
            • [^] # Re: Et le choix de Ruby on Rails ?

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

              Tu dois connaître wikipedia ou facebook. Ces deux sites sont dans le top 10 des sites les plus visités dans le monde, et ils sont codés en php. Fou non ? Surtout pour wikipedia qui utilise mediawiki, que je trouve aussi super lourd.

              Pour information, il existe des systèmes de cache (joliment appelés accélérateurs) pour ne pas reparser les fichiers.

              Dans le cas de facebook, ils transforment même le php en C++, ce qui a offert un gain en performances x2. À mon avis, leur problème à facebook se situe plus du cotés des bases de données et de la bande passante.

              Tout ça pour dire que le php n'est pas un truc à ne pas utiliser. C'est pas le langage le plus fun, mais il possède un code source relativement simple (bien que moche selon mes goûts), et est utilisé sur des très grands sites.

              Envoyé depuis mon lapin.

              • [^] # Re: Et le choix de Ruby on Rails ?

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

                > À mon avis, leur problème à facebook se situe plus du cotés des bases de données et de la bande passante.

                Facebook est sûrement confronté à des tas de problèmes, mais si on compte les serveurs, les serveurs web seraient bien plus nombreux que les serveurs de base de données ou de cache. En gros, le nombre de serveur PHp se compte en dizaines de milliers, le nombre de serveur de bases de données en milliers et ceux de memcached "seulement" en centaines.

                Quelques chiffres qui datent de 2008 : http://www.paragon-cs.com/wordpress/?p=144
            • [^] # Re: Et le choix de Ruby on Rails ?

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

              C'est ironique ou... ?

              Tout serveur de production PHP qui se respecte active une extension d'accélération pour ne pas reparser les fichiers à chaque requête.

              Quant aux frameworks PHP, Symfony2 n'est pas encore terminé (sortie prévue en mars 2011), mais pour le pratiquer au quotidien je peux vous dire que, couplé à Doctrine2, c'est une petite révolution dans le monde PHP. Le principe est de piocher le meilleur de ce qui se fait ailleurs, et Symfony1 était largement inspiré de Ruby on Rails.
              • [^] # Re: Et le choix de Ruby on Rails ?

                Posté par . Évalué à  4 .

                Le principe est de piocher le meilleur de ce qui se fait ailleurs, et Symfony1 était largement inspiré de Ruby on Rails.

                Mais porquoi se contenter d'une pale copie alors qu'on peut avoir l'original, bien plus efficace et performant ?
                • [^] # Re: Et le choix de Ruby on Rails ?

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

                  Ce n'est pas ce que je disais. Tu sembles considérer que le meilleur ne se trouve que chez Ruby on Rails alors que ce n'est qu'une partie des concepts de Symfony qui viennent de là. Il semble que Doctrine2 soit plus inspiré de Java Hibernate et le système d'événements de Symfony2 reprend le principe de Cocoa par exemple.
                  Pour plus d'infos:
                  http://symfony-reloaded.org/

                  Sur le côté "bien plus efficace et performant" j'imagine que tu as fait des benchmarks ?
                  • [^] # Re: Et le choix de Ruby on Rails ?

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

                    et en terme de perf ?
                    Par exemple Symfony 2.x version CakePHP ?
                    Sur le site, ils montrent un benchmark entre Sym' et Cake, mais je me méfie toujours de ce genre d'annonce. Quelqu'un a un retour sur ce genre de "versus" ?
                • [^] # Re: Et le choix de Ruby on Rails ?

                  Posté par . Évalué à  3 .

                  Parce que tout le monde n'a pas forcément envie d'apprendre un nouveau langage, surtout quand il en maîtrise déjà un.

                  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                  • [^] # Re: Et le choix de Ruby on Rails ?

                    Posté par . Évalué à  -1 .

                    Mais Ruby est simple à apprendre, et bien plus intéressant que Python: en ruby tu n'es pas obligé de déclarer explicitement ce que tu fais. Quant à PHP ,'en parlons même pas. Une horreur sans nom.
                    • [^] # Re: Et le choix de Ruby on Rails ?

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

                      Que veux tu dire par là ?

                      Si tu parles de la permissivité des objets (genre utiliser des données membres non déclarées), il me semble que python est aussi sympa que ruby.

                      Envoyé depuis mon lapin.

                    • [^] # Re: Et le choix de Ruby on Rails ?

                      Posté par . Évalué à  3 .

                      La simplicité est toute relative.

                      Tout le monde me dit que Mac c'est mieux parce que c'est plus simple, et pourtant je suis tout perdu quand j'arrive devant.

                      Pourquoi ? Parce que ça a beau être simple, c'est différent de ce que j'ai l'habitude d'utiliser de manière intensive.

                      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                      • [^] # Re: Et le choix de Ruby on Rails ?

                        Posté par . Évalué à  2 .

                        La différence, c’est qu’il m’a suffit d’une journée pour me faire à l’interface de MacOS X (et un deuxième jour pour trouver où activer les bureaux virtuels ;)), tandis que pour prendre mes marques sous vim+wmii, il m’a fallu plus de temps que ça (mais je ne le regrette pas :))
                        • [^] # Re: Et le choix de Ruby on Rails ?

                          Posté par . Évalué à  3 .

                          Ça m'étonnerait qu'en deux jours, je puisse retrouver toutes les fonctionnalités et la puissance d'outils que j'utilise depuis cinq ans.

                          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                          • [^] # Re: Et le choix de Ruby on Rails ?

                            Posté par . Évalué à  2 .

                            Pas toute la puissance non, mais largement de quoi ne pas être perdu.
                            • [^] # Re: Et le choix de Ruby on Rails ?

                              Posté par . Évalué à  2 .

                              Ça dépend de ce qu'on cherche, il y a une marge entre « ne pas être perdu » et « être efficache ».

                              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                              • [^] # Re: Et le choix de Ruby on Rails ?

                                Posté par . Évalué à  3 .

                                Déjà, tu disais « MacOS c’est pas simple, je suis tout perdu ». C’est à ça que je répondais.
                                Ensuite, sur le fond, c’est assez simple de prendre en main la pleine efficacité de MacOS X (entre une et deux semaines, d’expérience), le problème, c’est que la pleine efficacité de MacOS X, c’est rien par rapport à ce qu’on peut trouver ailleurs dans le libre (vim, wmii, pour rester dans le même exemple)
                                • [^] # Re: Et le choix de Ruby on Rails ?

                                  Posté par . Évalué à  2 .

                                  Oui, j'ai parlé de MacOSX comme exemple pour dire que l'argument « c'est simple donc on peut l'apprendre rapidement » n'est pas forcément pertinent.

                                  En plus, tu confirmes en relativisant son efficacité par rapport à ce que tu connaissais déjà.

                                  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                                • [^] # Re: Et le choix de Ruby on Rails ?

                                  Posté par . Évalué à  0 .

                                  La truc avec macos c'edt que les 80% de fonctionnalites utilisees par tout le monde sont effectivement tres simple a apprendre.
                                  La plupart n'ont pas besoin du reste et s'arretent la. C'est ce que t'appelles, je pense, la pleine efficacite de macos.

                                  Les 20% restants sont pourtant bel et bien presents, reste a les apprendre.
                                  La c'est moins evident, mais c'est tout a fait faisable.

                                  Quand a vim, il est dispo sur mac par defaut bien evidemment.
                                  Le wm de macos permet ds merveilles un fois qu'on a compris son paradigme (oriente document et pas oriente applications) et les qq racciurcis qui vont bient. Apres on aime ou on aime pas, les gout et les couleurs.

                                  If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                                  • [^] # Re: Et le choix de Ruby on Rails ?

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

                                    Les 20% restants tu les faits en ligne de commande. ETerm est très bien, tu as des tabs, il est scriptable...
                                    C'est sur que si tu tiens absolument à ton clickodrome ça devient plus compliqué.

                                    Mais Macos reste un Unix et ça c'est cool

                                    Un pays bien organisé est celui où le petit nombre fait travailler le grand nombre, est nourri par lui, et le gouverne - Voltaire

                                  • [^] # Re: Et le choix de Ruby on Rails ?

                                    Posté par . Évalué à  2 .

                                    > Le wm de macos permet ds merveilles un fois qu'on a compris son paradigme
                                    Le wm de MacOS est orienté application (cad que tu switches entre les applications), contrairement aux WM classiques qui sont orientés fenêtre.
                                    Et le coup de « pas de raccourci unifié pour switcher entre les fenêtres d’une application », c’est un manque franchement énorme.
                                    • [^] # Re: Et le choix de Ruby on Rails ?

                                      Posté par . Évalué à  2 .

                                      Euh, c'est pas à ça que sert F10 ou un truc du genre ?
                                    • [^] # Re: Et le choix de Ruby on Rails ?

                                      Posté par . Évalué à  1 .

                                      Bien sur que ca existe. Comme la plupart des trucs dont les gens pensent que ca n'existe pas sous macos.
                                      Cmd tilde sur clavier qwerty.

                                      Et si, il est oriente documents, lit qq docs cocoa pour t'en convaincre, ou regarde le nombre d'applis mdi la ou leur version windows/mac sont sdi.

                                      If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                                      • [^] # Re: Et le choix de Ruby on Rails ?

                                        Posté par . Évalué à  2 .

                                        > Cmd tilde sur clavier qwerty.
                                        Marche sur le terminal, pas sur Xcode.
                                        J’en déduis que c’est pas le WM mais l’appli.

                                        > Et si, il est oriente documents, lit
                                        Les HIG, et dans une certaine mesure les API, sont orientés document oui. Mais pas le WM : tu switches entre applications, pas documents.
                                        • [^] # Re: Et le choix de Ruby on Rails ?

                                          Posté par . Évalué à  1 .

                                          Apple a l'habitude de changer les raccourcis selon les claviers, questio d'accessibilite. J'ai donc aucune idee de ce que peut etre le raccourci sur un clavier fr.

                                          Honnetement, je m'en sert toute la journee du cmd tilde, si tu dois me faire confiance sur truc, que ca soit ca. Ca marche partout. Surtout dans xcode 3 et ses 25 fenetres.
                                          Au passage, chapeau, utiliser xcode sans ce raccourci... T'as ete mechant dans une vie anerieure? :)
                                          Essayes la version 4, tu sortiras du purgatoire :)

                                          If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                                          • [^] # Re: Et le choix de Ruby on Rails ?

                                            Posté par . Évalué à  2 .

                                            Non, j’ai appris les raccourcis pour mettre en avant plan la fenêtre principale et la console, ça suffit pour 95% des cas.

                                            > Honnetement, je m'en sert toute la journee du cmd tilde, si tu dois me faire confiance sur truc, que ca soit ca.
                                            Bon, je vais réessayer demain. Je suis persuadé d’avoir déjà essayé et que ça marchait pas, mais je serai ravi d’avoir tort ;)
                  • [^] # Re: Et le choix de Ruby on Rails ?

                    Posté par . Évalué à  1 .

                    Apres, si tu maitrises reellement un langage, en apprendre un autre est facile, pas plus dur que d'apprendre un framework en tout cas.
                    Si tu maitrises plusieurs langage, ca sera le dernier de tes soucis.

                    If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                    • [^] # Re: Et le choix de Ruby on Rails ?

                      Posté par . Évalué à  3 .

                      Seulement si les deux langages sont basé sur le même paradigme.

                      Parce que si tu prend un programmeur qui n'a jamais fait que du procédural et que tu lui donne un langage fonctionnel il sera encore plus perdu qu'un débutant.
                      • [^] # Re: Et le choix de Ruby on Rails ?

                        Posté par . Évalué à  0 .

                        C'est pas faux.
                        Apres on parle de dev web, faire du procedural ou du fonctionnel dans ce contexte, faut avoir du temps a perdre.

                        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                        • [^] # Re: Et le choix de Ruby on Rails ?

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

                          c'est paradigme que tu n'as pas compris ?

                          (je reste à l'intérieur, il va neiger là)
                        • [^] # Re: Et le choix de Ruby on Rails ?

                          Posté par . Évalué à  2 .

                          En fonctionnel ça ce fait très bien apparemment:
                          http://www.paulgraham.com/arc.html
                          (arc est une variante de lisp)

                          Pour avoir un exemple:
                          http://www.paulgraham.com/arcchallenge.html
                          • [^] # Re: Et le choix de Ruby on Rails ?

                            Posté par . Évalué à  2 .

                            Oui oui, bien sur.
                            D'ailleurs J2EE et PHP sont sur le point de se faire faire la nique par OCaml On Rails.

                            If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                            • [^] # Re: Et le choix de Ruby on Rails ?

                              Posté par . Évalué à  2 .

                              Oui oui, bien sur.
                              D'ailleurs J2EE et PHP sont sur le point de se faire faire la nique par OCaml On Rails.

                              C'est quoi ce ton condescendant. Qui a parlé de remplacer Jtruc et php? On est pas sur un site de passionnés d'informatique, s'intéressant à linux, aux logiciels libres, ayant de la curiosité pour les nouvelles technologies et les machins cool qu'on peut faire avec un ordinateur ici? On associe pas "curiosité" avec "hacker" et "geek" d'habitude?
                              • [^] # Re: Et le choix de Ruby on Rails ?

                                Posté par . Évalué à  -2 .

                                Sisi, de la a dire que ca se fait tres bien, ya un pas que je ne franchirais, d'ou le ton, desole s'il t'as blesse.

                                Je sais pas, c'est un peu comme si je te disais "ecrire un programme en whitespace, ca se fait tres bien".
                                Que la communaute du fonctionnel soit active et fasse des trucs de ce genre, tant mieux, pis j'aime bien le fonctionnel, je trouve ca elegant.
                                Mais c'est clairement inutilisable pour un projet web.

                                If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                                • [^] # Re: Et le choix de Ruby on Rails ?

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

                                  Le fonctionnel clairement inutilisable pour un projet web ?

                                  Je ne serais pas aussi affirmatif que toi. Il existe des frameworks web dans des langages fonctionnels dont certains sont assez avancés/intéressants :

                                  - Nitrogen en Erlang : http://nitrogenproject.com/
                                  - HAppS en Haskell : http://happs.org/
                                  - Ocsigen en OCaml : http://ocsigen.org/
                                • [^] # Re: Et le choix de Ruby on Rails ?

                                  Posté par . Évalué à  2 .

                                  Sisi, de la a dire que ca se fait tres bien, ya un pas que je ne franchirais, d'ou le ton, desole s'il t'as blesse.
                                  OK, c'est vrai qu'il y a eu mésentente et que je l'ai mal pris.

                                  Je sais pas, c'est un peu comme si je te disais "ecrire un programme en whitespace, ca se fait tres bien".
                                  Le site web est spartiate et aurait effectivement pu donner cette impression.
                                  Mais c'est clairement inutilisable pour un projet web.

                                  Arc fait tourner hacker news http://news.ycombinator.com/, plus de 30000 visiteurs uniques par jours.
              • [^] # Re: Et le choix de Ruby on Rails ?

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

                Doctrine2… ce truc m'a vraiment détourné des framework PHP. C'est super lourd, tant au niveau code qu'à l'utilisation. Apprendre un nouveau langage de requête, un format de description de schémas (à base de yml), etc. plus la génération de classe PHP…

                Quant on a goûté à SQLAlchemy et son mode déclaratif, c'est vraiment dur de se taper tout ça pour une table.

                http://www.sqlalchemy.org/
              • [^] # Re: Et le choix de Ruby on Rails ?

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

                C'est ironique ou... ?

                Quand on lit Pour la charge d'un site comme linuxFR, on va pas reparser tout les fichiers à chaques requêtes. Et puis qu'on compare à Ruby ou Python, ça répond à ta question.

                « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                • [^] # Re: Et le choix de Ruby on Rails ?

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

                  Sachant qu'en plus Linuxfr tourne actuellement sous PHP.

                  « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                • [^] # Re: Et le choix de Ruby on Rails ?

                  Posté par . Évalué à  3 .

                  Et puis qu'on compare à Ruby ou Python, ça répond à ta question.

                  Euh quand on fait du Web avec Python ou Ruby ça se fait avec des processus persistant, donc même si ce sont des langages interprétés comme PHP, on ne reparse pas les fichiers à chaque requête.

                  Et même avec un "accélérateur" en PHP on doit tout de même initialiser un processus à chaque requête.
        • [^] # Re: Et le choix de Ruby on Rails ?

          Posté par . Évalué à  2 .

          Je ne les connaios pas ... Etant allergique au Python et PHP .....
      • [^] # Re: Et le choix de Ruby on Rails ?

        Posté par . Évalué à  5 .


        La structure même du framework fait qu'un développeur habitué à Rails s'y retrouvera vite dans l'organisation du code.

        N'y aurait-t'il pas une lapalissade qui se serait glissée subrepticement dans cette affirmation ?
        • [^] # Re: Et le choix de Ruby on Rails ?

          Posté par . Évalué à  5 .

          Non. J’ai beau avoir des années de PHP derrière moi, la seule fois où j’ai voulu faire un patch pour LinuxFR, j’ai dû passer 1 semaine pour m’y retrouver très vaguement dans le code. À côté, retrouver ce qu’on cherche dans une application Rails, pour un développeur qui a bossé sur un ou deux projets, c’est immédiat.
          • [^] # Re: Et le choix de Ruby on Rails ?

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

            Je n'ai pas pratiqué Rails mais il me semble que ce que tu dois comparer n'est pas Rails (que tu connais) et PHP (que tu connais aussi) mais Rails (que tu connais) et Templeet (que tu ne connais pas).
            Mais bref je chipote et je vois bien ce que tu veux dire :-)
    • [^] # Re: Et le choix de Ruby on Rails ?

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

      C'est l'autre question que l'on me pose régulièrement. Pareil, il y a des débuts de réponses dans les commentaires mais faudrait que j'en fasse un journal. Ça attendra une prochaine fois (un vendredi de préférence).

      En attendant, http://linuxfr.org/comments/1180393.html#1180393 explique pourquoi je n'ai pas utilisé un CMS.
      • [^] # Re: Et le choix de Ruby on Rails ?

        Posté par . Évalué à  1 .

        Heu, honnêtement, choisir un CMS ça a été considéré sérieusement pour Linuxfr ??
        Vu les performances de ces trucs en général... (j'ai bouffé du drupal, je veux plus jamais y toucher)
        • [^] # Re: Et le choix de Ruby on Rails ?

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

          Oui, ça a été sérieusement considéré. LinuxFr.org est un site avec beaucoup de fonctionnalités et ça demande beaucoup de code pour ça (et donc du temps). Un CMS aurait sûrement permis de sortir plus rapidement une nouvelle version. Mais les performances ont effectivement été le point bloquant.
          • [^] # Re: Et le choix de Ruby on Rails ?

            Posté par . Évalué à  1 .

            SPIP n'aurait pas permis cela?

            Il me semble qu'il comble pas mal de prérequis pour LinuxFR.
            Tout dans sa définition et ses objectifs me font directement penser aux besoins de LinuxFR.
            D'accord, ça c'est la théorie vendue par les auteurs, mais dans la pratique, j'ai vu des sites à fortes fréquentations fonctionnant dessus et ma foi l'expérience n'était pas laborieuse et les pages étaient pourtant plus riches et chargées que sur DLFP.

            C'est juste une question à propos de SPIP, je n'ai aucuns jugement envers RoR.

            Merci en tout cas pour travail qu'il m'est difficile d'apprécié même avec la version Alpha, faut dire que la CSS n'aide vraiment pas.
            • [^] # Re: Et le choix de Ruby on Rails ?

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

              SPIP ? Mais il ne fait quasiment rien de ce qui est attendu. Ça paraît déjà compliqué d'avoir des sondages ou des commentaires sous forme de fil de discussions sous SPIP, alors je ne préfère même savoir comment on peut faire pour les fonctionnalités vraiment difficiles (gestion du karma, seuil de modération des dépêches en fonction du nombre d'AMR, tribune).
      • [^] # Re: Et le choix de Ruby on Rails ?

        Posté par . Évalué à  10 .

        faudrait que j'en fasse un journal. Ça attendra une prochaine fois (un vendredi de préférence).

        ca tombre bien, demain, on est vendredi ;)
    • [^] # Re: Et le choix de Ruby on Rails ?

      Posté par . Évalué à  2 .

      Donc en gros tu ne sais pas de quoi tu parles mais tu penses que c'est un mauvais choix ;)

      Sérieusement, d'après le webalizer linuxfr n'a ni un traffic monstrueux, ni des tas de données non cachables. Si tu mets à genoux une machine de notre siècle avec ca c'est qu'il y a un soucis quelque part.
      • [^] # Re: Et le choix de Ruby on Rails ?

        Posté par . Évalué à  2 .

        J'ai mis un serveur à genoux avec moins que ça, oui... Grâce à des frameworks PHP pas optimisés du tout, c'est facile à faire...
        Et une page d'accueil qui bouffe 2 secondes de CPU côté serveur (et avec les caches du framework activés), c'est pas la joie.
        Au passage, je n'ai pas dit que c'est un mauvais choix, loin de là, je demande juste pourquoi Ruby On Rails en prenant en compte la réputation que j'en ai perçu, c'est tout. Si jugement il y a, c'est dans ton interprétation de mon commentaire, pas dans mon commentaire.
  • # Bon courage

    Posté par . Évalué à  9 .

    Salut Bruno,
    je salue l'initiative et je mesure facilement l'ampleur de la tâche. Bravo à toi de tenter ce développement.
    • [^] # Re: Bon courage

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

      Je m'associe à toutes les moules pour te souhaiter bon courage ! Il faut un jour de je me plonge dans le code, histoire de voir ce que ça donne un site comme dlfp en Ror.

      Alexandre COLLIGNON

  • # Te bile pas

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

    Tout d'abord toutes mes félicitations pour ce travail, et bravo pour l'engagement, ça doit te pomper beaucoup de temps libre.. j'espère pouvoir aider un jour du haut de mes quelques lignes de code en Rails.

    J'ai un peu l'impression que tu as peur qu'on te reproche RoR, alors :

    1. C'est toi qui bosse, donc c'est toi qui décide. Tu es bénévole tout de même, on va pas t'imposer une techno que tu déteste
    2. <troll>Beaucoup de programmeurs PHP n'aiment pas Ruby car ils n'ont pas le niveau pour comprendre la puissance de ce langage</troll>

    Donc bravo, et c'est clair, on sera beaucoup plus à pouvoir t'aider !

    Un pays bien organisé est celui où le petit nombre fait travailler le grand nombre, est nourri par lui, et le gouverne - Voltaire

    • [^] # Re: Te bile pas

      Posté par . Évalué à  4 .

      pour ton 2 je dirais que c'est la même chose avec perl, mais les pythoneux vont encore me tomber sur le râble...

      Il ne faut pas décorner les boeufs avant d'avoir semé le vent

      • [^] # Re: Te bile pas

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

        Oui, enfin la différence entre perl et ruby, c'est que ruby permet d'écrire du code lisible...
        • [^] # Re: Te bile pas

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

          Tu connais le Perl Moderne ?

          Quelque soit le langage, il est assez facile d'écrire du code incompréhensible... Perl est un langage qui évolue régulièrement et en 10 ans, la manière de programmer est devenue très différente.

          Un petit exemple que j'ai vu passer il n'y a pas longtemps. L'objectif est de piloter mpd depuis une interface web écrite avec dancer. C'est pas un exemple archi-compliqué mais c'est intéressant à voir à mon sens.

          http://blog.preshweb.co.uk/2010/11/dancerjukebox-music-queui(...)

          https://github.com/bigpresh/DancerJukebox
          • [^] # Re: Te bile pas

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

            Perl a été écrit par Larry Wall, vainqueur deux fois à l'IOCCC.
            De la à dire que ça se ressent bien dans la lisibilité d'un code en perl, il n'y a qu'un pas, le franchirez vous ?
          • [^] # Re: Te bile pas

            Posté par . Évalué à  3 .

            > Quelque soit le langage, il est assez facile d'écrire du code incompréhensible.

            j'ai jamais compris comment des développeurs (censés avoir un minumum de logique) sont capable de sortir un argument aussi ridicule.

            Si on peut se crouter avec une 2CV comme avec une Mercedes, alors une 2CV et une Mercedes se valent.

            Le monsieur parle de code lisible, pas de code illisible. Et la, yá une petite marge.
            • [^] # Re: Te bile pas

              Posté par . Évalué à  1 .

              En perl il est tout à fait possible d'écrire du code lisible; comme dans la majorité des langages.
              Ensuite, il se trouve que le perl est généralement garni d'expression régulière; et c'est ces derinères qui peuvent rendre le code difficilement lisible, mais quelque soit le langage, si tu utilise les regexp tu vas facilement rendre du code illisible
              tu peux écrire un truc du genre

              while ( my $line = ) {
                if ( my ( $annee,$mois,$jour,$nom,$prenom ) = ( $ligne =~ /^ddn (\d{4})-(\d{2})-(\d{2}) "(.+?)" "(.+?)"/ ) ) {
                  # do something
                }
              }


              pour moi c'est parfaitement lisible (oui y a une paire de ( ) en trop, et $line pourrait être viré, et si tu préfère on peut même déclarer les variables avant, ou même ne pas les déclarer du tout, comme en pytyon );
              si le code est suffisamment clair, y a pas besoin de comprendre la regexp, si le bug est dans la regexp, quelque soit le langage tu risque de ramer.

              Il ne faut pas décorner les boeufs avant d'avoir semé le vent

              • [^] # Re: Te bile pas

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


                while ( my $line = ) {


                Templeet a mangé une partie de la ligne ?

                L'autre option, c'est que ça initialise $line à un truc vide, mais dans ce cas, je ne vois pas comment les lignes suivantes fonctionnent.
                • [^] # Re: Te bile pas

                  Posté par . Évalué à  2 .

                  rahhh oui templeet a bouffé <STDIN>
                  il fallait lire while ( my $line = <STDIN>)

                  Il ne faut pas décorner les boeufs avant d'avoir semé le vent

              • [^] # Re: Te bile pas

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

                Pour rendre des expressions régulières plus lisibles et, surtout, plus faciles à comprendre, il est recommandé d'utiliser le modificateur /x afin de permettre l'insertion de commentaires.

                Exemple :


                /
                (Y) # buffer 1
                ( # buffer
                (X) # buffer 3
                \g{-1} # backref to buffer 3
                \g{-3} # backref to buffer 1
                )
                /x

                http://perldoc.perl.org/perlre.html#Regular-Expressions
            • [^] # Re: Te bile pas

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

              Je ne trouve pas personnellement le code Python ou Ruby particulièrement lisible, voila pour une partie de ma réponse.

              Ensuite ta comparaison sur les voitures est intéressante, j'en conclue que Perl est la Mercedes et Ruby la 2CV ;-)
          • [^] # Re: Te bile pas

            Posté par . Évalué à  2 .

            Quelque soit le langage, il est assez facile d'écrire du code incompréhensible..

            Disons que c'est plus facile avec certains langage qu'avec d'autres.

            Sinon faire du Perl bien lisible (pour le commun des mortels), c'est assez frustrant. On est obigé de se cantonner à un langag de base, sans exploiter pleinement les possibilités du langage. Au bout d'un moment, ça dégoute (ya que le Perl objet qui est imbitable et qui n'aurait jamais du exister).
            • [^] # Re: Te bile pas

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

              une petite pensée pour le premier "framework" de DLFP qui était en PERL, mais qu'ils ont remplacer par php/templeet parce que le PERL était illisible et inmaintenable.

              Ca augure du tout bon pour le ruby :-)
            • [^] # Re: Te bile pas

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

              > ya que le Perl objet qui est imbitable et qui n'aurait jamais du exister

              Tu as regardé du coté de Moose ?
              • [^] # Re: Te bile pas

                Posté par . Évalué à  2 .

                Non. C'est quoi ça ?
                • [^] # Re: Te bile pas

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

                  Justement, si tu ne sais pas, c'est que tu n'y connais rien en Perl Moderne et donc tu bases tes critiques sur du vécu lointain...

                  Moose est le framework Perl conseillé aujourd'hui pour faire de l'objet et les développeurs ont vu les choses en grand et en plus, cela reste compatible avec Perl 5 !

                  http://www.iinteractive.com/moose/
                  • [^] # Re: Te bile pas

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

                    Moose c'est le truc qui permet de savoir si un gars connaît ou non Perl.

                    Il suffit de lui demander ce qu'il pense de l'OO en Perl.
                  • [^] # Re: Te bile pas

                    Posté par . Évalué à  3 .

                    Effectivement je me suis arrêté à Perl5.
                    Moose est le framework Perl conseillé aujourd'hui pour faire de l'objet
                    S'il faut sortir l'artillerie lourde pour juste palier les faiblesses d'un langage, je préfère utiliser un langage dont le paradigme Objet est prévu au départ (et me servir de Perl sans faire du Perl Objet).
                    • [^] # Re: Te bile pas

                      Posté par . Évalué à  3 .

                      Faut pas être fermé non plus. Je n'aime pas moose parce que je n'aime pas perl (syntaxe, trop implicite tout ça), néanmoins ça reste un très bon framework, plutôt clair, qui gère les révisions d'objets, et qui permet même de faire de l'aop, ceci dit il est un peu trop verbeu à mon gout.

                      Si tu suis cette logique tu n'utilises plus boost/qt, et que dire de ruby qui invente un dsl pour chaque besoin ?
                      • [^] # Re: Te bile pas

                        Posté par . Évalué à  2 .

                        et que dire de ruby qui invente un dsl pour chaque besoin ?

                        Que pour ça LISP le fait déjà très bien ?

                        ----> [ ]

                        (en plus j'aime bien ruby...)
                      • [^] # Re: Te bile pas

                        Posté par . Évalué à  2 .

                        Si tu suis cette logique tu n'utilises plus boost/qt, et que dire de ruby qui invente un dsl pour chaque besoin ?
                        La tu mélanges : on parle d'un besoin que je qualifierais d'"applicatif" avec le DSL par exemple et e combler un manque du langage avec moose. Deux choses diffférentes qui ne se placent pas au même nivrau.

                        Avec un langage comme Ruby (ou Python), je fais de l'objet nativement. Rien a voir avec les DSL.
                        • [^] # Re: Te bile pas

                          Posté par . Évalué à  2 .

                          Bon, c'est ptet une divergence sur la définition, mais perso je considère moose comme un dsl du "domaine" objet. D'ailleurs aquarium (qui rajoute une couche aop a ruby) se définit comme un dsl.
                    • [^] # Re: Te bile pas

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

                      Moose, c'est du Perl5 ;-)

                      Tu es un ralleur jamais content. Je te montre que Perl est un langage souple qui sais se modifier dans la continuité pour adopter des manières de programmer très puissantes que tu ne trouves pas forcément dans le système objet des autres langages qui commencent eux aussi à se faire vieux... mais tu préfères rester sur ton langage pour une raison bidon, surtout que la paradigme objet est dans Perl5, certes il est un peu bizarre et peu blesser certain.

                      Une chose assez sympa est la rencontre de Moose et de POE, cela donne de la programmation événementielle objet : MooseX::POE

                      http://search.cpan.org/~getty/MooseX-POE-0.210/lib/MooseX/PO(...)
                      • [^] # Re: Te bile pas

                        Posté par . Évalué à  2 .

                        Je ne dis pas que c'est mal, je dis seulement qu si c'est juste pour faire de l'objet, Moode, c'est peut-être un peu fort non ?
                        • [^] # Re: Te bile pas

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

                          C'est pas Moode mais Moose.

                          Sinon, tu es en train de me dire que tu préfères les langages qui ont plusieurs paradigmes pour faire de l'objet en fonction de ce que tu es en train de faire ? Si oui, Perl5 est donc parfait pour toi ;-)

                          Par ailleurs, il y a Mouse qui est un Moose simplifié mais il n'est plus trop recommandé. Les personnes de Perl travaillent beaucoup sur Moose et sur son optimisation. A moins d'une application critique en terme de temps, Moose parait aujourd'hui le meilleur choix.

                          Si cela ne te convient toujours pas, il y a plein d'autres systèmes objets sur le CPAN...
                          • [^] # Re: Te bile pas

                            Posté par . Évalué à  2 .

                            C'est pas Moode mais Moose. Glissage de doigtss (le d est à côté du s sur mon clavier).

                            Sinon, tu es en train de me dire que tu préfères les langages qui ont plusieurs paradigmes pour faire de l'objet en fonction de ce que tu es en train de faire ?
                            Non, je dis simplement que pour faire de l'objet, et que de l'objet je préfère utiliser un langage qui fait ça nativement. Après si moose apporte quelque chose en plus de l'objet et que ça correspond à mon besoin, je veux bien, mais si ce n'est que pour faire de l'objet, je préfère m'en passer (car, par exemple, ça risque d'apporter un tas de choses qui ne servent à rien et qui potentiellement pourraient contenir des failles).
          • [^] # Re: Te bile pas

            Posté par . Évalué à  3 .

            Sauf que dès que tu veux faire du Perl lisible, tu dois fuir tout ce qui est implicite, donc perdre beaucoup de la puissance du Perl :)
            • [^] # Re: Te bile pas

              Posté par . Évalué à  3 .

              ça concerne un peu tous les langages. sauf COBOL.
              • [^] # Re: Te bile pas

                Posté par . Évalué à  2 .

                Non, pas d'accord. En tout cas si c'est le cas pour d'autres langages, ce n'est pas aussi flagrant qu' en Perl.
    • [^] # Re: Te bile pas

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

      1. C'est toi qui bosse, donc c'est toi qui décide. Tu es bénévole tout de même, on va pas t'imposer une techno que tu déteste

      C'est quand même plus sympa d'expliquer le choix pour un éventuel contributeur, voire pour un simple utilisateur. Pour le premier, ça montre que tout n'est pas décidé en fonction de l'humeur du développeur et qu'on ne va pas te refuser une contribution parce que la lune n'est pas pleine. Pour le second, ça permet de montrer que son site préféré n'est pas soumis au lubie d'un gus dans son garage et qu'il ne va pas tomber du jour au lendemain sans plus personne pour le réparer.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

  • # Retour d'expérience bienvenu

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

    Je te souhaite une bonne migration et que celle-ci se déroule sur les rails ;-)

    Combien de temps as tu estimé pour cette migration et avec quelle marge d'erreur ?
    Sinon je serai très intéressé par ton retour d'expérience sur cette migration une fois celle-ci finie. J'attends donc avec impatience un journal là-dessus ;-)
    • [^] # Re: Retour d'expérience bienvenu

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

      > Combien de temps as tu estimé pour cette migration et avec quelle marge d'erreur ?

      Quand j'ai commencé la version Rails, je pensais pouvoir faire ça en 6 mois. C'était il y a 2 ans, donc maintenant, je suis beaucoup plus réservé sur mes estimations ;-)
    • [^] # Re: Retour d'expérience bienvenu

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

      Combien de temps as tu estimé pour cette migration et avec quelle marge d'erreur ?

      Qu'entends-tu par migration ? Le projet est découpé en 3 parties comme indiqué sur
      https://github.com/nono/linuxfr.org/wiki
      - le site en lui-même
      - la migration des données
      - le volet admin et configuration

      donc, bon, la migration des données, en moins d'une heure c'est fait, en voyant large :-)

      D'ailleurs, c'est déjà disponible sur http://alpha.linuxfr.org sur lequel tu peux déjà te logguer et identifier les améliorations possibles, vérifier que les pages sont conformes HTML5... En participant, tu pourras te rendre compte de la complexité d'ajouter des fonctionnalités, tester les régressions voire contribuer au retour d'expérience par toi-même :-) (et même rédiger le journal afférent). Même pas besoin de connaître Ruby pour tout cela :D
      • [^] # Re: Retour d'expérience bienvenu

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

        > donc, bon, la migration des données, en moins d'une heure c'est fait, en voyant large :-)

        Raté, faut compter environ 2h pour ça ;-)
        • [^] # Re: Retour d'expérience bienvenu

          Posté par . Évalué à  3 .

          Le projet migration, c'est pas plutôt le script qui permet de migrer les données actuelles vers la nouvelle version.
          Je pense très sérieusement que c'est la partie la plus compliquée à faire et qu'on se "fout" un peu de savoir combien de temps le script met à s'exécuter (qu'une seule fois a priori).
          • [^] # Re: Retour d'expérience bienvenu

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

            Oui, c'est juste le script pour migrer les données. Son temps d'exécution a effectivement très peu d'importance : il met 2h, mais je suis sûr qu'en y passant du temps, ça pourrait s'optimiser.

            Et ça a bien été une des parties les plus difficiles. D'ailleurs, il reste encore des bugs bien compliqués à résoudre dessus.
  • # Mais ouiii!

    Posté par . Évalué à  1 .

    À titre d'exemple, nous avons un bug connu sur le système de cache qui insère des 'my' dans tous les URL

    Ça me rappelle un truc: http://www.myohmy.fr/My_Oh_My!/My_Oh_My!.html

    THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

  • # Maintenance...

    Posté par . Évalué à  3 .

    Ah ben c'est sûr, ça pouvait paraitre séduisant de partir sur quelquechose comme Templeet qui va plus vite qu'un Apache servant des pages statiques (ça doit être le fait de ne pas utiliser un langage syntaxique) /o\

    Sérieusement, il est bien évident qu'utiliser une solution développée par 1 ou 2 personnes, et qui en plus a extrêmement peu d'audience par ailleurs n'a rien de la panacée. Au moins avec du Ruby on Rails, il y a une communauté autour. En tout cas je te souhaite sincèrement bon courage.
    • [^] # Re: Maintenance...

      Posté par . Évalué à  5 .

      Bah, je pense qu'au moment ou il a été développé, templeet n'était pas une mauvaise idée. A l'époque les frameworks et outils du genre n'étaient pas légions et se trainaient un peu me semble-t-il.
      • [^] # Re: Maintenance...

        Posté par . Évalué à  3 .

        Bah, je pense qu'au moment ou il a été développé, templeet n'était pas une mauvaise idée. A l'époque les frameworks et outils du genre n'étaient pas légions et se trainaient un peu me semble-t-il.

        Faudrait peut-être se renseigner alors.
        A l'époque où templeet a été développé, SPIP et d'autres existaient déjà.
        (je me rappelle d'ailleurs un fil de discussion cocasse où, à la question de savoir si templeet avait les mêmes fonctionnalités que SPIP, l'auteur de templeet répondait que non mais qu'il suffisait de recoder SPIP en templeet... ça faisait un peu MultiDeskOS sur les bords :-))
        • [^] # Re: Maintenance...

          Posté par . Évalué à  2 .

          SPIP existait, je le sais, mais le nombre de trucs du genre qui existait se comptait sur les doigts de la main. D'ailleurs, d'autres frameworks qui sont maintenant populaires ont vu aussi le jour. Le problème de templeet est qu'il n'a pas été aussi populaires que d'autres. Mais pouvait-on le savoir à sa création?

          Si j'en reviens aux autres framewors, aurait-il fallu s'abstenir de les coder sous prétexte que SPIP existait ?
          à la question de savoir si templeet avait les mêmes fonctionnalités que SPIP, l'auteur de templeet répondait que non
          Autres besoins, autres fonctionnalités ?
    • [^] # Re: Maintenance...

      Posté par . Évalué à  3 .

      tu crois vraiment qu'un outil codé par 1 gars, ou 2, c'est plus maintenable qu'un outil existant écrit par une communauté, qui est amélioré depuis des années ? Grooooos doute.

      Et si demain notre bienhacker devient papa ? ou déménage ? ou, pire, trouve un boulot qui lui demande du temps ? Qui qui va reprendre le flambeaux du bouzin ?
  • # système de cache

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

    Si mes souvenirs sont bon, la version actuelle avec templeet utilisait (je ne sais pas si c'est toujours le cas) la redirection des 404 vers l'appli qui générait une page statique pour la fois d'après, page supprimée à la moindre maj. Personnellement j'utilise ce système très souvent, avec nginx et une appli en proxy (python) c'est redoutablement simple et efficace.

    Quel système de cache est utilisé dans cette nouvelle version (et qui devrait rendre caduque les questions sur la rapidité du langage...) ?
    • [^] # Re: système de cache

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

      Le problème se complique légèrement dès que l'on a des données spécifique à l'utilisateur dans la page.

      Envoyé depuis mon lapin.

    • [^] # Re: système de cache

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

      > La version actuelle avec templeet utilisait [...] la redirection des 404 vers l'appli qui générait une page statique pour la fois d'après, page supprimée à la moindre maj.

      C'est comme ça que ça fonctionne, mais quasiment toutes les templates ont maintenant la directive ~dont_cache(). Donc, quasiment toutes les requêtes passent quand même par templeet.

      Il y a 2 raisons à cela. La première, c'est que la plupart des pages contiennent des informations spécifiques à un utilisateur (au hasard, le Bienvenue dans la barre de gauche).

      La seconde, c'est qu'il n'est pas simple de faire expirer le cache. Par exemple, quand on vote sur un commentaire, ça peut changer la note moyenne des commentaires du contenu associé. Or, cette note moyenne est affichée à chaque fois que le contenu est affiché, c'est-à-dire au moins sur une dizaine de pages.

      C'est donc beaucoup plus simple de gérer le cache au niveau des ~include(). En gros, on cache le bloc HTML pour un commentaire, ou juste la première partie d'une dépêche, puis avec templeet, on reconstruit la page à partir de ces blocs (depuis le cache quand c'est possible, avec les requêtes SQL sinon).

      > Quel système de cache est utilisé dans cette nouvelle version ?

      Ça fait parti des choses qu'il me reste à faire avant de pouvoir de passer la version Rails en production ;-)
      • [^] # Re: système de cache

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

        Oui, c'est un casse tête quand il y a beaucoup de parties dynamiques...

        Une solution que j'utilise maintenant, en complément, c'est de générer (à la volée toujours) un certain nombre de données dans des fichiers html ou json qui sont appelés en javascript/ajax.
        • [^] # Re: système de cache

          Posté par . Évalué à  7 .

          Et du coup, si tu désactives javascript, tu perds la moitié des infos.
          • [^] # Re: système de cache

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

            Desactiver javascript ? T'es au courant pour les web de la'près l'an 2000 ?
            • [^] # Re: système de cache

              Posté par . Évalué à  5 .

              Aucun site correctement conçu (même « après l’an 2000 »), qui vise à délivrer de l’information, ne nécessite javascript.
              Je ne parle bien sûr pas des applications web à la gmail.
  • # .

    Posté par . Évalué à  -8 .

    Je comprends que tu fais ça comme un hobby sur ton temps libre donc le choix de ruby peut se comprendre, mais si linuxfr veut gagner en crédibilité, ne penses tu pas qu'il serait préférable d'opter pour des langages plus pros comme java ou c# ? Ils ont l'avantage d'etre fortement typés, de bénéficier du support de vrais IDEs. Et en plus d'etre multiplateformes ils sont bien intégrés sous windows, ce qui n'est pas le cas des langages de script. Enfin ( et c'est pas le moindre quand il s'agit de passer en production ), ils bénéficient tout les deux de vrais serveur applicatifs comme IIS ou JBoss (Enterprise Grade Server).
    • [^] # Re: .

      Posté par . Évalué à  2 .

      Tu triche, on n'est pas encore vendredi!
    • [^] # Re: .

      Posté par . Évalué à  0 .

      Java ? Mais java SAPU CEPASLIBRE.
    • [^] # Re: .

      Posté par . Évalué à  5 .

      Deja à -6, ca ne me surprend pas vu le nombre de gens qui haissent ces deux languages.

      Pourtant, en tant que développeur professionnel, je ne vois pas comment faire autrement que de passer par des languages fortement typés pour avoir une base de code maintenable sur un gros projet.
      La disponibilité d'un IDE potable me semble aussi un minimum si on veut que les développeurs se concentrent plus sur le fond que la forme (autocomplétion, refactoring, affichage des erreurs à la volée)
      Le multiplatteforme par contre ne me semble pas vraiment être une condition nécessaire dans le cas de linuxfr
      • [^] # Re: .

        Posté par . Évalué à  1 .

        Tu as tout à fait raison sur les points que tu évoques je pense.
        Pour ma part, je déplore fortement la non-popularité des langages fortement typés. Le duck typing de python par exemple me semble très nocif pour la maintenabilité à long terme d'une application. Bon, le random typing de PHP, c'est pire, n'en parlons pas...
        Pour l'absence d'IDE "potable", c'est lié à deux choses :
        - les choix personnels : tout le monde n'apprécie pas un monstre tel eclipse ou netbeans. Pour ma part, j'aime bien KDevelop mais surtout Qt Creator, qui est léger et contient juste ce qu'il me faut.
        - l'absence de typage rendant très délicates des opérations comme le refactoring. Soient deux classes A et B contenant chacune une méthode test. Si tu renommes A::test en A::plop, comment s'assurer que ce qui est renommé dans le code est bien une instance de A et pas une instance de B ?

        Par contre à l'inverse, la plupart des frameworks dans des langages avec un typage fort vont être imbuvables ou avoir une architecture ultra compliquée (je pense que c'est lié à la fois techniquement et par "l'état d'esprit" des développeurs dans ces langages)...
        C'est le principal soucis des framework Web Java à ma connaissance... À quand le Java on Rails ? :) Ou le C+lons :)
        • [^] # Re: .

          Posté par . Évalué à  1 .

          Ca se discute.

          Prends spring, c'est un modele exemplaire d'architecture.
          Simple, concis non intrusif. Lit le code, c'est tres instructif.

          Hibernate se debrouille bien.

          Apres si tu veux parler de struts, des ejb et d'autres horreurs, c'est sur que ca va pas etre du meme tonneau.

          C'est vraiment un probleme de mentalite des dev. Et oui, beaucoup de dev java pensent que plus c'est complexe et mieux c'est. Mais pas tous, loin de la.

          If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

          • [^] # Re: .

            Posté par . Évalué à  4 .

            Le soucis, c'est que (en tout cas dans mon cas) en cours, on apprend aux pauvres petits étudiants les EJB, struts et autres horreurs...
            Forcément après quand ils voient <?php echo "hello world"; ?> ils sont excités et passent du côté obscur :)
        • [^] # Re: .

          Posté par . Évalué à  4 .

          Python et Rails sont fortement typés, hein.
          • [^] # Re: .

            Posté par . Évalué à  2 .

            En effet, excuse moi, je voulais parler de typage statique. (Ne plus commenter si tard)
        • [^] # Re: .

          Posté par . Évalué à  2 .

          > je déplore fortement la non-popularité des langages fortement typés

          Ca dépend de ce que tu appelles "popularité": C++ et Java sont deux langages a typage fort (et statique) très utilisés.

          Ils ne sont pas aimés parce que C++ est une bouse infame et que Java a d'autre problemes trop simple, trop verbeux, appartient à Oracle..

          Note que leur remplaçants potentiels respectifs D et Scala sont tout les deux aussi fortement et statiquement typés, mais avec inférence de type locale ce qui réduit le nombre de déclaration de type.



        • [^] # Re: .

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

          À quand le Java on Rails ?

          http://www.playframework.org/ :-)
          • [^] # Re: .

            Posté par . Évalué à  3 .

            Mieux !
            La puissance de l'environnement Java avec toutes ces librairies sous le coude, sa JVM multithread sans GIL, sans subprocess, tout ça combiné au plaisir d'un langage dynamiquement typé et d'un framework Web ala RoR.
            Mesdames et messieurs, j'ai nommé l'unique le seul le meilleur... Grails
            http://www.grails.org

            Comment ça, j'en fais un peu trop ?
            • [^] # Re: .

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

              Tout a fait d'accord !

              j'ai touché à 3 framework "façon Rails":
              - Ror (un peu, essentiellement du bidouillage/plugin autour de Redmine): un peu du mal a accrocher avec Ruby, mais c'est juste une question de gout.De toute maniere, j'en ai pas fait assez pour juger honetement, autant le dire
              - Turbogears2 en python. Environ 6-8 mois sur un gros projet. Un Orm tres interessant (SqlAlchemy), ... Pas mal du tout techniquement, et puissant, le principal défaut étant une doc tres eparsse sur plusieurs site, tres incomplete, obligeant a aller voir le code source lorsqu'on sort un poil des sentiers battus.
              - Et Grails, sur lequel je me suis fixé au final (pour 3 projets pour l'instant):

              La logique de base est la meme que RoR, TG2 de part la philosophie, structure générale et avantages concrets (concision du code, productivité...). L'Orm est béton (Hibernate), et forme une parfaite intégration autour de Spring+Hibernate, sans les erreurs basiques souvent à l'origine des echecs de projets Java, en particulier avec hibernate (voir le billet de Ploum pour rire).
              Et la doc est bien foutu, les exemples ou tutoriaux nombreux.

              A l'utilisation, en dehors des gouts inhérent à chacun, RoR, Turbogears et Grails sont équivalents.
              Là où Grails a un avantage certain, c'est en bibliotheques importable et utilisable directement.
              Et là ou Grails bat les autres par KO absolu, et on sort ici du technique, c'est quand il faut convaincre un client: Entre Ruby, Python, ou J2EE, le choix est souvent vite fait. Et comme le dévelopeur, dans Grails, peux choisir entre programmer en Java ou en Groovy (ou en mixe des 2), le développeur, aussi, est heureux.
              • [^] # Re: .

                Posté par . Évalué à  2 .

                > et comme le dévelopeur, dans Grails, peux choisir entre programmer en Java ou en Groovy (ou en mixe des 2), le développeur, aussi, est heureux.


                lololololz. c'est comme proposer le choix entre C# et Visual Basic .NET

                oui, s'il peut en blairer l'un des deux, il sera heureux, pas de problème.
        • [^] # Re: .

          Posté par . Évalué à  2 .

          Le duck typing de python par exemple me semble très nocif pour la maintenabilité à long terme d'une application.

          Le duck typing n'est pas gênant en soi, il faut juste s'y habituer. Non moi ce qui me gène, c'est d'un côté on demande aux développeurs python de tout écrire de manière explicite, tout en ayant ce concept de duck typing dans le langage. Incohérence, quand tu nous tiens ....

          i tu renommes A::test en A::plop, comment s'assurer que ce qui est renommé dans le code est bien une instance de A et pas une instance de B ?
          Comprend pas ton exemple.
          • [^] # Re: .

            Posté par . Évalué à  1 .

            Comprend pas ton exemple.
            Le monsieur parlait de refactoring. Du refactoring en python, ruby ou autre langage dynamique, c'est quasi impossible : ça implique, pour l'outil de refactoring, de faire une reconnaissance des types utilisés à travers tout le code...
            • [^] # Re: .

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

              > Du refactoring en python, ruby ou autre langage dynamique, c'est quasi impossible

              Heureusement que tu me préviens. Je faisais du refactoring en Ruby ou Javascript quasiment tous les jours, mais je vais arrêter. Sinon, l'univers va m'en vouloir de faire des trucs quasi impossibles aussi souvent...

              > ça implique, pour l'outil de refactoring, de faire une reconnaissance des types utilisés à travers tout le code...

              Ça fait 2 assertions avec lesquelles je ne suis pas d'accord dans la même phrase :

              1. qu'il faille un outil pour faire du refactoring (c'est vrai pour du java où le langage est très verbeux, mais beaucoup moins pour les langages dynamiques)

              2. qu'il faille analyser les types pour faire du refactoring (j'utilise régulièrement les techniques de refactoring listées sur http://sourcemaking.com/refactoring et dans la plupart des cas, on n'a pas besoin de connaître les types utilisés)
              • [^] # Re: .

                Posté par . Évalué à  4 .

                Effectivement, mea maxima culpa, je ne classais pas du tout la majorité des trucs listés sur la page http://sourcemaking.com/refactoring comme étant du refactoring.
                Maintenant, tu peux me dire tout de même comment l'exemple très simple que j'ai donné peut être réalisé avec un langage dynamique ?
                À savoir deux classes A et B contenant une méthode test, et tu veux renommer test dans la classe A...
                • [^] # Re: .

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

                  Bah tu lis ton code, tu prends un éditeur de texte, et tu édites si y a un truc qu'est pas bon.

                  J'ai faux ?

                  Nan mais sérieusement, lorsqu'on dépend d'un outil spécifique pour pouvoir lire et comprendre son code, il y a un problème.

                  Après on dit que Perl est illisible...
                  • [^] # Re: .

                    Posté par . Évalué à  3 .

                    C'est marrant ça, maintenant pour les gens le refactoring c'est la fonction du même nom d'Éclipse qui en plus porte très mal son nom ... Elle devrait s'appeler renaming ou quelque chose comme ça.

                    Mais effectivement, renommer une méthode dans un language à typage dynamique implique d'être attentif, et de savoir ce qu'on veut faire. Mais bon on le vit bien hein ... moi éclipse ne me manque pas du tout.
                    • [^] # Re: .

                      Posté par . Évalué à  4 .

                      C'est comme ca qu'elle s'appelle, ca tombe bien. Au milieu de move, extract interface, pull up/push down, generate delegate, change signature etc.

                      C me semble bien du refactoring tout ca :)

                      If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                  • [^] # Re: .

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

                    Bah tu lis ton code, tu prends un éditeur de texte, et tu édites si y a un truc qu'est pas bon.

                    Le but des outils de refactoring, c'est justement de ne pas devoir relire tout le code. Sinon, tu n'utilise pas l'outil et tu lis tout le code et tu le modifie à la main.

                    « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                • [^] # Re: .

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

                  Ça dépend. Est-ce qu'il y a une relation d'héritage entre A et B ? Est-ce que la méthode test de A est publique ou privée ? Et celle de B ?

                  J'imagine que tu veux parler du cas où A et B n'ont rien à voir et où les deux méthodes test sont publiques. Dans ce cas, on fait le remplacement à la main puis on lance les tests unitaires pour vérifier que l'on n'a rien cassé.
                  • [^] # Re: .

                    Posté par . Évalué à  1 .

                    Ensuite on met en prod, ca pete, on traque et 2 jours plus tard on se rend compte que bruno a oublie de changer un nom de methode, on le fouette, on corrige et on remet en prod.

                    Plus serieusement, c'est valable pour des "petits" projets ca. Ca implique que le mec qui fait la modif connait tous les workflow potentiel de la methode modifiee, c'est pas toujours possible.

                    La ou je bosse, on decoupe tout en pitis projets et on utilise maven pour tirer les dependances. Typiquement, je bosse sur le domain dans le backend, et les gars du front end tirent ma dependance, potentiellement transitive (donc qq niveau plus bas). Ou d'autres gars du back end.
                    Je peux m'assurer que tout mon code est ok, mais pas le leur (je connais pas tous ceux qui l'utilisent).
                    Un typage statique garantit que leur code ne compilera pas si le refactoring a foire qq part. Ca m'arrive meme regulierement, ayant tendance a changer un peu trop de trucs. On ferait du python, je pense qu'on aurait eu qq catastrophes recemment, et bon courage pour les traquer.

                    If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

                    • [^] # Re: .

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

                      Je pense que je n'arriverais pas à te convaincre et inversement.

                      Pour moi, la réponse à ton problème de fiabilité du code est l'écriture de tests. J'aurais tendance à voir le typage statique comme une forme particulière de tests, avec 2 spécificités :
                      - on est obligé que ces tests passent pour lancer le programme
                      - un effet de bord très sympathique est que cela améliore les performances.

                      Mais le typage statique ne remplace pas entièrement les tests. Il reste bien trop de cas d'erreurs où le typage est respecté (off-by-one, erreurs de logique, variables mal initialisées, la liste est longue).
                      • [^] # Re: .

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

                        Tout à fait d'accord avec toi, et dans un langage comme Eiffel, la programmation par contrat pousse encore plus loin la logique des langages à typage statique. En effet, pourquoi s'arrêter en si bon chemin ;-)

                        Tout cela me fait penser à l'Extreme programming qui place les tests dans le coeur de la méthode.
                      • [^] # Re: .

                        Posté par . Évalué à  1 .

                        > Je pense que je n'arriverais pas à te convaincre et inversement

                        ClIrement, mais ca fait pas de mal de discuter.

                        Je suis que les tests, c'est bien, mais reste le pb de la couverture.
                        Disons que si tu finit par reimplementer le typage a ta facon avec les tests, mais en pas fiable (erreur humaine, tout ca) quel est l'interet?

                        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

      • [^] # Re: .

        Posté par . Évalué à  2 .

        Pourtant, en tant que développeur professionnel, je ne vois pas comment faire autrement que de passer par des languages fortement typés pour avoir une base de code maintenable sur un gros projet.

        Si c'était le cas, tous les gros projets seraient écrits en ADA.
      • [^] # Re: .

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

        > Pourtant, en tant que développeur professionnel, je ne vois pas comment faire autrement que de passer par des languages fortement typés pour avoir une base de code maintenable sur un gros projet.

        Bizarrement, je ne connais que très peu de personnes qui utilisent des langages avec du typage statique vraiment efficace pour détecter des erreurs. Haskell propose ça, mais c'est loin d'être un langage très répandu.

        Par contre, C++ et Java ne rentre pas dans cette catégorie : le typage statique est là principalement pour des raisons de performance, pas pour aider les humains. Il suffit de voir qu'il n'y a pas de moyen de faire 2 types qui aient le même stockage (entier 32 bits) sans avoir de conversions implicites de l'un à l'autre.

        Exemple : avoir un type qui correspond à des distants en mètres et l'autre en pieds (tout ressemblance avec un engin spatial ayant dévié de sa trajectoire à cause d'une erreur de ce type ne serait pas forcément fortuite).
        • [^] # Re: .

          Posté par . Évalué à  2 .

          Il suffit de voir qu'il n'y a pas de moyen de faire 2 types qui aient le même stockage (entier 32 bits) sans avoir de conversions implicites de l'un à l'autre.

          http://www.boost.org/doc/libs/release/libs/serialization/doc(...)

          Là où je suis d'accord c'est que la façon de définir des nouveaux types en Ada par exemple (je ne connait pas Haskell) est bien meilleure et plus sûre et que ce serait une riche idée d'intégrer un genre de typedef new int myint en C++.

          Exemple : avoir un type qui correspond à des distants en mètres et l'autre en pieds (tout ressemblance avec un engin spatial ayant dévié de sa trajectoire à cause d'une erreur de ce type ne serait pas forcément fortuite).

          Il me semble pourtant que le code en question était en Ada.
          • [^] # Re: .

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

            Il me semble aussi mais code en Ada ne veut pas dire non plus code sans erreur ;-)
        • [^] # Re: .

          Posté par . Évalué à  4 .

          > avoir un type qui correspond à des distants en mètres et l'autre en pieds
          En C++ tu peux avoir une classe qui définie Pied et une autre mètre, et avec les surcharge d'opérateur, ne même plus avoir à t'en soucier

          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

      • [^] # Re: .

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

        Pourtant, en tant que développeur professionnel, je ne vois pas comment faire autrement que de passer par des languages fortement typés pour avoir une base de code maintenable sur un gros projet.

        Le typage est un critère de maintenabilité ? Pour un compilateur peut-être, pour un humain c'est déjà moins sûr.

        C'est plutôt la concision et la clarté du code qui compte. (cf l'étude d'IBM qui fait un rapprochement tout bête entre le nombre de lignes et le nombre de bugs).

        La disponibilité d'un IDE potable me semble aussi un minimum si on veut que les développeurs se concentrent plus sur le fond que la forme (autocomplétion, refactoring, affichage des erreurs à la volée)

        De la même manière, plus le code va être concis, explicite et clair, moins l'ide va avoir d'importance.
        • [^] # Re: .

          Posté par . Évalué à  2 .

          > C'est plutôt la concision et la clarté du code qui compte. (cf l'étude d'IBM qui fait un rapprochement tout bête entre le nombre de lignes et le nombre de bugs).

          Ya une raison toute simple a ca: les seuls bugs qu'on aura pas sont dans du code qu'on a pas ecrit.

          Par contre, concision ne veut pas mecaniquement dire moins de bug parce que moins de code. Ou ca depent comment tu comptes tes lignes.

          Transformes 5 lignes en un one liner, t'as moins de code, mais t'auras plus de chances d'avoir un bug si qq1 modifie ladite ligne.

          Change le design d'une class pour qu'elle ait moins de choses a faire, vires 200 lignes de code, la t'aura moins de bug potentiel.

          Le truc primordial, c'est une bon design objet adapte a son domaine. Domain driven design d'eric evans devrait etre sur la table de nuit de tout developeur qui se respecte. Le langage est (presque) accessoire la dedans.
          Porte un design de merde de java a python, t'aura le meme nb de problemes a la louche.
          Reste en java et change le design, les problemes s'en iront.
          Ca veut pas dire qu'un langage plus concis n'apportera rien, mais sa concision ne feront pas s'envoler les probleme de design qui sont bien plus important.
          Remarque, c'est ptetre ce que tu veux dire par clarte :) auquel cas on est d'accord en gros.

          En clair? Faire de l'objet correctement encapsule adapte a son domaine, utiliser le langage de son domaine, simplicite est *toujours* mieux que complexite. Applique rien que ca deja, t'eviteras deja enormement de pb.

          Apres quand je vois que l'anemic object anti pattern est religion dans certaine boite, qu'encapsulation veut souvent dire "field prives avec getter/setters", ce qui resulte en du code imperatif ecrit en java, je comprends ton raisonnement. Mais c'est pas un pb de langage, juste de developpeur.

          > De la même manière, plus le code va être concis, explicite et clair, moins l'ide va avoir d'importance.
          Dans l'absolu, c'est vrai, mais l'ide restera toujours indispensable. Ca apporte des gardes fous a cout nul dont il serait tres idiot de se passer.

          If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

  • # C'est vrai

    Posté par . Évalué à  1 .

    C'est vrai: Pourquoi ré-écrire LinuxFr.org ????
    Alors qu'on peut juste écrire "dalfp"...
  • # le choix de mysql

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

    Même question pour la base de données. Est-ce un choix technique ou une préférence personnelle ?
    • [^] # Re: le choix de mysql

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

      Un peu des deux. La technique a restreint les possibilités à deux : MySQL et PostgreSQL. Aujourd'hui, la liste serait plus longue, avec des bases NoSQL comme MongoDB en plus.

      Ensuite, j'ai choisi MySQL parce que je suis plus à l'aise avec et que je connais des personnes prêtes à m'aider en cas de problème qui connaissent bien MySQL et comment le tunner. Pour PostgreSQL, ça me faisait un peu peur de me lancer dedans sans trop d'expérience ni d'aide extérieure.
      • [^] # Re: le choix de mysql

        Posté par . Évalué à  3 .

        rassure-moi quand même sur un point : avec RoR et ses ActiveRecords tu as quand même une bonne couche d'abstraction qui suffira la plupart du temps et tu te fous assez que ça soit MySQL ou PostgreSQL une fois qu'ils sont raisonnablement tunés^Wconfigurés

        hein ? hein ?
  • # LE bug

    Posté par . Évalué à  1 .

    "Nous avons essayé de corriger le bug, mais nous n'en avons pas été capable. Pire, quand on trace l'exécution du module de cache de templeet, on se rend compte qu'il ne passe jamais par le même chemin."

    J'appelle ça un bug maléfique ^^

    C'est le genre de bug a priori incompréhensible, qui nécessite obligatoirement toute votre attention et dont la traque peut durer des jours voir des semaines à temps plein ...
  • # Et pourquoi pas au passage fournir un service ?

    Posté par . Évalué à  2 .

    En effet, ça permettrais simplement la création d'application pour les téléphone portable.

    Alors, est-ce que le nouveau linuxfr proposera une API web (http quoi :)) ?
  • # Merci.

    Posté par . Évalué à  3 .

    Juste merci pour ton travail, et merci à tous ceux qui contribuent à faire de linuxfr.org ce qu'il est. :-)

    Adhérer à l'April, ça vous tente ?

Suivre le flux des commentaires

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