10 astuces pour créer un environnement de travail motivant à la maison

Un article très intéressant sur les 10 astuces pour se créer un environnement de travail motivant à la maison. L'article est très bien réalisé, avec des images qui évitent la nécessité de lire les explications dans chaque parties.

Je vais vous lister les différents points ainsi que l'image associée. Pour le reste, je vous invite à vous rendre sur l'article d'origine, qui est complet et très agréable à lire.

Read the rest of this post »

Filed under  //  General   Projects   astuces   conseil   environnement   motivant   travail  
Posted by Cyril Nicodème 

Quelques astuces cyniques de gestion de projets

Le blog TechRepublic propose une liste de 20 astuces cyniques sur la gestion de projets, dont certains m'ont bien fait rire :

  • Les projets avec un budget et une durée réaliste ne sont pas acceptés
  • Rien n'est impossible pour les personnes qui n'ont pas à le faire
  • Tu as compris ce que j'ai dit, pas ce que je voulais dire
  • Si le projet échoue, renomme-le !
  • Tout le monde veux un très bon chef de projet ... jusqu'à ce qu'ils l'aient.

La suite ici.

Filed under  //  Development   Projects   astuces   chef   cynique   gestion   management   projet  
Posted by Cyril Nicodème 

Quelques optimisations pour MySQL

Cette liste, donnée par Dublish.com, regroupe quelques bonnes astuces à prendre pour améliorer le traitement de vos donnée stockées sur votre SGBD.

La partie PHP n'est pas traitée ici puisqu'elle à fait le sujet d'un autre article publié précédement.

  • MySQL interprète de la droite vers la gauche, de ce fait, mettez les signifiants limiteurs le plus loin possible de la droite.
  • Sélectionnez les colonnes, plutôt que * (tout).
  • Évitez de mettre des informations qui changent rarement dans la base de donnée, préférez les dans un tableau contenu dans un fichier que vous inclurez.
  • Utilisez des indexes dans les colonnes contenues dans les clauses WHERE et ORDER BY.
  • Les indexes sont très intéressants quand vous faites des recherches mais ralentissent considérablement l'insertion.
  • Utilisez la requête "EXPLAIN" pour analyser vos indexes.
  • Si vous ne voulez qu'une ligne de résultat, limitez votre requête avec la clause LIMIT 1; Cela aura pour effet de stopper MySQL à la première ligne trouvée plutôt que de continuer à parcourir TOUTE la table pour une donnée qui est déjà trouvée.
  • Préferez un FETCH_ASSOC ou FETCH_NUM plutôt qu'un FETCH_BOTH qui déclarera deux variables par colonne au lieu d'une seule.
  • Parfois, mysql_free_result (ou similaire en fonction de ce que vous utilisez) finis par consommer plus de mémoire qu'en gagner. Regardez la différence avec memory_get_usage ();.
  • Évitez de demander à la base de donnée la même chose encore et encore. Stocker la requête et réutilisez la !
  • Utilisez autant que possible NOT NULL en tant que valeur par défaut. Cela améliore l'éxécution et save 1 bit.
  • Utilisez des types de colonnes qui correspondent à votre utilisation. Un INT non signé peux contenir jusqu'à 4294967295 valeurs. En avez-vous vraiment besoin ? Préférez l'utilisation de SMALLINT ou TINYINT en fonction de l'usage.
  • Profitez des valeurs par défaut. Lors de l'insertion, insérer que ce qui n'est pas valeur par défaut afin d'améliorer l'insertion.

Beaucoup de choses sont logiques, d'autres le son après la lecture.
En suivant ces quelques règles, ainsi que celles sur le php, vous pourrez améliorer l'éxécution de votre code considérablement.
Ce qui est un avantage quand le nombre de visiteur augmente !

Filed under  //  Development   améliorer   astuces   fast   gain   mysql   optimisation   performance   rapidité   règle   speed   temps   tricks  
Posted by Cyril Nicodème 

Vous vous y prenez mal si ...

Le site de postal-code propose une news très intéressante sur comment améliorer son temps de travail en listant les pratiques qu'un programmeur à tendance à prendre.

Donc, vous vous y prenez mal si :

  • Vous ne baptisez pas votre application en se basant sur un framework
  • Vous développez votre propre framework
  • Vous n'utilisez pas une couche d'abstraction au bases de données
  • Vous développez votre propre couche d'abstraction sgbd
  • Vous croyez que vous pouvez développer plus vite, mieux et plus efficacement que des librairies existantes
  • Il y a plus d'un développeur sur votre projet et que ce dernier n'à pas de convention de codage
  • Votre plate forme de bug ou votre roadmap sont vos principaux champs de travail
  • Vous n'utilisez pas de système de gestion de version (type cvs, svn, git)
  • Vous commentez le quoi mais pas le comment
  • Vous tentez de passer des propriétés plutôt que des instances à vos fonctions (méthodes)
  • Votre procédure de déploiement implique n'importe quelle combinaison du FTP et du Drag'&'Drop
  • Votre méthode de développement est faite de telle manière qu'elle ne peut-être testée unitairement (Unit Testing)
  • La première chose que vous faites est un copier/coller
  • Vous ne lisez pas (ou peu) de blogs parlant des langages de programmation que vous utilisez majoritairement
  • Vous n'avez été à aucun meeting ou conférence ces dernières années
  • Le seul code que vous lisez au boulot est le vôtre
  • Vous espérez qu'un jour, votre code sera lu par quelqu'un d'autre et qu'il saura que ce code vous appartient
  • Vous vous y prenez mal si vous n'apprenez pas tous les jours !

Il y a certains points sur lesquels je ne suis pas trop d'accord notament l'histoire sur les meetings... on fait avec nos moyens !! :)

Il y a un adage qui ne s'applique pas en bien pour cette liste :
«Celui qui crée son propre protocole sécurisé est soit un génie, soit un idiot»
(anyone who creates his own security protocol is either a genius or a fool), Bruce Schneier’s.

Vous trouverez le post original à cette adresse : http://www.postal-code.com/binarycode/2008/07/28/youre-doing-it-wrong-if/

Filed under  //  Projects   astuces   conseil   mal   méthode   prendre  
Posted by Cyril Nicodème