Le Sénat discute d'une loi visant à limiter la liberté des semences – Reporterre – Le Hollandais Volant

Monsanto (ou Limagrain, peut-être) a encore frappé payé.

via Le Sénat discute d’une loi visant à limiter la liberté des semences – Reporterre – Le Hollandais Volant.
Et bah c’est bien. Encore quelques années et on devra payer pour vivre 🙂 Non mais je veux dire spécifiquement une taxe sur les naissances et sur les jours passés sur terre, en plus de ce qu’on paye déjà. Pourquoi pas payer l’air qu’on respire non ?

UFC-Que Choisir : les opérateurs dégradent la 3G pour vendre la 4G – Liens en vrac de sebsauvage

Dégradation volontaire… ou simple augmentation du nombre d’utilisateurs (réduisant mathématiquement le débit de chacun) ?
Free aussi a son débit 3G qui se dégrade, alors qu’il n’a actuellement aucune offre 4G.

via UFC-Que Choisir : les opérateurs dégradent la 3G pour vendre la 4G – Liens en vrac de sebsauvage.
Tiens tiens, les opérateurs choisiraient de dégrader la 3G pour vendre mieux leurs offres 4G (évidemment plus chères). Ca ne m’étonnerait pas du tout…

DoctorBeet's Blog: LG Smart TVs logging USB filenames and viewing info to LG servers – Liens en vrac de sebsauvage

Réfléchissez à deux fois avant d’adopter des technologies qui ont l’air cool. Arrêtez d’être con. (Quand je pense à ceux qui ont acheté 1500 dollars des Google Glass parce qu’ils trouvaient ça cool >< )

via DoctorBeet’s Blog: LG Smart TVs logging USB filenames and viewing info to LG servers – Liens en vrac de sebsauvage.
Je ne peux qu’adhérer largement aux propos de Seb sur ce point (et pas que ce que je cite).

Snippet #24 ~ PHP: Allégez vos classes avec des get/set automatiques | IdleBlog – Liens en vrac de sebsauvage => OUPAH

Astuce php pour éviter d’avoir à se palucher plein de getters/setters pour des classes de stockage.

via Snippet #24 ~ PHP: Allégez vos classes avec des get/set automatiques | IdleBlog – Liens en vrac de sebsauvage.
Ou alors revenir à la raison dans certains cas et ne pas appliquer les concepts de la POO façon recette de cuisine vaseuse sans prendre de recul. Par exemple pour des DTO ça ne sert strictement à rien selon moi de persister à utiliser des getters / setters. Mais alors à rien du tout ! Pire c’est contre productif à tous les niveaux.
Les DTO sont des objets destinés uniquement à stocker de la donnée. Aucune intelligence dedans. Pire, quand on fait du getter / setter dans un DTO on apporte même pas d’API et de stabilité dans les évolutions puisque les getters / setters sont nommés en fonction des données associées et donc le nom de ces méthodes est largement aussi peu stable que les attributs associés… Sans compter les cas ou les valeurs derrière ne sont même pas protégées puisqu’il y a des passages par référence des objets (cas pas assez souvent abordé en java selon moi).
Pire encore en terme de performance ! Utiliser du getter / setter à tarbasse dans certains cas (ici le DTO) est juste une immondice de performance. Ne pas oublier que quand vous concevez une méthode et l’utilisez l’interpréteur / la machine effectue un branchement / débranchement de l’exécution pour faire l’appel (sauf dans certains cas ou des optimisations sont possibles par le compilateur). Or c’est un processus qui prend du temps par rapport a une exécution séquentielle… Imaginez ça multiplié par le nombre de champs et d’enregistrements…
Et das certains cas (dans ce lien) on se retrouve a écrire des systèmes dégeu de génération dynamique des getters / setters, ce qui est largement aussi moche et prend du temps tout ça pour éviter une flemme d’écriture de code.
Bref, ne pas appliquer les recettes de cuisine brutos et prendre du recul est salvateur. Par exemple, dans le cas d’une DTO, arrêtez de continuer avec vos attributs privés et des getters / setters de merde. Passez simplement vos attributs en public ! Vous gagnez en temps d’exécution (accès mémoire only), vous gagnez en lisibilité et maintenance du code (attributs only) et vous ne perdez rien au passage…
Si vous ne me croyez pas je vous cite un bout de doc officielle de la javadoc (mais je pense que c’est applicable d’une manière générale).
http://www.oracle.com/technetwork/java/transferobject-139757.html

Typically, the members in the Transfer Object are defined as public, thus eliminating the need for get and set methods.

Bon après j’ai longtemps fait des getters / setters sur des DTO avant de penser ainsi.
Attention je parle bien de tout cela dans le cadre des objets de données purs, ne pas mélanger mes propos avec des classes définissant une API ou une intelligence métier.