Ce matin, lors de mon surf matinal j'ai fait un petit tour sur github[1] quand tout à coup je suis tombé là-dessus:
Description: The new version of LinuxFr.org will be in Ruby on Rails. It's my resolution for 2009. [2]
A vos trolls.
[1] http://github.com
[2] http://github.com/nono/linuxfr.org/
Journal LinuxFR en rails ?
6
jan.
2009
# Un peu tôt
Posté par Arnaud (page perso) . Évalué à 6.
# Note
Posté par Laurent J (page perso) . Évalué à 10.
- vote pour l'achat de 2 serveurs supplémentaires afin de répondre aux exigences du nouveau site en matière de tenu en charge.
(Hein ? comment ça on n'est pas vendredi ? ->[])
[^] # Re: Note
Posté par Bruno Michel (page perso) . Évalué à 1.
[^] # Re: Note
Posté par Julien Gilbert (jabber id) . Évalué à 3.
Vous voulez pas la jouer soft ? Je suis pas contraignant... vous voulez la jouer hard ? On va la jouer hard
[^] # Re: Note
Posté par Florent Zara (page perso, jabber id) . Évalué à 2.
Sinon, non, ca serait la déferlante de commentaires tous plus inutiles les uns que les autres pour atteindre le million.
[^] # Re: Note
Posté par adonai . Évalué à 10.
C'est vraiment pas le genre de la maison !
[^] # Re: Note
Posté par rewind . Évalué à 1.
ça ne vaudrait pas le coup de refaire le schéma de la base proprement plutôt que de continuer à utiliser le schéma actuel ?
[^] # Re: Note
Posté par Bruno Michel (page perso) . Évalué à 4.
[^] # Re: Note
Posté par Arnaud (page perso) . Évalué à 3.
[^] # Re: Note
Posté par Loïc d'Anterroches (page perso) . Évalué à 3.
Le bon gros troll des familles pour répondre à un autre. Pour la crainte au niveau de l'import des données, ce n'est jamais le nombre le problème, mais la qualité des données.
[^] # Re: Note
Posté par Ludovic Rivallain (aka Creasy) (page perso, jabber id) . Évalué à 2.
J'avais justement peur à une baisse de performances sur machine équivalente... et bien je n'ai pas été déçu du voyage:
- DotClear / 100 pages de garde = 1.819sec
- Django / 100 pages de garde = 2.625sec
Ça ne me gène pas à mon échelle... mais à d'autres, ça doit jouer j'imagine.
[^] # Re: Note
Posté par Johan Charpentier (page perso, jabber id) . Évalué à 2.
Sans parler du fait de bien d'optimiser tes objets/pages en cache + memcached
[^] # Re: Note
Posté par gUI (jabber id) . Évalué à 4.
Si je puis me permettre un conseil, ne considérez meme pas la possibilité de réutiliser la BdD telle quelle en utilisant les possibilité de Rails pour désigner les noms des tables, des clés etc... Sur la ML railsfrance, bcp trop s'y cassent les dents. Il vaut mieux réimporter la BdD dans un nouveau schéma spécialement conçu pour Rails.
Et comme bcp, si je peux aider (notamment aux tests par exemple, ou meme à la relecture de code)...
# Et voyages-sncf.com ?
Posté par windu.2b (jabber id) . Évalué à 10.
===>[]
[^] # Re: Et voyages-sncf.com ?
Posté par Nonolapero (page perso, jabber id) . Évalué à 4.
Pour vous étouffer aussi > http://www.vsc-technologies.com/?rfrr=indexLegal.htm_body_VS(...)
[^] # Re: Et voyages-sncf.com ?
Posté par maggic (page perso) . Évalué à 10.
[^] # Re: Et voyages-sncf.com ?
Posté par nilux_ (page perso, jabber id) . Évalué à 10.
[^] # Re: Et voyages-sncf.com ?
Posté par farvardin (page perso, jabber id) . Évalué à 7.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Et voyages-sncf.com ?
Posté par foulmetal canette (page perso) . Évalué à 10.
# Bah
Posté par Pascal Terjan (page perso, jabber id) . Évalué à 7.
[^] # Re: Bah
Posté par Benoît Sibaud (page perso, jabber id) . Évalué à 7.
[^] # Re: Bah
Posté par Bruno Michel (page perso) . Évalué à 6.
# Grillé
Posté par Bruno Michel (page perso) . Évalué à 3.
Je pensais poster un journal aujourd'hui pour annoncer cela, mais j'ai été grillé. Ma résolution pour 2009 est donc de réécrire LinuxFr.org en Rails. Cela va prendre du temps (le code existant fait quelques dizaines de milliers de lignes de code/template/css). Ne vous attendez pas à ce que ce soit mis en ligne avant plusieurs mois.
[^] # Re: Grillé
Posté par Nÿco (page perso, jabber id) . Évalué à 3.
[^] # Re: Grillé
Posté par alenvers (page perso) . Évalué à 7.
1) Apprendre ruby
au lieu de :
1) en faire encore moins que l'année dernière
[^] # Re: Grillé
Posté par ß ß . Évalué à 1.
[^] # Re: Grillé
Posté par JoeltheLion (page perso) . Évalué à 3.
[^] # Re: Grillé
Posté par Pierre Tramo (page perso) . Évalué à 5.
[^] # Re: Grillé
Posté par dyno partouzeur de drouate (page perso, jabber id) . Évalué à 3.
Troll à part, pourquoi changer un truc qui marche ?
If it ain't broke, don't fix it!
Au pire, que les nouveaux développements abandonnent Templeet, pourquoi pas (après tout, Apache peut utiliser toutes sortes de moteurs de scripts), mais j'espère qu'on ne va pas subir encore les affres du passage de DaCode à Templeet où on a retrouvé un site qui marchait moins bien (ça semble résolu maintenant) et avec moins de fonctionnalités au début.
Et tant qu'à lancer le débat, pourquoi pas en Java maintenant que ça-sent-bon-c'est-libre ? Il y a d'excellents frameworks et c'est beaucoup plus mature que Grails. Le choix me semble plus un caprice de développeur (un peu comme templeet, d'ailleurs) qu'un truc réfléchi.
Je suis d'accord que templeet est une horreur, à part ses performances. Oser mélanger le modèle, la vue, le contrôleur, le PHP, le SQL, le javascript, le HTML, la présentation, le business et la persistence, et d'autre horreurs dans un fichier unique en y collant une syntaxe abconse qui fait plus penser à un concours d'obfuscated LISP qu'à un design moderne, c'est du grand n'importe quoi qui mériterait de figurer sur http://thedailywtf.com/ mais c'est pas une raison pour faire n'importe quoi à la place.
Enfin, tant qu'il y aura encore la tribune...
[^] # Re: Grillé
Posté par Bruno Michel (page perso) . Évalué à 9.
> If it ain't broke, don't fix it!
Mais c'est cassé. Tu ne t'en pas rends pas compte, mais nous avons des problèmes avec la version actuelle. Parfois, le cache fait n'importe quoi. Certaines pages sont générées avec un "/my" au début de chaque URL (nous n'avons pas réussir à trouver ce qui déclenche ce problème, mais nous en retrouvons de temps à autres dans le cache). Nous, admins, passons régulièrement du temps pour corriger des problèmes.
> mais j'espère qu'on ne va pas subir encore les affres du passage de DaCode à Templeet où on a retrouvé un site qui marchait moins bien (ça semble résolu maintenant) et avec moins de fonctionnalités au début.
Il faudra probablement s'attendre à avoir des fonctionnalités différentes. Certaines vont manquer aux débuts. Mais il y aura aussi des nouveautés.
> Et tant qu'à lancer le débat, pourquoi pas en Java maintenant que ça-sent-bon-c'est-libre ? Le choix me semble plus un caprice de développeur (un peu comme templeet, d'ailleurs) qu'un truc réfléchi.
C'est un choix personnel (même si les autres admins de LinuxFr.org sont d'accord avec lui). Cela n'en est pas moins un choix réfléchi. Je connais très bien Ruby on Rails, ses forces et ses faiblesses. Je connais d'autres frameworks, et je pense que RoR convient mieux.
Par contre, il est vrai que je ne connais pas le monde Java. Il me semble donc plus prudent de ne pas se lancer dedans, car il faudra non seulement développer, mais aussi administrer tout cela (et je ne crois pas que les autres admins soient plus enthousiasmés que moi pour du java).
[^] # Re: Grillé
Posté par Arnaud (page perso) . Évalué à 2.
Mais c'est hélas un choix qui serait loin d'emporter le consensus :-( Le plus (?) important, c'est d'avoir une communauté: des contributeurs, des victimes testeurs...
[^] # Re: Grillé
Posté par windu.2b (jabber id) . Évalué à 4.
Tu penses à Pierre Tramo ?
[^] # Re: Grillé
Posté par Arnaud (page perso) . Évalué à 2.
Plus sérieusement, avec la montée (lente mais réelle) en popularité de GlassFish, il va bien finir par avoir une armée de libristes J2EEiens. Par des architectes hautains mais des bon p'tits programmeurs qui tournent à la bière, la pizza et au résultat.
[^] # Re: Grillé
Posté par ploum (page perso) . Évalué à 9.
(l'année commence bien, vive linuxfr)
[^] # Re: Grillé
Posté par Arnaud (page perso) . Évalué à 10.
Pourquoi J2EE sans masochiste? Par ce que c'est excellemment outillé, bien documenté, parce qu'il y a toujours une librairie de qualité pour répondre à un besoin, parce que depuis J2EE 1.6 c'est quand même beaucoup moins lourd (annotations, JPA, etc etc).
Oui, il n'y a pas le côté "fun" d'un Python 3K ou d'un Ror et il faut quand même encore écrire deux fois plus de ligne de code en Java pour obtenir un programme bien plus gourmand en RAM, mais au final, ce qui compte, c'est que ça marche, et bien (en particulier le clustering, ça a un côté magique). Plus chiant mais résultats prévisibles et stables sans perdre des jours entier à bidouiller pour contourner un obscure fonction non documentée, en résumé :-)
Pour infos, j'ai créé ma boite et au début, Java/J2EE, je ne pouvais pas le sentir. Mais à force de constater que "tiens, pour l'indexation, avec Lucene ça serait tellement mieux", "tiens, pour le déploiement JWS c'est quand même top"... ben au final, j'y suis passé. Et maintenant j'apprécie même certains points, comme les EJB stateless et remote.
Je vais me faire moisser, mois :-D Allez, encore un "vive J2EE" pour la route.
---> []
[^] # Re: Grillé
Posté par kowalsky . Évalué à 2.
[^] # Re: Grillé
Posté par JoeltheLion (page perso) . Évalué à 5.
[^] # Re: Grillé
Posté par cykl . Évalué à 7.
Y'a un moment faut arrêter de se pignoler sur comment gagner trois lignes de codes ou utiliser les dernier modules ouinouin beta pas documenté et pas testé en prod.
La JVM, Java et J2EE sont de très bons environnements si bien utilisés. Pour les c0d3rz tu peux jouer avec Ruby, Python, Scala ou JS sur la JVM selon tes besoins. Tu n'es pas non plus obligé d'utiliser toute la stack J2EE. Par contre tu es autorisé à tirer parti des excellents frameworks qui existent.
Je dis pas que c'est adapté à linuxfr* hein. Mais si on pouvait arrêter de dire des anneries deux minutes...
* Qui n'est somme toute vraiment pas si gros que çà.
[^] # Re: Grillé
Posté par wilk (page perso, jabber id) . Évalué à 3.
[^] # Re: Grillé
Posté par cykl . Évalué à 6.
Je ne suis pas sur que ce soit sacrifier les ressources machines dont il est question. Mais peut être plus de performances brutes contre scalabilité. Les deux sont importants mais ce n'est pas du tout la même chose. Dans tout les cas je ne suis pas convaincu que ce soit plus lourd/lent (non un contenu statique n'est pas géré par un serveur d'application mais par un CDN ou un lighthttpd, oui un niveau de cache memcached/ehcache/squid est utile et oui pas mal de choses peuvent être fait en asynchrone après la requête).
Il y a évidement un compris entre les coûts de développement, d'opérationnel, de maintenance etc. De plus LE bon choix n'existe pas. Il y a de nombreux moyens d'arriver à une archi fiable, évolutive et "cost-effective".
> besoin de l'innovation et de la motivation des développeurs c'est plutôt un frein
Je ne me sens pas freiné personnellement, c'est même une plate-forme plutôt marrante avec des outils hors du commun si on oublie le langage froid. Si tu cherches trois hackers fous pour pondre du code qu'eux seul pourront peut être maintenir dans une techno qui à un mois à la limite...
Note aussi que faire du Java ne rend pas neuneu et ne m'empêche pas de coder dans d'autres langages.
> Ce n'est pas pour rien non plus que ces même grosses boites dont tu parles utilisent aussi d'autres langages.
Évidement il n'y a pas de solution parfaite et je n'ai surtout pas dit que Java/J2EE l'était. Il faut savoir tirer parti des différentes technos selon les besoins. On peut même les combiner en fonction des besoins (linked in est un très bon exemple). Mon message était juste pour souligner que le message de ploum était encore plus idiot que tout les mecs incompétents en costards réunis...
[^] # Re: Grillé
Posté par ploum (page perso) . Évalué à 0.
Je n'en doute pas. Mais par contre "Ne faire que du Java", oui, on est pas loin. J'en veux pour preuve que tu flaires un programme Java à 15km à son UI dégueulasse, ses bouttons partout et son anti-utilisabilité.
Mais les programmes Java, c'est comme le langage lui-même : une fois que tu as dépensé 6 mois de ta vie à apprendre des trucs sans aucune logique auxquels on a collé des noms abscons, alors, forcément, tu commences à trouver ça bien parce que bon, dire le contraire reviendrait à jeter 6 mois de sa vie (ou du moins, c'est perçu comme tel).
Java, c'est le Qwerty des langages de programmation : il ne fait rien de bien et il le fait de manière compliquée mais tout le monde l'utilise parce que... tout le monde l'utilise.
Enfin, il est vrai que connaître Java est un atout indéniable. C'est comme le Cobol. 3 programmeurs Java qui ont leur conception d'un EJBS et spring sur un jboss personnalisé buildé avec un script Maven de 2000 lignes peuvent, en 3 mois, te créer 2 Go de code que plus personne ne saura même comment faire fonctionner.
[^] # Re: Grillé
Posté par cykl . Évalué à 1.
> Je n'en doute pas. Mais par contre "Ne faire que du Java", oui, on est pas loin
Tu viens de prouver que ne faire que du java implique de ne faire que du java. Ne change rien ploum tu es un dieu.
Note: J'aime bien comment tu passes d'une critique de Java pour du dev web à Java pour des applis clientes. Et au passage Eclipse et Netbeans ont une UI dégueulasse, des boutons partout et sont totalement inutilisables ?
[^] # Re: Grillé
Posté par ploum (page perso) . Évalué à 5.
Ben.. je ne vois rien à ajouter, on est parfaitement d'accord :-)
[^] # Re: Grillé
Posté par JoeltheLion (page perso) . Évalué à 8.
Je suis d'accord avec toi sur beaucoup de points, mais là... Il faut avouer que c'est dur d'utiliser eclipse quand on a gouté à vim...
[^] # Re: Grillé
Posté par yapoc . Évalué à 4.
[^] # Re: Grillé
Posté par Maxime (page perso, jabber id) . Évalué à 2.
Ça fait un moment que je me dis que je devrais le faire, j'en ai marre d'utiliser la souris :D.
[^] # Re: Grillé
Posté par JoeltheLion (page perso) . Évalué à 5.
[^] # Re: Grillé
Posté par Fabimaru (page perso, jabber id) . Évalué à 3.
[^] # Re: Grillé
Posté par Maxime (page perso, jabber id) . Évalué à 2.
Sous eclipse parfois je regrette certaines fonctions que l'on ne trouve pas dans des éditeurs classiques.
[^] # Re: Grillé
Posté par ʇpooɹquooɥɔs sɐȷoɔᴉu (jabber id) . Évalué à 7.
Tu confonds, gnome, c'est fait en Mono.
La plupart des gens aiment recevoir des montants avec plein de zéros. Moi je préfère quand il y a plein de neufs.
[^] # Re: Grillé
Posté par windu.2b (jabber id) . Évalué à 5.
[^] # Re: Grillé
Posté par alenvers (page perso) . Évalué à 2.
>in, amazon, google, par exemple ?
Google
http://panela.blog-city.com/python_at_google_greg_stein__sdf(...)
3 langages officiels python, c++, java et bcps d'autres en interne
yahoo
http://www.paulgraham.com/avg.html
Apparement, y a même du LISP
Ebay
http://highscalability.com/ebay-architecture
Semblerait que c'est du java
Les autres je ne sais pas
>* Qui n'est somme toute vraiment pas si gros que çà.
Ce n'est pas le plus gros site du monde c'est vrai. Mais ce n'est pas le plus petit non plus. En journée, il y a en moyenne 30 hits par secondes. Avec du java, on partirait surement directement vers une architecture distribuée et toutes les complication que cela entraine. Ici, on a un seul serveur qui tient très bien la mesure.
[^] # Re: Grillé
Posté par Pinaraf (jabber id) . Évalué à 3.
J'adore ce genre d'affirmations sans preuves, sans chiffres, sans arguments...
[^] # Re: Grillé
Posté par alenvers (page perso) . Évalué à 4.
Tu veux des preuves, en voilà.
>il y a en moyenne 30 hits par secondes
La source : https://linuxfr.org/stats/web.html/
>Ici, on a un seul serveur qui tient très bien la mesure.
https://linuxfr.org/images/load/load.png
>Avec du java, on partirait surement directement vers une architecture distribuée et toutes
>les complication que cela entraine.
Tout personne qui a un tant soit peu utilisé j2ee sait que sous cette appelation barbare se cache "distribué". Tout qui a fait de la distribution d'objet sait également qu'une archi distrubée est vachement plus compliquée qu'une archi standalone. Entre un serveur apache, php/templeet/nimporte quoi et une bd sur un seul serveur (standalone) et (distribué) plusieurs serveurs d'application et apache, des couches d'abstractions (beans, un orm - puisque que c'est la coutume dans le monde java -, ...), un serveur de db séparé (ben oui, il faut que plusieurs machines puissent y accéder), une authentification unique (ben oui, il faut ben que ces machines soient synchro), etc. etc. mon choix est vite fait.
[^] # Re: Grillé
Posté par Pinaraf (jabber id) . Évalué à 3.
[^] # Re: Grillé
Posté par cykl . Évalué à 5.
Pour linked in, tout est en Java sauf les moteurs de graphes qui sont en C++ sur de grosses machines (le graphe prenait 12Go il y a un ou deux ans). D'ailleurs leurs présentations techniques valent généralement le coup d'œil.
Pour les 30 *hits*/secondes ce n'est vraiment pas gros.
Par exemple un Jira ( http://www.atlassian.com/software/jira/ ) dans un tomcat 6 sur une veille machine (PIV 3.6Ghz, 2Go de RAM dont seulement 512 pour tomcat) tient facilement 30 *pages*/secondes. Au niveau backend et génération de page, Jira et linuxfr doivent être assez similaire. C'est juste de la présentation de données simples en DB.
La page de test utilisée était similaire à celle là: https://issues.apache.org/activemq/browse/AMQ .Il y a évidement des pages plus coûteuses à générer, mais elle doit être dans la moyenne. Un page plus complexe comme https://issues.apache.org/activemq/secure/IssueNavigator.jsp(...) supporte plus de 20 *pages*/secondes.
Note que la conf de tomcat est vraiment de base et pourrie pour les perfs (un max de logs), qu'il n'y a aucune optimisation que l'on pourrait faire pour linux-fr (aucun cache par exemple), que la conf de mysql est celle par défaut et que les clients HTTP attaquent directement le serveur d'appli. Bref je pense pas qu'on puisse faire plus défavorable pour un test.
Je ne dis pas que linux-fr est ridicule. Je dis qu'avec un serveur moderne il n'y a pas de gros exploit à faire tenir le tout sur une machine. De plus java n'est pas si à la ramasse que ca niveau perfs, et sa valeur ajoutée est son écosystème. Pourquoi linuxfr utilise google pour les recherche plutôt qu'un moteur interne par exemple ?
Après linuxfr est "tellement simple" (une seule source de donnée: la DB, pas d'appels à des services externes) qu'au final toutes les solutions me semblent plus ou moins équivalentes.
[^] # Re: Grillé
Posté par alenvers (page perso) . Évalué à 4.
>écosystème.
Je suis d'accord : java n'est pas plus à la ramasse qu'un autre langage. Le problème c'est justement son "écosystème" :
- Les librairies sont du "bloatware"
- Il est extrèmenent compliqué de configurer le brousouf (Fichiers xml pourris - options par défaut merdiques)
- Les couches d'abstractions s'empilent de plus en plus
- Les librairies (classiques - pas nécessairement dans java lui-même) changent en permanence du tout au tout (Exemples qui me viennent à l'esprit, struts1/2, jpa, les toolkits graphiques)
>Pourquoi linuxfr utilise google pour les recherche plutôt qu'un moteur interne par exemple ?
Peut-être :
- Parce que les développeurs n'ont pas la prétention de faire mieux que google
- Que cela ne devrait pas poser de gros problèmes avec du full-text search intelligent (par exemple : http://dev.mysql.com/doc/refman/5.0/en/fulltext-search.html ) mais google fait mieux
>Par exemple un Jira ( http://www.atlassian.com/software/jira/ ) dans un tomcat 6 sur une
>veille machine (PIV 3.6Ghz, 2Go de RAM dont seulement 512 pour tomcat) tient
>facilement 30 *pages*/secondes. Au niveau backend et génération de page, Jira et
>linuxfr doivent être assez similaire. C'est juste de la présentation de données simples en
>DB.
On peut globalement obtenir des bonnes perfs dans quasi n'importe langages mais cela à un coût différent dans tous ces langages. Et je pense que Java (et son écosystème) a un cout très élevé en resources, en temps, en matériel et en apprentissage car le monde Jave/j2ee a depuis très longtemps oublié le principes KISS.
[^] # Re: Grillé
Posté par dguihal . Évalué à 2.
Ces technos sont à disposition et utilisables de manière indépendantes les unes des autres.
C'est comme partout, y'a du bon et du moins bon, de l'adapté à tes projets ou pas. Mais de là à qualifier les libs classiques java de bloatware ou de trouver qu'éditer un fichier de config (xml ou non) avec vim est compliqué je ne dirai qu'un mot : FUD
[^] # Re: linuxfr.org en Java + ruby => JRails
Posté par mdiam . Évalué à 1.
Pourquoi ne pas tenter Jruby on Rails ?
Ce n'est pas pour rien que sun paye plusieurs personnes à plein temps
sur ce langage !)
-- Maurice
[^] # Re: Grillé
Posté par Thierry (page perso) . Évalué à 3.
Déja essayé... http://la.buvette.org/wikipics/linuxfr.org.1er-avril.html
[^] # Re: Grillé
Posté par ndesmoul . Évalué à 5.
C'est du Ruby on rails mais exécuté par une JVM java. Avantage: meilleure performance puisque JRuby surclasse nettement l'implémentation officielle de Ruby.
[^] # Re: Grillé
Posté par lezardbreton (jabber id) . Évalué à 2.
[^] # Re: Grillé
Posté par JoeltheLion (page perso) . Évalué à 2.
[^] # Re: Grillé
Posté par lezardbreton (jabber id) . Évalué à 1.
[^] # Re: Grillé
Posté par benoar (jabber id) . Évalué à 2.
http://wiki.python.org/jython/DjangoOnJython
[^] # Re: Grillé
Posté par benoar (jabber id) . Évalué à 3.
Hahaha :
500 Internal Server Error
java.lang.NullPointerException
at login.doGet(login.java:98)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:195)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:309)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:336)
at com.evermind[Oracle9iAS (1.0.2.2.1) Containers for J2EE].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:508)
at com.evermind[Oracle9iAS (1.0.2.2.1) Containers for J2EE].server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:177)
at com.evermind[Oracle9iAS (1.0.2.2.1) Containers for J2EE].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:576)
at com.evermind[Oracle9iAS (1.0.2.2.1) Containers for J2EE].server.http.HttpRequestHandler.run(HttpRequestHandler.java:189)
at com.evermind[Oracle9iAS (1.0.2.2.1) Containers for J2EE].util.ThreadPoolThread.run(ThreadPoolThread.java:62)
[^] # Re: Grillé
Posté par ploum (page perso) . Évalué à 2.
Parce que peut-être y'a pas une ferme de mainframe avec 4 TB de Ram à disposition ?
[^] # Re: Grillé
Posté par Arnaud (page perso) . Évalué à 3.
[^] # Re: Grillé
Posté par dguihal . Évalué à 1.
[^] # Re: Grillé
Posté par Fabimaru (page perso, jabber id) . Évalué à 6.
D'ailleurs pourquoi ne pas refaire le site en utilisant une seule et unique expression Lisp? C'est inutile donc indispensable. "je crois que le bug se trouve à la 3427ième parenthèse ouvrante"
[^] # Re: Grillé
Posté par Bruno Michel (page perso) . Évalué à 6.
Oui, ça résume bien le problème.
LinuxFr.org est le seul site avec un trafic conséquent qui utilise templeet. Cela pose des problèmes car nous sommes souvent les seuls à subir certains bugs. Par exemple, nous devons être les seuls à utiliser le système de cache de templeet, car celui-ci est régulièrement cassé, et nous avons dû le débugger par nous-mêmes.
Templeet est également un frein à l'évolution du site, car l'absence de communauté et sa syntaxe proche du lisp font que nous avons très peu de contributions directes et très peu de modules disponibles. Un exemple parmi tant d'autres : il n'y a rien pour faire de l'OpenID avec templeet.
Enfin, pour avoir utilisé régulièrement Ruby on Rails et templeet au cours des derniers mois/années, je vois le gouffre qui les sépare, et j'ai de plus en plus de mal à me plonger dans le code de LinuxFr.org.
Allez, un dernier lien (pub) sur le sujet : http://blog.menfin.info/post/2007/09/23/SEPT-RAISONS-POUR-LE(...)
[^] # Re: Grillé
Posté par Christophe GUILLOUX (page perso) . Évalué à 2.
[^] # Re: Grillé
Posté par ploum (page perso) . Évalué à 4.
[^] # Re: Grillé
Posté par Johan Charpentier (page perso, jabber id) . Évalué à 2.
[^] # Re: Grillé
Posté par gc (page perso) . Évalué à 3.
Vous avez demandé à Paul Graham ?
[^] # Re: Grillé
Posté par Bruno Michel (page perso) . Évalué à 6.
[^] # Re: Grillé
Posté par DarkPolo . Évalué à 0.
Il y a des raisons objective ou c'est juste par gout ou compétance (on ne peut pas tout connaitre, évidement) ?
[^] # Re: Grillé
Posté par Bastes . Évalué à 4.
- plus beau
- plus pratique
- plus maintenable
- plus orienté-objet et comportement
Alors que PHP c'est comme le côté obscur, c'est juste plus "rapide" et plus "séduisant".
Ah, non, mince, Ruby est aussi plus rapide et plus séduisant.
[^] # Re: Grillé
Posté par Bruno Michel (page perso) . Évalué à 4.
Pour des raisons objectives : oui (mais on va m'accuser de troller) : les frameworks MVC en PHP sont un niveau en dessous de Rails (pour les meilleurs), ont des performances rarement à la hauteur. Et ne pas utiliser de frameworks ou en recoder un est une grosse perte de temps (sur le développement, mais aussi à maintenir dans le temps).
Enfin, c'est également un choix par goût : je préfère Ruby à PHP. Je tiens également Django en haute estime, et je n'ai choisi Rails par rapport à Django principalement parce que je connais mieux Ruby que Python.
[^] # Re: Grillé
Posté par wilk (page perso, jabber id) . Évalué à 1.
[^] # Re: Grillé
Posté par Nicolas Blanco (page perso, jabber id) . Évalué à -6.
# On peut aider ?
Posté par yellowiscool (page perso, jabber id) . Évalué à 4.
Envoyé depuis mon lapin.
[^] # Re: On peut aider ?
Posté par Bruno Michel (page perso) . Évalué à 3.
# Si on peut aider
Posté par blackshack . Évalué à 3.
# et pourquoi pas ...
Posté par SOULfly_B (jabber id) . Évalué à 3.
je dit ça comme ça, mais c'est juste car il y a déjà une tribune en module ....
\_o<
poussez pas ... -->[]
[^] # Re: et pourquoi pas ...
Posté par steckdenis (page perso) . Évalué à 2.
Personnellement, Drupal, bien que un peu lent, n'est pas une si mauvaise idée :) . Il est déjà très développé, et très puissant.
Par exemple, il propose un bon module de forum parfaitement intégré, un bon système d'articles (dans l'admin, ça prend 2 cliques pour crée un nouveau type d'articles (Journal, Dépêche, etc) et de définir ses propriétés), un excellentissime système de gestion des droits et des groupes, et plein d'autres choses.
Bref, je n'estimais pas ce commentaire digne d'être moinssé, alors qu'il faut le prendre en compte :) .
Ce n'est peut-être pas un exemple, mais ubuntu-fr.org utilise Drupal (ok, seulement la page d'accueil), et le site de Logram (voir ma signature ;-) ). Je crois qu'il doit y avoir plein d'autres sites intéressants qui l'utilisent aussi.
Quoique vous fassiez, bonne chance :) .
[^] # Re: et pourquoi pas ...
Posté par Pinaraf (jabber id) . Évalué à 4.
C'est vachement bien, mais quand tu tombes sur ses limites, d'un coup, tu pleures.
J'ai eu à faire un site en Drupal pour une entreprise. Dans cette boîte, les logins des utilisateurs sont, pour des raisons pratiques, sous une forme numérique (exemple : 20001686).
Le site que je devais faire aller devoir s'authentifier sur un annuaire LDAP. J'ai vu le module drupal pour le LDAP, je me suis dit que c'était bon... Que nenni...
Dans drupal, il y a une supposition vraiment stupide : login == pseudo.
C'est typiquement le genre d'anomalie qu'on doit contourner, et c'est hyper chiant à la longue d'accumuler des tonnes de changements comme ça.
[^] # Re: et pourquoi pas ...
Posté par Bruno Michel (page perso) . Évalué à 3.
1) les performances,
2) le schéma de la base de données est propre à Drupal, et il aurait été très difficile de réimporter les anciennes données.
# Et pourquoi pas en C (voir C++)
Posté par mammouth . Évalué à 1.
[^] # Re: Et pourquoi pas en C (voir C++)
Posté par Alex . Évalué à 1.
[^] # Re: Et pourquoi pas en C (voir C++)
Posté par Pinaraf (jabber id) . Évalué à 2.
C'est notamment ce qui est utilisé avec lighttpd pour pouvoir faire du PHP : pas de mod_php qui va entraîner le serveur web dans sa chute (et je t'assure, c'est facile de planter mod_php sans droits particuliers, heureusement que les processus d'apache se relancent tout seul, mais c'est loin d'être "fluide")
[^] # Re: Et pourquoi pas en C (voir C++)
Posté par cykl . Évalué à 5.
Autrement tu pourras m'expliquer les gains ?
[^] # Re: Et pourquoi pas en C (voir C++)
Posté par fredix (page perso, jabber id) . Évalué à 2.
http://nodecast.net
# Défi
Posté par wilk (page perso, jabber id) . Évalué à 4.
[^] # Re: Défi
Posté par Bruno Michel (page perso) . Évalué à 8.
[^] # Re: Défi
Posté par Arnaud (page perso) . Évalué à 4.
Memcached vs Terracotta, MySql vs PostgreSQL (nooooooo do not feed the troll)
Après, derrière, que ce soit PHP/Django/Ror/J2EE, je doute que les écarts soit si importants si on reste sur un unique serveur Web+DB
[^] # Re: Défi
Posté par cykl . Évalué à 2.
Pour le reste je suis d'accord
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.