Reprise du message précédent :

Il avait des idées de merde aussi hein.
Apple vend clairement plus d'iPhones depuis qu'il est plus là pour décider de la taille de leurs écrans.

Vu les résultats de test canard-pc sur les alims chinoises pour téléphone, il peut être utile d'éviter les trucs les moins cher. Certe le matos Apple est trop cher, mais le chinois avec un courant dégeulasse, du plastique qui flambe bien et 0 protection c'est con. Surtout pour brancher sur un appareil à plus de $600.

https://www.reddit.com/r/Bad_Cop_No_Donut/  

À Montpellier toute la chaîne exécutive du maire au président de la république était à gauche.

 
ouais, enfin les scores dans les départements cités sont sans appel, hein.
 
21.32% à Montpellier, certes, mais :
 
Hérault : 35.9% contre 16.83 aux socialistes.
Aude : 37.07 contre 25.98
PO : 41.07 contre 19.°8
Gard : 40.64 contre 17.64
 
Ailleurs le FN fait dans les 25%.
 
Contre 17.24% à Toulouse.
 

au lieu de faire malin à faire des stats avec des nombres, tu ferais mieux de réviser ton pas de l'oie toi ...

 
Dans mon coin le FN est troisième à moins de 20%. Je vais donc lancer un mouvement de séparatimsmse.

séparatisme, c'est le mot codé pour terrorisme ?

 
Ça dépend si t'es soutenu ou pas par BHL

il est catho, ce ne sera pas du terrorisme
Au pire un mouvement sectaire, au mieux l'oeuvre d'un déséquilibré

Non mais /r/amibeingdetained, ce sont les types qui conduisent sans permis et déclarent qu'ils se déplacent donc ils peuvent.

C'est bien mais pas aussi bien

Un collègue vient de me partager ça :
 

/**
     * Cette méthode permet de construire un string reprenant tous les éléments de la liste passée en paramétres en appelant la méthode spécifiée pour récupérer
     * la representation "string" de l'objet en question.
     */
    public static String lineariseList(List list, String separator, String method) {
        StringBuilder stringBuilder = new StringBuilder();
        if (list != null) {
            for (Object obj : list) {
                if (!stringBuilder.toString().equals("" )) {
                    stringBuilder.append(separator);
                }
 
                try {
                    Method toString = obj.getClass().getMethod(method, (Class[]) null);
                    String representation = (String) toString.invoke(obj, (Object[]) null);
                    stringBuilder.append(representation);
                } catch (SecurityException e) {
                    logger.error(e.getMessage(), e);
                } catch (NoSuchMethodException e) {
                    logger.error(e.getMessage(), e);
                } catch (IllegalArgumentException e) {
                    logger.error(e.getMessage(), e);
                } catch (IllegalAccessException e) {
                    logger.error(e.getMessage(), e);
                } catch (InvocationTargetException e) {
                    logger.error(e.getMessage(), e);
                }
            }
        }
        return stringBuilder.toString();
    }

 
Autant de WTF dans si peu de lignes,; c'est presque beau

mais c'est un stagiaire non encadré qui a sorti ça ?

 
Aucune idée, c'est un projet qu'il analyse pour voir comment on pourrait le remettre sur les rails.
 
Il m'a montré les graphes de dépendances, c'sst assez funky.
 
