Mercurial Rainbow

Branches display un tortoise hg.

Reminds me of a tv serie: Gigi

Raccourcis clavier excel MS Office [fr]

Liste des raccourcis clavier excel MS Office

ALT+' (apostrophe)
Affiche la boîte de dialogue Style.
CTRL+1
Affiche la boîte de dialogue Format de cellule.
CTRL+MAJ+~
Applique le format de nombre Général.
CTRL+MAJ+$
Applique le format monétaire avec deux positions décimales (les
nombres négatifs sont mis entre parenthèses).
CTRL+MAJ+%
Applique le format pourcentage sans position décimale.
CTRL+MAJ+^
Applique le format numérique exponentiel, avec deux décimales.
CTRL+MAJ+#
Applique le format de date, avec le jour, le mois et l'année.
CTRL+MAJ+@
Applique le format horaire, avec les heures et les minutes, et AM ou PM.
CTRL+MAJ+!
Applique le format numérique, avec deux décimales, un séparateur de
milliers et un signe moins pour les valeurs négatives.
CTRL+B
Applique ou enlève la mise en forme gras.
CTRL+I
Applique ou enlève la mise en forme italique.
CTRL+U
Applique ou enlève le soulignement.
CTRL+MAJ+5
Applique ou enlève le barré.
CTRL+9
Masque les lignes sélectionnées.
CTRL+MAJ+((parenthèse ouvrante)
Affiche les lignes masquées au sein de la sélection.
CTRL+0 (zéro)
Masque les colonnes sélectionnées.
CTRL+MAJ+)(parenthèse fermante)
Affiche les colonnes masquées au sein de la sélection.
CTRL+MAJ+&
Applique un contour aux cellules sélectionnées.
CTRL+MAJ+_
Enlève le contour des cellules sélectionnées

Git vs Mercurial (hg)

Lately I'm playing with Mercurial (hg) and Git but I couldn't tell the difference between the two. Actually it is quite thin but noticable. Here's a comparison of hg vs git and my conclusion

Sorry for the format but these are notes I took while playing with hg and git. I 'm too lazy to format them in html ;)

# this comparison assume that you have 
# a ~/.gitconfig and a ~/.hgrc configured 
# with your username (otherwise you need to 
# add your username at every commit)
mkdir /tmp/scm-tests
cd /tmp/scm-tests

# create a central repo
mkdir [scm]-central
git: 
  git init --bare git-central 
# bare: you need to look at the man page to 
# find this - needed otherwise you not be 
# able to do push (you will need to go to central and pull)
hg:
  hg init hg-central 
# on the contrary hg assume by default 
# that you can push (might be seen as 
# a security issue - that doesn't bother me)

# user1 clone central 
mkdir [scm]-user1
git:
  git clone /tmp/scm-tests/git-central/ git-user1/ 
# you will get a 'warning: You appear to 
# have cloned an empty repository.' I don't 
# understand why they putted that ?! what's the problem here ?
hg:
  hg clone /tmp/scm-tests/hg-central/ hg-user1/

# add and commit 2 initial files
$ cd [scm]-user1
$ ls 
OTHER.TXT  README.TXT
$ cat OTHER.TXT 
other file
$ cat README.TXT 
readme file

git:
  git add README.TXT OTHER.TXT
  git commit -a -m "user1 modif1" 
# using the 'a' option or not 
# could be a post on itself 
hg:
  hg add README.TXT OTHER.TXT
  hg commit -m "user1 modif1"
# pushing modification to central repo
git:
  git push origin master 
# here you get some obscure 
# message in the output like 
# 'Delta compression using up to 2 threads'
hg:
  hg push default

# creating user2 and cloning central
$ cd /tmp/scm-tests
mkdir [scm]-user2
git:
  git clone /tmp/scm-tests/git-central/ git-user2/ 
hg:
  hg clone /tmp/scm-tests/hg-central/ hg-user2/
  
# - - - - - - - - - - - - - - - - - - - -
# concurrent modification of different files
# - - - - - - - - - - - - - - - - - - - -
modify [scm]-user1/README.TXT
modify [scm]-user2/OTHER.TXT

git:
  cd git-user1
  git commit -a -m "user1 modif"
  cd ../git-user2  
  git commit -a -m "user2 modif"
