Bruno Michel a écrit 3285 commentaires

Je n'ai pas réussi à mettre en forme les exemples avec templeet. La même chose sur la future version en Rails de LinuxFr.org est visible là : http://alpha.linuxfr.org/users/nono/journaux/essai-coloratio(...)

Si je comprends bien l'exemple, l'équivalent en Rails (ActiveRecord) serait :


# Le modèle est décrit dans le fichier app/models/user.rb
class User < ActiveRecord::Base
# Validations
validates :email, :uniqueness

# Lifecycle callbacks
before_save :do_stuff_on_pre_persist
before_save :do_another_stuff_on_pre_persist_too
after_save :do_stuff_on_post_persist

# Associations
has_one :address, :dependent => :destroy
has_many :phone_numbers
has_ad_belongs_to_many :groups
end



# La création de la table SQL se fait avec une migration (fichier db/migrate/_create_users.rb)
class CreateUsers < ActiveRecord::Migration
def self.up
create_table :users do |t|
t.string :name, :limit => 50, :null => false
t.string :email, :limit => 32, :null => false
end

# Indexes
add_index :users, [:name, :email], :unique => true
add_index :users, :name # Cet index est redondant, mais je l'ai gardé car il était dans l'exemple de départ
add_index :users, :email
end

def self.down
drop_table :users
end
end


Les goûts et les couleuvres, ça ne se discute pas. Personnellement, je suis bien content de ne pas avoir cette "abstraction" dans Rails et Django.

