hgsubversion on windows

November 4, 2009

Who likes mercurial? I do. Lately, I even started using mercurial as a client for subversion repositories. Let me describe the hgsubversion installation steps that worked for me; on my laptop that is boldly supplied with The Only Right operation system…

I heavily borrow from excellent entry by Ben Collins-Sussman and from outrageously diligent post by Dave Cameron. I want to focus on the smallest possible installation routine on windows. Also, I want to emphasize that you don’t have to build anything on windows. All the prepackaged installables or binaries are ready, waiting for you to grab them.

Oh right, here are the steps that worked for me:

  1. Install svn
  2. Install python
  3. Install python svn bindings
  4. Install mercurial
  5. Clone hgsubversion
  6. Configure hgsubversion extension
  7. Start cloning svn repos!
  8. Understand the gotchas
  9. Stay happy

1. Install svn command line client and put it on path. I downloaded, unzipped and PATH’ed svn 1.6.5.
Your cmd should react nicely to: svn help

2. Install python. I installed Python 2.6.2. Your cmd should happily execute: python -V

3. Install svn python bindings. I installed svn-python 1.6.5 py2.6. Your cmd should print ‘6′ when you execute:
python -c “import svn.core; print svn.core.SVN_VER_MINOR”

4. Install mercurial. I installed TortoiseHg (mercurial + tortoise). Your cmd should nicely take: hg version

5. Clone hgsubversion:

hg clone http://bitbucket.org/durin42/hgsubversion SomeFantasticFolder

In my case SomeFantasticFolder is c:\projects\open-source\hgsubversion. At the moment I cloned hgsubversion the tip was the changeset 500.

6. Configure hgsubversion extension. Add extensions to your USER_HOME/.hgrc, which on windows is Documents and Settings\SomeFabulousName. In my case SomeFabulousName is sg0897xxx (after years in IT industry I’m still just a number…). Note that hgsubversion is duplicated at the end – that’s fine. Your .hgrc should contain something like:

[extensions]
rebase=
svn=c:\projects\open-source\hgsubversion\hgsubversion

Your cmd should print enabled extensions at the bottom of the screen when you do: hg help extensions

7. Start cloning svn repos! For example:

hg clone http://example-for-hgsubversion.googlecode.com/svn example-for-hgsubversion

8. Understand the gotchas.

  • gotcha 1. If svn requires authentication, you may be asked to enter user/password… 3 times. Don’t worry, just enter correct credentials patiently. Three shall be the number thou shalt count, and the number of the counting shall be three. (update) Augie Fackler, the mastermind of hgsubversion points out svn+http or svn+https can be used to work around this gotcha
  • gotcha 2: After updating changes from svn (hg pull, hg update) never use ‘hg merge’, instead use ‘hg rebase’. Merges are not yet supported by hgsubversion I heard. If you accidentally do hg merge you probably have to rollback the merge in order to push.
  • gotcha 3: I’m not a mercurial expert so feel free to comment & give feedback. Also, newer (different) versions of before mentioned installables should work as well.

9. Stay happy. Are you kidding me? You know what to do =)

4 Comments | Planet TW, coding, mercurial, svn | Permalink
Posted by szczepiq

remote retrospectives

September 21, 2009

Ideally, I don’t like doing retrospectives remotely but many times I just have to. I live in the era of distributed teams. If this is not enough, there are usually more prosaic reasons: people working from home, lack of decent conference room, etc.

Many times I have to help with remote retros where people dial in from their desks, homes and remote offices. They don’t see each other, they only listen to each other. And there’s a gotcha.

The quality of the retrospective depends a lot on communication. We know that large percentage of communication is contributed by… non verbal stuff (was it 70%? or 80%? Look it up yourself =). You can add problems with quality of phone lines, latency, etc. This practically means remote retros are pretty much a challenge. Let me share a couple hints on dealing with remote retrospectives. I’m going to focus mostly on tools and I would really appreciate if you point me to some even better tooling.

