Alexandre Brillant a écrit 11 commentaires

  • # Eliza et ChatBot

    Posté par  . En réponse à la dépêche Bloquer le SPAM avec Postfix. Évalué à 6.

    Pour répondre automatiquement à un Spam façon
    "psychologue".

    http://webreference.com/perl/tutorial/13/4.html(...)

    Un petit exemple :

    >Subject: petition
    >Please sign and distribute Sent: Monday, April 16, 2002 10:43 AM
    >Subject: URGENT! WE NEED 1,000,000 SIGNATURES!
    >Dear all:

    Hi, how are you?

    >Please sign this petition and pass it around to everyone you know. It
    >is very important to collect at least 1,000,000 signatures.
    >Don't wait; just pass it to every one you know without delay. This is
    >a petition that may help lawyers in Belgium who are suing
    >Ariel Sharon. They need 1,000,000 signatures, so please sign it and
    >pass it on.

    Someone special perhaps?

    >To sung please click on the the website is given below. Thanks for all your
    >help.

    Tell me more about that.

    --

    Bon l'ennui dans tout cela c'est que le gars
    risque de vous ennuyez davantage. A moins qu'il
    finisse par se lasser ?
  • # Open-R et Cog

    Posté par  . En réponse à la dépêche Ca marche au GPL. Évalué à 10.

    Information Sony sur le passage de sa plate-forme Open-R en GPL : http://www.sony.co.jp/en/SonyInfo/News/Press/200205/02-017E/ Cog, un robot développé au MIT qui ne marche pas encore mais est à la pointe de ce qu'on peut faire en IA : http://www-caes.mit.edu/mvp/html/cog.html
  • [^] # Re: Java + Make = Ant

    Posté par  . En réponse à la dépêche Introduction à Make. Évalué à 9.

    Je l'ai utilisé chez France Telecom il y a
    un an puis chez Axa il y a un peu moins de temps.

    La phrase "make n'a aucune espèce
    d'utilité pour compiler du java" est aussi idiote
    que de prétendre que "ant ne sert à rien" ou
    que tel ou tel outil ne doit pas être utilisé.

    Je pense que c'est à chacun de choisir et pour
    choisir il faut au moins connaître le "terrain".

    Il y a souvent cette tendance à vouloir toujours
    se tourner vers le "plus facile", tendance que
    je rencontre à tous les niveaux et qui forment
    des gens qui ne savent même pas au final faire
    un chercher/remplacer par un script.
  • [^] # Re: Java + Make = Ant

    Posté par  . En réponse à la dépêche Introduction à Make. Évalué à 3.

    Voici une fiche qui décrit un peu prés le
    potentiel de Ant.

    http://www.djefer.com/articles/fiches/FT_SYS_ANT_01.html(...)

    Personnellement, Ant est bien lorsque l'on a
    rien d'autre sous la main. Mais il n'est pas
    comparable avec Make pour la simple raison
    que Make comprend son propre langage indépendant
    et un interfaçage transparent avec le shell courant (et pas ces fichus tags).
    Pour Windows, l'idéal reste cygwin. De toute
    manière faire du code portable est souvent plus
    une question de programmation de shell qu'une
    question de Makefile.

    Concernant Ant, il est fait en Java, il est
    exacte qu'une compilation globale sera
    plus rapide, mais cela masque la réalité du
    développement. Je ne recompile 99% du temps
    qu'un sous-répertoire lorsque je viens de
    modifier un truc et là Make est vraiment
    l'idéal. Je me vois mal mettre sur tous les
    répertoires un fichier build.xml. D'autant
    plus que le démarrage Java est lui bien plus
    lent !.

    Make s'intègre parfaitement à Emacs, un petit
    C-c c et je compile la classe modifiée, les
    lignes d'erreurs me sont retournés et je
    peux bosser le plus naturellement.

    Pour moi, Ant est plus intéressant en étape
    final d'un projet lorsqu'on souhaite tout
    packager (.war ou .ear) mais il est loin
    d'être incontournable. Il faut s'amuser
    à développer une extension pour voir ce
    qu'il y a derrière.
  • [^] # Re: Erreur dans le second exemple de lisp

    Posté par  . En réponse à la dépêche Développement d'un mode mineur avec Emacs. Évalué à 3.

    Exact j'ai de ce pas corrigé ma billevesé
  • [^] # Re: conception, vous avez dit conception ?

    Posté par  . En réponse à la dépêche Comprendre les Design Patterns. Évalué à 0.

    Tout d'abord comme tu le fais remarqué, il ne s'agit
    pas de rétablir toute l'étendu du paradigme objet
    en 10 lignes. Cet article s'adresse avant tout à
    des gens qui ne connaissent pas l'objet, me faire
    le reproche de ne pas être à la hauteur de gamma
    est ridicule, aucun débutant ne commencera par
    gamma, c'est comme de commençer le piano avec
    les préludes de Bach, irréaliste et sans intérêt.

    - Concernant la première remarque :
    Enlève le terme "se réduit" s.t.p. sinon la
    connotation est négative

    - 2° remarque : Le comportement n'est
    pas le résultat d'une exécution de la description
    d'une classe ? J'aimerai bien voir un objet
    qui ne serait pas "décrit" par une classe.

    - 3° remarque : Hors sujet aussi

    - 4° remarque : D'accord avec toi,
    cela porte à confusion

    - 5° remarque : Commune était à prendre
    au sens de "dans tous les languages Objets"

    - 6° remarque : "est une sorte de"
    appartient à un niveau sémantique, il ne s'agit
    pas d'une obligation. Par exemple regarde le
    dernier exemple et le DP "Template", cette
    relation n'existe pas

    - 7° remarque : C'est vrai que cela peut porter
    à confusion lorsque l'on connaît l'objet

    - 8° remarque : Théoriquement tu as raison, mais
    je me réfère avant tout à la pratique et à la
    pratique seulement. L'objet comme les réseaux
    de neurone n'ont pas grand chose à voir avec la
    réalité sinon comment classes-tu
    l'ornithorynque ? :)

    - 9° remarque : Tu as parfaitement raison, mais
    voir la remarque 3°

    - 10° remarque : Le contraire ne donnes pas
    une vision trés subtil du polymorphisme, mais
    il est vrai que les interfaces peuvent avoir des
    associations entre elles par héritage.

    - 11° remarque : Pourquoi pas, mais chacun
    sa manière.

    - 12° remarque : Mais tu t'attends à quoi ?
    J'ai pourtant bien écrit "Introduction", tu
    reconnais toi même qu'il s'agit d'une
    vulgarisation qui n'est pas à ton goût. Quant
    tu achètes un bouquin sur l'objet/UML tu ne
    prends pas les bouquins pour débutant et tu
    ne dénigres par les auteurs associés puisque
    ces mêmes auteurs t'ont permis de progresser ??

    Bonne continuation
  • [^] # Re: Hum... [première partie]

    Posté par  . En réponse à la dépêche Comprendre les Design Patterns. Évalué à -1.

    La remarque de Bobert va dans mon sens, mais pour
    bien éclairer le sens de ma phrase, un protocole
    HTTP est normalisé, l'usage en fait un standard.
    Les DP ne peuvent entrer dans cette catégorie.
    Quant aux factory c'est vrai que je n'ai pas trés
    appronfondi mais il suffit de regarder
    l'introduction aux modèles de création une ligne
    au-dessus pour avoir l'explication. RTFM
  • [^] # Re: Hum... [seconde partie]

    Posté par  . En réponse à la dépêche Comprendre les Design Patterns. Évalué à -1.

    Lorsque tu écris qu'une fabrique est une
    interface, cela n'à pour moi aucun sens puisqu'une
    interface désigne une abstraction afin
    d'interchanger l'implémentation sans rompre
    le cohérence de l'ensemble. L'interface couvre
    donc n'importe quel code Java y compris les
    fabriques si cela est utile.

    Un fabrique n'a selon toi aucun sens en dehors
    de l'interface mais puisque l'implémentation n'est
    pas délimitée comment pourrais - tu donné un
    sens à la fabrique ? La classe est ici à des
    fins pratiques, je ne veux pas embrouiller tout
    le monde au risque de choquer les
    pusillanimes de la programmation.
  • [^] # Re: Hum... [première partie]

    Posté par  . En réponse à la dépêche Comprendre les Design Patterns. Évalué à -1.

    Je pense que le terme Erreur Grave doit être
    remis dans un contexte saint.

    C'est une introduction donc je n'aborde pas
    tous les sujets.

    Concernant les interfaces et les classes abstraites,
    elles appartiennent à la même famille décrivant
    des squelettes de classes plus ou moins
    complet. La distinction n'est pas clairement faite
    ici car l'article tente (et je dis bien tente)
    d'être généraliste, or le concept d'interface
    se traduit par une classe abstraite en C++.

    D'autre part, l'héritage entre interface existe
    même avec une classe (hé oui, cela n'a
    à priori aucun sens), donc je te laisse conclure:

    // Ce code était présent dans l'outil WebObject
    public interface Toto extends java.lang.Object {
    }

    Donc l'interface Java est traitée comme une
    classe abstraite particulière. Je reconnais que
    extends et remplaçé par implements à l'usage mais
    c'est pour forcer l'usage de l'interface pas
    pour renforçé la différence de l'interface
    et de la classe abstraite.

    Concernant l'héritage de classe et l'héritage
    d'interface. Il faudrait peut être que tu
    lises l'article en entier et notamment la ligne
    suivante sur l'implémentation.

    Un standard est avant tout défini par un
    organisme indépendant, gamma et compagnie
    ne forme en aucun cas un organisme de contrôle
    et d'évolution des design patterns.

    Par exemple :

    Je viens de me définir une nouvelle norme pour
    les fabriques.

    public class ObjectBuilder {
    public ObjectBuilder( ClassLoader loader )...
    public Point getPoint( int x, int y )...
    public void setDelegate( ObjectBuilder ob )...
    }


    Encore une avec une hierarchie

    public class ObjectCreator {
    public Object getObjectForName( String name );
    public ObjectCreator getParent();
    }

    Encore une

    public class NewObject {
    public Instance getNewObject();
    }

    public interface Instance {
    public Object getObject();
    }

    Bref on peut faire tout et n'importe quoi autour
    des designs patterns alors pour moi il n'y a
    ni norme ni standard.

    Concernant ta dernière remarque toujours aussi
    grave, commence déjà par lire sérieusement
    l'article avant d'écrire au hasard.
  • [^] # Re: Une lecture intéressante

    Posté par  . En réponse à la dépêche Comprendre les Design Patterns. Évalué à -1.

    Tous les exemples de gamma, helm, johnson et
    vlissides sont en C++ (et un tout petit peu
    de smalltalk histoire de).

    Donc :

    Erm. À vrai dire, les monsieurs qui ont écrits le bouquin sont des développeurs C++, et tous les exemples sont en C++.
  • # Complément à l'introduction

    Posté par  . En réponse à la dépêche Comprendre les Design Patterns. Évalué à 1.

    Tous les design patterns du livre de gamma sont résumés ici :

    http://www.djefer.com/articles/design/index.htm(...)


    Bonne lecture