Reprise du message précédent :

le code posté, je l'ai testé sur IE6 / FF3 / chrome .. ca semblait OK

 
FF 3,5 linux ?? how do u do that ? j'ai que iceweasel 2,0 sur ma debian 5... j'ai vu que FF 3,5 était toujours en expérimental

ha bin non j'suis en 3.0.13

C'est dispo depuis 2 semaines si t'as une install issu du tar.gz (donc hors apt).
La 3.5 est peut-être un peu moins lente mais ne corrige pas les problèmes de lenteurs que j'avais déjà avec les anciennes versions sur des fonctions de prototype & co

C'est coûteux le file_exists() en Php ?

15 €, mais en ce moment y a une promo, 10.99 € seulement.

 
Avec NTFS c'est potentiellement la même merde, suivant certains flags du registre je crois.

Si le fichier existes, non, si le fichier n'existe pas, oui
Après pour les détails du "non" cf plus haut, mais en gros les considérations de cache c'est valable que si le fichier existe

j'ai une ptite question sur le design web (je sais je suis un peu HS mais bon)... il m'ait arrivé un truc bizarre... D'habitude quand je sauvegarde mes JPG ou PNG depuis Photoshop via "Save for the web", les couleurs sont toujours respectées... mais là je suis sur un design pour une gallery d'art, je sauvegarde comme d'hab, mais je m'aperçoit que le rendu final est beaucoup plus foncé
 
C'est une histoire de profil de couleurs, j'ai testé avec FF3.5 et Chrome 3, les 2 gèrent les profils correctement (mon écran est calibré)
 
Donc à votre avis, il faut lier les profils aux images ou pas ? en print je sais qu'il faut le faire, en web je sais pas trop...

Je bosse sur un nouveau projet, et dès que j'ai fini le design de celui-ci je passe au dev.
J'ai envie de découvrir un nouveau langage, donc, django ou ror ?
Pour, contre ?

rails
 
pour :
ruby > *
rails > *
 
contre:
rien
 
 
de rien

Regardes les deux langages, fais une passe sur la doc des deux frameworks (si tu peux trouver de la doc pour Rails), prends celui que tu préfères.

-Rails, Rails 3 arrive sous peu et c'est une grosse modif de Rails 2.x. Côté django, les grosses réarchitectures sont terminées depuis la sortie de 1.0, tout du moins jusqu'à 2.0 mais 2.0 n'est pas encore sur les cartes, voire même prévu.

Sinon, pour les +django:

• Python
• Promeut (au niveau communautaire) une approche très découplée basée sur des "apps" indépendantes au sein d'un projet
• Django Admin
• GeoDjango (support de géoloc dans django), Pinax (jeu d'apps à intégrer), Satchmo (boutique en ligne)
• Très bonne doc officielle complémentée par de très bon bouquins
• Django, c'est juste du Python, pas de magie, pas de modif des classes builtin, …
• generic views
• Très bon support pour Postgres
• Quasiment pas de génération statique, un projet django nécessite juste 2 fichiers (et une app est composée de 0 fichiers)
• Communauté active, globalement sympa

-django

• Manque de support de testing d'une app en isolation (les tests tournent au niveau projet si on fait pas de bricolage)
• Moteur de template pas toujours idéal, facile à remplacer mais on perd quelques raccourcis (les generic views par exemple) et il faut les recoder soi même
• fichier settings.py parfois malpratique, la communauté est en train de chercher comment résoudre ce problème

Bon bah si vous faites ca sans trolls :
 
Pour la doc rails :
- le wiki a été rénové il y a peu http://wiki.rubyonrails.org/
- Les guides très clairs : http://guides.rubyonrails.org/
- Le bouquin de référence en version assez recente : http://pragprog.com/titles/rails3/ [...] rd-edition
- et bien sur la doc de l'API : http://api.rubyonrails.org/ (ou a voir depuis apidock.com)
 
Les + :
- ruby + active_support : syntaxe très claire, super dynamique et un tas de trucs qui simplifient la vies, genre :
3.days.ago + 1.month => Fri, 09 Oct 2009 11:54:05 UTC 00:00
%w(maman papa).map(&:capitalize) => ["Maman", "Papa"]
Bref, hyper fun !
- MVC. du peu que j'ai vu de django leur approche du pattern semble assez différente de celle de rails qui a été reprise par la plupart des frameworks php. si on a fait du codeigniter/cakephp ou autre on est en terrain connu
- Le framework pousse à utiliser les conventions REST, on peut se retrouver avec des controlleurs très clean et ajouter un flux rss en 2 lignes de code
- Le routing est aussi plutot bien foutu
- ActiveRecord est quand même super sympa
- Ecrire des tests, c'est facile et très clair avec cucumber, rspec ou encore shoulda
- Un bon gros tas de plugins qui permettent de gagner du temps : paperclip, authlogic, will_paginate... (http://ruby-toolbox.com/)
- Des generateurs pour gagner du temps
- La console est bien pratique
- Des fichiers de conf en yaml, et un système d'environnements (developpement, test, staging, production...)
- Deploiement facile avec les environnement cités ci-dessus et capistrano
- les migrations pour la bdd
- Pas mal de solutions pour faire du messaging avec activemq ou stompserver par ex
- haml et sass
- De gros sites sont faits en rails donc il y a pas mal d'interêt dans tout ce qui est scaling, systèmes de cache etc
 
Les -
- Ruby est encore pas très répandu, et il y a pas quelques problèmes avec son intégration dans les distribs (y compris debian). on se retrouve souvent a compiler sa version voulue à la main. Python lui est installé par défaut un peu partout
- C'est un peu le bordel entre les differentes versions : 1.8.6, 1.8.7, 1.9.x
- Beaucoup de metaprogramming et de "magie", que ce soit dans le langage ou dans le framework. Au début, impossible de savoir ce qui se passe derrière les 2 lignes de code qu'on écrit
- C'est lourd : 16Mo pour le framework, quelques secondes pour lancer un serveur d'appli, les perfs pas au top... mais rails 3 améliorera les choses
- C'est clairement pas fait pour les petites applis (rails 3 changera peut-être les choses). Dans la communauté ruby on utilisera plutot merb, ramaze ou sinatra
- Ca bouge trop vite. On est obligé de se tenir au courant des dernières sorties de plugins et versions. La norme d'un jour peut devenir complètement obsolète et déconseillée 6 mois plus tard. Rails 1.2.6 date de fin 2007 et le framework a quand même bien changé depuis. Rails 3 aura aussi pas mal de changements, mais une fois faits cela devrait se calmer

Qu'est-ce que tu veux dire par "Beaucoup de magie dans Ruby" ?

que tu écris "pouet" et que derrière ça t'économise 200 lignes de codes... et que par conséquent tu ne sais pas ce que "pouet" fait en coulisse. (enfin j'en déduis que c'est ça )

Je parlais d'exemples précis

Plus exactement, que "pouet" fait ça, et ça, et *ça* qu'à rien à voir, en encore *ça* qu'à encore plus rien à voir, je pense.

Des fonctionnalités hyper pratiques mais dont le fonctionnement est difficilement explicable simplement. Fin c'est ce que moi j'entendrais par magie.

edit : ah, des exemples.

Bah non, ça c'est juste une fonction, mais les proxies de méthodes (find_by_foo_and_bar(foo, bar) qui n'existent nulle part dans le code et finissent dans method_missing qui fait du munging pour en sortir un find_by(:foo=>foo, :bar=>bar) (sachant que c'est un exemple trivial ça)), des trucs par défaut appelés de partout sans indication d'où et de quand ça vient, autoloading de constantes, injections de valeurs dans ton contexte sans indication de leur source, etc…

Après, YMMV, perso ça me gratte à contresens.

En gros oui. Explicable ou même découvrable, pour commencer.

 
Voui je parlais de ça
C'est quand même hyper pratique mais il faut être prêt à se dire que si ca foire on va galérer pour savoir pourquoi

Bah je sais pas, tu peux faire ça avec un comportement plus régulier, donc je trouve l'intérêt discutable.

Là où avec Rails tu vas écrire

Foo.find_all_by_name(name)

avec Django tu vas écrire

Foo.objects.filter(name=name)

Comme le __call en PHP

Oui method_missing correspond à __call en PHP (en fait c'est équivalent à une combinaison de __call et __get dans la mesure où Ruby n'a que des méthodes, et en python ça correspond à __getattr__ vu que Python n'a que des attributs)

http://jayrobinson.org/2009/09/11/ [...] itunes-lp/
 
Les packages iTunes LP sont (presque) entièrement faits en HTML+CSS+JS

Foo.find_all_by_name(name)

Foo.objects.filter(name=name)

 
En pratique on utilise plus trop les find_by_attr
 
Tu peut très bien faire Foo.find(:all, :conditions => {:name => name}) (aussi possible avec un array ou un string)
 
Ou à la mode avec un named scope :

J'ai un bug vraiment étrange, que je n'avais pas d'habitude.  
 
<option selected="selected" value="valeur">Titre</option> ne fonctionne pas (au niveau du selected) sous firefox 3.5 alors que ça marche sous Safari. C'est le premiere fois que je suis confronté à ce bug, d'habitude ça marchait, ça me surprend.
 
Mon doctype : <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 
Quelqu'un a une idée ?

Les F5/actualiser peuvent mémoriser la position du selected (et d'autres éléments de formulaires). Pour éviter ça, recharge la page par *clic dans la barre d'adresse + entrée* ou accèdes-y par un lien. Utilise autre chose que F5 ou même CTRL-F5, quoi.

Dis si ça marche.

J'ai mon cache de désactivé dans la toolbar donc c'est pas ça (j'aurais bien aimé)

Rien à voir avec le cache justement.

J'ai toujours utilisé Ctrl + F5 pour pallier ce "problème", ça a toujours marché ainsi

Ah ouais ça marche
Mais désactiver le cache ne change rien par contre.

 
Ouaip, c'est pas du cache... juste une fiture.

 
woohoo

WebGL dans les dernières builds de webkit :
http://blog.wolfire.com/2009/09/pr [...] -canvas3d/
 
j'ai hâte
 
et je vois déjà le coup que MS va encore être à la traine pendant 10 plombes là dessus  
d'autant plus que si mes souvenirs sont bon, ils sont pas super fan d'openGL

Moi encore plus...

un <form action=""> renvoie toujours à la page actuelle ? Quelque soit le navigateur ?