1. MS Office communicator and its shared white board. By the Big ‘M’ company that rules the world (Hopefully, I didn’t offend the Big ‘G’). The communicator is an example of non web-based tool for shared meetings. We started using it instead of twiddla (see #2). The communicator has fairly nice shared white board. The only downsides I encountered so far are:

  • occasionally someone cannot take part in a shared session.

Successful retrospective with MS IM might look like:

end of MS communicator facilitated retro screenshot

End of remote retro with MS communicator

I’m sure there are other peer-to-peer shared white board tools. Let me know if find something interesting.

2. Twiddla is an example of web-based, multi-user, shared white board. We actually tried it for several retrospectives with various success rate. The problems we encountered:

  • too many features, some of them deadly enough to remove everything from the screen
  • voting on items to discuss was somehow difficult
  • we had some minor usability problems and once we couldn’t set up a meeting for unknown reason

We had successful retrospectives with twiddla, for example:

End of twiddla-retro screenshot

End of remote retro with twiddla

You might want to try out twiddla or look for similar tools out there. There are bunch of web-based tools to facilitate shared meetings, shared sticky notes, shared white board etc.

There is one great benefit of using tools like #1 or #2 for shared meetings. It really does not matter if you use a web-based tool like twiddla or just an instant messenger with shared white board like MS communicator. Doing shared meeting with any of those tools allows unsure team members to speak up: they can participate almost anonymously by sticking items on the shared white board. Certain level of anonymousness increases the chance unsure/diffident team members actually participate.

3. Emails. That’s basically my plan B for remote retros. (Although my favorite plan B is forcing plan A). There are number of ways of doing the remote retro with emails. For example, I can ask everyone to spend the next 5 minutes on thinking of three :) ’s and three :( ’s and send me via email. Then I say what are the items most people wrote about and we discuss it. I don’t waste time on sharing the contents of the emails. This gives me a unique chance of steering the retro a little bit. If I feel that there’s an item only few people wrote about but I think it is really important… I can lie just a little bit =)

One other thing I find useful is that sometimes it’s better not to discuss most voted items. Let’s say 70% of retro’s participants are developers based in the same location. There’s a big chance they have similar problems and those problems are technical. In that case, most votes might go to technical problems related to the very same group of the team. I don’t like it… Many times I even skip technical problems during the retro so that we don’t waste customer’s time talking about issues with build. (or am I just too tired of talking about maven?).

***

Finally, I wish your team develop a habit of continuous improvement so that you don’t need a lot of ceremonial retrospectives to get better. Improve daily but if you don’t know how then by all means do retrospectives regularly.

Leave a Comment » | coaching, improving, retrospective | Permalink
Posted by szczepiq

Mockito in Zurich

June 21, 2009

I will have a pleasure presenting Mockito at Jazoon in Zurich. My session is on Thursday – make sure you don’t miss it. During the session I’m going to show few slides and do live TDD with Mockito & other mocking frameworks. I’m going to use Infinitest. Guys, it’s huge. Brett Schuchert wrote about it, Bartek told me to try it several times. Finally I did and I must say I’m impressed. Infinitest is like transcending to a real TDD.

2 Comments | TDD, coding, java, mock objects, mockito, testing | Permalink
Posted by szczepiq

is debugger a modern translator?

May 19, 2009

Couple of days ago we interviewed a young adept of the craft. We let him code but he got stressed out a bit and wrote very complicated code. At some point he stopped understanding the code he wrote. So he started using debugger to figure out the meaning of the code. This is when debugger became sort of a modern electronic translator.

The thing is we probably don’t want to use debugger as a translator. We prefer to understand the code we write. Instead of debugging I usually recommend writing a small test that covers the logic in question. You can try this exercise next time you are about to launch the debugger.

Don’t get me wrong – debugger is a handy tool in every developer’s kit. It’s just the less you use it the better you are in producing high quality code. Actually, it’s probably other way around – when you get fluency with TDD/simple design you will soon discover how rarely you use debugger.

4 Comments | TDD, coding, java, testing | Permalink
Posted by szczepiq

excuses for not doing dev testing

May 12, 2009

Yesterday I heart loads of excuses why the tests have not been written. I immedietaly remembered Misko Hevery’s session at amazing geecon conference (be sure to attend next year!). Misko told a story about influencing developers to write more tests, testable code and TDD. I liked his slide where he collected all the excuses he heart from devs explaining why they haven’t written tests. Basically, Misko’s conclusion was that the only valid reason of not writing tests/TDD was lack of skill. TDD or ability to write tests is a skill like any other and it is no shame if you haven’t acquired it yet!

However, some of the excuses I heart yesterday were beyond any common sense:

  • this is not really worth testing
  • this is a small application
  • we don’t have time
  • (my favorite one) tests would make it harder to refactor

That was all bullshit and the only reason the tests were not written was that it was hard to write them. Devs didn’t know how to write tests for the DAO layer (how to ensure db is in correct state, how to maintain test database, etc.). Devs didn’t know how to write integration tests because of lack of experience with tools like Selenium. So they didn’t write any tests, not even plain jUnits.

Half a year ago, the same development team wrote loads of tests achieving high quality code base & high test coverage. Those days they wrote a django application. Django is a modern framework with built-in means of testing. It significantly contributed to the fact that developers wrote tests without cheating themselves with it’s-not-worth-testing kind of excuses (complete list above).