Pour que chacun puisse juger, voici un petit exemple tiré du manuel [http://www.doctrine-project.org/docs/orm/2.0/en/reference/xml-mapping.html#example] :

// Doctrine.Tests.ORM.Mapping.User.dcm.xml
<?xml version="1.0" encoding="UTF-8"?>
<doctrine-mapping xmlns="http://doctrine-project.org/schemas/orm/doctrine-mapping"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://doctrine-project.org/schemas/orm/doctrine-mapping
http://www.doctrine-project.org/schemas/orm/doctrine-mapping.xsd">

<entity name="Doctrine\Tests\ORM\Mapping\User" table="cms_users">

<indexes>
<index name="name_idx" columns="name"/>
<index columns="user_email"/>
</indexes>

<unique-constraints>
<unique-constraint columns="name,user_email" name="search_idx" />
</unique-constraints>

<lifecycle-callbacks>
<lifecycle-callback type="prePersist" method="doStuffOnPrePersist"/>
<lifecycle-callback type="prePersist" method="doOtherStuffOnPrePersistToo"/>
<lifecycle-callback type="postPersist" method="doStuffOnPostPersist"/>
</lifecycle-callbacks>

<id name="id" type="integer" column="id">
<generator strategy="AUTO"/>
<sequence-generator sequence-name="tablename_seq" allocation-size="100" initial-value="1" />
</id>

<field name="name" column="name" type="string" length="50" nullable="true" unique="true" />
<field name="email" column="user_email" type="string" column-definition="CHAR(32) NOT NULL" />

<one-to-one field="address" target-entity="Address" inversed-by="user">
<cascade><cascade-remove /></cascade>
<join-column name="address_id" referenced-column-name="id" on-delete="CASCADE" on-update="CASCADE"/>
</one-to-one>

<one-to-many field="phonenumbers" target-entity="Phonenumber" mapped-by="user">
<cascade>
<cascade-persist/>
</cascade>
<order-by>
<order-by-field name="number" direction="ASC" />
</order-by>
</one-to-many>

<many-to-many field="groups" target-entity="Group">
<cascade>
<cascade-all/>
</cascade>
<join-table name="cms_users_groups">
<join-columns>
<join-column name="user_id" referenced-column-name="id" nullable="false" unique="false" />
</join-columns>
<inverse-join-columns>
<join-column name="group_id" referenced-column-name="id" column-definition="INT NULL" />
</inverse-join-columns>
</join-table>
</many-to-many>

</entity>

</doctrine-mapping>

Dans un genre assez similaire (macarons pour afficher les bonnes intentions), Aza Raskin a proposé, dans le cadre de son travail chez Mozilla, des icônes pour la vie privée. Les sites peuvent indiquer via quelques icônes les traitements qui pourront ou ne pourront pas être faits sur les données des utilisateurs.

Ça se passe sur http://www.azarask.in/blog/post/privacy-icons/ .

Dans les deux cas (MC et privacy icons), je suis assez perplexe sur l'efficacité d'un tel système. Le découpage se fait toujours avec un coté "bien" et un coté "moins bien". Je vois bien les gens utiliser les icônes "bien" mais pas les autres, or c'est justement les icônes qui avertissent du danger/coté négatif qui seraient utiles.

> Et une vidéo est mieux que de l'hypertexte ?

Non, mais c'est un bon complément.

> Une vidéo n'est pas indexable

Si, cf http://www.google.com/search?q=GNU+parallel&tbo=p&tb(...) par exemple.

> une vidéo n'est pas navigable comme du texte

Oui, et le texte n'est pas navigable comme de la vidéo. Ce sont deux médias différents, avec leur méthode de navigation. Certains préfèrent le texte, d'autre la vidéo. Je ne vois pas de raison de ne pas avoir les deux quand c'est possible.

> une vidéo n'est pas accessible.

C'est très discutable. Il existe des bonnes pratiques pour rendre accessible des vidéos. D'autre part, un texte n'est pas forcément accessible : il doit être dans la bonne langue, rédigé avec un vocabulaire adapté aux lecteurs, sans abréviations et acronymes non-expliqués, etc. Bref, dans certains cas, une vidéo peut être plus accessible que son équivalent textuel.

Pour info, d'autres participants avaient également déclarés que prolonger le concours allait les aider à proposer une CSS.

Pour l'April, il y a eu un dossier (refusé). Pour LQDN, je ne sais pas.

En cherchant un peu, j'ai fini par trouver des exemples dans http://www.gitorious.org/whippet/whippet/trees/master/tests dont un Hello world :


methods_begin
proc myproc (a)
{
printout $a
}
methods_end

set string hello "Hello world!"
myproc ( $hello )
unset hello


Je me demande si les fonctions trampolines ne permettent pas de faire ça : http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html

C'est très difficile à évaluer et j'ai du mal à voir quels critères objectifs pourraient appuyer une opinion sur le sujet. Disons juste que les 100 millions de téléchargements en 18 mois doivent bien servir des gens, donc l'utilité moyenne ne doit pas être trop mauvaise.

Non, je n'en sais rien.

> Lisaac ne l'utilise pas encore mais j'ai du mal à voir ce qui est plus complexe que changer la gestion interne des string.

PHP 6 dont la principale nouveauté devait justement être la prise en charge en interne d'Unicode a finalement été annulé. Après plusieurs années de développement, il restait encore bien trop de problèmes à résoudre pour espérer pouvoir sortir une version avant un paquet d'années. Ce n'est donc probablement pas si simple que ça d'ajouter sa prise en charge à un langage existant.

Un petit lien sur le sujet : http://schlueters.de/blog/archives/128-Future-of-PHP-6.html

> Je ne pense pas que l’ouvrage cité au début de l’article traite du temps libre des informaticiens mais plutôt de moyens d’augmenter sa « valeur marchande » en tant que programmeur.

Le livre traite de comment devenir un meilleur programmeur. Après, on peut l'appliquer dans un contexte professionnel ou sur son temps libre, libre à chacun de choisir.

> Au lieu d’apprendre un nouveau langage de programmation, la plupart des informaticiens devraient plutôt parfaire leur connaissance du langage …humain que ce soit sous forme écrite ou verbale.

Il y a aussi quelques conseils à ce sujet dans le livre The Pragmatic Programmer ;-)

> En pratique d’ailleurs je conseillerai plutôt aux programmeurs d’approfondir plutôt leur connaissance dans le domaine où leur application sera utilisée.

Tiens, encore un conseil présent dans The Pragmatic Programmer.

> Une spécification mal comprise, interprétée de travers voire pire « améliorée » donnera quelque soit le langage de programmation utilisé un résultat non conforme.

Oui, mais bon, j'ai vu tellement de spécifications mal écrites, incomplètes, inconsistentes ou qui changent à de multiples reprises que j'ai du mal à croire que s'en tenir stricto sensu à des spécifications est le chemin de la réussite. Après, cela doit sûrement dépendre du domaine.

Est-ce que tu as essayé Scala ? Ça a l'air de répondre pas trop mal à tes contraintes.

> Si tu trouves une syntaxe affreuse, c'est généralement parce que tu n'es pas familier avec elle.

Et on devient familier au bout de combien de temps ? Nan, parce que ça fait quelques années que je fais du templeet et je trouve la syntaxe affreuse. Franchement, quelle idée d'utiliser un caractères à la con comme le tilde pour quelque chose d'aussi courant que appeler une fonction, mais peut-être qu'un jour je comprendrais :-)