hg:
  cd git-user1
  hg commit -m "user1 modif"
  cd ../git-user2
  hg commit -m "user2 modif"

# push user2 modif to central
git:
  git push origin
hg:
  hg push default

# pull from user1
cd ../[scm]-user1
git:
  git pull origin master 
# I always have a doubt if it's 
# origin master or the opposite
hg:
  hg pull default 
# notice that you don't need to tell 
# hg where you want to send the changes 
# it assume it's the current dir
...
(run 'hg heads' to see heads, 'hg merge' to merge)
  # this message is important because it means you 
  # have to issue 2 extra command to merge otherwise you can't push
  # the merge will be easy but in this case git just does it !
  hg merge # we don't specify any revision, 
  # hg is smart enough to find the right one
  hg commit -m "Merge" # by default in tortoisehg the 
  # commit message is already configured - don't know if it's 
  # a tortoisehg feature...

# push user1 modif to central
git:
  git push origin
hg:
  hg push default

# pull user1 modif in user2 folder
cd ../[scm]-user2
git:
  git pull origin master
hg:
  hg pull default
...
(run 'hg update' to get a working copy)
  # again this message is important, hg fetched the central 
  # repo info, but didn't moved you automatically on the latest revision
  # we could have done this by using the -update option, 
  # but I wanted to show you this situation
  hg update # another extra command compare to git

# diplay graph of what we made
git:
  git log --graph --color # notice the commit 'Merge branch...' was done 
  # automatically, we did nothing (except push and pull)
*   commit 817f6e11a14530c6b09502edd069895ab19d8aea
|\  Merge: b0647d4 c0a4f25
| | 
| |     Merge branch 'master' of /tmp/scm-tests/git-central
| |   
| * commit c0a4f259c33f8d8876088b08703776bb2739bb4a
| | 
| |     user2 modif
| |   
* | commit b0647d415b30a407f0367ff96e5a417956d83d93
|/  
|   
|       user1 modif
|  
* commit 6ffe857f8ece5ea7df051975b36c4384bdbe1383

hg: # didn't found any text based graphical tool 
# at first but apparently there is an 
# extension off by default: 
# http://mercurial.selenic.com/wiki/GraphlogExtension
  hg log
hangeset:   3:2e322ec563c5
tag:         tip
parent:      2:995f574cea3d
parent:      1:4d258b644a75
summary:     Merge

changeset:   2:995f574cea3d
parent:      0:a3ebb2490ce5
summary:     user1 modif

changeset:   1:4d258b644a75
summary:     user2 modif

changeset:   0:a3ebb2490ce5
summary:     user1 modif1

# git and hg: same number of revisions

# - - - - - - - - - - - - - - - - - - - -
# concurrent modification of the same file (with conflict)
# - - - - - - - - - - - - - - - - - - - -
modify [scm]-user1/README.TXT
modify [scm]-user2/README.TXT
the same line
commit code omitted

# push user1 to central
git:
  git push origin
hg:
  hg push default

# pull central to user2
cd ../[scm]-user2
git:
  git pull origin master
...
Auto-merging README.TXT
CONFLICT (content): Merge conflict in README.TXT
Automatic merge failed; fix conflicts and then commit the result.
hg:
  hg pull default
...
(run 'hg heads' to see heads, 'hg merge' to merge)
  hg merge # extra command 
merging README.TXT
warning: conflicts during merge.
merging README.TXT failed!
...
use 'hg resolve' to retry unresolved file merges or 'hg update -C' to abandon

# fix conflict by editing file
vi README.TXT

# mark file as merged
git:
  git add README.TXT
  git commit -a -m "fixing conflict"
hg:
  hg resolve -m README.TXT # this m option was hard to find
  hg commit -m "fixing conflict"
  rm README.TXT.orig # I don't know if it's me not 
  # using hg properly or hg behavior but we need to 
  # cleanup manualy some backup file :(
  
# push user2 conflict fix to central
git:
  git push origin
hg: 
  hg push default

# update user1
cd ../[scm]-user1
git:
  git pull origin master
hg:
  hg pull default
...
run 'hg update' to get a working copy)
  hg update # extra command

# diplay graph of what we made
git:
  git log --graph --color
 # notice that this time there is no automatic merge message but ours
