Julien Portalier a écrit 412 commentaires

Je n'ai jamais eu tous ces problèmes lors de merge back avec subversion, même lorsque les modifications sont particulièrement lourdes, touchent à tout, effacent et déplacent des fichiers. Par contre il faut que la branche soit parfaitement synchronisée avec le trunk avant de tenter le merge back.

Mais les branches sont en effet lourdes à gérer, subversion n'est pas (encore) vraiment adapté à la gestion de branches, et apparemment c'est toujours pas prêt de devenir simple. Ça marche, mais il faut bien tout noter : à quelle révision on a créé la branche ; la dernière révision du merge avec le trunk ; la dernière révision du merge back ; etc.

En effet. Il est bien trop dur de cliquer sur le lien fourni en début d'article et pointant vers la page Wikipédia de EVE Online, très informative (et en français de surcroît).

Je pense qu'il ne se trompe pas.

Je code en PHP depuis longtemps, en PHP 5 depuis au moins deux ans. J'ai même codé un framework MVC l'an dernier pour me faciliter la tâche (n'aimant pas ceux existants) et apprendre la forme objet de PHP 5.

Curieux, j'ai jeté plusieurs fois un ½il à Ruby. Je ne l'ai pas aimé les premiers temps, car la forme me rebutait. Cependant ces dernières semaines, j'ai lu les livres Why's (Poignant) Guide to Ruby et Programming Ruby (The Pragmatic Programmer's Guide)[2]. J'ai alors pris conscience de la vétusté (et de la staticité) de PHP ! Ruby est un language élégamment pensé, dans sa conception comme dans sa syntaxe et ses possibilités.

Je n'ai pas encore lu les livres sur Ruby on Rails que je saisi déjà toute sa puissance, et pourquoi Rails ne peut pas exister dans un autre language (moi aussi j'étais sceptique... avant). Je sais déjà que lorsque je serai au point sur Ruby, je passerai à Rails ; et lorsque je serai au point sur Rails, je laisserai tomber PHP, sans regrets (juste de la nostalgie). Ce qui me retient d'y passer de suite c'est que je suis efficace en PHP et qu'il va me falloir encore un peu de temps pour vraiment l'être en Ruby. Quoiqu'en fait il me faut juste lire un bouquin sur Rails, et me lancer.

Le seul truc qui m'embête c'est que la doc librement accessible de Ruby on Rails est assez spartiate -- seule la réf. est vraiment complète, ce qui est un peu abrupt pour découvrir le framework. Il faut donc acheter les livres. C'est dommage. En attendant les livres pour Ruby sont librement accessibles, notamment sur http://ruby-lang.org/fr/

[1] http://qa.poignantguide.net/
[2] http://www.rubycentral.com/pickaxe/


> C'est un langage très facile à apprendre

Ruby n'est pas dur. Vraiment. Sa syntaxe est pensée pour arranger le développeur, pas l'interprêteur (qui finalement y trouve très bien son compte). Cependant pour bien saisir Ruby, il vaut mieux avoir une bonne connaissance de la programmation et une connaissance solide de l'objet au préalable. J'avais déjà été impressionné par le modèle objet de PHP 5. Celui de Ruby est incomparable.

> Pour celui qui ne sait pas programmer, il y'a une quantité industrielle de CMS en tous genre, et c'est souvent l'envie de modifier ceux-ci pour l'adapter a son site qui fait que l'utilisateur moyen se lance dans l'apprentissage de PHP.

C'est justement là le problème de PHP. Des tas de CMS et de frameworks dans tous les coins. Tellement de diversité qu'on ne sait plus vers quoi se diriger. Du coup on finit par coder ses propres outils, ce qui ne règle rien au problème.

Bonne question. Concernant PHP il a débuté sur du pur procédural (avant PHP3) pour implémenter de l'objet au fur et à mesure. Bref le language lui-même est passé du procédural à l'objet, tout en restant compatible avec le procédural. Je pense que c'est justement cet héritage procédural qui fait de PHP un language difficile à faire évoluer sans tout casser. Il faudrait (presque) le forker et tout transformer en profondeur pour fonder un PHP6 où tout serait objet, et non fonctions et, ou objets (comme l'extension SQLite 2), etc.

