Archives par mot-clé : Optimisation

For-each ou for Iterator ?

Publié dans Java | Laisser un commentaire

En Java (comme dans plusieurs langages), il existe plusieurs manières de parcourir une liste d’éléments. Mais entre une boucle for classique, une boucle Iterator et un for-each, il existe quelques différences qu’il est de bon ton de connaître.

ilustration d'une boucle for

Continuer la lecture

Enable hardware keyboard on Android emulator

Publié dans Java | Laisser un commentaire

I thought it was possible in previous version, but it appears that now it is not possible to use the physical hardware keyboard of a computer in an Android emulator… Hopefully, this is just a small configuration to edit!

  • Open the AVD Manager: in Eclipse > AVD Manager
  • Select the particular AVD, or create a new one, and click on Edit
  • Go to the « Hardware » section, click on « New ».
  • Select the Property: « Keyboard Support », and change its value to « yes » (it is « no » by default)
  • That’s it! You can start your emulator and use your physical keyboard.

AVD Manager

More information

Activer le clavier physique sur un émulateur Android

Publié dans Java | Laisser un commentaire

Il me semble que dans les versions précédentes cela fonctionnait, mais toujours est-il qu’avec les derniers émulateurs Android, il n’est plus possible d’utiliser le clavier physique de mon ordinateur pour taper un texte sur l’émulateur !
Heureusement, ce n’est qu’une petite configuration à modifier 🙂

  • Dans Eclipse, aller dans l’AVD Manager
  • Sélectionner un AVD existant ou en créer un nouveau
  • Aller dans la section « Hardware » et cliquer sur « New »
  • Sélectionner la propriété « Keyboard Support » et changer sa valeur à « yes » (elle est à « no » par défaut)
  • L’émulateur est prêt à être redémarrer !

Continuer la lecture

Problèmes de mémoire ?

Java, memory leak et les erreurs de PermGen space

Publié dans Java | Laisser un commentaire

Trois articles (du même auteur) très intéressants sur les fuites mémoires en Java. A lire absolument, à tête reposée !

StringBuilder vs StringBuffer vs String.concat – done right | kaioa.com

Publié dans Java | Laisser un commentaire

D’après cet article StringBuilder vs StringBuffer vs String.concat – done right | kaioa.com (en anglais), il est plus avantageux en terme de performance d’utiliser StringBuilder à partir de Java 1.5 (ou StringBuffer pour les versions antérieures) que de concaténer des chaînes de caractères à coups de concat. Les chiffres sont assez parlant !

Each time you append something via ‘+’ (String.concat()) a new String is created, the old stuff is copied, the new stuff is appended, and the old String is thrown away. The bigger the String gets the longer it takes – there is more to copy and more garbage is produced.

Ce que l’on pourrait traduire par :

A chaque fois que l’on concatène à l’aide de String.concat(), une nouvelle instance de String est créée, l’ancienne étant copiée, accolée à la nouvelle, puis jetée. Plus longue est la chaîne de caractères et plus longtemps cela prendra. Donc plus on concatène, plus on créé du déchet.

De plus, le compilateur Java va transformer tout seul les concaténations manuelles avec des « + » ou des « line breaks » en utilisant des StringBuillder::append. Donc on peut utiliser sans problèmes cette écriture ! C’est de loin la plus lisible pour de petites chaînes de caractères. Quant aux autres : StringBuilder à la rescousse !

Voilà qui est bon à savoir 🙂

Pour aller un peu plus loin avec StringBuiler

Une approche façon Creative Commons pour expliquer sa politique de confidentialité

Publié dans Geekeries | Laisser un commentaire

Ce billet papote autour d’une manière de faciliter l’explication des politiques de protection de données personnelles inspirée de « Creative Commons ». C’est un mouvement qui est en train de se former, qui est sujet à recherche et qui tend à s’appeler « Privacy Commons » (ô originalité !) !

Quelques mots sur Creative Commons

