Robert Cowham's Weblog 2 to 6 of 43 articles Syndicate: full/short

Subconf 2007 - Subversion and the Enterprise   31 Oct 07
[print permalink all comment ]

This article is a result of my visit to Subconf in Munich a couple of weeks ago.

The first thing to say is that Subconf was very enjoyable and interesting and my compliments to the organisers. There were some excellent speakers and it was good to chat to various vendors too. I also had a very good time at the dinner that evening - the only slight fly in the ointment was the S-Bahn strike the following morning which meant a rather earlier taxi to the airport than I might have wished!

The two keynotes by Brian Behlendorf and Karl Fogel respectively were particularly good. Indeed it was good to get them at the conference since both guys seem to be scaling down their Subversion involvement - Brian has stepped down as CTO at Collabnet and Karl is running QuestionCopyright.org (although remains as President of Subversion Corporation.

Some of the slides are now available online.

Brian's Keynote

Brian mentioned his involvement in Apache and some of the lessons learnt about creating a community that worked. These lessons were then applied by Collab.net to get Subversion going. If you create a high quality community, you will create high quality software.

  • Need to be nice to people to avoid a "fork" - Development leaders exhibit good communication skills, and can bring different ideas together.
  • Conscious effort to bring new developers along the path: from “consumers”, to bug reporters, to patch submitters, to active contributors. 

Brian was asked the question in his talk about Linus's somewhat inflammatory video about Git where various sideswipes about brain-dead CVS and Subversion people are made. Brian had no particular axe to grind about this and said that the Subversion camp bore no ill will to the distributed crowd and were rather surprised at some of the venom coming back - a very measured and mature response.

Brian mention the difference between a centralised model and a distributed model - there is a lot that enterprise like about the control of a centralised model. For example, laptops get stolen (he lost his a few weeks ago), and a laptop might contain a whole distributed repository. Enterprises prefer more control!

Martin Doettling's Intro to Karl

The key points of this were:

  • Estimated user base now exceeds 2 million
  • 10x growth since 1.4
  • Large numbers of enterprise users

Karl's Keynote - How Stuff Happens

Karl picked up on some of Brian's points about the community, and showed various ways in which they have been able to get hackers to create software that the enterprise can use!

  • There is a very comprehensive guide to how to contribute - 43 pages of it! This is where people start.
  • Some principles:
    • Make it easy to do things right
    • Make it rewarding to do things right
    • Influence proportional to effort
      • Moving from contributor to partial-committer to commiter
      • Tracking no of patches etc by user - all automated with links (see Contribulyzer)

Other Notes

I couldn't stay for the second day, but some other points of interest:

  • There are increasing numbers of tools based around Subversion - Collabnet, Polarion, CodeBeamer etc
  • Subversion command line is increasingly irrelevant as people use it through Tortoise, Eclipse etc.
  • Merge tracking there at long last with 1.5 just around the corner
  • Really being used in the industry
  • SVK provides an interesting distributed method

I also had some chats with Collabnet around the idea of perhaps the BCS CMSG working with them to put on an event in London next year - definitely something to look into.

Well worth a visit as a conference.

Directing vs. Managing Configurations   10 Jul 07
[print permalink all comment ]

In a recent CM Crossroads article on defining Agile SCM I included the quote from Charles Handy that I recently picked up on my travels through an airport:

Go to the theatre and look at the programme. Everyone connected with the performance is listed, no matter how small their contribution. People like to be recognised as individuals. The word "manager" is reserved for those in charge of things, not people, the stage manager and the lighting manager. The people who are in direct communication with the customer, the actors, are directed, not managed, by someone who actually leaves the scene once the project is under way. He or she trusts the cast to go it alone, and as often as not, they improve on the production once the director departs. Trust inspires. One more thing - at the end of each performance they receive an expression of appreciation from their audience, direct feedback from the people who matter. No waiting for the annual performance appraisal.

Charles Handy, Myself and Other More Important Matters, Arrow Books, 2007 - ISBN 9780099481881

This obviously applies to more than just the directing vs. managing debate (e.g. feedback/appreciation), but really hit home for me as an expression of what those of us in the Configuration Management arena need to be doing. We should be directing our colleagues and developers rather than managing them (although we can of course manage actual configurations as before!). We need to get out and about amongst our congregation of developers and others, and infect them with enthusiasm and skills for the delights and benefits of good CM.

There is a huge danger, which I come across fairly frequently, of sitting in your ivory tower wondering why developers aren't doing what you know is "the right thing". They haven't got the message, they aren't doing what they should, and management isn't helping you to beat them up with a big stick to force them into doing it. Sometimes it seems we are just on a hiding to nothing...

In CM we need to aspire to the director (servant-leader) mold - we provide a support service for people to get on with their jobs and we help them do it, but it is they that do (most of) it, not us. There is obviously some level at which CM is still responsible for certain things - in particular processes and systems, and for auditing to ensure things have been done correctly.

Thus I am more and more convinced that, particularly for Agile teams, CM should be the responsibility of everyone not just the CM person(s). This means that as CM professionals our job is:

  • to sell the ideas, principles and tools of sound CM while supporting people in getting their jobs done and delivering value to the business (not just ticking CM boxes)
  • to solve people's day-to-day issues through education and tool/automation support
  • to show how it is easier to do "the right thing" than it is not to do it - a little discipline is worth a ton of lost time due to bugs introduced, or things suddenly not working
  • to get out and about and work with developers, pairing with them and demonstrating good CM practice, discovering those little niggling things that cause lost time and productivity or pain and solving them
  • to ensure that our own working practices are suitable role models (avoid "do as we do not as we say...")
  • to focus on continuous process improvement - there is almost always something more we can do (but again focus on value)

There are many challenges, and in an Agile world, it is more about working with people to define just enough process to be useful, and not too much to get in the way. I was fascinated to hear a vendor representative complaining that some of their customer had developers who were downloading and using Subversion for their day to day work as opposed to using the corporate tool. I wondered what had happened to make the tool or the configured process so unfriendly as to force the developers down this path.

Perforce Branch Naming and Repository Structure Guidelines   19 Jun 07
[print permalink all comment ]

One of the the things that comes up just about every time I go in to do some Perforce related consulting for a client is that of repository structure - how do you map some particular branching scheme (combination of branching patterns) onto the repository?

This of course necessary since Perforce uses the repository structure to represent branches as well as other directory structures. This way of recording branches is feature one might occasionally wish were implemented otherwise, but it does have its attractions, and is the same model as used in Subversion and also Microsoft's new Team Foundation Server product (as an aside, it is perhaps not surprising that Microsoft chose this model since it is a not very well kept "secret" that their in house SCM tool called SourceDepot, introduced during the development of Windows 2000, was a re-badged copy of Perforce. Team Foundation Server is obviously a total rewrite on top of SQL Server, but they seem to be comfortable with the "branch in path space" model).

Some clients need help working out a good branching scheme, and some have relevant experience with other tools so are comfortable with that part, but many need help with the mapping. I have covered a little of this in my article Introduction to Perforce Branching, but this article expands on that.

For their flexibility, I would generally recommend people use branch specs (e.g. created by "p4 branch" command) for branching since you can add view mappings to address not propagating renames, and branch extra components. However, if you can keep the branch spec to a single view mapping then that is great! (Note that the P4V GUI allows integration via drag-and-drop - sometimes convenient, but can be somewhat dangerous...).

Guidelines

A repository branch structure is about creating an appropriate information hierarchy (designing an information architecture). So here are some guidelines that I have found useful over the years and seen successfully used in many organisations (and I certainly didn't invent any of them!). Maybe in the future I can come up with some appropriate pattern like descriptions, but for now, here they are:

  • Standardise naming conventions - make branch directories obvious
  • Keep branch spec mappings and client workspace spec mappings as simple as possible (and permissions)
  • Make it as easy as possible for users (new and experienced) to visualise the branching scheme as they click down through the hierarchy
  • Find the right balance between broad & shallow vs. narrow & deep hierarchies
  • Keep branches of a similar type at similar depths in the structure
  • Make branch directories sort sensibly
  • Plan for the future: 2, 3, 5 years down the line - include things like the year (and optionally month) somewhere in the path to provide a natural sorting.
  • Provide Guidelines and Delegate!
  • Remember - there is no one best solution, but there are many good enough solutions!

Some of what comes below is also covered by Laura Wingerd in her recent book "Practical Perforce" (O'Reilly) - you really need to get this book if you are responsible in any way for Perforce usage at your company! Her quote which sums things up nicely is:

"There is no reason that the repository structure should match the release lineage, but when it doesn’t it causes confusion to new users [and cognitive dissonance to all users]."

Now while I agree with the intent of what Laura has written, I find her suggested option is perhaps a little too restrictive, and it doesn't take into account organisations with many branches at a particular level (and indeed many different types of branches).

Standardise Naming Conventions - Make Branch Directories Obvious

Laura gives a very simple example in her book of naming convention - just use uppercase for the branch component. Thus she has:

//depot/MAIN/...
//depot/REL1/...
//depot/SOME_PROJECT/...
//depot/ANOTHER_PROJECT/...

This is simple and can work very well (although it rather suggests that you don't use uppercase for any other paths which might be unnatural in certain companies for certain items). Another alternative is to append (or prepend) something to the name indicating that it is a branch directory, e.g. ".branch" or or "-branch", or ".br" for those who don't like typing! Thus the above becomes:

//depot/main.br/...
//depot/rel1.br/...
//depot/some_project.br/...

I am happy to have other suggestions recommended!

Sensible Sorting

Directory (and thus branch) names should sort sensibly at any point in the hierarchy, thus

  • use leading zeros for numeric components, such as 01 instead of 1 if you are going to have more than 10, or indeed 4, 5 or 6 leading zeroes where necessary
  • reverse the order of dates using yyyy-mm rather than mm-yyyy

Examples:

//depot/main.br/...
//depot/rel_01_00.br/...
//depot/rel_02_00.br/...
//depot/rel_02_01.br/...
//depot/rel_02_02.br/...
//depot/dev/2007_06_some_project.br/...

Broad & Shallow vs. Narrow & Deep

At any one level the number of choices (sub-directories/branches) should be appropriate and naturally limiting (note that the structure needs to be as useable in several years time as it is now). For example, a structure which ends up with thousands of branches in a single directory will become unwieldy over time. Divide these branches into sub-directories using appropriate naming (and sorting). For example if you wish to create lots of branches for individual change requests then the obvious structure is very wide and shallow at some point in your repository:

~/rel 	/CR000001/...
	/CR000002/...
	:
	/CR000099/...
	/CR000100/...
	:
	/CR009100/... 
	:

Instead of that, try:

~/rel 	/CR0000xx	/01/...
			/02/...
			:
			/99/...
	/CR0001xx	/01/...
			:
	/CR0091xx/	/01/... 
			:

This naturally splits things up and also sorts at all levels.

As a corollary of the above you should split things up even if they don’t have a “natural” dividing component. One alternative is to use the date as an element of the path (or even a prefix) as YYYY or YYYY-MM to give some sort of natural sorting by date. Examples being:

~/2006-01/some_project/...
Or without introducing another level but using a prefix (which is often just a matter of personal preference):
~/2006-01-another_project/...

In 2 or 5 years time it should be obvious to any user which are the which are the “new” ones where they are likely to be spending most of their time, and which are the “old” branches which can typically be ignored.

Hiding or Retiring Old Branches

It is possible “hide” old branches by removing read permissions on those repository paths (leaving them visible to superusers or perhaps an "archive" user). There are some potential performance implications to doing a lot of this (the more lines you add to the protections table the more work the server has to do for commands).

Often the easiest way is just to make them easily ignored via an appropriate hierarchical naming convention as shown above.

Provide Guidelines and Delegate Responsibility

Larger organisations may have a number of teams or units each of which is responsible for products with sometimes quite different lifecycles and thus branching schemes. In these cases it makes sense to set the guidelines and principles and delegate to the teams the work of defining the precise conventions to be used.

Automation

If your repository structure is simple enough and regular enough then it is easy for tools or scripts to:

  • create them (perhaps with input from a user), including adding a mapping to the current client workspace view
  • have triggers that validate that they are being created in the correct place (e.g. don't allow a branch with wrong naming convention to be created in certain directories or levels of the repository). This prevents user error.
  • work out the relationship between branches automatically and thus be able to produce simple reports for things like changes that need to be propagated etc. While this is often done by means of some configuration file (stored in the repository), and indeed this is sometimes necessary anyway, it is easier if it can be automatically deduced from the structure (so that a new branch "popping up" is automatically included into the reporting mechanism).
  • make your protections table easier to maintain

There is No One Best Design!

And remember that this is always true - there are always many ways that are good enough, and the final choice often comes down to personal preference.

However, every type of branch should have a “home”, so that when a user creates a type of branch your CM Plan should have simple guidelines so the user is never at a loss as to where to create one. This requires identifying the types of branches likely to be used.

You need to do enough thinking and planning to get at least 80% of it right. It is of course possible to re-structure your repository (by branching from old name to new name and deleting the old within the same atomic changelist). However, this can cause you quite a few problems if the branch you are re-structuring has relationships with lots of other branches (e.g. release branches being maintained).

People who are aware of the issues and have experience, can slot in a new branch type fairly easily (though they can still end up making sub-optimal choices that they regret).

P4Web Usage and Action Codes   08 Jun 07
[print permalink all comment ]

People ask from time to time how to browse a Perforce repository, and the easiest answer is to use p4web.

Some advantages:

  • It's free, and in browse-only mode doesn't consume extra licenses - which means that you can "publish" changes via your Perforce server to managers and other people who may not normally have a Perforce license.
  • It will "serve up" things like Word documents such that they are typically opened in Word by your browser
  • It can give "canoical" or fixed URLs for documents or other configuration items stored in Perforce, so that fixed references always get the latest versions (as opposed to a file share where it is often unclear which is the latest and if there are any other versions etc)
  • The default URL to get the head revision is very simple:
    • <p4web-base-url>/<document path within perforce without double slash at start>, e.g.
    • http://p4web-machine/depot/some/path/to/document.doc

Example of Accessing a Document

A test document has been setup in the Perforce Public Depot.

The direct URL to load the document is http://public.perforce.com/guest/robert_cowham/test/testdoc.doc 

Alternatively it can be accessed for example with the history via p4web as:

http://public.perforce.com:8080/guest/robert_cowham/test/testdoc.doc?ac=22

Bear Security in Mind

If you setup in browse only mode as a user with access to the whole repository, you may be bypassing other security requirements and protections.

Consider setting up different p4web instances with different access permissions. Putting a separate layer on top of p4web with usernames and passwords, while possible, is likely to lead to maintenance problems.

DNS Alias to keep the URL fixed

If you start referring to a Canonical URL which then becomes used inside documents, make sure that the machine where p4web is running is accessed via a DNS alias so that it can be moved easily without breaking the references.

Also consider having a setup (e.g. via Apache or IIS virtual server settings) where the default web port of 80 is used to avoid ugly port components of the path such as :8080 or some other port  being required.

Parameters

The following were culled from personal experience and postings on perforce-user (by Noah Salzman  and Nick Levine )

Action Codes
10	Changelist Detail
http://p4web.example.com:8080/12345?ac=10

14	Branch Specification
http://p4web.example.com:8080/foo_branch?ac=14

16	Label Spec
http://p4web.example.com:8080/build_tag_123?ac=16

22	Revision History
http://p4web.example.com:8080//depot/main/foo.c?ac=22

64	View Head Revision
http://p4web.example.com:8080//depot/main/rel1/foo.c?ac=64

69	Submitted Changelists
http://p4web.example.com:8080//depot/main/rel1/foo.c?ac=69
http://p4web.example.com:8080//depot/main/rel1/...@build_tag_123?ac=69

142	View Annotated
http://p4web.example.com:8080//depot/main/rel1/foo.c?ac=142

143	View Fully Annotated
http://p4web.example.com:8080//depot/main/rel1/foo.c?ac=143

Note: the single forward slash (versus a double forward slash) is  
important in URLs that do not include depot paths.
107	List Jobs  (p4 jobs)
http://clrfi.alu.org:8080/?ac=107
http://clrfi.alu.org:8080/?ac=107&jsf=Job&jsf=Status&jsf=Date&jsf=Title&jsf=Area&jsf=Priority&ft=status%3Dopen

111	Describe Job (p4 job)
http://clrfi.alu.org:8080/job000005?ac=111
URLEncode the "@" (%40) or "#" (%23), for example, show contents of head rev

//public/jam/src/Build.com#2 is
http://public.perforce.com:8080/public/jam/src/Build.com%232?ac=64 

For #1
http://public.perforce.com:8080/public/jam/src/Build.com%231?ac=64 

For label @jam2-2-0 it is:
http://public.perforce.com:8080/public/jam/src/Build.com%40jam2-2-0?ac=64 

 

Vinterleir 2007 with Suganuma Sensei   19 Mar 07
[print permalink all comment ]

This is a personal review of the Norwegian Aikido Federation (NAF) Vinterleir (winter school), 15 - 18 March in Tromso. Jessica Loeb and myself formed the London contingent - unfortunately Francis and Craig who were due to come too were not able to in the end.

Tromso is a very nice small town in the north of Norway, well inside the arctic circle. At this time of year there is plenty of snow and yet the daylight is a good 12 hours (it is far enough north to range from almost no daylight mid-winter to no real darkness in summer). There is not a vast amount to Tromso, but one of its attractions is that it seems to take about 10 minutes by car to go anywhere, including being out of the town and in some lovely nature.

The Vinterleir is traditionally taught by Bjorn Eirik Olsen (6th dan), Technical Director of the NAF, but this year, in honour of 30 years of aikido in Tromso (which was the first club in Norway at all), they invited Suganuma Sensei (8th dan). He has been 11 times to Norway but always in the south for the summer camp, and I think he very much enjoyed the different surroundings of snow and nature.

This also worked out very well as they have the Doshu Moriteru Ueshiba leading the summer camp in July this year. That promises to be a rather larger affair than usual!

I have actually been half a dozen times to the Vinterleir - there was a period when I went every year, but the last time was 5 years ago - Benedict who is now 4 and a half years old changed life a little!

As ever, the welcome in Norway is always extremely friendly and the atmosphere is a huge part of the success of the camp. Most people stayed with dojo members which was very nice, and in my case, together with Geirr from Oslo, we were kindly looked after by Ingelill.

It was great to see that Suganuma sensei had brought a large party from Fukuoka - nine in all. As was mentioned at one point in the speeches, it was also very nice that the Japanese group were not just fairly senior teachers, but ranged from a 17 year old to a 70 year old, and beginners to a 6th dan.

Suganuma Sensei

The training itself was excellent as usual - very clear and precise. Suganuma sensei's teaching seems to vary very little from year to year, and is very unflashy on the surface and always seems to be oriented towards the basics in these courses. He is always very clear about techniques and gives lots of smaller pointers to particular things to watch out for ranging from use of atemi to positioning for maximum safety during nikkyo.

There are times when this can almost seem a little boring - and it certainly contrasts with Inaba sensei who spends quite a lot of time talking/lecturing during courses can also give some very interesting food for later thought and reflection (although some people find that very boring!).

Suganuma sensei is very attentive during the practice and frequently helps beginners with great patience, including taking ukemi for them to make sure they have understood.

Over the years it has become an interesting exercise to tease out more from what Suganuma sensei is demonstrating, and I was starting to get a better sense of how he uses his body and energy, and feels the connection with his partner. I still have lots of questions about the "shape" of some of his techniques which I can not replicate without expending a lot more muscle in comparison with other ways of doing the same techniques. Something to work on next time.

One very interesting point for me was when he mentioned how often we tend to provoke a negative response from our partners by inappropriate or hard techniques. This is something I am finding very fruitful for my current practice.

I will certainly be back again, although am interested to know if his teaching varies for example in his home dojo(s), although an interview with him implies that it doesn't. It was very useful to practice a little with Tokuda sensei (6th dan) and get an alternative feel from someone who has trained with Suganuma sensei for many years. A very clear use of energy and sense of sticking and controlling in some techniques. I would love to arrange a visit on a future trip to Japan. For me a lot of the interest is because of the contrast with Inaba sensei - two very inspiring, but very different, teachers.

My Class

Due to the number of people on the course and the size of the main dojo not being sufficient to accommodate everyone, people were divided up into groups and roughly a third went off for a separate class at various points. I was asked to teach one of these and had some fun doing it.

I taught a somewhat relaxed and very much feeling based class rather than technique based, mainly because this is what I am finding most interesting in my personal practice at the moment. We started with some breathing exercises, breathing out and sucking the belly in, and then rotating the hips to drop the tanden/belly forward and using this to allow a fast in-breath, but with no hint of force or strain. It is important to feel as if breathing first into the belly and not fill the upper chest, or at least not let stiffness in there. Also there can be a temptation is to "sniff" which tends to stiffen the body - I find it much easier to do with an open mouth. This exercise certainly seemed a little strange at first, but I then built on it to show some simple techniques, e.g. from katatedori, where I find that an out-breath to absorb your partner's attack/energy, followed by a quick in-breath seems to release some energy upwards which makes it much easier to lift their arm and indeed their energy.

I then focussed on keeping very soft and relaxed arms and shoulders while performing simple koky-ho from ryotedori (2 hand grab) or tenchinage, and allowing the arms to drop in a very relaxed manner without any sense of strain or pushing.

People seemed to enjoy it (after the initial confusion perhaps on the breathing and where I might be going with it!) and I had several appreciative comments afterwards which is always nice. My sources are mainly Inaba sensei's teaching regarding the breathing, and Peter Ralston's book "Zen Body-Being" for a fascinating approach to relaxation and effortless power which I am finding very rewarding to study.

Grading

I missed the kyu grading, but watched the dan grading on Saturday with interest: three shodans and two nidans, of whom I knew 4: Vegard, Steinar, Haakon and Kai Hare. The shodan grading took a good 20 minutes or more - any number of techniques being required to be demonstrated. Somewhat unnecessary in my opinion, but then Inaba sensei does rather tend to an alternative approach others find not rigorous enough. Interestingly the nidan gradings were shorter, since the requirement to work through the basic techniques was dropped in favour of a more free style approach. The candidates all did very well and deservedly passed. A nice surprise at the end was when Stein-Are Engstad was called out - he seemed very surprised and didn't know quite what was going on only to be awarded his yondan.

The Party

As always the party on Saturday night was a great success, and this year was held in Polaria (the Polar Centre) - one of the main tourist attractions in Tromso. The food was delicious and there were some very good speeches around the celebration of 30 years. Birger Sorenson was present who started the club in Tromso as a 4th kyu back in 1977. In that first group were Bjorn Eirik and Kore (both present) so we were treated to a few reminiscences of life back then (including some slightly alternative views of exactly what did go on!), and a little earlier in the evening a slide show of some photos over the years.

Suganuma sensei also spoke, and offered his congratulations. He also mentioned that in the summer camps a few years ago I had asked him the question "What was the most important thing in Aikido?" He answered that it was musubi or connection. A couple of years later, I asked him the same question, not wishing to catch him out, but genuinely interested if he had changed his mind or not. When this was pointed out to him at the time, he saw the funny side, and this year saved me the trouble of asking it again by saying that he still thought musubi the most important thing!

I realised that he had demonstrated the importance of "connections" off the mat as well - it is one of the qualities that make him the very impressive man that he is. You don't build an organisation of 100 or so dojos over 30 years if you can't establish and more importantly maintain good connections with people. There are lots of aikido teachers who are technically very capable, but very few who have the personal qualities and lack of ego of Suganuma sensei. I am sure that his many years of study of zen alongside his aikido has had a large influence.

The dancing afterwards was ably lead as ever by Bjorn Eirik and Birger Sorenson! Having been kicked out at 1am those of us who were left walked through the centre of a still buzzing Tromso, and while the main diehards went to the "Fun Pub", a smaller group of us enjoyed a beer at a slightly quieter local. The morning did however roll around rather early!

Touristy Things

The hosts had arranged a visit on Sunday morning for the Japanese, and Jessica and I tagged along. We took the cable car up the mountain on the mainland (to 420m), and were met by a couple of Sami (Lapp) hosts who gave us a reindeer sleigh ride and some coffee in a "lava" or tepee like tent. It seemed rather touristy and kitsch at first, but thanks to the really friendly and genuine guides turned out to be a lot of fun. The reindeer sleigh rides were only a quick circuit of perhaps 200m, but my ride became a touch more interesting when in response to my question "do you ever race?", much encouragement was given to the reindeer who promptly got over excited and veered off course heading for his mates down the hill. It turns out that reindeer don't like to be touched, and aren't terribly easy to control - starting out consisted of pulling the reindeer forward with them initially resisting, and then turned into a quick sprint and a leap on to the sledge as the reindeer suddenly bounded off!

Our hosts were young guys whose family apparently has some thousands of reindeer in their herd who spend the summer around Tromso (from April onwards), but they winter about 100km further south and inland where the climate is drier and the snow easier to dig for lichen/moss in. They were very friendly and enthusiastic with their explanations on details of dress and life, and it was very enjoyable. The only problem was that our time was a little limited and it would have been great to have a walk after lunch given the great weather up there.

Conclusion

A great course, leaving me feeling rather well exercised, and with some more happy memories to add to the store associated with Norway. Thanks to Bjorn Eirik and all the other members of Reimeikan.

 

Copyright © 2008 Robert Cowham