*   commit 58e0ec598f272ac5d4dff02b7a9d0e3842a08c81
|\  Merge: 7c4b4dc e176f07
| | 
| |     fixing conflict
| |   
| * commit e176f07da2db925528c7a068af5f558484af6f56
| | 
| |     user1 modif conflict
| |   
* | commit 7c4b4dc8cbbb49138312df41fe19f2b2dee90d2b
|/  
|   
|       user2 modif conflict
|    
*   commit 817f6e11a14530c6b09502edd069895ab19d8aea
...

hg:
  hg log
changeset:   6:6f8dceccba2d
tag:         tip
parent:      5:32085fee1b07
parent:      4:7417be83b483
summary:     fixing conflict

changeset:   5:32085fee1b07
parent:      3:2e322ec563c5
summary:     user2 modif2

changeset:   4:7417be83b483
summary:     user1 modif2

changeset:   3:2e322ec563c5
...

# git and hg: same number of revision: 3

# - - - - - - - - - - - - - - - - - - - -
# conclusion
# - - - - - - - - - - - - - - - - - - - -
learning curve (if you already know svn):
git:  not easy, need regular practice and at least 
one week to become familiar with command line args
hg:   1 day, just feels like svn

commands:
git:  21 commands with (obscure) command line arguments
hg:   50 (obvious) commands

branches:
git:  merging from branch is done with one command line
hg:   you need to type extra (useless) command to merge in obvious (non conflicting changes) case. 
Apparently the extra (useless) commands behavior can be change by tuning some conf parameter: 
http://hgbook.red-bean.com/read/a-tour-of-mercurial-merging-work.html#sec:tour-merge:fetch

vocabulary:
git:  origin
hg:   default

windows support:
git:  lame
hg:   good (tortoisehg)

linux support:
git:  good (git help are man pages)
hg:   good enough

merge conflict:
git: easy 
hg:  less obvious / elegant

me:
I like both
hg:  because it's so easy to use 
git: for it's elegant way of handling merge and branches
 

TDD next step evolution: (almost) no tests

Disclaimer: I don't think you can understand this until you used TDD for a few years...

I have to admit I do TDD less and less (shame on me). But that's strange because my code quality doesn't decline that much?!

I noticed it but I couldn't put words on it untill guess who twitted about about a blog article: "TDD without the T".

Simply put:
1- first you code without tests, you make bugs, crappy code and it freaks you out (if you're a control freak)
2- you write tests and you get confidant again (even if you know your tests don't catch all bugs)
3- you write more and more tests but you become enable to start a simple little program/idea just for fun because you need to setup all the tdd(ish) components before you can actually start something
4- you don't write tests and you realize that you now write better code and do less bugs (because you've written tests for so many years)

This evolution process span on many years but that's my current understanding of TDD after starting to use it back in 2003!

That doesn't mean I don't write tests, I just write them when I think they are necessary, when I want regression suite, when I realize something is becoming to complexe to simply launch it and see if it works etc...

For my latest pet project: http://code.google.com/p/gmail2ldap/
I didn't write any tests because code was just about wiring ldap + gmail contact api.
Unit code was useless.
Making a functional test suite was too complexe for a little program like this.
I'm actually happy I didn't make any test!

Take a look at this article, you'll learn stuff: http://coderoom.wordpress.com/2010/04/27/tdd-without-the-t/

Cucumber cheatsheet

A simple cucumber cheatsheet:

An example:



Extracted from : Making BDD Fun

Git

Random thoughts about git after playing a bit with it

• git is NOT svn
• moving to git is more complicate than moving from cvs to svn or vss to cvs
• git learning curve is high
• git is powerfull
• git nicely solve some corner issues that svn doesn't solve well
• git is well-suited for open source projects
• i'm not sure it is well-suited for entreprise
• git is not well-suited for corporate (no brain, don't give a dam about it's job) delevopers
• git commands are complexe because git is powerfull
• last time I tried git on windows it sucks!
• github rocks
• without gihub git is less powerfull
• gitk is ugly
• gitk is fine to browse history commits and diffs
• only Vulcan can understand gitk branches display
• git commands lines are hard to grasp
• i think there's room for a nextgen git: it would be git principles but easier command line options/names (juste like the cvs to svn improvement)

Technorati tags: git scm

Fun: Theory vs Reality

Theory: What you're supposed to do in professionnal life (if you're a senior developer)

