Je pense en Java, Java is fun

The article is here : Optimising TortoiseSVN

The page is here : Hacking Knowledge: 77 Ways to Learn Faster, Deeper, and Better

<<One of the most important things in this “guess—compute consequences—compare with experiment” business is to know when you are right. It is possible to know when you are right way ahead of checking all the consequences. You can recognize truth by its beauty and simplicity. It is always easy when you have made a guess, and done two or three little calculations to make sure that it is not obviously wrong, to know that it is right. When you get it right, it is obvious that it is right—at least if you have any experience—because usually what happens is that more comes out than goes in. Your guess is, in fact, that something is very simple. If you cannot see immediately that it is wrong, and it is simpler than it was before, then it is right. The inexperienced, and crackpots, and people like that, make guesses that are simple, but you can immediately see that they are wrong, so that does not count. Others, the inexperienced students, make guesses that are very complicated, and it sort of looks as if it is all right, but I know it is not true because the truth always turns out to be simpler than you thought. What we need is imagination, but imagination in a terrible strait-jacket. We have to find a new view of the world that has to agree with everything that is known, but disagree in its predictions somewhere, otherwise it is not interesting. And in that disagreement it must agree with nature…>>
— Feynman, The Character of Physical Law, 1965, Chapter 7, “Seeking New Laws”.

C’est dit ! Si le code est joli, simple, claire, facile à comprendre, on peut penser qu’on a fait la chose correctement. Au contraire, si le code est compliqué, pas très claire, difficile à comprendre, on sait qu’il y a quelque chose qui ne va pas et il est nécessaire de prendre du recul pour améliorer le code.

L’article original se trouve ici: Open the windows explorer with a file selected in eclipse

Just une image pour se rappeler rapidement.

Une comparaison entre des systèmes de contrôle de version se trouve ici: Version Control System Comparison

C’est ici How I Explained REST to My Wife

Intéressant à lire !!! On peut maîtriser les choses, mais est-ce qu’on est capable de les expliquer de façon aussi simple et intuitive ?

C’est ici Managing the Java classpath (Windows)

C’est pas nouveau, mais ça vaut un lien pour rappeler des choses.

Idée de Reducing the memory consumption of your Java application (Part I)

Dans la partie commentaire, il y a une proposition d’utiliser la méthode ensureCapacity de StringBuffer, je veux préciser que la méthode ensureCapacity(int minimumCapacity) ne fait rien si la capacité actuelle de StringBuffer >= minimumCapacity. Donc le command suivant n’affecte pas StringBuffer

StringBuffer buffer = new StringBuffer(256);
buffer.append("bla");
buffer.append("bla");
–> buffer.ensureCapacity(buffer.length());
(Les tests sont faits sur JDK 1.4.2_08 et JDK 1.5.0_06)

Par contre, la méthode substring de StringBuffer crée toujours une nouvelle instance String, donc
- Si on ne veut pas que le programme crée un nouveau String, utilise
String s = buffer.toString();
- Si on veut que le programme crée un nouveau String, utilise
String s = buffer.substring(0);
(Les tests sont faits sur JDK 1.4.2_08)

Avec JDK 1.5.0_06, on a toujours un nouveau String quelque soit on utilise buffer.toString() ou buffer.substring(0)

Introduction: Cette partie est un résumé des “tips” dans le livre Effective Java – Programming Language Guide de Joshua Bloch que je trouve utiles pour mon travail de développeur. A préciser, même si le livre de Joshua Bloch est vraiment excellent et je le conseille pour tous les développeurs Java, je n’applique pratiquement pas tous les conseils listés ici dans toutes les situations. Il existe toujours des raisons (propre à chaque développeur et chaque situation) pour mettre en question l’application de façon mécanique un ou des conseils ci-dessous. J’invite tous les gens qui s’intéresse de participer à la discussion autour de ce livre et de partager leurs expériences

Creating and Destroying Objects

• Item 1: Consider providing static factory methods instead of constructors
• Item 2: Enforce the singleton property with a private constructor
• Item 3: Enforce noninstantiability with a private constructor
• Item 4: Avoid creating duplicate objects
• Item 5: Eliminate obsolete object references

Methods Common to All Objects

• Item 7: Obey the general contract when overriding equals
• Item 8: Always override hashCode when override equals
• Item 9: Always override toString
• Item 10: Override clone jusdiciously
• Item 11: Consider implementing Comparable

Classes and Interfaces

• Item 12: Minimize the accessibility of classes and members
• Item 13: Favor immutability
• Item 14: Favor composition over inheritance
• Item 15: Design and document for inheritance or else prohibit it
• Item 16: Prefer interfaces to abstract classes
• Item 17: Use interfaces only to define types
• Item 18: Favor static member classes over nonstatic

Methods

• Item 23: Check parameters for validity
• Item 24: Make defensive copies when needed
• Item 25: Design method signatures carefully
• Item 26: Use overloading judiciously
• Item 27: Return zero-length arrays, not nulls
• Item 28: Write doc comments for all exposed API elements

General Programming

• Item 29: Minimize the scope of local variables
• Item 30: Know and use the libraries
• Item 31: Avoid float and double if exact answers are required
• Item 32: Avoid strings when other types are more appropriate
• Item 33: Beware the performance of string concatenation
• Item 34: Refer to objects by their interfaces
• Item 35: Prefer interfaces to reflection
• Item 37: Optimize judiciously
• Item 38: Adhere to generally accepted naming conventions

Exceptions

• Item 39: Use exceptions only for exceptional conditions
• Item 40: Use checked exceptions for recoverable conditions and run-time exceptions for programming errors
• Item 41: Avoid unnecessary use of checked exceptions
• Item 42: Favor the use of standard exceptions
• Item 43: Throw exceptions appropriate to the abstraction
• Item 44: Document all exceptions thrown by each method
• Item 45: Include failure-capture information in detail messages
• Item 46: Strive for failure atomicity
• Item 47: Don’t ignore exceptions