Il est obligé de "deviner" un peu : en fait chaque war porte ses libs (mais pas avec un maven like ou autre, elles sont "versionnées" dans l'un des 240 repos Git du bloubi-boulga), mais les libs partagées sont dans le répertoire lib du serveur.
 
Donc t'as des risques de pas avoir la même lib au build et à l'exécution Donc ça marche pas super.
 
Mais déjà dans le concept : il y a un portail WPS, et des applis JavaWS dans les portlets.. Lesquelles applis ouvrent des connexions vers la DB
 
 
 
Là, je lui ai demandé de voir combien de fois cette méthode était appelée avec autre chose que "toString" en dernier paramètre. Ca va être le fnu.

Bordel de merde

 
J'ai l'impression que c'est le genre de projet où tu peux avoir un impact violent super vite.

/**
     * Cette méthode permet de construire un string reprenant tous les éléments de la liste passée en paramétres en appelant la méthode spécifiée pour récupérer
     * la representation "string" de l'objet en question.
     */
    public static String lineariseList(List list, String separator, String method) {
        StringBuilder stringBuilder = new StringBuilder();
        if (list != null) {
            for (Object obj : list) {
                if (!stringBuilder.toString().equals("" )) {
                    stringBuilder.append(separator);
                }
 
                try {
                    Method toString = obj.getClass().getMethod(method, (Class[]) null);
                    String representation = (String) toString.invoke(obj, (Object[]) null);
                    stringBuilder.append(representation);
                } catch (SecurityException e) {
                    logger.error(e.getMessage(), e);
                } catch (NoSuchMethodException e) {
                    logger.error(e.getMessage(), e);
                } catch (IllegalArgumentException e) {
                    logger.error(e.getMessage(), e);
                } catch (IllegalAccessException e) {
                    logger.error(e.getMessage(), e);
                } catch (InvocationTargetException e) {
                    logger.error(e.getMessage(), e);
                }
            }
        }
        return stringBuilder.toString();
    }

Chais pas, à part le check du stringbuilder vide c'est plus l'idée de base qui est problématique, si on considère qu'elle est valable (parce qu'on vient d'un langage avec des HoF toussa) et qu'on est en Java < 8 l'implémentation semble pas illogique, c'est pas comme si les generics de java pouvaient te sauver le cul et demander une Method en entrée ca rend l'appel tout merdique.

Ouais mais non ça c'est la sécurité de l'emploi, on te dit que c'est lent, tu special-case "toString" pour faire directement un sb.append(obj) et paf tu sauves la boite (et ça te laisse encore la réification du sb à chaque tour de boucle pour la prochaine fois)

 
Clairement. Enfin, vu l'ampleur du merdier, il faut quand même faire un peu attention parce que les effets de bords peuvent être difficiles à maîtriser, et que malgré tout "ça marche"
 
Mais sur mon projet principal qui est un peu du même tonneau, je suis passé de 55 k lignes à 38 k lignes, et ça marche mieux qu'avant (et on doit pouvoir sans problème enlever encore du gras, mais bon, y'a 15 k lignes qui sont des JSP et du mapping qu'on va dégager quand on refera l'IHM, donc voilà)
 
 
La vraie question, c'est comment des clients se font refourguer de la merde pareille, alors qu'ils sont sensés avoir des exigences de qualité dans le contrat.
 
La réponse, c'est en partie que les mecs chargés de contrôler la qualité sont des neuneus équipés d'outils de merde qu'ils ne font pas passer assez souvent (genre sur mon appli, c'est du CAST une fois par an au max, avec le set de règles génériques pour le JEE appliqué partout, mêem aux batchs), que en plus, ils ne font jamais faire de revue de code ou d'architecture.  
 
Il serait assez intéressant de chiffrer le coût de cette non qualité, mais bon.

 
bah déjà la recherche de al méthode à chaque tour de boucle, c'est sympa aussi.
Le catch de Exception ou autre super-classe à la place de tout le merdier aussi, sans parler de StringUtils.join(..) par exemple, mais bon

Les objets de la liste sont censés être du même type?
Je comprends pas du tout l'utilité du truc mais je vois pas comment implémenter ça proprement (à part dans un lisp...)

Y'a des tonnes de moyens de faire mieux que ça, le plus propre sans Java 8 étant d'appeler toString(). Si jamais tu peux pas, parce que toString() a une autre sémantique que la tienne, y'a ça :  
 

public interface Representable {
    String representation();
}

 
Et ta méthode devient (sans utiliser de dépendance)
 

public static String representation(List<Representable> elements, String separator) {
    if (elements == null) {
        return "";
    }
 
    StringBuilder representations = new StringBuilder();
    for (Representable element : elements) {
        if (representations.length() > 0) {
            representations.append(separator);
        }
        representations.append(element.representation());    
    }
 
    return representations.toString();
}

 
D'habitude je préfère éliminer les nulls et null checks à la con, avec du @Nonnull et des Preconditions.checkArgument(elements != null) (Google Preconditions). Et j'aurais fait un StringUtils.join() de liste.
 
Et fait ça en Java 8 :  
 

