Le service des résidences est impecable. Je me suis plains qu’il fait trop chaud dans ma chambre et que je suis obligé de travailler fenêtre ouverte (génial les économie d’énergie). Le service fut super rapide ils m’ont coupé le chauffage!
Après une nuit à grelotté j’ai pris les choses en main et j’ai acheté une pince comme cela je peut régler le chauffage moi même ;)
Récemment j’ai du imprimer un gros pdf. Le problème c’est que la moitié des pages était inutile. J’ai donc chercher une solution pour supprimer les pages d’un pdf sous mon OS préféré.
Après un échec avec Kword j’ai trouvé cette article qui parle de pdftk qui est un outil en ligne de commande pour manipuler des pdf.
L’installation sous ubuntu est comme toujours très simple:
sudo apt-get install pdftkCet outil peut donc supprimer les pages d’un pdf, il suffit pour cela de lui donner les intervalles de page à conserver:
pdftk pdftroplong.pdf cat 1-9 11-13 16-end output superpdf.pdf Bref un petit outil sympa à garder dans un coin de la tête lorsque l’on doit manipuler un pdf.
A noel j’ai reçu un nouveau jouet, le reflex EOS 400D (Rebel XTi en amérique du nord) de CANON. Laissons les qualités technique de la bête au spécialistes, pour nous intérésser à son support sous Ubuntu Edgy.
Pour accéder à vos photos il faut installer gphoto. Malheureusement la version fournis avec Edgy ne contient pas le support du 400D, rassurez vous c’est très simple à ajouter.
Commencez par installer gphoto:
sudo apt-get install gphoto2Ensuite éditer le fichier /etc/udev/rules.d/45-libgphoto2.rules et ajouter ces deux lignes avec les autre du même style:
SYSFS*idVendor*=="04a9", SYSFS*idProduct*=="3110", GROUP="plugdev", MODE="0660"Ensuite il vous suffit d’utiliser une application compatible gphoto pour télécharger les photos, perso étant fan de KDE j’utilise Konqueror ou Digikam.
Et voilà désormais vous pouvez archiver et retoucher vos photos sous Ubuntu.
Ceci est un ensemble de bonne pratique à suivre lorsque l’on utilise subversion. Ces recommandations sont issues de mon expérience dans l’utilisation de subversion dans des projets aussi bien de petite que de grande taille.
#Testez avant de commiter Règle élémentaire tester que le code marche avant de faire un commit pour éviter de créer des problèmes aux autres développeurs. Si vous avez des tests unitaire vérifiez qu’il passe toujours. Ne commitez jamais un code qui ne marche pas et qui pourrait gêner un autre développeur.
#Faite un update avant de faire un commit Cela peut sembler aller de soi, mais certains développeurs ne le font pas. Ce n’est pas parce que subversion n’a pas râler à propose d’un conflit lors du commit que le projet marche toujours. En effet quelqu’un peut avoir changé le comportement de portion de code que vous utilisez.
#Pas de message de commit vide S’il y a une bonne pratique à imposer c’est celle là. Ecrire un message de commit qui décrit les changements prend 30 secondes, retrouver une version peut prendre des heures.
De plus avec de bons messages de commit vous pourrez mettre en place des notifications par mail ou des flux RSS.
Vous pouvez mettre un hook de pre-commit pour contrôler cela et refuser le commit lorsque le message est trop court.
#Synchronisez votre branche régulièrement Lorsque vous travaillez sur une branche vous ne devez pas rester pas trop longtemps désynchronisé du projet. Il vaut mieux traiter régulièrement des petits problèmes de merge qu’un gros merge qui a toutes les chances d’échouer et d’introduire des bugs.
J’ai connu une situation où un développeur a travaillé un mois sur sa branche et le travail accumulé pour le merge et le debuggage de ce merge fut tellement gros qu’il fallut mettre plusieurs personnes pour l’aider. Les changements étaient tellement importants qu’il était dur de localiser où les bugs avaient été introduit.
#Faite des commit atomique Lorsque vous faites un commit, commitez d’un bloc tous les changements (idéalement faite un commit à la racine du projet). Cela simplifie les retours en arrière et évite de polluer les logs.
#Mettez à jour tout le projet Faire un update sur seulement un fichier ou un répertoire c’est pratique, mais il ne faut pas en abuser. Beaucoup de problème mystique du type samarchechezmoietpascheztoi vienne d’update partiel. Et lorsque vous aurez passé une heure avec un de vos collègue à chercher un bug dû à cela vous ferez tout petit.
#Des normes de codes strict Par exemple faite votre choix pour des espaces ou des tabulations pour le projet, mais ne mélangeais pas les deux. Sinon à chaque modification votre éditeur de texte va tout réindenter et tout le fichier apparaîtra comme modifier lors des diffs.
#Commitez souvent A chaque fois que vous réalisez un pas dans le projet et que vous pouvez commiter sans gèner les autres faite le. En effet on ne sait jamais ce qui peut arriver le disque dur qui crash, maladie… En mettant vos sources sur le serveur subversion vous ou vos collègue pourrez toujours les récupérer.
C’est un avantage pour vous, car vous pouvez casser complétement votre code en ayant la garantie de pouvoir facilement revenir en arrière.
Avec l’arrivée de Yann en australie j’ai fait le point sur mes relations dans les différents pays du monde.
Je connais donc personnellement des gens qui sont actuellement dans ces pays:
Comme toujours je produit du vent, notre dernière production à tout de même atteint les 62 pages en un mois à quatre.
Ma nouvelle source d’insparation le cours de découverte du québec où je dois produire 8 page sur un visite que j’ai fait et qu’est ce qu’elle m’a apporté dans ma comphrénsion du Québec et des quebecois. On dirait les rédaction racontez vos vacances.
Noplay cultivateur éolien