Monday, July 20, 2009

Why Scala

I wanted to write a post 'Why Scala is such a nice/great language', but after I've seen the Martin Odersky presentations at google, and at FOSDEM 2009, Bonas Joner at QCon 2009 'Pragmatic Real-World Scala)', Evan Weaver with 'Improving Running Components at Twitter' and the James Strachan's (of groovy fame) post, an impressive collection of learning Scala resources, I had the impression that there is nothing more to be said (that hasn't be said before).

There is even an online and offline ScalaTour.

Nevertheless, we could/should mention


* seamless java integration
* IDE support, build support (maven, ant, sbt, buildr)
* java code coverage

* objects all-way-down (see ScalaOverview) (the Smalltalk way)
** primitives are efficiently wrapped & handled by the compiler
* closures/functions are objects too
* multiple trait inheritance (e.g. utility-belt, logging, ...)

* extensible pattern matching (i.e. switch on steroids on objects)
* functional idioms allowed
* type inference (Hindley-Milner)
* reified generics
* type classes
* elegant solution to the Expression Problem

Monday, July 13, 2009

Moved Code Snippets to Mercurial

I've just moved the tip of the svn trunk to mercurial.
In order to make a push without a password you'll need to modify the .hgrc (specify your google code username, password :

thought-tracker =

In order to get it:
hg clone local_folder

In order to push/publish it (after a local hg ci -Am"some msg"):
hg push thought-tracker

Thursday, July 09, 2009

DVCS(hg) vs SVN workflows

Suppose we work in an international company, remote sites, not so good connection between those sites.
We have the following scenarios:

1. We have to do a rather big refactoring, which will take several weeks.
- With svn: we create a 'feature branch' where we'll do the refactoring. We update daily from trunk, we push to trunk regularly/at the end. The feature branch is allowed to be CI-red. (Due to an svn issue merging back-and-forth became a problem for svn-merge-tracking, and we had to do a tree-diff on 2 local sandboxes)
- With hg: you just create a clone-branch, you work on it, you can merge with<->from trunk regularly,
whithout any merging problems.
- Guerilla tactics: shadow the svn trunk/branch with some hg repositories and to the merges with hg (no tree-diff), at the end push the changes to svn

2. Junior (remote) developer needs help fixing a unit-test.
- With svn: do a branch, svn switch to it, push the code with the broken tests, fix them, merge back to trunk.
- With webex: do a remote session an explain the fix
- With hg: just pull the changes, make a fix, push them back to the remote developer. (hint: hg is more network-friendly then svn)

3. An interface between 2 components is changed radically. Both the user & the implementation must be changed.
- With svn: do a branch, do all the changes, merge to trunk
- With hg: change the interface in a cloned repository, then share this repository between the user & implementer. They can work in parallel, the last one finishing pulls the changes from the other one and does the integration.

4. Junior developer, friday@17.00, before a 3 week holiday, wants to commit his _weekly_ changes. He cannot create a local ci build within 1 hour so he doesn't commit anything.
- He shouldn't integrate friday@17.00. (but he did)
- With svn: create a branch, svn switch, push your changes to the server
- With hg: a colleague could pull the changes an do the integration + push the changes, without the need to go through the server.

5. Always keep the code green.
- With svn: run the CI on the pre-commit hook (TeamCity does it). The code get's in the repository only if the build is green
- With hg: maintain 2 repositories: in the 1st one we push the changes, which are peeked by the CI, validate, and on success pushed to another repository. (or just do a rollback; much easier with hg)

A lot of the hg power comes from the fact that is changeset-based (unlike svn) and merges are really easy. Another big plus point goes to the distributed nature of hg: it enables more flexible workflows; in a centralized vcs all the communication is done through the server.

links: hg, git