The interesting thing about the situation I encounter yesterday was this: junior developer wanted to write tests for some DAO code that did not have any tests (actually, there were zero tests at all…). So I asked senior developer responsible for architecture to help out setting up a TestCase that can prepare connection to test database, etc. Instead of helping, the senior guy started his mantra of excuses trying to convince junior developer not to write tests. Fortunately, I was there…

4 Comments | TDD, coaching, coding, learning, testing | Permalink
Posted by szczepiq

be careful with fundamentalism

February 8, 2009

One of my colleagues told me the other day:

“Szczepan, last year, when I started working in the X team someone warned me not to speak too loud about unit testing”

Apparently, there were feisty TDDers in the X team and they witch-hunted devs who not necessarily had written test-first. I guess it’s easy to become a fundamentalist of any methodology or technique. Personally, I don’t mind dogmatic coaching… so long it works. In the X team it clearly didn’t because devs were not feeling comfortable to even talk about testing.

At devoxx I met Jakub and he told me how he had introduced TDD to his team. Apparently, he used his tech lead mandate and just demanded test-fist. After a week or two of resentment, the developers started finding benefits of the new technique. They removed needles from the voodoo dolls, thanked Jakub for almost an eye-opening experience and continued to test first. Nice work! Hopefully I remember his story right – our conversation might have been after few beers.

2 Comments | Planet TW, TDD, coaching, testing | Permalink
Posted by szczepiq

subclass-and-override vs partial mocking vs refactoring

January 13, 2009

Attention all noble mockers and evil partial mockers. Actually… both styles are evil :) Spy, don’t mock… or better: do whatever you like just keep writing beautiful, clean and non-brittle tests.

Let’s get to the point: partial mocking smelled funny to me for a long time. I thought I didn’t need because frankly, I haven’t found a situation where I could use it.

Until few days ago when I found a place for it. Did I just come to terms with partial mocks? Maybe. Interestingly, partial mock scenario seems to be related with working with code that we don’t have full control of…

I’ve been hacking a new feature for mockito, an experiment which suppose to enhance the feedback from a failing test. On the way, I encountered a spot where partial mocking appeared handy. I decided to code the problem in few different ways and convince myself that partial mocking is a true blessing.

Here is an implementation of a JunitRunner. I trimmed it a little bit so that only interesting stuff stayed. The runner should print warnings only when the test fails. The super.run(notifier) is wrapped in a separate method so that I can replace this method from the test:

initial-code1

How would the test look like? I’m going to subclass-and-override to replace runTestBody() behavior. This will give me opportunity to test the run() method.

subclass-and-override1

It’s ugly but shhh… let’s blame the jUnit API.

The runTestBody() method is quite naughty but I’ve got a powerful weapon at hand: partial mocking. What’s that? Typically mocking consist of using a replacement of the entire object. Partial stands for replacing only the part of real implementation, for example a single method.

Here is the test, using hypothetical Mockito partial mocking syntax. Actually, shouldn’t I call it partial stubbing?

partial-mocking1

Both tests are quite similar. I test MockitoJUnitRunner class by replacing the implementation of runTestBody(notifier). First example uses test specific implementation of the class under test. Second test uses a kind of partial mocking. This sort of comparison was very nicely done in this blog post by Phil Haack. I guess I came to the similar conclusion and I believe that:

  • subclass-and-override is not worse than partial mocking
  • subclass-and-override might give cleaner code just like in my example. It all depends on the case at hand, though. I’m sure there are scenarios where partial mocking looks & reads neater.

Hold on a sec! What about refactoring? Some say that instead of partial mocking we should design the code better. Let’s see.

The code might look like this. There is a specific interface JunitTestBody that I can inject from the test. And yes, I know I’m quite bad at naming types.

refactored-code1

Now, I can inject a proper mock or an anonymous implementation of entire JunitTestBody interface. I’m not concerned about the injection style because I don’t feel it matters that much here. I’m passing JunitTestBody as an argument.

refactored-test

Let’s draw some conclusions. In this particular scenario choosing refactoring over partial mocking doesn’t really push me towards the better design. I don’t want to get into details but junit API constrains me a bit here so I cannot refactor that freely. Obviously, you can figure out a better refactoring – I’m just yet another java developer. On the other hand, the partial mocking scenario is a very rare finding for me. I believe there might be something wrong in my code if I had to partial mock too often. After all, look at the tests above – can you say they are beautiful? I can’t.

So,

  • I cannot say subclass-and-override < partial mocking
  • not always refactoring > subclass-and-override/partial mocking
  • partial mocking might be helpful but I’d rather not overuse it.
  • partial mocking scenario seems to lurk in situations where I cannot refactor that freely.