Creative Commons est une association à but lucratif permettant de protéger des créations par une licence. Ces licences sont particulières car elles permettent de protéger ses œuvres tout en permettant leur rediffusion sous certaines conditions. Une licence se décompose en trois couches :

  • Les termes légaux
  • Des icônes, traduisant de manière rapidement compréhensibles par un lecteur humain les termes légaux
  • Des moyens pour une machine de comprendre les termes légaux

Je suis sûr que vous avez déjà vu les icônes ci-dessous ! Sur le Site du Zéro ou Flickr par exemple. Ce sont des icônes Creative Commons.Creative Commons a ainsi réussi à rendre la loi sur les copyrights très facilement compréhensibles pour tous les utilisateurs.

Continuer la lecture

Comment sécuriser les mots de passe de mes utilisateurs ? Le Hashage !

Publié dans Geekeries | 5 commentaires

Aujourd’hui j’ai eu un cours qui m’a permis de comprendre ce que je n’avais jamais compris. Lorsque j’ai appris le PHP, on m’a dit : « il faut chiffrer les mots de passe de tes utilisateurs quand tu les enregistres dans une base de données ! ». Moi, docile, j’ai obéis ! (quoi, on me glisse dans l’oreillette que cela n’a rien à voir avec le chiffrement mais plutôt avec le hachtakage hashage ? Oui bon, on y vient !)
Cela paraît logique :

  • lors de son inscription, l’utilisateur me fournit un mot de passe en clair (appelons-le Mclair),
  • je le chiffre (il devient Mchiffré) et l’enregistre dans ma base de données,
  • lorsque cet utilisateur veut se connecter, il me fournit un mot de passe en clair (appelons-le Tclair), je le chiffre (appelons-le Tchiffré) et teste s’il correspond au mot de passe chiffré de ma base de données (Tchiffré == Mchiffré ?)

Avec ce système, si quelqu’un accède à ma base de données, il ne lui servira à rien de lire les mots de passe de mes utilisateurs puisqu’ils sont sécurisés, il ne pourra donc pas se faire passer pour un de mes utilisateurs. C’est déjà suffisamment embêtant que quelqu’un ait réussi à s’introduire dans ma base de données !

Ce que je n’avais bien capté, c’est ce qui signifie chiffré un message et pourquoi on m’avait encouragé à utilisé la fonction de chiffrage « Md5 » alors que je lisais par ailleurs qu’il valait mieux utiliser « Sha-1 ». Aujourd’hui, je suis un homme nouveau qui voit le monde autrement et qui se couchera accessoirement légèrement moins bête ce soir.
Continuer la lecture

Booster ses CSS

Publié dans HTML et CSS | 2 commentaires

Depuis que je suis sur Twitter (vous pouvez me suivre), j’ai l’occasion de lire plus d’articles sur le Web qu’auparavant et notamment quelques uns sur les CSS. Je vous livre donc mes découvertes et réflexions du moment.

CSS sur une ligne

Single line CSS en anglais. C’est le concept qu’il est mieux d’écrire ses CSS sur une seule ligne plutôt qu’en bloc. Par exemple en bloc :

ul li {
list-style:none;
border:1px solid black;
font-weight:bold;
}
dl dt {
width:800px;
}

donnerait sur une ligne

ul li{list-style:none;border:1px solid black;font-weight:bold;}
dl dt{width:800px;}

Le grand avantage c’est que ça réduit le poids du fichier CSS (assez significativement d’ailleurs, même si ça n’a pas grande influence sur le poids total d’une page Web), et ça évite de scroller des heures pour arriver à la fin du fichier. L’énorme inconvénient c’est que c’est moins lisible. C’est vrai, mais j’ai testé et en fait pas tant que ça. Pour ma part je pense que je vais adopter une sorte de mix : CSS sur une ligne, et CSS en bloc pour les lignes trop longue. Sans oublier de commenter les différentes parties du code, on n’est pas à 10 lignes près quand même !

Quelques exemples

Éviter les espaces superflues