Je n'ai pas suivi l'évolution de PERL, mais il me semble que c'est ce qu'ils ont choisi de faire pour la version 6 : repenser tout le language. D'ailleurs après avoir lu quelques trucs, il a l'air pas mal du tout ce PERL 6.

PHP intégre les changements graduellement. C'est pratique, car si on programme de manière propre, l'évolution du code est simple. Il suffit de lire les guides de migration, et on passe sans trop de difficultées d'une version à sa suivante. Mais c'est aussi un très gros inconvénient en ce que le language est inconstant.

D'autres languages, comme Ruby, ne devraient pas avoir ce problème à mon avis. Ils ont été conçus pour un style de programmation (pur objet), et ne mélangera pas plusieurs formes en un seul language (ce serait contraire à sa philosophie).

J'espère que tu n'inclues pas la forme <?= $foo ?> qui permet de remplacer <?php echo $foo ?> dans ton propos, si ? Parce que si ce n'est pas plus rapide pour l'interprète, c'est plus rapide et agréable à lire pour le programmeur.

> plus on va monter dans les versions de PHP, plus les scripts codées avec les pieds seront inutilisables.

Tant mieux.

Ah. Donc JRE va continuer à grossir à chaque version ?

Tout à fait. Au lieu d'imprimer une masse de papier (un par condidat et votant inscrit sur les listes électorales) qui va se retrouver directement à la benne, on pourrait imprimer un seul bulletin par votant (remplissant son devoir). Ce serait mieux. De plus la machine pourrait comporter un lecteur d'écran (en braille), permettant aux aveugles de voter sans tierce personne par exemple ; car je ne crois pas que les bulletins soient imprimés en braille.

Cependant la machine peut aussi compter, rien ne l'en empêche. Cela permettrait une estimation dès la fermeture du bureau de vote par exemple. Mais juste une estimation, pas un résultat, car seul un dépouillage pourra le donner, ce résultat. Cela permettrait même une vérification directe, le résultat de l'ordinateur devant être identique à celui du dépouillage.

Être contre la machine -- en tant qu'outil -- est peut-être tout aussi idiot que de lui confier aveuglement son vote.

Depuis que je suis passé à Epiphany je me rends compte combien Firefox est lourd et lent chaque fois que je dois l'utiliser. Le moteur est le même (Gecko) et seule l'interface est en GTK et non plus en XUL, et pourtant ça n'a rien à voir.

Si Gecko n'était pas dopé au XUL, peut-être serait-il lui aussi plus léger et performant ?

XUL a beau être utilisé par diverses applications plus ou moins connues, quand on sait qu'ebay, la FNAC etc. créent actuellement leurs interfaces riches avec MS Silverlight & Adobe Apollo on se dit que XUL a perdu d'avance. Silverlight & Apollo sont tous deux basés sur du multimédia (son, animation et vidéo) : Flex pour l'un ; Flash pour l'autre. Ce sont des composants essentiels pour composer des interfaces riches qui en mettent plein la vue et qui permettent d'aller plus loin qu'avec de l'image toute bête.