public static String representation(List<Representable> elements, String separator) {
    checkArgument(elements != null)
 
    return representations.stream()
        .map(Representable::representation)
        .collect(Collectors.joining(separator);
}

https://www.linkedin.com/pulse/mong [...] hn-de-goes trop fort chez mongo
 
j'ai une idée pour le connecteur BI, y a ka tout pousser dans un postgres et ça roule

Ah et sinon gfive, récupérer l'objet Method doit être fait dans la boucle parce que la liste peut contenir des objets hétérogènes.

Mais en utilisant son equals pourri au lieu de length() > 0, il instancie une String à chaque itération, pour rien
Alors qu'on utilise des StringBuilders pour éviter ça, justement

 
Effectivement, je me suis tellement habitué aux Generics que j'ai oublié qu'il pouvait construire une liste hétérogène.
 
Mais bon, en pratique, c'est complètement con dans la mesure où on utilisera ça que avec toString au final, j'en suis quasi certain.
 
Sans parler du fait qu'il y a 99% de chances que ça ne soit utilisé que pour du log.
 
bref.

 
Y'a aussi mieux que length > 0 , je trouve :
 

public static <T> String lineariseList(List<T> list, String separator, String method) {
        if (list == null || list.isEmpty) {
           return "";
        }
        Iterator<T> it = list.iterator();
        StringBuilder stringBuilder = new StringBuilder(toString(it.next(), method));
        while (it.hasNext()) {
             stringBuilder.append(separator).append(toString(it.next(), method));
        }
        return stringBuilder.toString();
}

 
Avec l'invocation de sa méthode dans le toString(...)  
 

Avec un design raisonnable c'est évident
 
Mais là il peut passer un truc complètement arbitraire comme nom de méthode.
C'est en effet débile mais si tu veux faire ça proprement en Java je vois pas...

je peux pas m'empêcher de relever

 
ouais, il peut aussi, mais c'est rare d'en avoir besoin en réalité (des objets qui n'ont rien en commun, quoi)
 
Et au final, dans sa méthode pourrie, si un objet n'a pas la méthode demandée, il ne se passe rien. C'est peut être voulu, mais c'est pas sûr.

T'as pas de garantie que c'est la même classe partout

Sauf que là tu bouffes aussi une erreur dans le stringifier non?

C'est du Apache Commons, pas du JDK standard, j'ai bien précisé (puis de toute manière ça aide pas si t'as décidé d'un stringifier custom)

public interface Representable {
    String representation();
}

public static String representation(List<Representable> elements, String separator) {
    if (elements == null) {
        return "";
    }
 
    StringBuilder representations = new StringBuilder();
    for (Representable element : elements) {
        if (representations.length() > 0) {
            representations.append(separator);
        }
        representations.append(element.representation());    
    }
 
    return representations.toString();
}

Ça marche que si tu contrôles le type d'origine ça

public static String representation(List<Representable> elements, String separator) {
    checkArgument(elements != null)
 
    return representations.stream()
        .map(Representable::representation)
        .collect(Collectors.joining(separator);
}

Oui clairement en java 8[0] t'as pas vraiment besoin de tout ce bordel, et à ce compte là t'inline la méthode et tu te fais pas chier

[0] ou avec la plupart des langages qui sont pas java[1]
[1] ou Go

public static <T> String lineariseList(List<T> list, String separator, String method) {
        if (list == null || list.isEmpty) {
           return "";
        }
        Iterator<T> it = list.iterator();
        StringBuilder stringBuilder = new StringBuilder(toString(it.next(), method));
        while (it.hasNext()) {
             stringBuilder.append(separator).append(toString(it.next(), method));
        }
        return stringBuilder.toString();
}

Si tu pars d'une List<T> (ou mieux un Iterable<T> ) t'as aussi l'option d'un interface Stringifier<T> { String stringify(T t); }, et tu peux avoir une implémentation sur Object qui appelle toString.

 
oui, mais là il s'agissait surtout d'implémenter le "je met pas le séparateur pour le premier élément" d'une manière plus élégante (à mon avis) que le test sur la longueur de la chaîne ou le boolean first qu'on trouve partout.

Par curiosité j'ai regardé l'implémentation de StringUtils.join(Iterator<?>, String) qui est utilisée pour StringUtils.join(Iterable<?>, String) :

public static String join(final Iterator<?> iterator, final String separator) {
 
        // handle null, zero and one elements before building a buffer
        if (iterator == null) {
            return null;
        }
        if (!iterator.hasNext()) {
            return EMPTY;
        }
        final Object first = iterator.next();
        if (!iterator.hasNext()) {
            @SuppressWarnings( "deprecation" ) // ObjectUtils.toString(Object) has been deprecated in 3.2
            final String result = ObjectUtils.toString(first);
            return result;
        }
 
        // two or more elements
        final StringBuilder buf = new StringBuilder(256); // Java default is 16, probably too small
        if (first != null) {
            buf.append(first);
        }
 
        while (iterator.hasNext()) {
            if (separator != null) {
                buf.append(separator);
            }
            final Object obj = iterator.next();
            if (obj != null) {
                buf.append(obj);
            }
        }
        return buf.toString();
    }

Eux zappent carrément le StringBuffer quand il n'y a qu'un élément, ce qui est nettement plus malin, amha
(bon le nullcheck du début m'a fait vomir par contre)

Putain que je trouve ça ridicule chaque fois que je lis ce genre de trucs sur un profil.
Je suis un vieux con .

 
l'informatique est en pleine fraichitude par moment .....

 
Tu dis ça parce que t'es plus disruptivateur de paradigmes.

 
Ca veut dire qu'il chie sur le changement ?  

il épand de la merde, ça veut pas dire que c'est la sienne ...

Sacré Jean Philippe

Plam, réducteur d'entropie et conceoteurs d'empreintes digitales. (j'aime bien réutiliser digital au sens propre )

http://www.bloomberg.com/news/arti [...] cate-owner
putain ! mes 747 ! je savais bien que j'oubliais un truc !