Blog // Exirel.me

Ugly code

Dans Technique par Florian Strzelecki - 23:56 - 27.09.2011

Tags : Framework, Programmation, Bonne pratique, Chaton, Optimisation, Problème, loldev

Il est parfois difficile de dire d'un code qu'il est bon ou mauvais, qu'il est moche ou élégant. Parfois, les deux se confondent dans un doute profond sur la nature d'une idée, et sur son implémentation.

Beautiful is better than ugly.

Heureusement, parfois, il y a du code php/java/python/javascript/ruby/perl/autre bien sale et c'est très facile à repérer.

Notez l'effort pour ne pas troller toujours sur le même langage.

Lire la suite - 2 commentaires

Svn Id dans un template

Dans Technique par Florian Strzelecki - 11:11 - 19.08.2011

Tags : Web, Documentation, Programmation, Bonne pratique

Parfois j'y pense (et parfois j'oublie) : utiliser la propriété svn "svn:keywords" sur les fichiers, en utilisant tout particulièrement Id, et de temps en temps Author et Date (mais cela dépend du projet et des conventions de l'équipe).

Pour ceux qui ne connaissent pas, il s'agit d'une propriété que l'on peut mettre sur un fichier versionné avec svn (et pas un répertoire), de cette façon là :

svn propset svn:keywords "Id" fichier

Ensuite, dans le fichier, n'importe où (de préférence en entête du fichier, dans les commentaires), il suffit d'écrire ceci :

$Id$

Au commit du fichier, ceci sera remplacé par quelque chose comme :

$Id: Fichier 7814 2011-08-19 07:49:47Z Exirel $

En général, je pense à le mettre sur des fichiers de code, mais pratiquement jamais sur mes templates. Pourtant, c'est tout aussi pratique, surtout lorsque le template a plus d'importance que la façon de récupérer les données (ce qui est parfois une opération tout à fait triviale).

Du coup, au début de tous mes fichiers de template avec php, je mets ceci :

<?php /* @version $Id$ */ ?>

Avec smarty, je mets ceci :

{* @version $Id$ *}

Et avec django, je mets ceci :

{% comment %}
(...)
  - Version : $Id$
(...)
{% endcomment %}

Parfois, je me demande encore comment je peux oublier ça. Peut-être parce que je devrais l'automatiser, et plus le faire à la main ? Je dois être trop nostalgique de la ligne de commande...

Lien permanent - Commentez l'article

(bool) $flag

Dans Technique par Florian Strzelecki - 11:00 - 08.08.2011

Tags : Framework, Web, Programmation, Bonne pratique, PHP, loldev

Je suis toujours autant amusé par ce que je peux trouver dans le code-source du Zend Framework. Oh, rien de grave, cela fonctionne très bien de cette façon là :

public function setNoRender($flag = true)
{
    $this->_noRender = ($flag) ? true : false;
    return $this;
}

Il s'agit d'une méthode de la classe Zend_Controller_Action_Helper_ViewRenderer, qui effectue un traitement fort simple et basique, mais d'une façon que je trouve "inutile".

Je veux dire... si j'analyse ce bout de code d'un coup d'oeil, je peux voir qu'un cast implicite en booléen est effectué, pour ensuite... affecter cette même valeur (mais écrit "explicitement"). En gros, ce bout de code est strictement équivalent au suivant :

$this->_noRender = (bool) $flag;

Pourquoi faire plus compliqué ? Pourquoi s'embêter à écrire explicitement "true" et "false" ?

Oui, c'est du pinaillage. Mais j'aime bien pinailler sur ce genre de choses.

Lien permanent - 5 commentaires

Algorithme en if mineur

Dans Technique par Florian Strzelecki - 09:47 - 18.07.2011

Tags : Programmation, Bonne pratique, PHP, loldev

Un petit truc auquel je viens de penser, en regardant du code trouvé sur Internet dans l'une de mes recherches :

$ok = $database->query($sql);

if ($ok !== false) {
    $ok = $this->doSomething();
}
if ($ok) {
    $ok = $this->doItAgain();
}
return $ok;

Ce petit bout de code, nous allons (je vais) l'optimiser. Comment ? En réduisant les instructions inutiles, et en le rendant un brin plus "lisible" - en tout cas, moi, les if à la chaîne, ça me file des boutons.

if (false !== $database->query($sql)) {
    return $this->doSomething() && $this->doItAgain();
} else {
    // Ne faudrait-il pas lever une exception ?
    // Ou au moins traiter l'erreur ?
}
return false;

Le principe est simple : lorsqu'une expression booléenne est forcément fausse ou vrai, elle n'est pas évaluée jusqu'au bout. Dans notre cas, si $this->doSomething() retourne false, alors $this->doItAgain() ne sera jamais évalué.

Simple, efficace. J'aurais pu éviter le premier if d'ailleurs, mais je me dis que traiter l'erreur c'est un peu mieux que simplement retourner false et laisser le reste s'en charger.

Lien permanent - Commentez l'article

Moins de code, plus de fonctionnalité

Dans Technique par Florian Strzelecki - 19:17 - 10.06.2011

Tags : Framework, Programmation, Bonne pratique, Optimisation

En ce moment, je répète souvent à mes collègues (et à d'autres personnes) la maxime suivante :

Moins de code, plus de fonctionnalité.

C'est devenu mon leitmotiv en ces jours sombres où je dois travailler avec des gens qui n'ont pas encore acquis toutes les compétences nécessaires sur le projet. Et vu mon niveau d'exigence, autant dire que c'est vaguement difficile à gérer pour moi (mais je me soigne).

Pour paraphraser cette pensée, je dirais qu'il ne sert à rien d'écrire beaucoup de lignes de code pour apporter de nombreuses fonctionnalités.

L'important, notamment et surtout dans le cas d'utilisation de framework, c'est de proposer un code simple, facile à étendre, et qui s'intègre bien à son environnement. C'est ma façon à moi de rappeler les principes KISS et DRY : Keep It Simple & Stupid, Don't Repeat Yourself.

Je parle du cas où l'utilisation d'un framework est obligatoire (parce qu'il s'impose de lui-même ou parce qu'il a été arbitrairement imposé), car c'est exactement dans ces moments là qu'il faut rester vigilant.

Dans le cas d'un framework, écrire "moins de code" ne veut pas dire littéralement écrire moins de code, mais plutôt "intégrer parfaitement le moindre code dans le contexte du framework".

Si le framework impose d'écrire une classe, ou plusieurs, pour écrire un "plugin", alors il vaut mieux le faire, plutôt que d'écrire quelque part codé en dur dans le code, la modification voulue.

C'est peut-être paradoxal, mais cela fonctionne mieux. C'est peut-être frustrant, mais cela évite bien d'autres frustrations.

Croyez-moi, il vaut mieux que tout fonctionne toujours parfaitement avec le framework, que tout fonctionne maintenant comme vous le voulez contre le framework.

Parce que le framework lui, il a déjà écrit beaucoup, beaucoup, beaucoup de lignes de code.

Lien permanent - Commentez l'article

data.decode('UTF8')

Dans Technique par Florian Strzelecki - 16:00 - 19.05.2011

Tags : Python, Documentation, Programmation, Bonne pratique

Gérer du texte est parfois (souvent) un véritable casse-tête quand des problèmes d'encodage de caractères pointent le bout de leur nez. Alors, pour avoir perdu bien trop de temps, je m'écris un article "marque-page" pour me rappeler que, bordel, voilà comment récupérer les données d'un fichier en UTF-8, les traiter avec Markdown, puis écrire le tout dans un fichier.

import markdown

f = open('fichier.txt', 'r')
data = f.read()
f.close()

html = markdown.markdown(data.decode('UTF8'))

h = open('fichier.html', 'w')
h.write(html.encode('UTF8'))
h.close()

L'idée, c'est de "décoder" la chaîne qui est à l'origine en UTF-8 vers de l'Unicode, puis la traiter comme je le souhaite (ici avec Markdown), puis de l'encoder en UTF-8 pour l'écrire dans un fichier. Voilà.

Simple, efficace, mais il faut y faire scrupuleusement attention, sous peine de se prendre ce genre d'erreur :

UnicodeEncodeError: 'ascii' codec can't encode character

Lien permanent - Commentez l'article

Je développe donc j'écris des tests unitaires.

Dans Technique par Florian Strzelecki - 00:07 - 18.05.2011

Tags : J'aime, Programmation, Bonne pratique, Développement, Unit Testing

Suite à mon article sur PHPUnit, il m'a été posé la question, fort simple dans sa forme, de "Mais pourquoi faire des tests ?".

Après tout, cette question, je me la suis aussi posé avant de faire des tests, ainsi qu'à mon premier apprentissage, et encore aujourd'hui quand j'écris tel ou tel morceau de code, je me demande à quoi servent les tests que je vais écrire, ou que j'ai déjà écrit.

Je vais essayer de faire rapide, car expliquer "pourquoi faut-il faire des tests" n'est pas mon but premier : tout un tas de gens ont écrit tout un tas de choses sur le pourquoi comment, avec études théoriques et pratiques. Non, moi, je vais me contenter de vous exposer, de manière très subjective, pourquoi je fais des tests unitaires.

Lire la suite - Commentez l'article

À la découverte de PHPUnit

Dans Technique par Florian Strzelecki - 17:40 - 10.05.2011

Tags : Programmation, Bonne pratique, PHP, Unit Testing

Les tests unitaires, je connais depuis que je fais du python, et je sais qu'il est possible d'en faire avec php, mais je n'avais jamais vraiment essayer avec ce langage. Il faut dire que mes dernières expériences professionnelles n'étaient pas vraiment portées sur la qualité du code (ce qui est dommage, et particulièrement frustrant pour moi).

Mais ce matin, j'ai relevé ma motivation pour m'intéresser de plus près aux tests unitaires avec php. Je suis tombé sur PHPUnit, et j'ai donc passé la matinée à l'installer, l'utiliser, et à me poser des questions.

Cet article traite donc de mon exploration (très récente) de PHPUnit, de sa phase d'installation puis d'utilisation. Le contexte est un petit projet de carte en 2D gérée par Tile (2D-tile based system) avec un algorithme de shadowcasting recursif et tout un tas d'autres détails.

D'ailleurs, ce petit projet sera l'occasion d'un autre article après la publication d'une première version stable (probablement sur bitbucket) avec sa documentation. Oui, c'est du teasing, c'est mal, mais je parle d'abords des tests unitaires. Si je veux.

Lire la suite - 4 commentaires

Boucle et SQL (et ORM) : la petite erreur à éviter

Dans Technique par Florian Strzelecki - 16:51 - 11.04.2011

Tags : Programmation, Bonne pratique, PHP, Optimisation, ORM, SQL

Petite précaution avant d'entamer la lecture de cet article : il est technique, certes, mais ne concerne pas spécifiquement ni symfony ni doctrine. Le sujet de l'article est un problème technique très concret, qui se retrouve dans tous les langages, et avec n'importe quelle base de données.

En lisant le livre "Pratical symfony", plus spécifiquement le chapitre 6, je suis tombé sur un cas très classique : afficher une liste d'élément par catégorie, comme dans l'exemple qui suit.

  • Catégorie 1 :
    • Article du dd-mm-yy
    • Article du dd-mm-yy
    • Article du dd-mm-yy
  • Catégorie 2 :
    • Article du dd-mm-yy
    • Article du dd-mm-yy
    • Article du dd-mm-yy
    • Article du dd-mm-yy
  • Catégorie 3 :
    • Article du dd-mm-yy
    • Article du dd-mm-yy

L'approche ici - mais j'ai déjà vu ça ailleurs très souvent - est de récupérer la liste des catégories, puis, pour chaque catégorie, de récupérer la liste des offres de ladite catégorie.

Sauf qu'il y a un problème : voyez-vous lequel ?

Lire la suite - 4 commentaires

Navigateur web : syndrome de la vitesse au démarrage

Dans Geek par Florian Strzelecki - 23:19 - 03.09.2010

Tags : Web, Hypocrisie, Bonne pratique

C'est souvent à la vitesse au démarrage que l'argumentaire des utilisateurs s'arrête lorsqu'ils me parlent du choix de leur navigateur.

Cet argument, utilisé seul, m'agace au plus haut point. J'utilise Firefox depuis la version 1.0 - à l'époque, lorsque je l'ai annoncé dans la classe à l'IUT, personne ne connaissait, la honte - et j'en suis toujours satisfait.

Il existe bien d'autres critères, beaucoup plus pertinent que la vitesse, pour choisir son navigateur.

Lire la suite - 3 commentaires

Maitriser son environnement de travail

Dans Technique par Florian Strzelecki - 06:30 - 30.06.2010

Tags : Web, Bonne pratique, Ordinateur, Développement

Premier billet de mon thème "industrialisation de son travail de développeur (web)", le sujet en sera l'environnement de travail.

Par environnement de travail, j'entends votre matériel et vos logiciels : des écrans au système d'exploitation en passant par la machine Virtuelle et le traitement de texte.

C'est que, mine de rien, un informaticien passe la plus grosse partie de son temps sur son ordinateur : il vaut mieux pour lui qu'il sache bien l'exploiter.

Computer History Museum

Image : Computer History Museum - Laughing Squid (http://www.flickr.com/photos/laughingsquid/) - Creative Common by-nc

Lire la suite - Commentez l'article

Industrialisation du travail pour développeur web professionnel

Dans Technique par Florian Strzelecki - 22:33 - 29.06.2010

Tags : Web, Bonne pratique, Développement

J'ai évoqué récemment dans un billet l'industrialisation de son travail quotidien de développeur web. C'était un billet râleur façon coup de gueule contre la médiocrité que je rencontre au travail, et pas une réflexion spécialement poussée très loin.

Aujourd'hui, je vous propose, lecteur au profil technique, ou s'intéressant au monde du développement web, d'aborder un sujet autour de l'industrialisation.

L'industrialisation, c'est ce qui sépare l'amateur du professionnel, l'artisan de pièces uniques en industriel à la production rationnelle.

Houses and factories

Image : Houses and factories - Library of congress (http://www.flickr.com/photos/library_of_congress) - No known restrictions on publication.

Lire la suite - 2 commentaires

Fotopedia : source d'images libres

Dans Geek par FLorian Strzelecki - 17:11 - 28.05.2010

Tags : Société, Bonne pratique, Photo, Creative-Common, Fotopedia

J'ai eu l'occasion, à plusieurs reprises, d'avoir des retours très positifs de mon lectorat (je ne m'emballe pas, vous devez représenter grand max une 30aine de personnes fréquente, et encore) sur mon choix d'illustration pour mes billets de blog.

Pour les plus perspicaces, vous avez pu remarquer que j'indique presque toujours l'auteur et la licence, mais jamais l'endroit où j'ai trouvé l'image. Je vais donc vous parler un peu du site www.fotopedia.com sur lequel je trouve la majorité des images.

www.fotopedia.com

Image : www.fotopedia.com

Lire la suite - 6 commentaires

Le rôle du scénario

Dans Ludique par Florian Strzelecki - 21:17 - 02.04.2010

Tags : Bonne pratique, Jeu de rôle, Scénario

Le scénario, dans le jeu de rôle, est l'élément essentiel au support de l'amusement des joueurs - le meneur étant, par là, considéré comme un joueur. C'est lui qui va permettre de fixer des bases communes à la narration de l'histoire qui va être vécue par les joueurs, et que le meneur devra donc leur faire vivre.

Un scénario ne fait pas l'histoire : celle-ci prend ses origines tant dans le scénario que dans l'interprétation du joueur, et la façon qu'aura le meneur de lui donner vie.

Quelque part, le scénario, c'est le script des possibles.

(sans titre)

Image : (sans titre) - Petr Jan Juračka (http://www.fotopedia.com/users/scientik) - Creative Common by-nc

Lire la suite - 5 commentaires

Le rôle du recul

Dans Ludique par Florian Strzelecki - 12:01 - 09.03.2010

Tags : Société, Bonne pratique, Jeu de rôle

Ou de la distinction entre son personnage et soi-même. De la non-influence souhaitée et souhaitable de ses sentiments sur ceux de son avatar. Du respect de la personne qui ne fait que s'opposer par son rôle, tout doté d'une hallebarde diplomatique qu'il soit.

Pour faire simple : savoir prendre du recul, sur le jeu des autres, sur son propre jeu, et bien séparer ce qui est en jeu, de ce qui est en dehors.

Et aussi, car nous sommes humains, à la tolérance aux erreurs.

Jungle Speed

Image : Jungle Speed - Gamethyme (http://www.flickr.com/photos/gamethyme/) - Creative Common by-nc-sa

Lire la suite - 4 commentaires

RSS