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, NdM: réédité en 2021 pour la version archive.org de l'époque), 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 Pinaraf . Évalué à 10.
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 totof2000 . Évalué à 3.
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 Pinaraf . Évalué à 10.
Pareil pour Synphony.
Pareil pour tout framework bien foutu quoi...
[^] # Re: Et le choix de Ruby on Rails ?
Posté par Bruno Michel (site web personnel) . Évalué à 10.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Et le choix de Ruby on Rails ?
Posté par yellowiscool . Évalué à 5.
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 Bruno Michel (site web personnel) . Évalué à 3.
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 Dinofly (site web personnel) . Évalué à 2.
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 totof2000 . Évalué à 4.
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 Dinofly (site web personnel) . Évalué à 2.
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 Prae . Évalué à 2.
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 zebra3 . Évalué à 3.
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 totof2000 . Évalué à -1.
[^] # Re: Et le choix de Ruby on Rails ?
Posté par yellowiscool . Évalué à 1.
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 zebra3 . Évalué à 3.
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 Moonz . Évalué à 2.
[^] # Re: Et le choix de Ruby on Rails ?
Posté par zebra3 . Évalué à 3.
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 Moonz . Évalué à 2.
[^] # Re: Et le choix de Ruby on Rails ?
Posté par zebra3 . Évalué à 2.
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 Moonz . Évalué à 3.
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 zebra3 . Évalué à 2.
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 pasScott pasForstall . Évalué à 0.
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 Ontologia (site web personnel) . Évalué à 1.
C'est sur que si tu tiens absolument à ton clickodrome ça devient plus compliqué.
Mais Macos reste un Unix et ça c'est cool
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Et le choix de Ruby on Rails ?
Posté par Moonz . Évalué à 2.
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 lasher . Évalué à 2.
[^] # Re: Et le choix de Ruby on Rails ?
Posté par pasScott pasForstall . Évalué à 1.
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 Moonz . Évalué à 2.
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 pasScott pasForstall . Évalué à 1.
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 Moonz . Évalué à 2.
> 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 pasScott pasForstall . Évalué à 1.
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 wismerhill . Évalué à 3.
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 pasScott pasForstall . Évalué à 0.
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 BAud (site web personnel) . Évalué à 7.
(je reste à l'intérieur, il va neiger là)
[^] # Re: Et le choix de Ruby on Rails ?
Posté par boq . Évalué à 2.
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 pasScott pasForstall . Évalué à 2.
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 boq . Évalué à 2.
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 pasScott pasForstall . Évalué à -2.
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 Bruno Michel (site web personnel) . Évalué à 3.
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 boq . Évalué à 2.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Et le choix de Ruby on Rails ?
Posté par claudex . Évalué à 3.
Quand on lit Et puis qu'on compare à Ruby ou Python, ça répond à ta question.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et le choix de Ruby on Rails ?
Posté par claudex . Évalué à 5.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Et le choix de Ruby on Rails ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Et le choix de Ruby on Rails ?
Posté par claudex . Évalué à 4.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Et le choix de Ruby on Rails ?
Posté par Jean B . Évalué à 3.
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 yellowiscool . Évalué à 3.
Envoyé depuis mon lapin.
[^] # Re: Et le choix de Ruby on Rails ?
Posté par totof2000 . Évalué à 2.
[^] # Re: Et le choix de Ruby on Rails ?
Posté par El Titi . É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 Moonz . Évalué à 5.
[^] # Re: Et le choix de Ruby on Rails ?
Posté par Dinofly (site web personnel) . Évalué à 1.
Mais bref je chipote et je vois bien ce que tu veux dire :-)
[^] # Re: Et le choix de Ruby on Rails ?
Posté par Bruno Michel (site web personnel) . Évalué à 5.
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 Pinaraf . Évalué à 1.
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 Bruno Michel (site web personnel) . Évalué à 3.
[^] # Re: Et le choix de Ruby on Rails ?
Posté par Gabin . Évalué à 1.
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 Bruno Michel (site web personnel) . Évalué à 4.
[^] # Re: Et le choix de Ruby on Rails ?
Posté par NeoX . É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 Bruno Michel (site web personnel) . Évalué à 2.
[^] # Re: Et le choix de Ruby on Rails ?
Posté par ckyl . Évalué à 2.
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 Pinaraf . Évalué à 2.
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 Sébastien Douche . Évalué à 9.
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 Alexandre COLLIGNON (site web personnel) . Évalué à 1.
Alexandre COLLIGNON
# Te bile pas
Posté par Ontologia (site web personnel) . Évalué à 8.
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 !
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Te bile pas
Posté par fearan . Évalué à 4.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Te bile pas
Posté par gnumdk (site web personnel) . Évalué à 10.
[^] # Re: Te bile pas
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
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 Lutin . Évalué à 4.
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 Sébastien Douche . Évalué à 3.
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 fearan . Évalué à 1.
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 Bruno Michel (site web personnel) . É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 fearan . Évalué à 2.
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 Raphaël SurcouF (site web personnel) . Évalué à 1.
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 Sytoka Modon (site web personnel) . Évalué à 2.
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 totof2000 . Évalué à 2.
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 grid . Évalué à 5.
Ca augure du tout bon pour le ruby :-)
[^] # Re: Te bile pas
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Tu as regardé du coté de Moose ?
[^] # Re: Te bile pas
Posté par totof2000 . Évalué à 2.
[^] # Re: Te bile pas
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
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 jbbourgoin (site web personnel) . Évalué à 1.
Il suffit de lui demander ce qu'il pense de l'OO en Perl.
[^] # Re: Te bile pas
Posté par totof2000 . Évalué à 3.
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 Alex . Évalué à 3.
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 lasher . Évalué à 2.
Que pour ça LISP le fait déjà très bien ?
----> [ ]
(en plus j'aime bien ruby...)
[^] # Re: Te bile pas
Posté par totof2000 . Évalué à 2.
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 Alex . Évalué à 2.
[^] # Re: Te bile pas
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
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 totof2000 . Évalué à 2.
[^] # Re: Te bile pas
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
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 totof2000 . Évalué à 2.
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 Moonz . Évalué à 3.
[^] # Re: Te bile pas
Posté par Gniarf . Évalué à 3.
[^] # Re: Te bile pas
Posté par totof2000 . Évalué à 2.
[^] # Re: Te bile pas
Posté par claudex . Évalué à 2.
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.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Retour d'expérience bienvenu
Posté par Miguel Moquillon (site web personnel) . Évalué à 5.
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 Bruno Michel (site web personnel) . Évalué à 7.
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 BAud (site web personnel) . Évalué à 4.
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 Bruno Michel (site web personnel) . Évalué à 3.
Raté, faut compter environ 2h pour ça ;-)
[^] # Re: Retour d'expérience bienvenu
Posté par _seb_ . Évalué à 3.
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 Bruno Michel (site web personnel) . Évalué à 2.
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 Grunt . Évalué à 1.
Ç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.
[^] # Re: Mais ouiii!
Posté par Gniarf . Évalué à 2.
# Maintenance...
Posté par galactikboulay . Évalué à 3.
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 totof2000 . Évalué à 5.
[^] # Re: Maintenance...
Posté par Antoine . Évalué à 3.
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 totof2000 . Évalué à 2.
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 asteroid . Évalué à 3.
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 wilk . Évalué à 1.
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 yellowiscool . Évalué à 2.
Envoyé depuis mon lapin.
[^] # Re: système de cache
Posté par Bruno Michel (site web personnel) . Évalué à 4.
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 wilk . Évalué à 1.
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 Moonz . Évalué à 7.
[^] # Re: système de cache
Posté par dyno partouzeur de drouate . Évalué à -1.
[^] # Re: système de cache
Posté par Moonz . Évalué à 5.
Je ne parle bien sûr pas des applications web à la gmail.
# .
Posté par snt . Évalué à -8.
[^] # Re: .
Posté par wismerhill . Évalué à 2.
[^] # Re: .
Posté par totof2000 . Évalué à 0.
[^] # Re: .
Posté par weonbin . Évalué à 5.
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 Pinaraf . Évalué à 1.
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 pasScott pasForstall . Évalué à 1.
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 Pinaraf . Évalué à 4.
Forcément après quand ils voient <?php echo "hello world"; ?> ils sont excités et passent du côté obscur :)
[^] # Re: .
Posté par Moonz . Évalué à 4.
[^] # Re: .
Posté par Pinaraf . Évalué à 2.
[^] # Re: .
Posté par reno . Évalué à 2.
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 Sufflope (site web personnel) . Évalué à 2.
http://www.playframework.org/ :-)
[^] # Re: .
Posté par El Titi . Évalué à 3.
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 Johann Ollivier-Lapeyre (site web personnel) . Évalué à 3.
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 Gniarf . Évalué à 2.
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 totof2000 . Évalué à 2.
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 Pinaraf . Évalué à 1.
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 Bruno Michel (site web personnel) . Évalué à 3.
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 Pinaraf . Évalué à 4.
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 jbbourgoin (site web personnel) . Évalué à 4.
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 Jean B . Évalué à 3.
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 pasScott pasForstall . Évalué à 4.
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 claudex . Évalué à 3.
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.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: .
Posté par Bruno Michel (site web personnel) . Évalué à 1.
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 pasScott pasForstall . Évalué à 1.
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 Bruno Michel (site web personnel) . Évalué à 4.
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 Sytoka Modon (site web personnel) . Évalué à 1.
Tout cela me fait penser à l'Extreme programming qui place les tests dans le coeur de la méthode.
[^] # Re: .
Posté par pasScott pasForstall . Évalué à 1.
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 totof2000 . Évalué à 2.
Si c'était le cas, tous les gros projets seraient écrits en ADA.
[^] # Re: .
Posté par Bruno Michel (site web personnel) . Évalué à 2.
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 Étienne . Évalué à 2.
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 myinten 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 Sytoka Modon (site web personnel) . Évalué à 4.
[^] # Re: .
Posté par fearan . Évalué à 4.
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 wilk . Évalué à 1.
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 pasScott pasForstall . Évalué à 2.
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 fcartegnie . Évalué à 1.
Alors qu'on peut juste écrire "dalfp"...
[^] # Re: C'est vrai
Posté par DLFP est mort . Évalué à 3.
DLFP >> PCInpact > Numerama >> LinuxFr.org
# le choix de mysql
Posté par wilk . Évalué à 3.
[^] # Re: le choix de mysql
Posté par Bruno Michel (site web personnel) . Évalué à 2.
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 Gniarf . Évalué à 3.
hein ? hein ?
[^] # Re: le choix de mysql
Posté par Bruno Michel (site web personnel) . Évalué à 3.
[^] # Re: le choix de mysql
Posté par totof2000 . Évalué à 2.
# LE bug
Posté par zeanmi . Évalué à 1.
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 kowalsky . Évalué à 2.
Alors, est-ce que le nouveau linuxfr proposera une API web (http quoi :)) ?
[^] # Re: Et pourquoi pas au passage fournir un service ?
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Oui, c'est prévu mais pas tout de suite. Pour le moment, la priorité est de sortir le site web.
# Merci.
Posté par Pol' uX (site web personnel) . Évalué à 3.
Adhérer à l'April, ça vous tente ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.