Dans le même genre, histoire de grappiller quelques octets, c’est vrai que ça ne sert à rien de rajouter des espaces entre une propriété et sa valeur, une balise et l’accolade qui la suit. Bref, je suis pour d’enlever les espaces superflues ! Mais quand même, un espace entre chaque propriété quand on écrit en ligne : c’est cool pour les yeux !

Enlever les les sélecteurs

CSS superflues D’après PageSpeed (un outils de Google pas mal du tout pour tester la rapidité de ses pages Web), il serait avantageux de réduire au maximum la liste des sélecteurs CSS. Prenons l’exemple suivant :

#menu ul li{font-weight:bold;}

Préciser l’élément ul est en général superflue puisque pour un cas classique, il n’y aurait pas de li en dehors d’un ul dans #menu. Il vaudrait donc mieux écrire :

#menu li{font-weight:bold;}

Et je dis : ouais, ça se tient ! ça réduit la taille du fichier CSS, améliore la lecture du fichier, et il y a des chances que cela facilite le travail de l’interpréteur de CSS. Attention tout de même à ne pas tailler à l’arrache dans le CSS, certains sélecteurs sont utiles !
C’est tout pour aujourd’hui !

Mise à jour 2 ans plus tard : de nos jours, on cherche toujours plus à grappille des octets ! Par contre, on évite absolument de faire ce que je propose ! On écrit son code CSS aussi humainement que possible, puis on génère à partir de ce code, un feuille de style minifiée à laquelle tous les espaces inutiles, ainsi que les commentaires, auront été retirés. Certains vont même jusqu’à utiliser un langage plus haut niveau que CSS (acceptant des variables par exemple), puis le faire passer à la moulinette d’un pré-processeur (SASS, LESS, … chacun ayant son mini-langage) qui génère une feuille de style minifiée et optimisée pour le traitement par le navigateur.

Optimiser ses requêtes MySQL

Publié dans SQL | 4 commentaires

Je travaille actuellement sur une table MySQL qui va contenir près de 7 millions de tuples (avec une quinzaine de colonnes chacun bien sûr, ce ne serait pas drôle sinon !), il se trouve qu’elle en contient déjà près de 3 millions, et que je suis obligé de faire une vingtaine de requêtes différentes dans cette table pour chaque page et que, par conséquent, le site qui l’utilise plante à fond. La mémoire utilisable par MySQL est dépassée. Alors certes, on peut modifier la taille de la mémoire utilisable par MySQL (et il faudrait aussi sûrement modifier la durée maximum d’exécution d’un script PHP), mais le but c’est quand même de charger des pages en moins de 30 secondes. J’ai donc cherché des réponses sur le Web et auprès des développeurs de ma boîte. Voici donc quelques points que j’ai pu retenir.

Structure de la table

Il vaut mieux éviter, sauf si c’est nécessaire, l’utilisation de champ NULL par défaut. En effet, comme on peut le voir sur cet article d’Apprendre PHP NULL est une valeur spéciale qui nécessite un traitement spécial, MySQL ne peut pas le tester avec un égal et ne peut le comparer à la chaine vide ou à 0, il est obligé d’utiliser IS ou le symbole équivalent < =>. NULL par défaut est d’autant plus à bannir pour les index. Utiliser des colonnes avec le meilleur type et la meilleure taille possible. Un prénom n’a par exemple par besoin d’être en VARCHAR(255), un VARCHAR(20) suffit plus que largement. Une bonne technique pour optimiser ses tables est d’utiliser PROCEDURE ANALYSE(). On créé ses tables au feeling (je parle juste de la structure, vous ne couperez pas à la normalisation tout ça, héhé), on les remplie avec un contenu à peu près définitif est on utilise une requête du style :

SELECT id, titre, message FROM blog PROCEDURE ANALYSE()

MySQL va nous répondre un joli petit array avec la taille max et min de chaque colonne id, titre et message, quelques autres informations intéressantes et surtout une proposition de type(taille) optimisée à votre table. Encore une fois, c’est l’article d’Apprendre PHP qui en montre un exemple vraiment parlant.
Continuer la lecture