Microsoft a l'avance côté serveur avec .NET, mais Adobe a l'avance côté client avec Flash (utilisé partout aujourd'hui). Reste à savoir qui sera le plus convaincant.

Est-ce que ça va révolutionner le Web ? Franchement, je ne crois pas.

Pourquoi cela devrait-il être forcément gratuit ? Moins cher que MS Windows je suis d'accord, car il n'y a pas à payer la licence, mais de là à dire que ce devrait être gratuit, je ne suis pas d'accord.

Certes les logiciels sont gratuits, mais rien n'empêche Dell de les vendre et de vendre du support. Pouvant par là-même devenir un support financier pour OOo et GNU/Linux en général.

Sinon c'est toujours de la « force forcée », rien ne change, sauf qu'on aurait alors le choix du système d'exploitation : MS Windows (Vista) ou GNU/Linux (ubuntu?). On trouvera d'ailleurs toujours un bon nombre d'utilisateurs pour râler, car ils devront acheter telle distribution alors qu'ils veulent en mettre une autre, un *BSD ou encore autre chose.

Sauf qu'un ordinateur doit être vendu fonctionnel. Or sans OS un ordinateur ne marche pas et il me semble que ça n'est pas très légal. De plus augmenter les choix dans une chaîne de production revient à la complexifier, à générer plus d'erreurs et coûte au final bien plus cher à maintenir, ce qui oblige à vendre plus cher :/

Moi ce qui me fait rire c'est que le WMA est bien marqué compatible windows c'est tout. Le MP3 est marqué compatible avec tout : tous lecteurs, tous baladeurs, tous systèmes.

Pourquoi vendre une version WMA dans ce cas, vu que c'est lisible que sur un ordinateur alors que le MP3 est lisible partout ?

Les gens ne pourraient alors plus écouter ce qui est extrait des catalogues des majors, c'est-à-dire une la grosse majorité des ventes sur itunes. Les majors ne s'arrêteront pas pour si peu et continueront d'exiger des DRM. Le WMA serait alors la seule solution pour les majors.

Apple perdant, Microsoft gagnant. Pas possible pour Apple.

Un intégriste, quel qu'il soit, cherche à imposer son idéologie. Les « intégristes » du libre ne me semblent pas chercher à imposer leur croyance, mais la défendent mordicus -- sans pour autant sortir armes et baïonnettes --, défendant tout le monde au passage.

Je crois que ça fait là une sacrée différence.

Des frameworks de qualité pour PHP il commence à y en avoir, il faut juste ne pas généraliser à partir d'un seul. Seulement PHP continue de véhiculer une image cheap par ses origines de petits scripts vite fait (mal fait) du coup ils n'ont pas toute l'attention qu'ils méritent. On préfère les JSP, c'est plus rassurant, plus professionnel.

Pourtant PHP5 est vraiment bon. Ses performances sont largement au dessus de celles de Ruby par exemple. Le problème des frameworks PHP c'est qu'ils sont presque tous à la sauce RoR et qu'ils font un maximum de choses sans penser aux performances et à la simplicité du code du framework lui-même. C'est le cas de CakePHP[1] par exemple. Il est complet, stable et a une grande communauté derrière lui, mais le code est trop compliqué et ses performances sont égales à celles de RoR. Autant profiter des avantages de Ruby dans ce cas.

Mais dire que tous les frameworks PHP sont des usines à gaz, c'est un peu fort. CodeIgniter[2] me semble léger et élégant dans sa conception. J'en ai aussi programmé un dont les performances sont tout à fait honorables : FeatherPHP[3]. Malheureusement je n'ai pas encore eu (ni pris) le temps d'écrire la documentation et le site web correspondant -- il est à peu près stable et plutôt complet, mais n'a que 2 mois d'existence ;)

À noter que si Ruby on Rails est si demandé, c'est grâce à 37signals (son concepteur), qui a construit toute une gamme de sites professionnels de qualité dessus. Du coup tout le monde veut son site web avec RoR aujourd'hui.

PS : http://www.php.net/manual/fr/language.oop5.php et http://www.php.net/manual/fr/migration5.php permettent de bien comprendre et maitriser tous les trucs ajoutés dans PHP5.

[1] http://cakephp.org
[2] http://codeigniter.org
[3] http://code.google.com/p/featherphp
[4] http://37signals.com

Il est en deux partie : un driver pour xorg et un module pour le noyau. Le premier discute avec le second qui discute avec la carte (enfin je crois).

C'est pas une question de fonte, plutôt ? Une fonte dont le 7 et le Z seraient barrés. Mais de typographie, j'ai un doute là...

