DPhil a écrit 453 commentaires

Ce sont eux qui ont demandé au W3C de réintégrer le travail:
http://lists.w3.org/Archives/Public/public-html/2007Apr/0429(...)

Une grande partie des lecteurs MP3 ayant un chipset de type S1MP3 peuvent lire les ogg même si rien n'est indiqué dans la doc.

Je dispose d'un MemUp Senso qui lit très bien les ogg même si rien n'est indiqué dans la doc et même chez MemUp ils ne semblent pas être au courant.

D'après ce que je comprend de la GPL, ton code n'a pas besoin du driver mysql pour fonctionner et le driver mysql n'a pas besoin de ton code pour fonctionner, libre à toi de lui donner la licence que tu veux.

C'est mon interprétation de la faq:
http://www.gnu.org/licenses/gpl-faq.html#TOCGPLInProprietary(...)
http://www.gnu.org/licenses/gpl-faq.html#TOCGPLIncompatibleA(...)

Le moteur de rendu de Apollo est Webkit issu du projet OpenDarwin. Celui ci est sous licence LGPL mais Adobe a promis de reverser les améliorations et modifications faites sur Webkit à la communauté.

Tu te trompes ;-)

Les résultats de Google sont de moins en moins pertinents à cause de leurs différents filtres pour empêcher la spamdexing qui pénalisent aussi les sites web classiques.

Bah pour un boulot sur Paris et en plus il cherchent quelqu'un d'expérimenté ( ça ce comprend vu la boite ), je pense que c'est quand même relativement mal payé.

Au passage, mon troll du jour, quelqu'un d'expérimenté refusera sans doute de bosser avec des trucs comme Smarty.

A propos de Django et Turbogears.Ca ressemble plus à un assemblage de briques eparses (CherryPy, ....) qu'a une offre consistante. Ca n'est pas encore comparable à RoR.

Pour avoir bosser avec ROR et bossant actuellement avec Django,je peux t'assurer qu'il n'a rien a lui envier. Django est mature, il existe depuis aussi longtemps que ROR ( si ce n'est pas plus ).

Pour ce qui est de TurboGears, oui c'est un assemblage de différents composants et c'est une très bonne idée je trouve. On utilise des briques éprouvées et on peut réutiliser le code en dehors du framework.


La communauté Python cherche encore son framework web:

Pour quoi ne devrait-il y avoir qu'un seul framework ?
A chacun ses spécificités, Django étant plus orienté publication et TurboGears plus orienté application.

Il ne faut pas prendre en compte uniquement les abonnements, il y a tous les "à côté":

- achat de sonneries pour GSM à partir du portail du FAI
- idem pour tout ce qui est affiliation
- les services complémentaires ( anti-spam, anit-virus ... )
- services audio/vidéo payant

etc ...

Une valorisation à moins de 600€ l'abonné, on est loin de la grande époque de LibertySurf ou World On Line où un abonné était valorisé à plus de1500€ .

+1, le tutoriel es très bien fait.
La doc Python sur le site est pas mal aussi même si elle manque d'exemples. Ils gagneraient à ouvrir les commentaires comme pour la doc PHP, les exemples les plus intéressants se trouvant souvent dans les commentaires.

On peut rajouter quelques ressource disponibles gratuitement sur le web:
- dive into python de Marc Pilgrim qui permet d'aller un peu plus loin que le simple apprentissage
- Thinking in python de Bruce Eckel dans la même veine que le précédent
- Apprendre à programmer avec python de Gérard Swinnen ( très bon livre pour débuter )

Par contre, j'ai acheté le livre Programmation Python de Tarek Ziadé et j'en ai été très déçu, il se présente comme un livre de programmation avancée et en fait il n'en est rien, juste une simple compilation de diverses informations piochées ci et là sur le web sans jamais rien expliquer.

Après un rapide coup d'oeil à la documentation pour les développeurs, il semble que Vanilla ait été conçu dans un réel soucis d'extensibilité.

Fini les hacks immondes du code de l'application ( cf les forums les plus connus ). Avec Vanilla, on créé un plugin, on dit à quels événements il se rattache et c'est tout. On peut donc par exemple agir sur le rendu d'un post sans devoir retoucher le fichier de l'application correspodant.

Maintenant, il va falloir rearder d'un peu plus près si le code de l'appli est propre.

Ben oui, pourquoi crois tu que c'est le haricot *de java*

En même temps, à l'heure ou j'écris ces lignes, 2, 56% des abonnés regardent Gulli, il n'y aurait pas un petit problème dans leurs stats.

Puisque tu en es à faire des corrections, ce n'est pas MPEG3 mais MPEG II Layer 3.

FF 1.5 a le support SVG en natif.

FF 1.5 et Opera 9 ont mieux que le SVG, c'est le canvas qui est en cours de normalisation par le W3C.
http://standblog.org/blog/2005/09/13/93114364-firefox-15-pou(...)

les appels d'offre sont publiés ou JO (ou équivalent), pas envoyés en secret aux entreprises

Si si, on peut le faire en France tant que le montant de l'appel d'offre ne dépasse pas un certain montant ( 90 000 ¤ il me semble ), on appelle ça une consultation ou un marché négocié. Au dessus il y a effectivement un concours.

Rajouter htmlentities ne servira pas à grand chose, cette fonction n'est pas compatible avec certains encodage comme utf-7

http://jabphone.com/rates.php

Est-ce que la v2 est plus rapide que la version 1 ?

Car c'est très bloquant, on ne peut l'utiliser que sur des sites à faible traffic sous peine de voir le site ramer complètement et de ne jamais pouvoir consulter ses stats.

Sinon, dommage qu'on ne puisse pas migrer directement de la v1 à la v2.

[i]Generalement les gens aiment Ruby pour Ruby .[/i]

Ou n'aime pas Ruby à cause de Ruby.

Je confirme, création d'un fichier vide de la taille du fichier en téléchargement dès le debut de celui-ci.

En plus, une petite remarque sur la syntaxe SQL.

Il est bien ( recommandé ) de faire les jonture avec la clause JOIN et non dans la clause WHERE, d'ailleurs PostGreSQL peut s'avérer plus performant avec la syntaxe JOIN.

Comme dans presque tous les langages de script actuel, PHP est compilé pour tourné dans une sorte de machine virtuelle.

Par contre, le script doit être recompilé à chaque exécution à moins d'utiliser un cache d'op-code ( le code produit par la compilation ).

On a tout d'abord ADODB-ext., dbx, DBDO ( qui fait du mapping OR en plus )

Avec PDO, on a très peu d'accès au meta données, ce qui oblige à les récupérer d'une autre façon ( façon qui est souvent dépendante du SGBD, on perd donc l'abstraction )

Les objets retournés avec PDO sont des objet standards ( comme avec mysql_fetch_object ), ça ne fait pas vraiment avancer le schmilblik en terme de programmation objet.

Un binding avec libgda ( gnome-db ) aurait été à mon avis plus opportun.

Maintenant, ça reste quand même une bonne chose qu'on ait une interface intégrée et objet de surcroit pour l'accès aux SGBD.

L'intégration de PDO est une bonne et une mauvaise nouvelle à la fois.

Une bonne nouvelle car on a enfin une interface unifiée d'accès au SGBD intégrée dans PHP.

Une mauvaise car PDO est loin d'être complet et quasiment inutilisable dans des projets conséquents, c'est dommage que ce soit PDO qui ait été retenu alors qu'il y avait pléthore de projets bien lus avancés.