29 Apr 2011

Delicious Time

Big news for me today, Yahoo sold Delicious to Avos (see more about this: http://www.delicious.com/help/transition)

From all the web2.0 company burst, Delicious was and is still by far the service I found the most (the only one ;) ) useful; far before Facebook, Twitter, YouTube etc. those ones just make me waste time...

So time to backup my 3500 bookmarks using delicious export functionnality (just in case).

I haven't decided yet if I opt-in for the new service...
Clearly I don't want to put all my bookmarks in google system, they already own too many personnal informations about me (including this blog)

I you know and used something equivalent to delicious that can be hosted on dedicated server, drop me a line in comment section ;)

I'll wait for nice/smart people to read Avos privacy policy for me and detect if something is wrong in usage terms ;)

So long Delicious :)

28 Mar 2011

NTP on Solaris

I tried to unable NTP on a solaris machine. Here's how it works in a nutshell:
cp /etc/inet/ntp.server /etc/inet/ntp.conf
vi /etc/inet/ntp.conf

# comment those lines
# server 127.127.XType.0
# fudge 127.127.XType.0 stratum 0

# add those lines
# server list http://tf.nist.gov/tf-cgi/servers.cgi
server time-b.nist.gov

touch /var/ntp/ntp.drifts
svcadm restart svc:/network/ntp
svcs ntp
ntpq -p
date

10 Mar 2011

Tortoise GIT

Lately I've use tortoise git and it seems windows support for git is becoming better :)

You'll have to install msysgit before using tortoisegit tortoisegit

The benefit is obvious, now you don't have to learn all the git command line tricks and tips and newcomers to git are less frustrated

I haven't use it on a day to day basis, but I imported a svn history and synchronised my git commit to a svn repo using git-svn rebase and it worked like a charm :)

Technorati tags: git tortoisegit

18 Oct 2010

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

19 Jul 2010

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
 

29 Apr 2010

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/

22 Apr 2010

15 Apr 2010

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

17 Mar 2010

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)