Eventually, I chose subclass-and-override for my implementation. It’s simple, reads nicer and feels less mocky & more natural.

2 Comments | TDD, coding, java, mock objects, mockito, refactoring, testing | Permalink
Posted by szczepiq

coacheating

December 28, 2008

A bit about coaching, a bit about cheating this time.

A colleague asks me for help with some random problem about random technology.

I might say: “push here, run that, do this…”

Or I’d say: “I don’t know. What do you think? Hang on… I bet this tool should allow doing something like that. Let’s pair on this for a moment…”

A geek like me tend to enjoy showing off with how much he knows. Sometimes it’s really hard to shut up and pretend I don’t know. There is a reward, though. It’s when we finally work out the solution together and I feel we both made a little step ahead to be better software engineers.

One wants to get things done. One aims for fabulous architecture. Many times I seem to have quite different agenda. I’d rather make someone learn stuff. So I might say “I don’t know” even if it means things are not done as quickly or the design ends up imperfect. Is it clever or just… unethical?

Whoa, deep blogging. I bet it’s this Christmas time inspiration. This blog post is sponsored by Mariah C. (All I want for Christmas is… closure in java?).

4 Comments | coaching, learning | Permalink
Posted by szczepiq

build systems @ devoxx

December 11, 2008

I couldn’t attend to the session on gradle because there was a Mockito session at the same time. For some unknown reasons I chose Mockito…

About gradle. Later on, Hans Dockter (AKA the gradle guy) was kind enough to help me writing a build.gradle for Mockito. Also, we played with multi-project builds and brand new gradle jetty plugin.

Then I went to Jason Van Zyl’s session, mostly on maven3. Third time lucky, right? Let’s not mention M1 or M2 here because I would have to use words gentlemen don’t use. Maven3 looks quite promising and I wonder what’s gonna be my first choice build system in mid-2009: gradle, maven3, or maybe something else? Felix made a wild experiment and cut an interesting, object-oriented java build system.

Oups, did I just call maven a build system? Oh, I know it is “not just a build tool” but 94.72% of developers use it to build projects so pardon me for taking this mental shortcut.

After Jason Van Zyl’s session I had an impression that he believes the best fit for the build system is a declarative architecture. I tend to disagree and I believe the build has inherent scripting nature. Then the natural fit for the build system is some scripting language. Quick reminder: xml is not a scripting language. Fully declarative build system like maven makes me eventually hit the boundary – it’s when the stuff that can be declared or configured is not good enough. Then I need a painless way of “specialising” my build, for example by scripting. Mind that I’m not nearly a build architect so don’t take my rambling too seriously.

I didn’t meant to complain about maven – there are many really good ideas in it. However, allow me to have my favorite build system different from maven. Good luck with your maven builds. You’ll never know when they stop building…

6 Comments | build systems, coding, java | Permalink
Posted by szczepiq

more of devoxx, more on interfaces

December 9, 2008

I gave my talk at devoxx and hopefully those who attended were not offended by my weird sense of humor :) Guys, we need to have more fun in IT…

Shortly after I gave the talk I had an interesting discussion about the coding style some folks call “coding to interfaces”. It started when I was asked if Mockito is able to mock concrete classes? The answer is yes, Mockito doesn’t care if you mock an interface or a class. Mockito can do it thanks to primordial voodoo magic only ancient shamans understand these days (you guessed right – it’s the cglib library).

Here starts the controversy. Should Mockito allow to mock only interfaces and hence promote “coding to interfaces”? Dan North, a respected IT guru and Mockito friend, said between the lines of one of his articles:

it allows me to mock concrete classes which I think is a retrograde step – remember kids, mock roles, not objects

What about the guy who approached me after the Mockito session told me a story about the codebase deeply proliferated with interfaces? Interfaces were introduced by developers not because they wanted to mock roles, not objects but because the mocking framework they used “promoted” coding to interfaces. This codebase was not very friendly.

To me, interface frenzy makes the codebase hard to browse, for example due to extra effort required to find implementation. Also, too many interfaces dilute the actual meaning of those interfaces that are really important. Therefore sometimes I mock classes, sometimes I mock interfaces and Mockito deals with it transparently. There are situations where I always use interfaces but let’s not bring it here.

I remember some old-school java book I read years ago. It read: “every java class should have an interface“. Don’t believe everything you read and the best example would be this blog, wouldn’t it?.

Use the coding style that works best for you. Drink mockitos only with interfaces if you like it this way.

3 Comments | coding, mock objects, mockito | Permalink
Posted by szczepiq

« Previous Entries