Je plussoie. Je préfèrerais vivement accéder simplement aux ½ et ¼ de cette manière que de devoir aller le chercher dans un coin de clavier... Certes le format azerty est un format où on se tord les doigts en permanence, mais là quand même...

Pouvant générer les deux autres caractères via les touches mortes, je ne vois pas de raison de ne pas changer. Surtout si le patch est « agressif » ;)

Il n'empêche qu'une lib facilement intégrable à des lecteurs ou un logiciel de manipulation et de compression serait fort agréable. Car pour le moment bosser avec des sous-titres SSA/ASS sous GNU/Linux ce n'est pas (encore) possible.

Dommage, ne serait-ce que pour pouvoir utiliser différentes fontes ou des styles (couleur, emphase, etc.) ce serait fort sympathique. Surtout dans des conteneurs avancés, type Matroska (mkv) :)

Mais si arrive, alors je dis méga-glop !

Le contenu de ton blog ne doit pas faire référence à ce que les bots cherchent. Les seuls trackbacks de spams que j'avais sur mon ancien site étaient pour de rares posts où je parlais de trucs connus, comme Les Simpson. Le reste ne recevait aucun spam.

Ça doit expliquer pourquoi les cartes sont aussi détruites par la compression JPEG. C'est pas bon pour l'IGN de donner ses cartes d'aussi bonne qualité, comme ça, à tout le monde.

Sauf que c'est un mauvais calcul : si le site était superbe, avec de très belles cartes, ça pourrait donner envie d'acheter des cartes, ne serait-ce que pour les chemins de randonnés. C'est plus pratique en rando. Mais avec une qualité aussi mauvaise, ça ne donne pas envie d'aller acheter des cartes de l'IGN.

Bah ils vont nous bricoler un GeoPortail payant, avec cette fois les cartes parfaites. Faut bien rentabiliser.

Ah non, en fait c'est à nouveau Disney. Faudrait qu'ils arrêtent leur chassé-croisé ces deux-là...

Et Pixar c'était Disney (distribution), mais plus maintenant (enfin quand ils auront fini les films sous contrat).

Y'a Jarring Effects aussi ! C'est-à-dire tous les albums d'Ez3kiel, High Tone, etc. Sauf que les albums d'Ez3kiel ont de telles pochettes qu'il serait dommage de ce priver des CD :)

http://www.indemusicshop.com/index.php?page=label&lab=94

Dommage pas de format FLAC ou tout simplement de format de compression sans perte, ce serait bien mieux pour pouvoir générer les versions compressées que l'on souhaite en fonction de ce dont on dispose. Ne serait-ce qu'un OGG au bitrate qu'on souhaite. Et pour se graver un CD ce serait parfait, un format lossless c'est mieux quand-même.

À noter que Magnatune fournit un service bien plus intéressant (différents formats, donc des lossless, re-téléchargement, etc).

Il mérite la première page, ne serais-ce car cela va faire découvrir les fictions interractives à pas mal de monde (moi le premier). Ce n'est pas une news, même s'il est bien rédigé. Cependant il aurait fallu préciser la nature non-libre et la non disponibilité de cette version 7 pour Linux.

Intéressant sinon ces logiciels et le concept général de fiction interactive. Quoiqu'un peu limité au purement textuel, ce qui est dommage dans un environnement multimédia. Et les visual-novels alors ?

Euh non justement, ce sont des exemples de distrib que Mme Michou elle va avoir 'achtement du mal à s'en servir si elle veut pas mettre les mains dans le camboui.

Quoiqu'avec ma arch, je passe franchement pas beaucoup de temps à tripatouiller. J'en passe plus à dépatouiller la ubuntu du portable de ma copine -- qui aurait franchement besoin d'une mise à jour, sauf que ça sera pas pour tout de suite. J'aurai dû mettre une arch ;)

Mais question : ça apporte quoi Frugalware face à Archlinux ? D'après ton journal je dirais que pas grand chose...