• 50% Code
• 50% Write documentation (specifications etc..)

Reality: What you really do

• 15% Read/Write mails and Search old mails for proof that someone failed
• 15% Tell what you did last month
• 15% Todo lists
• 13% Install and integrate things (frameworks, products...)
• 10% Write documentation
• 10% Argue in meetings about the documentation you just wrote
• 10% Meetings with boss to tell about coordination
• 10% Fix badly written code by other
• 1% Coordinate with teammates
• 1% Write excellent code (that will likely become miserable after some student take back your code to add something useless)

"Proactively" Tivoli

I transcripted a sentence from a Tivoli demo, I just love it :p

Tivoli Availability Management Solution allow you to proactively monitor and manage through a single customizable workspace portal for an end-to-end view.

Around 1 min after start: IBM_Demo_Tivoli_Monitoring

Technorati tags: ibm tivoli

Thunderbird Lightning Tip: Display tasks in calendar

If you're using Lightning in Thunderbird, a little tip to display tasks in the current calendar:

Technorati tags: thunderbird lightning

Groovy LDAP

I stumbled upon this experiment at apache LDAP project. I don't have the utility right now but I think this is a great idea: Groovy LDAP (I would have made it in ruby/jruby but I'm language agnostic so why not in groovy)

I remember when we were using rdf has a storage mecanism at joost, we used to run update scripts written in jruby (calling java native api). It was an handy solution, script language are more "natural" when it comes to creating/updating/deleting stuff (like SQL does)

Usually you want to hack something quick to fix some bad data and you don't want to start eclipse, compiling and build (like with ant).

Using groovy to ease LDAP maintenance tasks is a great idea.

Switching to Ubuntu (2 months after)

2 months ago, after many issues with my own or my familly members computers, I decided to switch "completly" 3 computers to Ubuntu (Karmic Koala).

I wasn't really scared of Ubuntu (I already had a dual boot) but I used to spend most of my time under windows just because I know my way around windows well...

The reasons I swtiched:

• Stability! Turn on the computer and use it (mail, internet, photo, musik) that's all!
• Administration: Wanted to reduce the time I spend administrating computers (updating stuff, dealing with windows licensing, scanning for viruses...)
• Have a single operating system for all computers; not many windows flavor (XP, Vista etc...)
• Increase disk space by removing one operating system and it's partition

My conclusions after 2 months: overall good but not has much has I would have expected :(

What went "well":

• Part of stability: ubuntu told me that a laptop battery had only 10% maximum charge and that an hard drive was about to die (with the number of failing sectors). I already knew that but I find it the hard way with windows (one day the hard drive just didn't boot anymore)
• Administration: reduce time since I don't have to scan for viruses anymore
• One "Free" OS to rule them all
• Disk space

What went "wrong":

• Stability: what I gained on the hardware part I lost it with numerous problems when turning the computer to "hibernate" mode. Usually when I ask the computer to hibernate and some usb drive is pluged in I have to reboot the hard way
• Administration: most of usual administrative task (installing with apt-get, updating etc.) are fast but I spend a lot of time trying to install my old webcam, make the wifi work and I failed to make the SD card reader work. Every time I plugin something new into a computer run on linux (here ubuntu) it can become quite easily a command line nightmare
• As you would expect, there is still a learning curve to find where stuff are located (for example under windows I know instantly where the printers are... under ubuntu I had to scan all menus to find them) now I know but it the same for everything, you just have a certain amount of time dedicated to re-learn what you already know...
• Musik: I don't find rythmebox (the already installed musik player) good. I find the usabily is really poor (not sort on columns names, playlist get shuffled when re-starting the player, items "diseappear" from playlist when they have been played argh!...) I need to find something better...

I still spend lots of time on administrating but I think that also my geek nature that want me to customize everything :p

SNCF multitouch project

I don't usually make publicity for my company on this blog but what they did for the next generation of multitouch screen for the SNCF (french rails road) is nice :)

You can have a look at the Youtube video:

More information on the contest: http://pro.01net.com/editorial/510297/concours-multitouch-sncf-les-finalistes/ [fr]

Technorati tags: sqli sncf

Update: I just realized some students of my school also participate to this contest, funny! (http://pro.01net.com/editorial/509269/concours-multitouch-sncf/)