Comprendre est une chose. Savoir modifier le code et garder le même nombre de parenthèses ouvrantes et fermantes (de préférence aux bons endroits) en est une autre :p

> Chaque langage présentant ses spécificités, le mélange des genre risque même d'être plus préjudiciable qu'autre chose, à mon sens.

Au contraire, apprendre des langages différents permet d'apprendre de nouvelles façons de programmer, y compris pour les langages que l'on maitrisait déjà. Par exemple, je connaissais relativement bien Ruby, puis quand j'ai appris un langage de programmation fonctionnel, mon style en Ruby a changé : j'ai utilisé plus souvent des méthodes comme map et inject, et j'ai tendance à écrire des méthodes avec beaucoup moins d'effets de bord. Bref, je trouve mon style en Ruby bien meilleur et j'ai probablement plus progressé que si je n'avais fait que du Ruby sur cette même période.

Par contre, je te rejoins sur un point, apprendre plusieurs langages peut présenter des risques de confusion. Il faut donc mieux éviter de vouloir se lancer dans plein de langages tant que l'on n'en maitrise pas correctement un, et il vaut mieux choisir des langages avec des paradigmes différents : programmation fonctionnelle contre orientée objets, typage statique vs typage dynamique, le choix est vaste ;-)

> Pourquoi ne pas utiliser erlang plutôt que d'essayer Reia ?

Parce que la syntaxe d'Erlang est assez affreuse ;-)

Je l'avais mis en 4ème lien dans la dépêche, ce n'était pas suffisant ?

> Il n'aurait pas été possible d'avoir un mode de compatibilité ruby (ie juste une nouvelle vm pour l'existant ruby) ?

C'est possible, mais ça demande un effort plus conséquent, notamment pour supporter tout ce qui est metaprogramming. En tout cas, l'auteur de Reia n'a pas l'air de vouloir aller dans cette direction.

> En revanche, il est franchement mauvais pour monter une communauté :)

C'est pas faux :-)

Mais la communauté ne se limite pas à une mailing-list et un wiki. J'attends surtout de voir ce que ça va donner quand la nouvelle version sera en ligne : est-ce que l'on aura + ou - de CSS spéciales ? Est-ce que le wiki interne sera utilisé et jardiné régulièrement ? Est-ce que l'on aura des propositions d'évolutions intéressantes avec des discussions dans les commentaires pour faire encore mieux ? Va falloir attendre encore un peu pour voir ça ;-)

> Franchement, c'est à jeter l'éponge de trouver des contributeurs dans la durée sur LinuxFr

Non, il y a déjà des contributeurs réguliers dans la durée sur LinuxFr.org, mais il faut les chercher du coté des CSS. Je pense à Obsidian, à Benoît Monin, à Stéphane Blondon, et à d'autres qui proposent régulièrement de nouvelles CSS ou des évolutions depuis 2 ou 3 ans.

Alors que les ingénieurs de Google se débrouillent bien mieux, comme on a pu le voir avec Google Wave par exemple ;-)

Plus sérieusement, dans ces entreprises, il y a beaucoup de développeurs, trop pour pouvoir tous les classer dans une seule catégorie. Il y a de très bons développeurs et aussi des moins bons. On ne peut pas juste prendre une entreprise de cette taille et dire que tous les employés sont mauvais.

L'auteur n'est peut être pas aussi objectif que l'on pourrait l'espérer, mais il reste très pertinent. En particulier, le premier point me paraît important : Diaspora n'a toujours pas de plan pour "distribuer" le graphe social et les actions qui vont avec.

Pour ma part, je reconnais bien plus vite un avatar que je ne déchiffre un petit bout de texte. Et je m'en souviens plus longtemps, ce qui peut être pratique quand on discute souvent dans les commentaires.

> quels changements sont faits ?
> ya un avant / après pour ceux qui proposent des css ?

Les changements sont à chaque fois assez mineurs, mais dans le lot, il y a sûrement une ou deux feuilles de styles où cela peut avoir des effets de bord (des marges en plus, un sélecteur qui ne s'applique plus, etc.).

> tout est-il sur https://github.com/nono/linuxfr.org/issues/labels/HTML%20CSS ?

Non, ça serait trop simple ;-)
Il y a aussi des demandes sur le suivi interne de LinuxFr.org [http://linuxfr.org/tracker/], en commentaires sur alpha, et même une que j'ai reçu par email.

> je suggérais de remonter des améliorations possibles sur le code qui génère le HTML...

Je confirme : les améliorations sont aussi les bienvenues !