Planet TW

Simon Brunning: Links for 2009-11-13 [del.icio.us]

Sat, 14 Nov 2009 08:00:00 +0000

Sumeet Moghe: DevLearn 2009 - The Changing Learning Function: Rethinking how your organization works

noreply@blogger.com (Sumeet Moghe) — Sat, 14 Nov 2009 06:19:05 +0000

The last session from DevLearn 2009 that I sat through was the one by David Mallon from Bersin & Associates, called "The Changing Learning Function: Rethinking how your organization works". David was presenting empirical evidence from 798 Organisations and 40,000 training and HR business leaders and using Bersin's analysis about what the new face of the learning organisation should be like.

What I learnt

Why are we talking about all of these new technologies? Its because business is changing and that's forcing businesses to rethink what we do in each of our departments and that includes learning and development, knowledge management, and the like. Are all the thinks we knew about our job really as good and are we using ourselves in the best way for our organisation?
The problem is context, not content. Its everyone's responsibility to deal with information and act on it. Everyone is a knowledge worker and the overwhelming amount of information floating around. Its tough to find the most useful information.
We need to reuse and have some set of standards to be successful. Frequent change of information makes it difficult to find the most current information. Inconsistency of information formats or sources makes it difficult to use and comprehend new info.
Learning professionals have the ability to create the context and the standards that organisations really need.
The ongoing role of a modern enterprise L&D function is two fold:
- Deep Specialisation:Focus on your company's niche. What's your competitive advantage?
- Learning Agility: At an organisational level, how quickly can you add new skillsets, learn from your mistakes and create new capabilities.
A change is needed: Large and midsized organisations are still spending most of their learning time in their classrooms. Technology enabled learning is gaining strength each year, but very slowly. Having said this, most leaders believe that on the job experience, mentoring, projects, job rotation, and coaching are the most valuable learning approaches. 72% companies believe that the most valuable learning approaches are informal, yet only 30% of resources are focussed in that area! So, we need to optimise the informal learning in organisation and not just the classroom.
The modern learning organisation should be structured in the following framwework:
- Your Learning Programs addressing your Audiences and Problems
- Your Approaches and Architecture:
  - Formal Learning: 20%
  - Informal Learning: 80%. This includes
    - On-demand Learning: Elearning, help, search, books, etc
    - Social Learning: Blogs, wikis, forums, communities, social networks, etc.
    - Embedded Learning: All the ways that we learn inside work. eg: Performance Support, Feedback, Rotational Assignments, Course Corrections, Retrospectives, etc.
- The Disciplines that people need to master to adopt these approaches
- The tools and technology that support these disciplines
- But most importantly, beyond all of this, under the hood -- there's the culture of the organisation.
The Modern Enterprise Learning Index (MELI) is a set of 10 indicators to determine readiness/ capacity to support learning agility and thrive in the face of informative change. (Internal Indicators: Capacity Building, Business Analysis, Content Efficiency, Adaptation, Versatile) (External Indicators: Business Driven, Talent Linked, Timely, Targetted, Proximal)
Retention after training events is high, but it drops over time and so does expertise. Learning is a process and not an event, so informal learning create a series of events that helps people learn over time. How about blending informality into formal learning by leveraging online communities, and by using tools such as Job Aids (Standard Work), Forums, EPSS, etc. David showed a case study from Nationwide insurance in how they blended informal learning around a large formal program to help a major capabilities shift for the company. IBM Blue Pages was another example that David showed as an enterprise wide collaboration system.
Coaching is a highly underestimated way of creating learning over time.
I loved the case study of BT that he showed where they were looking at Formal Learning supported by Social Learning, developed by anyone, using segments lasting minutes, delivered by anyone, given just in time, pulled and in real time and was dynamic and adhoc (long sentence, I know!) This apparently built reputation and people wanted to contribute to be known as "the guy". The community flags inappropriate content and there's hardly ever been anything that they had to pull out.
David lastly looked at the Disciplines we need to engage in as Learning professionals to make our organisations successful. He had culled this using data from the 10% of the most successful companies he had surveyed
- Knowledge Management: Develop overall strategies for capturing and harnessing the collective knowledge of an organisation.
- Business Intelligence/ Analytics
- Information Architecture: Structuring information to make it easy to find. Stop paying attention to a single course, but pay more attention to the learning experience. This involves thinking spatially across contexts.
- Performance Consulting
- Development of Rich Media (information, visualisation, etc)
The role of a Training team: "Center of Excellence for Learning in the organisation". Focus on capabilities (preparing for tomorrow) as against skills (preparing for today).
New Roles in the learning organisation:
- Performance Consultants
- Instructional Designers
  - Work out in the biz, teaching others to structure knowledge;
  - Supervise SMEs.
  - Add additional disciplines to create environments
  - Be masters of the business
  - Measure approaches in business terms
  - View fast/ efficient business performance/ improvement as ultimate expression of their ablities.
- Content Developers
- Multimedia Specialists
- Information Architects
- Editors/ Production Support
- Community Management
- Content Stewards
- Moderators
- Program Managers
- SME's

Mark Needham: Mercurial: hg bisec

Sat, 14 Nov 2009 01:20:13 +0000

We've been using Mercurial locally on the project I've been working on and Phil showed me a cool feature called 'bisec' a couple of weeks ago which can be helpful for working out which revision we managed to break our code in.

It's been ported across from Git and is included in Mercurial from version 1.0.0 rather than just being an extension.

From the bisec extension page:

Its behaviour is fairly simple: it takes a first revision known to be correct (i.e. without the bug) and a last revision known to be bad (i.e. with the bug). The bisect extension ouputs a revision halfway between the good and the bad ones and lets you test it. If this revision is a good one, you mark it as good with hg bisect good, otherwise you mark it as bad with hg bisect bad. In both cases, bisect outputs a new revision to test, halfway between the good and the bad ones. You repeat until only one revision is left: the culprit.

The usage has changed a bit now that it's included as part of the initial download.

I was working on something yesterday and checking in fairly regularly before realising that I'd broken something.

I was fairly sure that the break had happened in the tip (revision 98) but I could only remember it definitely working in revision 96.

I defined the good and bad revisions like this:

hg bisec -b tip

hg bisec -g 96

In this case revision 97 was now checked out and I checked that the code was working with that revision before marking it:

hg bisec -g

It's now able to work out that the problem is in fact in revision 98:

The first bad revision is:
changeset:   98:86260809c309
tag:         tip
user:        mneedham
date:        Fri Nov 13 16:31:02 2009 +1100
summary:     seem to have screwed up the graphs. Not sure how

I managed to mess up setting up the good and bad revisions a few times – I somehow had the impression that I needed to manually update to the original good and bad revisions which isn't the case.

The reset command was my friend before I worked out what I was doing wrong:

hg bisec -r

It seems like a neat little feature. I'm sure there are lots of other cool things like this in Mercurial so if you know any let me know!

Sumeet Moghe: DevLearn 2009: Yawn-Proof Your e-Learning without Busting the Bank

noreply@blogger.com (Sumeet Moghe) — Fri, 13 Nov 2009 19:05:24 +0000

Stephen Walsh and Cammy Bean from Kineo put together an interesting session on how you can create engaging elearning without really burning a hole in your pocket. Cammy and Stephen are friends and I really enjoyed their session. They put together some great examples of elearning that were, let's just say quite stunning! There were some great takeaways for attendees and I've summarised that in this blog.

Key Takeaways

Things that bore people:
- Navigation;
- Text Heavy;
- Endless videos;
- Talking heads
- Cookie cutter approach to design;
- Locked navigation; violating basic rights of freedom;
- Systems simulation;
- Patronising or elementary content;
- Monotony and Redundancy;
How to design rapidly:
- Show, don't tell: Get a prototype out as soon as possible; "Get it wrong first time, and iterate from there."
- Get in front of users as soon as you can;
- Keep a playlist of ten tracks of design.
Stephen introduced to the audience his Ten tracks of design:
1. Hit me with your best shot: Use stories that show what can go wrong. Find the killer fact, stat or quote. Learn from your marketing team.
2. Give me a Reason: Object to learning objectives. Instead of a dozen boring learning objectives, try a lead-in video and show what normally happens and then point out how this will solve a problem that your learners will face.
3. Getting the best stories: Get war stories from your best people and get true stories from your newer people. Don't just go to your senior people -- ask people in the trenches, so that way people who go into this training will actually relate to the real situations. Audio interviews over Skype were a great idea Stephen put forward.
4. Tear down the wallpaper: Use purposeful graphics. Make them earn their place. "Decoration isn't design."
5. This is assessment in the real world: Make it tough as hell. Make it open any time. Do it, prove it, move on.
6. Make more mistakes: Find the mistakes that hurt the most. Simulate them in elearning. Keep them real, play them out. When you're providing feedback provide more than just incorrect/ correct observations, add context about why a choice is appropriate or not.
7. A little less conversation, a little more action: Simplicity is tough, cut your training to the bone. Watch out for dialogue amongst characters. Keep text to a minimum and tone it down to the absolute key message!
8. What more can I do?: Think outside the course -- create a learning campaign. Reach out with online support - don't do everything through elearning! Don't get caught up in the technology, think about the problem and the solution. What's are the different ways to spread the word, the simplest way to get learning out, and the most effective way to get them engaged.
9. Keeping it real: Make the most of media and use audio and video where it counts! Use real people and film them (think of doing it secretly, so people aren't conscious!). When people's identities are at risk use a witness protection style by blurring people's faces out. Video is proven to be the most effective medium for behavioural skills.
10. Now what?: The end is the beginning. Call to action and then don't let go! Build in ways to sustain performance and link into your LMS and Knowledge Management System to access follow up activities and resources. Leverage communities of interest and people's desire to be altruistic.

Sumeet Moghe: DevLearn 2009 - Leo Laporte's keynote on New Media

noreply@blogger.com (Sumeet Moghe) — Fri, 13 Nov 2009 17:48:13 +0000

Again a great storytelling keynote by Leo Laporte, arguably the czar of New Media. Leo touched upon the stories of his life and the shift from advertising driven mass media to content driven new media where he's trying to be the "CNN for Geeks". Great wisdom and since some people liked my mindmap from yesterday, here's another one. Please click on the image for a larger size. As Leo said, "Its a river of information, dip your foot in whenever its convenient."

Patric Fornasier: Lessons Learned (Part 2: Performance Testing and Garbage Collection)

noreply@blogger.com (Patric Fornasier) — Fri, 13 Nov 2009 15:14:46 +0000

This is a continuation of my previous blog post. The goal is to sum up some lessons that I've learned during the last couple of months while I was involved in performance tuning a large-scale distributed web-app.

Golden Rules

Although there are probably many more rules and good advice out there, these are the ones that I remember off the top of my head as being important:

Change one thing at a time

I often found myself very tempted to violate this rule. The problem with breaking it, however, is easily illustrated with an example: Imagine that you make two changes, c1 and c2, at the same time. If c1 results in a performance improvement of 20% and c2 in a performance penalty of 30% you'll get an overall performance deterioration of 10%. Consequently, you'll decide not to implement any of the changes, even though c1 on its own would have resulted in better performance.

Look at the system as a whole and fix the slowest running part

Even if you can make some part of the system thousands of times faster, it will not affect you application performance if the part you changed was not your primary bottleneck. For example, it doesn't make sense to optimise application code if the bottleneck is the result of a slow running database query. I'd even go as far as saying that it is harmful to optimise parts of the systems, when it's not needed. Firstly, it's a waste of time that could be used for tasks that provide more value. Secondly, making performance optimisations often introduces additional complexity at the code level. If you can't justify this extra complexity with a significant performance boost, don't do it. Of course, I'm not advocating against common sense and sound software design principles. For example, I know that making lots of fine-grained RPC calls is a bad idea, so I'll avoid it in the first place.

Don't optimise prematuerly, i.e. without measuring

This one probably goes hand in hand with the rule above. Don't optimise unless you can prove that it will have an effect on overall system performance. Again, this rule is not an excuse for not using sound software design principles.

Performance Testing Cycle

Keeping the above rules in mind, we continuously iterated through the following cycle:

Measure performance
Identify single bottleneck (i.e. pick lowest hanging fruit)
Fix single bottleneck
Verify performance has improved

Once step 4 is complete, the cycle restarts. Sometimes, we would loop through this cycle several times a day. Other times, one loop would take us several days or even weeks. This process essentially continued until our release target was reached.

Measuring Performance

We used JMeter to generate load against the application under test. We set up the tests so that the generated load would increase over time and therefore put the application increasingly under more stress. While running the tests, we measured a number of parameters. The most important ones were throughput, average response time and CPU utilisation.

Looking at charts similar to the ones shown below, we got a fairly good understanding of how much load the application under test could handle.

In the above charts, for example, you can see that, at some point, application throughput reaches a plateau while the average response time per transactions continuous to grow. At this point, the application reached some physical or logical limit that prevented it from doing more work. The challenge, of course, is to find out what those constraints are in order to increase throughput or reduce response times.

Identifying Bottlenecks

Bottlenecks created by hardware constraints are normally quite easy to identify. Usually, the symptoms are maximum CPU utilisation, reaching network bandwidth limits, etc. The solution is often to change and restructure application code. Identifying bottlenecks not directly created by hardware constraints is more difficult. Likely causes are slow running external systems, resource starvation, suboptimal configuration settings, etc.

In the last project, we eliminated the hypothesis that slow running external systems are constraining our system quite early by taking them out of the equation completely and using stub implementations instead. At the same time, this made our performance tests much more robust, reliable and faster.

Fixing Bottlenecks

In the first few weeks of our performance tuning initiative, we made quite a lot of progress. There were a large number of easily identifiable bottlenecks which were relatively trivial to fix. These included simple programming errors, unnecessary database calls, unnecessary network calls, slow running SQL queries, no caching where data was easily cacheable, concurrency issues, etc.

After some time, however, it started to get more difficult to identify bottlenecks. In particular, there has been one case that I think is worth writing about.

Garbage Collection

We had already spent several weeks trying to identify a bottleneck, which was not obviously caused by hardware constraints. Here are the things we noticed:

Throughput reached a plateau at point t
Response time grew significantly at the same point t
Hardware was far from being exhausted. CPU utilisation, for example, was about 60% at point t
Although total CPU utilisation was around 60%, one (of eight) cores was maxing out occasionally

The last point was indicative that there was probably a CPU-intensive task executing in a single thread, hence single core. One such task that we could think of was garbage collection. We verified this using Perfmon and found that GC was indeed taking up a large amount of processing time (up to 30%).

As a result, we did some reading on how .NET GC works. We've learned that, by default, the GC is optimised for standalone apps running on single-core machines (called Workstation GC). On multiprocessor machines, however, there is an additional GC mode available (called Server GC). The difference between the two is basically that the latter creates a separate GC heap and GC thread for each processor and that collection occurs in parallel. Here's the change we made to our configuration:



<configuration>

  <runtime>

    <gcServer enabled="true" />

  </runtime>

</configuration>

After making the above configuration change, the throughput of our application increased by almost a factor 3! At the same time, we were again reaching 100% CPU utilisation and average GC time was down to 2-3%.

Of course, this dramatic change meant that we were dealing with a completely new application profile. Consequently, we restarted our iterative cycle described above again from beginning in order to find the next bottleneck.

Conclusion

The fundamental prerequisite for doing effective performance tuning is to have a set of repeatable and reliable performance tests. Ideally, these tests are easy to execute, finish in a reasonable amount of time and give you rapid feedback with regards to how the application is performing. Also, you'll need an isolated environment, which allows you to deploy new versions of the application easily and frequently. This gives you a good platform to experiment with changes. Measuring the difference between these changes with respect to the overall application performance then gives you the ability to make informed choices.

Mark Needham: TDD: Combining the when and then steps

Fri, 13 Nov 2009 14:17:57 +0000

I've written before about my favoured approach of writing tests in such a way that they have clear 'Given/When/Then' sections and something which I come across quite frequently is tests where the latter steps have been combined into one method call which takes care of both of these.

An example of this which I came across recently was roughly like this:

@Test
public void shouldCalculatePercentageDifferences() {
	verifyPercentage(50, 100, 100);
	verifyPercentage(100, 100, 0);
	verifyPercentage(100, 50, -50);
}

private void verifyPercentage(int originalValue, int newValue, int expectedValue) {
	assertEquals(expectedValue, new PercentageCalculator().calculatePercentage(originalValue, newValue));
}

This code is certainly adhering to the DRY principle although it took us quite a while to work out what the different numbers being passed into 'verifyPercentage' were supposed to represent.

With this type of test I think it makes more sense to have a bit of duplication to make it easier for us to understand the test.

We changed this test to have its assertions inline and make use of the Hamcrest library to do those assertions:

@Test
public void shouldCalculatePercentageDifferences() {
	assertThat(new PercentageCalculator().calculatePercentage(50, 100), is(100));
	assertThat(new PercentageCalculator().calculatePercentage(100, 100), is(0));
	assertThat(new PercentageCalculator().calculatePercentage(100, 50), is(-50));
}

I think we may have also created a field to instantiate 'PercentageCalculator' so that we didn't have to instantiate that three times.

Although we end up writing more code than in the first example I don't think it's a problem because it's now easier to understand and we'll be able to resolve any failures more quickly than we were able to previously.

As Michael Feathers points out during Jay Fields' 'Beta Test' presentation we need to remember why we try and adhere to the DRY principle in the first place.

To paraphrase his comments:

In production code if we don't adhere to the DRY principle then we might make a change to a piece of code and we won't know if there's another place where we need to make a change as well.

In test code the tests always tell us where we need to make changes because the tests will break.

Jie Xiong: 三人成众

Fri, 13 Nov 2009 11:20:47 +0000

一个人是孤单的，就像“人”字，只能自己支撑自己。

两个人的团队，如果不是互相对立的话，就难免有一人比较强势。如同一个“从”字，主从关系往往确定下来就不易改变。

四个人或更多人的团队，就常会分裂成小帮派。

三个人的团队是个绝配。三人成“众”，既互相支撑，又互相平衡，均势来回变，难有某一人永远强势。一起出现，三人不显太多；分开行动，一人两人可以灵活配置。

而且争吵能得到有效控制。一旦两人出现争执，另一人便可客观评判，居中调停。而且这次的旁观者下次就可能成了争执的一方，这次的争执者下次又换了调停的角色。于是每个人在身涉争执时大可各执一端畅所欲言，因为信任旁观者已有准备平息战火。于是争执也常被带往健康的方向。

所以如果去陌生而紧张的环境工作，三个人的团队是很好的选择。

Patric Fornasier: RSpec and TextMate

noreply@blogger.com (Patric Fornasier) — Fri, 13 Nov 2009 11:09:40 +0000

Just struggled to get the RSpec bundle working with TextMate. After installing the bundle as described on the RSpec site, I kept getting the following error message:

Library/Application Support/TextMate/Bundles/RSpec.tmbundle/Support/lib/spec/mate.rb:4:in `join': can't convert nil into String (TypeError)

After a few hours of fruitless searching on the web, it occured to me that I should maybe have a look at the file listed in the error message above (mate.rb:4).

File.join(ENV['TM_PROJECT_DIRECTORY'],'vendor','plugins','rspec','lib')

The bundle basically failed, because the TM_PROJECT_DIRECTORY variable was not set.

So, instead of trying to run the file in standalone mode, I pulled the spec file into a new project (⌃⌘N) and ran it again.

Et voilà. No errors this time round. ...and thanks so much for the helpful error message, RSpec-TextMate-bundle! *grrr*

Simon Brunning: Links for 2009-11-12 [del.icio.us]

Fri, 13 Nov 2009 08:00:00 +0000

The Limits of TDD
Doom, The Roguelike
Marina Hyde's interview with Charlie Brooker
Net.Data programs for the HTTP Server
Writing great documentation: what to write

And Jacob knows whereof he speaks; the Django documentation is exemplary.
What they don’t tell you about user stories
Writing great documentation: technical style
iSeries DocFinder
IBM i For Power Systems including AS/400, iSeries, and System i
In The Seventh House
Google's New Language: Go

Lots of detail here.
Google Wave Cheat Sheet

Felix Leipold: Using Extension Methods

Fri, 13 Nov 2009 00:06:46 +0000

I came up with the following extensions method in C#:

 
public static class NeatExtensions{
    public static bool In<T>(this T element, params T[] elements){
        return new HashSet<T>(elements).Contains(element);
    }
}

It actually yields a nice syntax for checking enum values and the likes:

 
enumValue.In(Enum.X, Enum.Z)

I am wondering whether there is actually a de-factor standard library in the C# world that has extensions like this.

Sumeet Moghe: DevLearn 2009 - Web 2.0 and Performance: What's working for Google employees

noreply@blogger.com (Sumeet Moghe) — Fri, 13 Nov 2009 00:06:20 +0000

The last session I attended today was by Julia Bulkowski and Erika Grouell from Google about how they're leveraging Web 2.0 technologies to help drive performance in their company. Again, nothing new given that Google's products are all free for public use. This said, it was a great reinforcement of how much you can do with just one integrated (single sign-on suite).

Key Takeaways

Culture is key to adoption of Web 2.0 technologies.Google and ThoughtWorks have very unique cultures that are geared towards rapid technology adoption, minimal access barriers and hierarchy and a lot of companies still need to figure out the best structure to make Enterprise 2.0 adoption succeed.
A clever use of blogs and discussion forums: Practicing and reviewing transactional skills like writing and email communication.
A clever use of Google Code Labs: Leverage fellow software developers to learn a programming language. Use Google Code labs to provide code snippets to learn practical styles and patterns of programming. Very wiki like, especially with revision history and crowdsourced descriptions. This makes experts visible and lets new developers ramp-up quicker.
A clever way of sharing instructional resources: Create a Google Wave and embed it into your class homepage. People can discuss the problem amongst themselves, but at the same time make a private submission to the instructor if this was an assignment, test, etc.
A clever use of online photo and video sharing: Sharing howto's, tips, screencasts, tutorials. Take a look at YouTube's Google Apps Channel. As a social tool as well, users can create their own tutorials, etc and they could do videos of themselves doing presentations and get feedback from each other.
Clever way of preparing for a session, panel discussion, conference talk: Use Google Moderator so participants can brainstorm questions for the session. Helps you prepare as a speaker as well.
Providing Web 2.0 services in the enterprise is a way of reducing your risk. If you don't, people will in any case use these tools outside and then you don't have any control and have in a way increased your own risk!

Sumeet Moghe: DevLearn 2009: Catch the WAVE: Google WAVE and e-Learning Applications

noreply@blogger.com (Sumeet Moghe) — Thu, 12 Nov 2009 22:58:12 +0000

This afternoon I sat through Adam Mash's (? I think that's his name) session on Google Wave. Being a Google Wave tester, nothing that he said was new for me except he highlighted a few things worth reiterating.

So what should you know about Google Wave

There are some really interesting uses for Google Wave:

Collaborative creation of documents, reports, observations, requests
Group/ Afilliation rosters;
Agenda, meeting minutes, to-do list combos;
Collaborative proposal Writing and approval;
Collective visioning and brainstorming;
Getting to know you style stuff
Fun, special interest conversations

A few things that people may not know about Wave

The complete wave guide -- all there is to know about Wave
You can create and access public waves. You can explictly choose to follow public waves.
Wave is an open protocol, so it is possible to create custom clients to interact with Wave.
Just like every other Google Application, Wave is extensible and there are already quite a few extensions in play for Google Wave, that will make it a fully featured collaboration platform whenever it is out.
It is not possible to remove people from a wave, yet.
Support for mailing lists and groups isn't great yet. Actually its almost non-existent.
There's a twitter feed for google wave at #googlewave

Mark Needham: Adapting our approach for the context

Thu, 12 Nov 2009 20:34:00 +0000

Amongst the many posts written recently about unit testing one which I quite liked was written by fallenrogue where he describes how in different contexts/cultures a different approach is favoured which means a technique like TDD might not work so well.

cashto, the guy who wrote the original post, agrees with this in the comments on that post:

Absolutely right. I write apps on mobile devices in C++. What works for me may not work well for someone who designs websites with RoR, and vice versa. Context definitely matters — it was one of the points I was trying to get across.

Recently I've started noticing that it's quite beneficial to consider the context that we're working in for all sorts of approaches we might want to take.

Immutability

When I was first playing around with F# I liked the idea of having everything in the code being immutable and I decided that it would be interesting to try and apply that idea to the code I wrote in C# on the project I was working on.

Unfortunately it didn't work out as well as I'd hoped because it requires more code to do that, it's not really idiomatic C# so it was confusing to my colleagues and we ended up having objects hanging around which weren't updated with the latest state changes because I'd forgotten to re-assign the variable to the new instance.

I still think that we could probably make more use of value objects in our code but I'm not convinced that aiming for immutability everywhere when using C# is the way to go.

If it was a different context such as a problem we were trying to solve in Haskell or to a lesser extent F# then it would make perfect sense.

Confidence changing code

Another example of this is the confidence that we can have in making changes to the code base.

I've worked on projects where there's been a lot of test coverage across the board and also ones where there wasn't.

With the latter we'd have to put some time in to get tests around that code before thinking about making big changes.

If we don't have the time to do that then we need to be quite careful when changing code since we don't have a quick feedback mechanism to let us know whether we've broken anything or not.

Final thoughts

Corey Haines wrote a post on pragmatism about a month ago where he suggested the following:

Often times, people use the term 'pragmatic' as a way to hide a lack of skill and experience. Or, sometimes, it is used in ignorance: someone doesn't realize that they don't understand something well enough. Usually, though, it is brought to play when someone is justifying cutting corners on something.

I think this applies when deciding that an approach isn't useful in our context. We need to be careful that we're not just making excuses for our lack of skill in that area.

When I first started working professionally in software development I was fairly convinced that there would be an optimal approach to take in every situation that I just didn't know about yet.

A few years later I've come across a lot of really good approaches to solving problems but no approach that is applicable across the board.

Dan North: The lady in the taxi – a parable of metrics

Thu, 12 Nov 2009 20:15:51 +0000

Once upon a time there was a lady in a taxi. It took such a long time for the lady to get to her destination in the taxi that she went to the town hall and told the man from the council. The man from the council wanted to figure out why the taxi journey was so slow, so he placed cameras at all the traffic lights in the town to measure how many cars went past, and how quickly. The traffic light cameras would click every time a car went past the lights.

He wanted to speed up the rate of cars, so he changed the layout of the town. He figured if he introduced a one-way system the traffic flow would be more efficient. This confused the taxi drivers and they started to get lost. The taxi driver would go past a light, click, discover he couldn’t go the way he wanted, try to find a way through and find himself going back past the same light, click, realise he had been this way before, turned around and drive back through the light, click, and would still not find his way to the lady’s destination. The new one-way system was good at moving cars around – it just wasn’t very easy to navigate. And just as the taxi drivers were learning the new layout, the man from the council would try a new layout just in case.

What a lot of clicking, thought the man from the council, and what a lot of cars must be driving through my town. How efficient this is! I shall invite more cars into this town because it is so efficient at moving cars around.

So he invited more cars into the town, which of course just clogged up the streets. Every time the light would go green, a line of cars, nose-to-tail, would crawl through the lights: click, click, click! When they were past the lights, they would sit stuck in traffic. Sometimes the taxi drivers would get so fed up they would just abandon the journey and make the lady get out of the taxi. Of course she would have to pay for the journey so far. And wait for another taxi. And get in and try to resume the journey. (She often had to go a way back up the road to find another taxi.) Same lady, same journey, different taxi, back through the same lights. Click, click.

The taxi drivers realised they were losing money by spending all day in traffic jams, so they decided to have two kinds of tariff. When the taxi was moving they would charge by the mile. When the taxi was stopped, they would charge for waiting. What a clever idea!

This made the lady very upset. It is taking me longer than ever to get to my destination, she thought, and it is getting more and more expensive because it is costing me money just to sit here.

She sighed and looked out of the taxi window, and saw the cameras at the traffic lights. Then she realised what was happening. The poor man from the council thought that each time the same taxi went past the light, it was a different vehicle! He thought that when different taxis were taking the same lady to the same destination, that it was different jouneys! He probably figured that having lots of cars going through the lights meant they were travelling quickly!

Then she had an idea. I shall take a camera in the taxi she thought, and I shall show the film to the man from the council. So she took a camera in the taxi (and cleverly recorded the taxi meter at the same time). Look at this, she said to the man from the council. Ths shows you my experience as a passenger in the taxi. I move from red traffic light to red traffic light, crawling through the lights in a little batch of cars, queued up behind the next traffic light. I don’t mind paying for the mileage, but I don’t think I should have to pay just to sit waiting to go forwards. And to make matters worse, the journey to my destination is taking longer and longer!

Oh my! said the man from the council. I’ve been looking at the wrong thing all along. Instead of trying to maximise the amount of cars that go through a particular light, I should try to minimise the amount of time it takes you to get to your destination! How silly of me.

Oh, and perhaps I should pay you if you have to sit there in a taxi because my town is all backed up with traffic. At least then there would be an incentive for me to work on the most blocked-up parts of the town. Perhaps they are the only places I should be concerned with anyway, because by unblocking the most constrained parts I will probably have a better flow of traffic altogether. And perhaps when a particular street is backed up, I should stop more traffic coming in and causing traffic jams.

Thank you! said the lady. I now feel like you really are going to be able to help me to get to my destination quicker. I know it won’t happen overnight, but I am sure that over time my journeys will be faster. That’s quite alright, said the man from the council. Thanks for teaching me to look from the point of view of a passenger in the taxi, and not just to take snapshots from the different stages of the journey.

And they all lived happily ever after.

Thanks to Oliver Schreck for the idea that led to this story.

Sumeet Moghe: DevLearn 2009 - Eric Zimmerman's Keynote on "Meaningful Play"

noreply@blogger.com (Sumeet Moghe) — Thu, 12 Nov 2009 18:19:23 +0000

I can't attempt to summarise Eric's keynote, also because I feel woefully inadequate to be able to tie together the thousand pieces of wisdom and interconnections that he through out in the speech. My slow brain's going to take some time to process this information. But anyways, I did a mindmap while Eric was presenting, and I'd like to share it with you. Here you go! Click on the mindmap for a full-size version, because I imagine it'll be impossible to read at this size. Again, its a very personal note-taking approach, so I don't imagine it'll be most intuitive.

Paulo Caroli: Most if-statements are evil

noreply@blogger.com (Ralph Jocham) — Thu, 12 Nov 2009 12:04:21 +0000

I’ve really come to loath if-statements. It developed over time. At the very beginning they are great as they give you the power to put some logic into you application. Usually a small program in one of your first programming classes. Well, over time I realized the hard way that they clutter your code and make it harder to read and hence understand and maintain. In OO languages you have far more powerful ways to put logic into your application without using if’s. However, this requires a good skill in programming and lots of practice. I’ve come to realize that you can identify a good programmer by her if-avoidance skill. Well, after some time in acceptance but dislike I now try to avoid them at any price and so should you. By the way, I consider switch-statements to be nested if’s.

Frederick Brooks coined once the terms ‘Essential Complexity’ and ‘Accidental Complexity’. The first describes the real complexity which comes from the domain and the problem to solve. The second one is manmade i.e. it is the complexity we get into by our own making like which OS, which language, which framework, … we choose. Using this point of view, there are essential if-statements and accidental if-statements. The accidental ones, what a fitting name, are the ones which need to be eliminated.

Essential if’s

There are things you need to check. Can I save the file, is there enough free disk space.



if (diskHasEngoughFreeSpace()) {

document.save();

}

Those decision are driven from external forces and are out of our control and so we need to check them every time we save.

Accidental if’s

Those buggers creep up everywhere in you code.



if (date == null) {

date = new Date(); // this is called defensive programming, one of the worst things you can do

}



if (date != null) {

uiWidget.setText(date.toString());

} else {

uiWidget.setText(“”);

}

Before you get creative in finding a workaround you should analyze whether date actually can be null. If yes, how? Is it a field of the class, a parameter of the method, a return value from a called method. All these questions and their answers provide you with a multitude of options.



/**

* @param date of the document to be printed; must not be null

*/

public void printHeader(Date date) {

// Usually I put those checks into a utility class and a checkParam method.

// i.e. Check.checkNotNull(date, “date”);

if (date == null) throw new IllegalArgumentException(“invalid parameter: date cannot be null. Good bye!”);



// once we are here we know that all parameter are valid

date.doSomething();

…

}

It is a good practice to have an object to be in well pre-defined state after creation.



class DocumentPrinter {

private Date date; // this is the same as private Date date = null;

…

}

It is better to do it this way



class DocumentPrinter {

private Date date = Date();

// if this is not sufficient then have  the date passed in as parameter with the constructor and make the default constructor private

…

}

or even better use the Null-Object pattern



class Document Printer {

private Date date = new NullDate();

…

}



class NullDate extends Date {

public void toString() {

return “not set”;

}

From now on you can use date anywhere in your class without the need to check for null.

Now lets look at a return value from a called method. First I would study the documentation of the method and see whether the method actually can return null objects. In important cases I would even go so far as to quickly write a bunch of tests. With those tests you have clear documentation if the method can return null and under which conditions.



public void doSometing() {

…

Date date = getDateOfTransaction(transaction);

…

}

Knowing, that date might be null we need to see how the variable is being used subsequently. If it is being used for some simple display purposes we can wrap the method and return a NullDate in case the return value is null. If there is some more serious work with the object down the road then ‘Houston we have a problem’! Creating a fake date will not work and invite some big risks. Bypassing the date accesses even more so:



…

doThis();

doThat();



if (date != null) {

rebate = calculateRebate(date);

bookTransaction(rebate);

}

…

Sure, we could move the bookTransaction-method out of the block and guarantee that it will be always booked. But, assuming that we are dealing with a preferred customer who always gets a 10% discount. In this case we will get bunch of calls to our customer service folks which would have to deal with an upset customer. We don’t want that. Depending on whether you have access to the source code of used method you can go in fix the problem if not then you have a problem which you should encapsulate. The encapsulated problem offers a clear separation between working and broken smelly workaround code. Also it adds a lot the readability of the source code and you would have only one place to go and do the fix.

But now let’s look at another piece of code. Assuming we have so transmit data via a selectable protocol. The transmission must be encrypted under specific circumstances. So the code could look like this



public void send(String text, String transmission, String encryption) {

String sendText = “”;



if (encryption.equals(“RSA128”)) {

encryption = new RSA128();

sendText = encryption.encrypt(text);

} else if (encryption.equals(“RSA1024”)) {

encryption = new RSA128();

sendText = encryption.encrypt(text);

} else { // no encryption

sendText = text;

}



if (transimission.equals(“ftp”)) {

FTPTransmitter transmitter = new FTPTransmitter();

transmitter.transmit(sendText);

} else if (transmission.equals(“ssh”)) {

SSHTransmitter transmitter = new SSHTransmitter();

transmitter.transmit(sendText);

}

}

How about this



public void send(String text, String transmission, String encryption) {

Transmitter transmitter = Factory.createTransmitter(transmission, encryption);



Transmitter.transmit(text);

}

First, we extracted a Transmitter interface or if feasible an abstract class. The transmitter internally uses a strategy pattern to encrypt the text. The encryption is injected during construction time of the Transmitter. Again, there is an abstraction for the encryption. The factory could be a own creation or you could use a framework like Spring.



class Factory {

public static Transmitter createTransmitter(String transmission, String encryption) {

Encryption encryptionObj = createEncryption(encryption);

return createTransmitter(transmission, encryptionObbj);

}



public static Transmitter createTransmitter(String transmission, Encryption encryption) {

Transmitter transmitter = createTransmitter(transmission);



transmitter.setEncryption(encryption);

return transmitter;

}

…

}

Sure, if you were following correctly I would expect a ‘but now we have the if-statements in the conveniently not shown createEnryption and createTransmitter method’. Yes, your are right. However, I consider those if-statements at this location to be essential. Also, if you use Spring the condition checking will be externalized into the bean descriptor file.

Also, since the factory is driven by Strings, these could easily come from the UI. In that regard the UI would drive the behaviour without adding any conditional checking and would be easily extendable to other means of transmission and encryption without the need to modify it. And yes, the code will much easier to test. MockObjects anyone ;)

PS If anyone can give a me hint to how show source code in a nice and readable using Blogger. This would be highly appreciated.

Ola Bini: QCon San Francisco, RubyConf and JRubyConf

Thu, 12 Nov 2009 09:23:34 +0000

I’m gearing up for the next conference stretch. This time it’s San Francisco next week, and I really hope to see lots of people at these conferences - they are gearing up to be something special.

First QCon San Francisco. Except for JAOO, QCon is the best general developer conference I’ve ever been to. Go check out the schedule at http://qconsf.com. This year I’m very excited about doing a full day tutorial about domain specific languages together with Martin Fowler.

I’m also in charge of the languages track, where I have five people who will talk about their experiences with different languages. This time there will not be much introduction to the languages, but instead experience reports, objective descriptions of what worked, what didn’t work and how you can improve your chances of success. The languages covered are Scala, Clojure, Ruby, Groovy and F#. Should be great fun.

Hopefully I will have lots of time to see other presentations too. There are many I would love to see. ThoughtWorks also happens to be a sponsor of QCon, so there will be a booth where it’s a big possibility you can find me or my colleagues.

I will do one day of RubyConf - the Saturday. Funnily enough I haven’t ever been to RubyConf, so I’m looking forward to this too.

Finally, the first ever JRubyConf will happen next Sunday. The program looks really interesting. I’m going to be talking about testing, and also be part of the ending JRuby Core Team panel.

I’m very excited about these conferences. Hope to see you there!

Simon Brunning: Links for 2009-11-11 [del.icio.us]

Thu, 12 Nov 2009 08:00:00 +0000

State pattern
Disgruntled Star Editor Takes Constructive Revenge
The Go Programming Language
The Sun Shows How Easy It Is To Get A Name Wrong
Curvy women may be a clever bet

Load of old tosh, but still...
Dragon Age: Origins

Looks fun - but I'll wait 'till it starts being discounted.
A history of Python packaging
Agile is Micromanagement
Great Observatories Explore Galactic Center

Beautiful.
CubeSat

A CubeSat is a type of miniaturized satellite for space research that usually has a volume of exactly one liter (10 cm cube), weighs no more than one kilogram, and typically uses commercial off-the-shelf electronics components.
Rupert Murdoch: for whom the net tolls
LightSail

The Planetary Society is building a spacecraft that will sail on sunlight alone by the end of 2010.
Backward star ain't from around here
10 Geeky Laws That Should Exist, But Don’t | GeekDad | Wired.com

Munroe’s Law: A person in a geeky argument who can quote xkcd to support his position automatically wins the argument.

Patrick Kua: What they don’t tell you about user stories

Thu, 12 Nov 2009 06:00:02 +0000

Agile methods have a gap on how to do deal with requirements that often leaves business analysts confused about what to do. From an analyst’s point of view, user stories seem to be the only technique agile methods prescribe. When people are new to agile, they take this as agile’s “only” way of modelling requirements. What isn’t made explicit often gets forgotten, so I want to make this clear: Agile methods don’t discourage thorough analysis or modelling. They don’t discourage the use of diagrams and other visualisations that help people better understand and refine their domain representation. They want everyone to focus on value and communication by using the rights tools for the job.

When coaching analysts, I often find myself telling them, all the tools they draw upon to question, to challenge, to refine and capture their understanding is important. Agile methods focus on better understanding of value, not better note taking. Writing things down does not automatically translate into understanding between two people. Cockburn’s already demonstrated a model that talks about the richness of communication methods, with written documentation being one of the worst.

The best business analysts I’ve worked with have little need to write things down, having absorbed what needs to be done, understood the real requirements, and constantly available ready to help clarify them. Conversely, the worst business analysts see their job only as writing “requests” and “demands” down, doing little to question and challenge what is really needed versus what is merely articulated. These I call overpaid scribes.

Question what value your tools are using and if they help you either better understand or better communicate with other people. If you find modelling in UML helps you better see relationships, do so but avoid spending all your time polishing the model and getting the syntax correct. Be wary of investing yourself too much in one particular model or document that makes you potentially more resistant to changing it. Neal Ford describes this as Irrational Artefact Attachment. If you find yourself writing something down to remind yourself of what is important to get across, do so but don’t use it as a way to avoid helping others understand it.

Agile methods appear nebulous to many people because “user stories” simply appear. It’s not prescriptive about how you get there because there are simply too many different ways to get there. Whilst being prescriptive will help some projects, it would no doubt hurt many others.

Image of Shh! taken from Anthony Gattine’s flickr stream under the Creative Commons Licence

James Crisp: HTML to PDF Conversion Plugin For Rails (A fork of wicked pdf)

Thu, 12 Nov 2009 04:47:07 +0000

Once a business web application reaches a certain size, the need often arises to generate PDFs from HTML/CSS.

Up until recently, the story around this for a MRI Rails application was not good. You could either use tools like Prawn, which require a description of the layout in a specific DSL, or pay for a tool like Prince XML which can convert from HTML, but which costs quite a bit. Those using JRuby were in a stronger position as they could use the Java PDF library called Flying Saucer.

The good news is that PDF generation for MRI Ruby is now easy and free, thanks to webkit, the open source webkit wrapper called wkhtmltopdf and mileszs's wickedpdf plugin. I was really excited to come across this plugin and started to use it right away. However, it had a couple of issues:

Temp file handling caused errors when two PDFs were being generated within the same second (eg, 2 requests at almost the same time)
Problems generating PDF were not reported

Galdomedia forked the code and updated it to use standard Ruby temp files. This was great for ruby 1.7, but not good for Ruby 1.6 which does not allow you to set the extension on temp files (wkhtmltopdf relies on having a .html extension).

As my production servers run Ruby 1.6, I needed a different approach. My fork uses streams rather than temporary files, and adds some basic error handling and basic integration tests.

To install in a rails app:

script/plugin install git://github.com/jcrisp/wicked_pdf.git

Or clone the code from GitHub.

Sumeet Moghe: DevLearn 2009: Kim Zibrick's session on Business Alignment: Focus on the Workplace ...Not the Classroom!

noreply@blogger.com (Sumeet Moghe) — Thu, 12 Nov 2009 02:36:41 +0000

The last session I attended today was Kim Ziprik's short talk on "Business Alignment: Focus on the Workplace ...Not the Classroom!". Kim took aim at the tendency of training departments to "train their way out" of a performance problem and how that has very little impact on actual workplace performance. She went onto talk about approaches that may be useful to bring the focus back to the workplace, where most learning happens.

What did I learn?

There are tremendous challenges that training teams are facing as a consequence of the changing pace of businsess:
- performance variables;
- learner motivation;
- change of business situation;
- retention drops drastically a short time after a training event.
- training doesn't address the entire value stream and looks at localised optimisations
- training is a cost based exercise that traditionally doesn't focus on workpplace performance whereas we should be investing in learning which is geared at solving challenges in the workplace
Kim talked about creating "Learning Wells and not Training Dams":
- drive what people need via their experience levels. She gave tips very similar to the ones I used in my older post about the Dreyfus Model
- Leverage performance based tools like:
  - Job Aids (Standard Work?);
  - Employee Performance and Support Systems;
  - Self Assessments;
  - Coaching;
  - Communities;
  - Career based curriculum
- Integrate learning into the workplace - create continuous learning opportunities.
- Redesign your Learning Architecture. Rethink the roles your training team plays, the places where training happens, the measures for effectiveness, technologies assisting learning and the culture that surrounds these experiences.
- Reduce the dependency on a single source of information. Harness the power of the collective - people together are far smarter than you can ever be.

Sumeet Moghe: DevLearn 2009 - Ruth Clark's session on Evidence Based Training

noreply@blogger.com (Sumeet Moghe) — Thu, 12 Nov 2009 02:10:03 +0000

The first concurrent session that I attended this morning was Ruth Clark's talk about Evidence based Training. Ruth talked about moving from fads and fiction to facts about the use of multimedia in training and education. Ruth as usual was her confident, articulate self and displayed some wonderful research and evidence that contradicts a lot of traditional wisdom

What did I learn?

Learning styles are overrated and a waste of time. There's no relationship between someone's learning style and their eventual performance on the job. eg: being a visual learner doesn't mean that you will have a high recall of an image.
Liking a session has no correlation to an individual's learning in the session. A highly rated session may not be the most effective.
People need the bare minimum detail to apply the learning. Extraneous detail is confusing (war stories, anecdotes, etc) and while immensely likeable, can hurt learning.
Tips for use of multimedia in elearning and training:
- Graphics with text create the highest impact learning because of the dual encoding phenomenon. This is a great mode for novices and apprentices.
- Audio narration is proven as the most effective method of providing descriptions to graphics. This should be the default on elearning courses, with the ability to pause, and turn off.
- Simple line drawings are much easier to recall than complex 3D pictures.
- Stills are often more effective than animation, to explain how things work. In such situations, animations put the brain in a passive state and create extraneous mental load
- Videos are proven to be effective in teaching social skills and motor skills and to show examples.

Sumeet Moghe: DevLearn 2009 - Andrew McAfee's Keynote. Enterprise 2.0 - the state of the art

noreply@blogger.com (Sumeet Moghe) — Thu, 12 Nov 2009 01:53:38 +0000

This morning I sat through the most awesome keynote by Andrew McAfee - author of Enterprise 2.0: New Collaborative Tools for Your Organization's Toughest Challenges. Andrew is one of the 100 most influential people in IT. His talk was not just informative and eye-opening, it was immensely entertaining. In short it was a privilege.

What did I learn?

Andrew's talk deserves a fairly long post (though with very random thoughts). His address was in 3 parts; the definition of Enterprise 2.0, the "state of the art" as he saw it and the things to avoid ("how to snatch defeat from the jaws of victory")

The Definition of Enterprise 2.0

Involves use of emergent technology or new uses of technology or social software;
Solves business problems and answers business goals

The State of the Art

Andrew defined the state of the art of Enterprise 2.0 under 6 major headings:

Altruism

People want to help each other
Enterprise software needs to be people centric not document centric
The paranoia about risks is not senseless, but overrated. Most risks never materialise because in the enterprise, you don't have the luxury of being anonymous like on the web. People are unlikely to do the "wrong" things. In fact they never do it.
The entry barrier for people to want to help each other, needs to be low -- eg: Twitter. People can help each other and do that within just 140 characters!

Process

There's rarely one best way to do things in today's business world -- the era of best practices is dying.
People need to have the ability to self select and self organise when contributing content and deciding how and when to collaborate.
We need to limit workflow - it can't take several levels of approval to do something simple.
Structure shouldn't be imposed. Tools need to facilitate structure and structure should develop over time.

Innovation

Example: Innocentive, the idea of crowdsourced innovation, where its only a matter of getting a different person to take a look at your problem and solve it for much less than the solution is really worth!
Getting more eyeballs to look at a problem often generates more solutions.
Expertise is emergent, not identified. Anyone can be an expert and people are recognised for their contribution and not their position/ credentials.
Communities should be the one that people want. Nothing should be imposed. (Something someone said "Communities of interest" vs "Communities of Practice")

Intelligence

Harness the collective. The wisdom of crowds makes decision making really powerful.
Peer decision making, peer reviews, peer innovation and peer feedback make ultimate sense (given the number of eyeballs looking at the issue!)
Andrew gave the example of the prediction market's analysis of the Obama campaign where crowdsourced probabilities resulted in a more accurate prediction of the election results than the most sophisticated analysis by expert statisticians.

Benefits

Enterprise 2.0 gives you the opportunity to "narrate your work" to the extent that you can all of a sudden demonstrate your expertise.
It creates for better social connections. You are connected to the right people sooner.
It offers the opportunity to benefit from varied perspectives on a certain topic.

Impact

Results of a McKinsey study about web 2.0 tools shows:
- Access to knowledge 68%
- Access to internal experts 43%
- Employee satisfaction 35%
- Increased innovation 25%
- Increased customer satisfaction 43%
Its a bad idea to sit out the Web 2.0 phenomenon.
We need to look at technology with a fresh set of eyes.
We can't go back to "business as usual" after this recession.
Businesses need to leverage technology as one of its key components.

Things to Avoid

Don't try to replace email: Instead think of things that email cant do.
Don't accentuate the negatives: Instead point out risks while accentuating the huge business benefits.
Don't fall in love with features: Start simple, iterate through the solution
Don't declare war on the enterprise: Its a bad sales strategy to alienate the very people that'll sponsor such a thing. Organisations need structure to function
Don't build walled gardens: Instead allow multiple groups to flourish in the same place. Moving between groups needs to be seamless.
Don't overuse the word "social": It creates the wrong connotations for the business; especially in a time when we're seeking tangible results.

Sumeet Moghe: DevLearn 2009 - Actions Speak Louder than Words, by Ethan Edwards

noreply@blogger.com (Sumeet Moghe) — Wed, 11 Nov 2009 23:13:03 +0000

I just sat through a session called "Actions Speak Louder than words - Creating Meaningful e-Learning Interactions", by Ethan Edwards of Allen Interactions. The session was about interactions that create mental stimulation to eventually improve workplace performance. Ethan explained that an interaction has four aspects to it; namely Context, Challenge, Activity and Feedback. The focus of the session was on crafting and implementing meaningful challenges and activities for elearning.

What did I learn?

Ethan's session provided a balance of detail between instruction and demonstration. Here are a few things I'll remember.

A different style of presentations: Show and tell -- Ethan didn't just talk about his work, he actually showed real life examples of the interactions he's worked on. He embedded these as clickable links into the presentation and that made the entire experience almost seamless.
It helps to have some time aside to answer questions as a conference speaker. Ethan did pretty well to set aside almost 20 minutes for QnA.
On the content front, my big takeaway was Ethan's rules for elearning interaction design:
- Measure an observable action.
- The interaction should need attention and thought. This I feel is particularly important since a lot of elearning seems to be just a lot of click and turn!
- The interaction should have relevance and meaning in the real world.
- The interaction should allow the learner to model real world performance.
- The interaction should require effort to complete.
- And lastly, in keeping with my philosophy of "a safe environment to fail fast and learn from mistakes", the activity should be reversible. If a learner makes a mistake in elearning, it isn't the end of the world and we shouldn't be making the learner feel that way either!

Ross Pettit: Restructuring IT: Organizing for Results

noreply@blogger.com (Ross Pettit) — Wed, 11 Nov 2009 16:24:56 +0000

Up to this point in this series on Restructuring IT, we’ve looked at how IT has adopted an industrial model. IT has achieved scale, but at the cost of results, as is clear from the low rate of success of IT investments. We'll now take a look at how we can organize IT for results.

Professional versus Industrial

IT needs to reorganize for results, not scale. Organizing for results requires professionalism as opposed to industrialism.


People in industrial and professional situations each use drills, but you wouldn’t staff an assembly line worker in an operating room to get "capacity" on a surgical team.

To get professionalism, we need to organize less to try to be predictable (which will always escape us) and more to be responsive and accountable.

Let’s think about the things that would professionalize IT.

Instead of scrambling just before a deployment, what if every solution build acted as an internal gatekeeper of quality, continuously executing to validate technical, functional and non-functional completeness of everything we do?

Instead of trying to “inspect quality” into IT, what if testing were a team responsibility, automated and integrated into what we do daily?

Instead of watching big-up-front designs morph from whiteboard masterpiece to over-engineered Frankentecture, what if teams had the flexibility to take design decisions in near-JIT fashion, with a minimum of duplication and the fewest moving parts possible?

Instead of a “requirements arms race” between business and IT, what if we were able to accommodate continuous business involvement, facilitated to enable continuous change management and adaptive project management?

Instead of standing up volumes of impenetrable and unactionable requirements, what if we had short, business oriented requirements that could be quickly steered through development and QA and into production?

Instead of sending round reams of paperwork for PMs to fill out in little more than CYA exercises, what if we were able to govern IT non-invasively, ascertaining from our delivery teams whether they’re delivering value for money, and working in accordance with expectations?

We have the means by which to do all of these things. Today. Right now. But we can’t simply will them into place. To get these things, we need to restructure IT.

What does it really mean to “restructure”?

Before we discuss what restructuring IT is, let’s first understand what it isn’t.

Restructuring IT isn’t a question of org charts. All too often, new reporting lines just rearrange the deck chairs on the Titanic. It also isn’t about budgets, either: we can’t do more with less, because there isn’t that much less with which we can get any more done with.

How about the management cheerleading of recent years, things like “be close to your customer” and “have fewer hand-offs in your work processes.” When folks like Tom Peters started putting those messages forward in the 1980s they were a wake-up call that business had gone adrift. And yes, we need to restructure with this in mind. But we can’t have reorganization by platitude. We need something actionable.

Restructuring IT is about behaviours. Changing behaviours away from industrial thinking to professional thinking is a pretty big shift. Among other things, it means each person is responsible not just for doing the tasks they’ve been assigned, but doing what is necessary for the project to succeed.

Think back to the surgical team metaphor. As my colleague Greg Reiser points out, the surgical team collaborates toward a shared objective, improving the quality of life of the patient. Their primary goal may be to graft blood vessels that bypass a coronary artery blockage, but their objective is to prolong the life of the patient. What does the team do when they discover, as they almost always do, that the condition of the heart and surrounding tissue is not exactly as they expected? They apply their professional expertise and work as a team to adapt in order to achieve the primary objective. This is how professionals behave.

It doesn’t help, of course, that there are so many headwinds to getting things done in IT, ranging from a constant cycle of upgrades that change points of integration to an abundant supply of people without the complete gene in their DNA. Results are hard. Finishing stuff is hard.

This begs a critical behavioural question: why take the risk of getting “results”? Why put yourself on the line, underwriting success with your personal guarantee, especially if you have a built-in scapegoat? I met with a team last year where the PM, BA and dev lead knew a project was going to fail, because the development team simply didn’t have the capability. The project leadership didn’t make any effort to change staff, because the decision of who to staff was somebody else’s: people were supplied to them by procurement. The project was conspicuous because it was late starting as it was, so their priority was to get started. Never mind that they knew it wouldn’t finish. In the end, they could say they simply played the hand they were dealt by the organizational structures – in this case, an industrial-inspired procurement function – that existed to make IT effort “cost effective.”

So rather than work to success, rather than pressing the button and stopping the line and saying “this project is going to fail and we need to do something about it before we make a commitment of capital and time” they simply got on with the work knowing they were going to fail.

This is all too common. There is structural disincentive to achieve results in a lot of IT organizations. This disincentive is supplemented with soft scrutiny. Most measures of “complete” amount to little more than people working to a state where nobody can tell them they’re not done, instead of working to a state where somebody can conclusively tell them they are done.

So what makes us think people will make the effort to get things done?

It also makes you wonder: how much of this is going on in your IT organization today?

In our next installment, we'll take a look at how, specifically, we restructure for results.

Mark Needham: Coding: Pushing the logic back

Wed, 11 Nov 2009 10:30:08 +0000

I was reading a post on the law of demeter by Richard Hart recently and it reminded me that a lot of the refactorings that we typically do on code bases are about pushing the logic back into objects instead of exposing data and performing calculations elsewhere.

An example that I spotted where we did this recently was while building a 'BusinessSummary' object whose state was based on the state of a collection of other objects.

The code was keeping a count of the various states of the business objects:

public BusinessSummary buildSummaryObject() {
	BusinessSummary businessSummary = new BusinessSummary();
 
	for(BusinessObject businessObject : businessObjects) {
		State state = businessObject.getState();
		if(State.STATE_1.equals(state)) {
			businessSummary.incrementState1();	
		} else if(State.STATE_2.equals(state)) {
			businessSummary.incrementState2();
		} else {
			// and so on
		}					
	}	
	return businessSummary;
}

In this example 'State' is an enum representing the state the 'BusinessObject' is currently in.

Our first change to the code was to push the logic around state back into the 'BusinessObject' which results in the following code:

public BusinessSummary buildSummaryObject() {
	BusinessSummary businessSummary = new BusinessSummary();
 
	for(BusinessObject businessObject : businessObjects) {
		if(businessObject.hasState1()) {
			businessSummary.incrementState1();	
		} else if(businessObject.hasState2()) {
			businessSummary.incrementState2();
		} else {
			// and so on
		}					
	}	
	return businessSummary;
}

public class BusinessObject {
	...
	public boolean hasState1() {
		return State.STATE_1.equals(state);
	}
	...
}

I think this is an improvement but it still isn't following the tell don't ask principle, we're just asking to be told about the data instead of asking for the data itself.

We didn't have the time to do the next change where we would have got rid of the 'hasState' methods and just got the 'BusinessObject' to update the 'BusinessSummary' itself:

public BusinessSummary buildSummaryObject() {
	BusinessSummary businessSummary = new BusinessSummary();
 
	for(BusinessObject businessObject : businessObjects) {
		businessObject.writeTo(businessSummary);					
	}	
	return businessSummary;
}

public class BusinessObject {
	private final State state;
	...
	public void writeTo(BusinessSummary businessSummary) {
		if(State.STATE_1.equals(state)) {
			businessSummary.incrementState1();	
		} else if(State.STATE_2.equals(state)) {
			businessSummary.incrementState2();
		} else {
			// and so on
		}
	}
	...
}

Looking back on this code having written this post I wonder whether we need to do the loop or whether it would be better to pass the collection of 'businessObjects' to the 'BusinessSummary' and let it take care of that logic instead.

If we did that then we would need to expose 'hasState1′ and 'hasState2′ methods on 'BusinessObject' like on the first refactoring so that we could work out how to populate 'BusinessSummary'.

I prefer the solution where 'BusinessObject' writes to the 'BusinessSummary' although it seems like 'BusinessObject' now has more than one reason to change – if it changes or if 'BusinessSummary' changes. This would violate the single responsibility principle

I discussed this with Dave and he pointed out that as long as the contract that 'BusinessSummary' and 'BusinessObject' have – i.e. the 'incrementState1′ and 'incrementState2′ methods – stays the same then it wouldn't really be a problem.

Simon Brunning: Links for 2009-11-10 [del.icio.us]

Wed, 11 Nov 2009 08:00:00 +0000

Cell Size and Scale

Awesome zoomable window.
django-axes - Project Hosting on Google Code

"django-axes is a very simple way for you to keep track of failed login attempts, both for the Django admin and for the rest of your site."
Sass - Syntactically Awesome Stylesheets

Sumeet Moghe: DevLearn 2009 - Ruth Clark's workshop on Scenario Based Learning

noreply@blogger.com (Sumeet Moghe) — Wed, 11 Nov 2009 07:01:34 +0000

Today was my second day at DevLearn 2009 and I must say its been a great investment this far. If not for anything else, its been a great opportunity to meet a lot of great learning professionals not just from the United States, but from all across the world. The ideas and thoughts that we've shared will be of great value to my work back in Bangalore, India. Today I sat through the workshop by Ruth Clark on the topic of "Scenario Based Learning" and I thought I could do a quick report on some things I learnt from the experience.

What did I learn?

Scenario based learning can be described as follows:
- What: Scenario based learning uses simulated, real life scenarios to trigger the acquisition and simultaneous application of a skill. It gives the learner the opportunity for Whole-task practice. Whole task practice involves being able to combine various non-integrated parts of skills and information to put together a real-world, real-life performance. An example of whole task practice is the ability to put together a budget in Excel as against the part-tasks of editing cells, creating formulae, etc. Scenario based learning also allows for better Far transfer of learning as against the procedural near transfer.
- When:Scenario based learning is effective in to simulate situations that are rare, strange, high-risk or impractical to simulate in a classroom or in the workplace.
- Who: Scenario based learning is best suited for Novices and Apprentices. The experts are perhaps the people that can help design this learning!
There's empirical evidence to suggest that Scenario based elearning benefits the most from rich multimedia additions, such as real life videos.
As with every other teaching strategy, its best not to use this as a silver bullet - consider your subject and your audience carefully before you deploy this approach.
Lastly, I learnt that to build a learning scenario, you need to consider and plan six factors in your design:
- Task Deliverable: What will the learner do to demonstrate competence?
- Trigger Event: How the task or problem normally initiates in the job setting.
- Case Data: What background information is needed to solve the case?
- Guidance: How will learners get assistance when solving the case?
- Feedback: How will the learners receive intrinsic feedback as the scenario plays out? How will they receive traditional, instructional feedback a.k.a Teaching Moments?
- Reflection: What opportunities will the learner have to review their actions/ decisions and consider alternatives?

Overall, I think the workshop brought out some really interesting discussion and I think the various perspectives and styles that people applied to their own design situations was particularly amazing. I'll recommend Ruth's session to anyone that has the opportunity to attend in the future.

Simon Brunning: Links for 2009-11-09 [del.icio.us]

Tue, 10 Nov 2009 08:00:00 +0000

The power of "no"

Is it Open Source versus Commercial that makes the difference, or a Benevolent Dictator? I'd say the latter.
Test Driven Deployment

Nice idea - but don't call it bleedin' TDD. FFS.
Drugs and the BNP

Nice data visualization.
SideWiki changes everything
Django-Jython 1.0
Front Page - css-discuss
Rupert Murdoch's threat unlikely to worry Google

Dahlia Bock: Working Effectively with Legacy Code (Robert C. Martin Series)

Tue, 10 Nov 2009 02:40:56 +0000

Working Effectively with Legacy Code by Michael Feathers

I’ve been carrying around this book with me for the past few weeks and I find myself going back and reading parts of a chapter again and again, trying to soak in the concepts. This particular chapter, titled: I Don’t Have Much Time And I Have To Change It, struck me specifically when Feathers starts out talking about change and how often it happens in code bases and that steps should be taken to make every consequent change easier than the one before. When teams make it a point to only introduce changes to the code only if they have tests to cover that change, they find that their velocity slows down and people feel like they aren’t getting as much done as they need to. Feathers emphasizes that this is normal but if they persevere, they slowly realize that they are revisiting better code and changes get easier and easier to make.

I think that it’s important for teams to understand the benefits of testable code and how it eases the process of change so that they will invest the time and energy needed to get the code to that point. And I quote:

Ultimately, testing makes your work go faster, and that’s important in nearly every development organization.

Having code that is testable is only possible if we do one of the following (If I remember correctly, I think this is according to Uncle Bob):

Write the tests before writing the code
Design for testability

Doing the latter isn’t easy, and in fact it is so hard to achieve that people end up not doing it at all. So that leaves us with Option 1. But sometimes you come across code that doesn’t have any tests AND doesn’t look like it is testable, but you have to make some changes in a short amount of time. So what do you do? Michael Feathers suggests 4 approaches, and my colleague Mark documents it in a short and sweet way (basically he beat me to writing the post first).

Sprout Method

Advantages: Separating new code from old code. New code is testable.

Disadvantages: You’re giving up on the old code for now.
Sprout Class

Advantages: Allows you to move forward with more confidence.

Disadvantages: Conceptual complexity – moving new code into a separate class disrupts the flow of how key classes in the code base work together.
Wrap Method

Advantages: A great way to introduce seams (this is a concept that Feathers talks about in a previous chapter, which we will visit in a later post) while adding new features.

Disadvantages: This method requires you to rename the method that you want to change, and create a new method with the same name as the previous method before the rename was done. Sometimes this could introduce sloppy method names because we needed to do some renaming to make way for the new method.
Wrap Class

This method is pretty much the same as Wrap Method except you’re extracting new behavior out into a new class. Feathers mentioned that 2 things push him towards choosing to use Wrap Classes and one of them is when a class has grown so large that he cannot stand to make it worse. Pushing behavior into a new class when the existing class is unmanageably large could also indicate that the original class might have too many responsibilities and thus needs to be gutted.

I like this chapter because it formalizes a lot of things that I try to do very often because of the large range of code bases that I work with, but find it difficult to nail it down to something that could be explained to someone else.

Mark Needham: Legacy Code: Sensing

Mon, 09 Nov 2009 20:33:22 +0000

In 'Working Effectively With Legacy Code' Michael Feathers describes two reasons for wanting to break dependencies in our code – to allow separation and sensing.

The former describes the need to get a piece of code into a test harness while the latter describes the need to assert whether that piece of code is doing what we want it to.

On the projects I've worked on we've tended to run into problems with the latter more frequently and Matt and I actually ran into this problem when we were refactoring some code into a role based interface approach.

We started with the following code:

public class ApplicationController : Controller
{
	public string BusinessType
	{
		get { return GetType().Replace("Controller", ""); }
	}
 
	public override void OnActionExecuting(ActionExecutingContext context) 
	{
    		base.OnActionExecuting(context);
		ViewData["SomeViewDataKey"] = CreateThatViewDataStuff();
	}
 
	private ViewDataStuff CreateThatViewDataStuff()
	{
		return new ViewDataStuff 
		{
			Content = BuildContent()
			// and so on
		};
	}
 
	private IContent BuildContent()
	{
		if(BusinessType == "BusinessType1")
		{
			return CreateContentForBusinessType1();
		}
		else if(BusinessType == "BusinessType2")
		{
			return CreateContentForBusinessType2();
		}
		else
		{
			return CreateContentForEveryOtherBusinessType();
		}
	}
}

The 'BuildContent' method is the one that we're really interested in here but it's a private method on the controller so we currently don't have an easy way to assert that it's being created correctly.

In order to test that functionality more easily we decided to make the method public so we could just call it directly.

We wanted to do this so that we could write some tests around this bit of functionality before we refactored it so that we could be sure we hadn't broken the way it worked while doing so.

As Hamlet D'Arcy points out, if we're going to call it refactoring then we need to make sure that we're protected by tests. Otherwise we're just changing stuff.

[Test]
public void ShouldCreateContent()
{
	var someRepository = MockRepository.CreateMock<ISomeRepository>();
 
	var controller = new BusinessType1Controller(someRepository);
 
	someRepository.Expect(s => s.GetBusinessType1Message()).Return("someValue");
 
	var content = controller.BuildContent();
 
	// and so on	
}

We did the same for the other business types as well.

I normally don't like making private methods public but we didn't intend to checkin our code until the refactoring was complete at which point the method would be made private again.

The code ended up something like this:

public class BusinessType1Controller : ApplicationController
{
	public override IContent CreateContent()
	{
		return new BusinessType1Content(someRepository);
	}
}

public class BusinessType1Content : IContent
{
	private readonly ISomeRepository someRepository;
 
	public BusinessType1Content(ISomeRepository someRepository)
	{
		this.someRepository = someRepository;
	}
 
	public string GetMessage()
	{
		// this would be a different repository call for other business types
		return someRepository. GetBusinessType1Message();
	}
}

We were able to create a test against the business types directly instead of having to write a test against the controller:

[Test]
public void ShouldCreateContent()
{
	var someRepository = MockRepository.CreateMock<ISomeRepository>();
 
	var content = new Content(someRepository);
 
	someRepository.Expect(s => s.GetBusinessType1Message()).Return("someValue");
 
	var message = controller.GetMessage();
 
	// and so on	
}

Having got these new tests passing the ones we'd written against 'BuildContent' now also worked and since they were effectively testing the same thing we were able to get rid of them and make 'BuildContent' private again.

Despite the fact that I was initially reluctant to expose the 'BuildContent' method this approach seemed to work out reasonably well.

An alternative approach would have been to create a test only ApplicationController and then create a method on that which called the 'OnActionExecuting' method.

We've done that to test some other things and it would have allowed us to test the creation of 'Content' in a more roundabout way without needing to make 'BuildContent' public.

The additional effort involved in doing that for not much gain means that given a similar situation in the future I'd probably use just make the method public again!

Jie Xiong: 测试驱动咨询

Mon, 09 Nov 2009 14:26:07 +0000

当别人求助你解决一个问题时，第一件要做的是什么？

不是挽起袖子解决问题。不是诊断症结在哪儿。甚至都不是问5个why。

首先要问的问题是：

如果这是一个问题，用什么数据能体现它？
如果问题被修复了，从这个数据上是否能反映？

然后，把度量放下去。每个度量项要有几个要素：

哪些数据？
如何得到数据？
以什么频率采集数据？
如何发布结果？

按照这几个要素制定一个跟踪度量方案。用这个方案先采集现有数据。根据现有数据定一个改进目标。

这就是你的──正在失败的──测试。先把测试放下去，然后再提任何改进措施。

Thomas Czarniecki: HTTP method primer for RESTful web services

Mon, 09 Nov 2009 11:41:20 +0000

The following is just a reminder to stop me from getting confused

GET

Used to fetch a resource.
The server sends back a representation of the resource in the response body.
Safe operation (see below).

DELETE

Used to delete a resource.
The response from a server may contain a status message or nothing at all. It is usually nice to send back at least a 204 (No Content).
Idempotent operation (see below).

PUT

Used to create or modify a resource. If your server should not permit users to determine the URI of a new resource then you may need to create it via a POST to a factory service (see below).
The request body contains the proposed new representation of the resource.
From my reading there seems to be some contention as to whether the request body should contain a full representation of the resource or a delta when modifying an existing resource. My personal preference is that the request should contain a representation of the whole resource, and use a POST method to the resource to update part of a resource. Alternatively, if possible, you can PUT to a sub-resource (e.g. PUT to /user/12345/address if all I want to do is modify the user’s address).
The response from a server may contain a status message or nothing at all. It is usually nice to at least return a 200 (OK).
Idempotent operation.

POST

Used to create subordinate resources: resources that exist in relation to some other parent resource.
- For example: POST /weblogs/myweblog with the request body containing the contents of a new weblog entry would create an entry called /weblogs/myweblog/entries/SS0093WSA.
- Response to such a POST request usually has a status of 201 (Created) and a HTTP response “Location” header that has the URI of the created resource.
POST can also be used to append to an existing resource or to update an existing resource.
- For example: POST to /log adds a log message to the /log resource.
Not safe or idempotent. Expect side-effects. “Here be dragons”

HEAD

Used to retrieve metadata about a resource, rather than the resource itself.
Can be used to check if the resource exists, or if a newer version of the resource is available.
Gives you the same HTTP header as the response to a GET request, just without the response body.
Safe operation.

OPTIONS and TRACE

Currently not really used by most RESTful systems. Nobody can really figure out how to use them properly.

OPERATION TYPES

Safe operation: Should not change any server state – or at least any state that matters as even GET requests can get logged or access counters can become incremented.

Idempotent operation: Has the same effect irrespective of the number of times its applied. In other words, the second and subsequent requests leave the resource in exactly the same state as the first request did.

Ola Bini: A week at Øredev

Mon, 09 Nov 2009 11:06:42 +0000

I just came back from 10 days in Malmö, Sweden, for the Øredev conference. I’ve had a great time. Part of that was because I had Stella with me, and she got to meet all my conference-friends, so that was nice.

But a big part of it is basically just the fact that Øredev is an outstanding conference.

Some of my impressions, things I learned and did in no specific order:

Hadoop is really cool and I wish I had time to learn more about it. Alex Loddengaard from Cloudera did a very good job introducing this technology in his tutorial. We got to do way fun stuff!
People liked my talk about Ioke - and I was very happy with how it went too.
Stuart Halloway is really good at introducing Clojure - I’m looking forward to his talk at QCon SF even more now.
Me, Tyler Jennings, Neal Ford, Dan North and Stuart Halloway spent several hours of BoF time to create a new BDD framework for Clojure - this was way fun hacking, interesting from a group management and design perspective and just plain fun. There is a distinct possibility that me and Neal will give a talk at the TW US Away Day about this, if anyone is interested.
Ze Frank is amazing. Really great evening keynote/entertainment.
Niclas Nilsson and Hans Brattberg did a very accurate depiction of common problems and failure modes of pair programming. Good stuff.
Tyler Jennings gave an introduction to Software Craftsmanship. Glad I didn’t miss this presentation. Very nicely done.
Kevlin Henney did a great presentation about agile modeling. I enjoyed it a lot.
We did a very fun closing panel that was basically just six geeks disagreeing about lots of stuff. I hope everyone else enjoyed it as much as the panel members.

Conclusion: Øredev was a great conference, I was honored to get the chance to speak there and I’ll definitely try to go back next year.

Joe Poon: The Last Mile

Mon, 09 Nov 2009 05:47:19 +0000

Often the most painful and time consuming part of a software project is the Last Mile, getting it deployed and working in production. Why is this the case? To understand this, it is useful to look at the underlying issues such as not having decent source control, lack of automated tests, excessive branching (and eventual merging), dedicated teams and infrequent releases. These impede our productivity on a daily basis and when left unresolved, become magnified during the Last Mile.

Without shortening the Last Mile, our deployments are delayed and unpredictable events. As a result, we are unable to quickly respond to changing business needs.

So how do we shorten the Last Mile? Enter continuous integration. The beauty of continuous integration is that it is the cornerstone for resolving these issues - it forces us to get source control under control, brings visibility to the health of our code base, challenges us to think of multiple environments and configurations and encourages us to automate repetitive tasks. True to it’s name, it encourages us to integrate early and often. With CI, we’re already resolving integration issues from day 1 thereby making deployment to production thankfully, a non-event.

Troy Gould and I presented The Last Mile at the Agile Vancouver 2009 Conference this week. The presentation looks at the problems faced by teams trying to get software released, recommends good CI practices, introduces build pipelining with Cruise as an overall structure to manage the build-deploy-test-release process and encourages us not to stop with CI as a build server, but leverage it to automate deployments to environments including production. Thanks to those who attended. It was exciting to see all those actively using CI on their projects. The slides can be downloaded here (17MB).

Thanks to Owen Rogers and the team of organizers for an excellent event and lining up a great set of speakers including Eric Evans, Michael Feathers and Martin Fowler.

James Crisp: Presentation Zen by Garr Reynolds

Mon, 09 Nov 2009 04:25:23 +0000

After being impressed by Garr Reynolds speaking in Sydney a year or so ago, I've been keen to check out his Presentation Zen book. It is an enlightening read, especially if you have never studied art or graphics design. The book is a little over 200 pages long, with many illustrations and a impressive, clean layout (no surprise there!).

Near the start of the book, Garr talks about creativity requiring an open mind (child like) and a willingness to be wrong, and to experiment. He recommends exercising restraint, and focusing on simplicity, clarity and brevity. He starts presentations brainstorming using pen and paper, whiteboards or post-its rather than in front of the computer (personally I often use story cards as you can jot slide outlines on them, group, and shift the order around). He recommends grouping the ideas, and identifying the core message and sticking with that message throughout the whole presentation.

Garr highlights the importance of taking the time to slow down and really think about what to put in the presentation. He suggests that you keep two important questions in mind: "What's your point?" (what one thing do you want the audience to remember), and "Why does it matter?" (put yourself in the audiences' shoes). If bits of your content don't aid in answering these questions, "when in doubt, cut it out"! Garr also suggests an "Elevator test" - can you make your pitch in 30-45 seconds? A structure that works well is starting with an introduction which explains the issue (the pain) and the core message. Then something like 3 parts that support your assertions or solve the pain (sounds a bit like Bosworth's Solution Selling).

"Amplification through simplification" is central to Garr's design approach. He advocates lots of empty space to highlight just one or a few important elements on a slide. "Simplicity can be obtained through the careful reduction of the non-essential" and decreasing the signal vs noise ratio of the slides. Garr is a big fan of using images on slides with just a few words. The aim is to make slides which have strong, memorable impact, and enhance the presenter's spoken words. He also highlights the importance of having the audience know where to look. Eg, simplicity plus images leading the eye to the right spot (eg, people in images on the slide look towards the words on the slide). Garr is a big fan of using quotes to support his points.

Garr suggests a mix of symmetrical and asymmetrical slides. Symmetrical are more formal and static, where as asymmetrical slides are often more dynamic and interesting and activate empty space. He also suggests using a grid, such as the rule of thirds (2 horizontal and 2 vertical lines providing a grid of 9 equally sized boxes), with the main subject placed on one of the crossing points of the lines. Contrast (using colour, shape, space, etc) can be used to make an element stand out and helps the viewer "get" the point of the design quickly. Repetition can be used (eg, text on each slide in an image of a post-it) to provide a professional and unified look. Use proximity to group related objects.

Although Garr doesn't talk about it explicity, his sample slides tend to make use of clever typography. Often lower case text, with most important part in a bigger font. A mix of colours and sizes and styles and sometimes rotations to add interest to the slides. Generally sans-serif fonts.

On presenting itself, Garr says you should be completely present - enthusiastic and completely focused on presentation that you are giving, lost in the moment. Nothing else. Although you may make mistakes, don't dwell on them. Practice like mad to become confident and appear easy and natural for the presentation. However, remain flexible, aware and open to possibilities as they arise (being "in the moment").

Near the end of the book, Garr says: "It's not about us [the presenter], it's about them. And about the message.". He also suggests that shorter is better, leave the audience wanting more, not overloaded (as per Japanese proverb "eat until 80% full"). On delivery, Garr suggests standing front and centre, leaving the lights on and advancing slides with a remote.

Garr's points are much more clearly illustrated using images in the book. I would recommend Presentation Zen to anyone who is interested in making more visually inspiring and interesting presentations.

Ye Zheng: 我们很忙

Sun, 08 Nov 2009 15:52:32 +0000

软件开发似乎就应该是忙碌的，加班似乎也应该是常态。我听到最为痛心的一个说法是，每天都在加班，忙得连洗衣服的时间都没有。也是因为忙，忙得有没有时间学习、没有时间思考。所有一切都是因为忙。

但是，我们都是怎么忙的呢？不妨看一些细节。

软件开发中，最重要的过程应该是编码，但真正的编码有多长时间呢？在一个采用传统开发方式的团队中，会有一个最后集成阶段。因为前期做的验证不够充分，所以，要给后面留下很长的时间，用来做集成和测试，更有甚者，这个时间要比“开发”时间还长。这里的“开发”阶段只是在纯粹的编码。就这样，在计划中，很大的一段时间被砍掉了。

即便是在“开发”阶段，就真正能坐在那里好好写代码吗？未必。在大企业里面，最浪费时间的是什么？开会。人多，沟通不畅，开会成了“自然”的选择，而且，往往是人越多，会就越多。事实上，很多企业的会都是非常低效，一开会就发散，通常一个会一两个小时就进去了。在《做好一件事》中还提到矩阵式管理也会让人无法好好写代码。就这样，在团队开发中，又有一段时间被消耗掉了。

即便真正开始写代码，又是怎么做的呢？对于历史悠久的产品而言，程序员需要面对大量的遗留代码，编译一次代码，都要用很长时间，这意味着，消除编译错误这样原本应该很简单的事情都要消耗大量的时间。于是，经常可以看到一个个程序员面无表情的在那里等待编译。遗留代码，通常也意味着欠了一屁股的技术债务，也就是说，为一个功能要遍地开花的改许多代码，这也很耗时。对于不编写单元测试的程序员，常用的验证手段就是调试器，因为人的参与，这个过程不能自动化，很是缓慢。好容易到了该提交代码了，因为文件很大，出现冲突的几率也增加了，处理冲突也是耗时的事。在个人开发中，时间就在不知不觉中流逝。

我们很忙，因为忙而认为一切都是理所当然的。正如上面所列，很多时间实际上是在一环扣一环的低效中无谓消耗了，所以，每天不得不加班，让自己看上去很忙，以此换回内心的“安宁”。

我们真的很忙吗？

博客大巴，你的个人传媒早班车

Mark Needham: Coding: The agent noun class

Sun, 08 Nov 2009 10:44:18 +0000

I refer quite frequently to a post written by my colleague Peter Gillard Moss where he describes the agent noun code smell for class names.

An agent noun is defined by Wikipedia as:

In linguistics, an agent noun (or nomen agentis) is a word that is derived from another word denoting an action, and that identifies an entity that does that action.

Some typical examples of this are classes which end in the name 'Manager', 'Retriever', 'Helper' or even 'Controller' as Carlos points out.

It's often the case that these classes better describe a method which belongs on another object and I quite like Peter's idea that agent nouns are useful for describing the roles that our objects carry out.

We came across an interesting problem related to this a while ago where we wanted to calculate the age of a given customer and then send that data to another web page where it would be displayed.

The date of birth was an attribute on the 'Customer' object and we didn't need any of the other attributes of a customer on this web page so my first thought was that we needed an 'AgeCalculator' class.

public class AgeCalculator 
{
	private readonly IClock clock;
 
	public AgeCalculator(IClock clock)
	{
		this.clock = clock;
	}
 
	public int CalculateAge(DateTime dataOfBirth)
	{
		// do some calculation with clock & date of birth here
	}
}

public void SomeMethod()
{
	var age = new AgeCalculator(new Clock()).CalculateAge(customer.DateOfBirth);
	// and so on 
}

This approach worked quite well as it allowed us to easily test the age calculation logic in isolation and we could then pass on the age returned to the web page.

The thing I didn't like about this solution is that it seems a lot like an agent noun class.

The giveaway in this case is that the method name is just a variation on the class name. This suggests that this behaviour belongs on another object instead.

It's not as object oriented as it could be but it doesn't seem as bad as some of the other examples such as classes ending in 'Manager' since this object is only solving one problem and we do have calculators in real life.

Some colleagues suggested that perhaps age should be an attribute on the customer which does seem to be a better place for this logic to reside.

On the other hand age isn't used anywhere else in the application and we don't need any of the other attributes of customer as I mentioned earlier.

I'm not sure what the 'right' solution is but there seem to be a few different potential approaches:

Should age be an attribute of the customer? There could be a tiny type 'Age' which does the above logic.
Should we have a role/interface 'ICalculateAges' which the customer implements?
Should we just keep the 'AgeCalculator'?
Is there some other solution that I'm not seeing?!

–

In reality after we'd discussed all these alternatives it turned out that the requirement was slightly wrong and that we actually needed to send down the date of birth and not the age.

I still think it's an interesting problem though and one that I'm bound to come across again!

Simon Brunning: Links for 2009-11-07 [del.icio.us]

Sun, 08 Nov 2009 08:00:00 +0000

Exploding Software-Engineering Myths - Microsoft Research
OpenOfficeMouse

This *can't* be real, surely?

Mark Needham: Knowing when to persevere and when to change approach

Sat, 07 Nov 2009 23:57:41 +0000

It strikes me that one of the most important skills to develop in software development is knowing when to keep going with an approach to a problem and when we should stop and try something else.

This situation doesn't always happen because if we have two people available and realise before we start on the task that there is some doubt as to which solution is the most appropriate then we can adopt a set based approach whereby we try out multiple potential solutions in parallel.

However I've found that there are times when we might think that one solution is much better than the alternatives and we will start working on that and discard the alternatives for the moment.

Frequently the approach we choose will solve our problem but on other occasions we can end up getting a bit bogged down when it doesn't work out as expected.

At this stage I often find that my instinct is to try and solve these problems and while I think this is certainly a valid approach it's also very easy to end up shaving the yak.

This seems to happen much more frequently when working alone and even when we're getting feedback which suggests that what we're trying isn't working we can be reluctant to back track.

I think there is some pride involved as I frequently find myself really wanting to make the current approach work as I believe that a better developer than myself would be able to do so.

Sometimes that is the case but more often than not when I work through the problem with a colleague their suggestion is to try another approach rather than continuing to struggle with the current one.

It doesn't make a lot of sense to spend all our time going down one avenue when our goal is solve a particular problem and the solution is a means to that end.

When discussing this with Nick he pointed out that we also need to recognise when we should persevere with the approach.

One way to avoid too much yak shaving is to set a timebox by when we should either have a better idea of whether we are going to be able to solve the problem with this solution or if we need to consider an alternative.

If there's some light at the end of the tunnel with an approach after this period then I would be inclined to keep on going but it's sometimes difficult to tell how close we actually are and how much is wishful thinking!

I still sometimes find myself struggling to decide whether to keep going or change direction so it'd be interesting to know if anyone has ideas around doing so more effectively.

Sumeet Moghe: Looking forward to DevLearn 2009

noreply@blogger.com (Sumeet Moghe) — Sat, 07 Nov 2009 23:42:40 +0000

If we've ever corresponded online, I'd love to have the opportunity to put a face to your name. Please do get in touch and say hi -- I'm looking forward to networking with a lot of learning professionals at the conference. See you there!

Sumeet Moghe: Put your learners on a diet - consider a pull-based learning approach

noreply@blogger.com (Sumeet Moghe) — Sat, 07 Nov 2009 22:33:18 +0000

Have you ever had a time when you got slammed in the face with a huge plate of food which you just couldn't say no to? I have. Picture the above meal -- for some it might just be the tastiest thing they could imagine. For me, while I find it difficult to say no sometimes and even if I only want a little, I have to labour through the entire meal. I just got off a five hour flight to Hong Kong, and I've had a bit of an epiphany. Let me tell you the story first. This flight left Bangalore at about 2:35 AM -- a time at which I'm usually fast asleep. So what I really wanted on this flight was some sleep. That said, airlines have a strange sense of hospitality so at about 3:30 AM they made me put my seat back upright, turned on the lights and gave me some food to eat. Well I can't say no to food, so I ate. They then kept the lights on at full-blast; don't know why, but they did. If that snack wasn't enough, at about 6:30 AM they shook me up and asked, "Vegetarian or Non-vegetarian". My instinctive response is "Non-vegetarian" and well I got what I asked for while being half asleep, but really I didn't need a big breakfast with beans, tomatoes, sausages, an omelette, potatoes, yoghurt, fruits, cheesy bread and juice. I really just wanted some sleep. A part of me wondered if it was ever going to be possible for me to tailor my flight experience for the next several years that I travel economy! And then, all of a sudden I thought about training (like I always do!).

Most training experiences push learning to the learner

Regardless of our good intentions, many of the courses we design tend to take a whole bunch of learning objectives which we then push onto the learner. We keep asking ourselves the question of whether something needs to go into a course and then we say, "But they really need to know this..." and we slam that topic right into the training. While some learners enjoy it and others endure it, we need to ask ourselves if this is really effective. Research proves that human brains work very sensibly in these situations -- we stay conscious only about the pieces of knowledge or the skills that we will need/use on our immediate work. The rest slips into the subconscious and we incubate those bits of information until we need it at a later time. John Medina's Brain Rules, explain these phenomena in great detail. So if people are only going to retain what they will use, why contaminate that message with the surrounding nice-to-have stuff?

Learners need to be self aware

People learn from experience and most learning sinks in, on the job. People learn from feedback and feedback comes not only from peers and coaches, it also comes from your environment. When you keep attempting something and get a result that you didn't expect, you're getting some feedback. The key is that as people progress on the job, they get feedback from various sources and become more and more self-aware about where they are and where they'd like to be. A safe environment to fail fast and learn from mistakes is critical to this self-awareness. So I often think that while training is important, its more important for organisations to provide a safe environment that's conducive to learning. Only then can you develop people that are truly in control of their development and have the awareness they need to succeed.

Self aware learners can pull the learning they need

Once you're self aware, you automatically know what resources you need to learn. The key is that different people learn differently. Some people learn by reading a book, others by attending a course, a lot of people can learn effectively online and there are others who learn by networking and socialising with people. The key to being a learning organisation is in providing these learning opportunities throughout someone's career. There are many ways to create these opportunities. Here are some I can think of:

Design your instructor led courses to be no more than 90 minutes each with a targeted set of objectives for each 90 minute chunk. This way, you increase your flexibility to run them on-demand
Design your elearning to be in the form of small coursels (like morsels in case of food). Think of bite-sized chunks no longer than 10 minutes. Adopt a how-to approach.
Invest in Enterprise Social Software for your firm, so that people can crowdsource learning. After all, most learning happens by talking to the guy that sits beside you, or over that cup of coffee. Most importantly this opens up opportunities for your learners to network with people they never knew
Facilitate informal events, like Hack Nights, Lunch and Learns (people bring in food and sit in a session over lunch), Pecha-Kucha nights and Ignite evenings.
Institute other forms of support such as a book budget where people have the opportunity to spend money on something they feel can help their learning.

I'm sure there are dozens of other, non-intrusive ways to create opportunities for continuous learning. What has your experience been with things such as this? Feel free to share your thoughts liberally in the comments section of the post and if you'd like to, please write to me.

(Photograph in this post taken from cocomo7's Flickr stream)

Steven List: With Blame Goes Guilt

Sat, 07 Nov 2009 20:18:29 +0000

I was talking to a colleague last night about my thoughts around A Culture of Blame. He was sharing with me one of the tactics used by management, and it occurred to me that it’s hard to live in a culture of blame without also having blame’s counterpart, guilt.

“We’ve made a commitment to our customer, and we must fulfill that commitment.” This frequently means “I made a commitment to our customer, and YOU must fulfill that commitment (or YOU will suffer).”

Poor managers frequently combine blame and guilt as their two weapons of destruction. Rather than think of positive ways to motivate people, they undermine and discourage, somehow believing that this will produce better results.

Research and anecdotal evidence reveal that reward and positive motivation work far, far better than punishment and negative motivation. And yet, there we are.

One of the many things I love about Agile teams is that we move away from blame and guilt to collaboration, support, respect, and motivation.

Tweet This Post

Liang Qiao: where is the first step in Lean thinking

Sat, 07 Nov 2009 13:31:00 +0000

Value-creating work.Activities adding directly to the value of the product as determined bythe customer. (Manufacturing examples are painting the product oradding parts during assembly.) A simple test is to ask whethercustomers would mind if this work was not done but their product stillperformed properly. If they would mind, it is value creating. Forexample, almost all customers expect their products to be painted withall the parts assembled, so these steps are value crea

Kai Hu: 5个为什么

Sat, 07 Nov 2009 12:27:07 +0000

就在前两天，我们一起合作的团队某PL在本地（而不是在专门的服务器上）手工编译大包时，忘记了清理几个文件夹，导致编出的大包不可用，发布组花了一天的时间才发现原因是编译引起的。

事实上，在持续集成服务器上，有一个项目是专门用于生成大包的，但是这个PL却宁可去手动编译，我本想给他再说教一遍自动化是如何的好，可重复，效率高，但话在出口时变成了：

你干嘛不在持续集成服务器上点一下呢？手工编多麻烦啊，还得改配置。

我也知道啊，但是不能点啊，我看不见那个按钮

你为什么会看不见那个按钮呢？把页面打开我看看

原来是没有权限啊，你为什么不让管持续集成服务器的人给你开个权限呢？

他不给开啊

我去问问。

于是我找到了负责持续集成服务器人：

嘿，你为什么不给XX开权限呢？他在负责生成大包呢。

如果给了他权限，几个人都一起点上面的按钮怎么办呢？

不会的，你看（演示给他看），服务器自己会处理的

你看，原来真正的原因在这里，负责持续集成服务器的人不了解持续集成服务器的工作机制，对未知的恐惧让他不相信任何人，打消了他的顾虑，我又回到之前犯了错误的PL那里，

最后一个问题，就算手工编译，为什么不在服务器上进行呢？你自己的机器多慢啊

服务器是Windows 2003，允许多人登录，我如果在上面手工编译，可能会有别人也在上面编译的，协调机会出问题的，而且还有别人在上面调试脚本，我可能会影响他们的。

于是我和他一起重新配置了2003服务器，只允许同一时刻一个用户登录。

并且我得到了下面的问题列表：

为什么不能同时编译不同的项目呢？问题在哪儿？

为什么有人在服务器上调脚本呢？服务器不是工作机，他们面临的是什么问题？

…….

还记得当初我们面对的问题么？

有人不去自动化的生成大包

我们解决了的是什么问题呢？

对持续集成服务器的功能不熟悉

服务器的操作系统没有经过精心的配置

当我们不断的追问时，你会发现问题的真相在不断的浮出来，用眼睛观察问题，也不见得为实。亲爱的咨询师同事们，我建议你们也在自己的工具箱里面加上这个工具： 5 Whys

Liang Qiao: 如何使用企业持续集成成熟度模型？

Sat, 07 Nov 2009 10:34:00 +0000

所有团队在四个维度都达到统一的企业持续集成成熟度是很困难的。企业持续集成在不同的条件和状态下，应该考虑选择不同的方向来实现或加强。为了表明这一点，下面是一个企业的例子，提供了企业持续集成混合成熟度的解决方法。

Liang Qiao: 企业持续集成成熟度模型简介之四——报告

Sat, 07 Nov 2009 09:46:00 +0000

持续集成工具一直以来就负责报告最近一次构建的状态。报告是持续集成的一个至关重要的元素。在企业持续集成中，报告应包含所做软件的相关质量和内容方面的信息，以及与企业持续集成过程有关的度量信息。没有报告的团队就象一个没有雷达的飞机在飞行。如果没有人看测试结果的话，所有的测试都是无用的。同样，很多数据如果没有被提取成可消化利用的信息的话，就很难使用，一样可以视为无用。越成熟团队的报告，其可视化程度越高，有用的信息也会越多。很多工具在构建过程中都会产生报告。在一个团队中，如果某人利用一些工具来产生报告，并分析它，之后会根据它来做出行动的话，这个团队就已经是入门级成熟度了。

Simon Brunning: Links for 2009-11-06 [del.icio.us]

Sat, 07 Nov 2009 08:00:00 +0000

Setting up a Python CI server with Hudson
Thank you, Rails
Python in the Scientific World
It’s Okay To Write Unit Tests
Post/Redirect/Get
GitX

GitX is a git GUI made for Mac OS X
The Twitter Times: brunns

Patrick Kua: Fixing Notepad++ 5.5 Langs.xml

Fri, 06 Nov 2009 18:25:02 +0000

I upgraded to the latest version of Notepad++ (5.5) and noticed that I sometimes get some problems with a dialogue box that pops up, looking like the picture the right stating (Load Langs.xml failed!)

Having a quick look at the installation directory, it looks like a langs.xml file exists yet it has a 0KB size. I’m not sure what causes it yet (perhaps it’s if you kill the process mid-way using Task Manager) but all I did was take a copy of langs.model.xml and rename the copy as langs.xml. Fixes it all up!

Jie Xiong: Sponsor的价值所在

Fri, 06 Nov 2009 14:38:10 +0000

今儿给麦罗打电话的片段摘录…

我：俺们SVN server装Windows上，用个32位Apache做前端，那玩意有2G内存限制…
麦：一，用Windows做SVN server。二，代码库很大。三，很多人同时访问。
我：对头～～
麦：你在XX公司？

知音啊～～我又内牛满面了～～介个就是Sponsor的价值亚～～

Mark Needham: TDD: Useful when new on a project

Fri, 06 Nov 2009 11:57:10 +0000

Something which I've noticed over the last few projects that I've worked on is that at the beginning when I don't know very much at all about the code base, domain and so on is that pairing with someone to TDD something seems to make it significantly easier for me to follow what's going on than other approaches I've seen.

I thought that it was probably because I'm more used to that approach than any other but in Michael Feathers' description of TDD in 'Working Effectively With Legacy Code' he points out the following:

One of the most valuable things about TDD is that it lets us concentrate on one thing at a time. We are either writing code or refactoring, we are never doing both at once.

It also temporarily removes us from the feeling of drowning in all the new information which is typical at the start of projects. In a way it reminds me of the 'Retreat Into Competence' pattern from 'Apprenticeship Patterns' as it gives us a chance to regain composure and take in all the new information.

We can probably make a much more useful contribution if we only need to understand one small piece of the system rather than having to understand everything which can often be the case with what Feathers coins the edit & pray approach to development.

It's still necessary to spend some time trawling around the code base working out how everything fits together but I'm now more aware that it's also really useful to take some time to just focus on one much smaller class or piece of functionality.

Perhaps also something to keep in mind the next time I'm pairing with someone who's new to a project that I've been working on for a while.

Simon Brunning: Links for 2009-11-05 [del.icio.us]

Fri, 06 Nov 2009 08:00:00 +0000

Mingle + Google Wave for Project Collaboration
twategy inc

At least, I *hope* it's funny...
Customize MediaWiki
Les Sapeurs du Congo
Customise GMail offline

Superb
Google Dashboard
Actor model
Ubuntu 9.10: "unknown filesystem type 'iso9660'"

Not just me then.
How To Use An Apostrophe
The rise of the non-veggie vegetarian

Tarek Abdelmaguid: Shouldn't We Local-Optimize at Bottlenecks?

noreply@blogger.com (Tarek Abdelmaguid) — Fri, 06 Nov 2009 00:28:19 +0000

The short answer is no. Once we start thinking local, we are heading down the wrong path.

Consider what we should do at a bottleneck:

Increase the resource's throughput, by increasing its efficiencies.
Manage the flow in the system to reduce idle time at the resource.
Add more capacity, by introducing other resources capable of the same function.
Outsource a portion of the work to resources outside the system.
Rethink the need for some work to go through the bottleneck.

You'd notice that only the first of these points is local in nature, and we should only consider it as an option. It may not be the best one.

Felix Leipold: Objects as Functions in Java

Thu, 05 Nov 2009 16:30:36 +0000

Earlier this year I wrote a build tool in java. The core idea at the time was to express the build in terms of functions and function composition. This is not exactly a good fit with java. So last week I had some spare time and came up with this way of defining a function (application) in java:

 
 public static class FancyFunction extends FunctionBase {
        @In
        public final Str a;
        @In
        public final Str b;
 
        @Out
        public final Str c = null;
        @Out
        public final Str d = null;
 
        public FancyFunction(Str a, Str b) {
            this.a = a;
            this.b = b;
            super.reflect();
        }
 
        protected void evaluate() {
            setResult(c, new StrImpl(a.getValue() + "-" + b.getValue()));
            setResult(d, new StrImpl("XX"));
        }
    }

There is obviously a lot of magic going on and I do feel a bit bad abou setting final fields using reflection.

What it actually does is defining two functions. In a friendlier syntax somwhat like this:

 
fancy.c(a, b) = a + "-" + b;
fancy.d(a, b) = "XX";

But back to the java example, you can now compose applications like this:

 
FancyFunction fun = new FancyFunction(new StrImpl("x"), new StrImpl("y"));
FancyFunction fun2 = new FancyFunction(fun.c, new StrImpl("z"));
assertEquals("x-y-z", fun2.c.getValue());

As this is all very reflective I could actually traverse the metadata and get dot to render this:

There is no code, as it is all very dirty. But to me it looks like a viable syntax for specifying tasks and wrapping imperative code into a functional style. The current implementation relies heavily on interfaces, because it generates a lot of proxies that allow for lazy evaluation.

Peter Gillard-Moss: Killing the Config

noreply@blogger.com (Peter Gillard-Moss) — Thu, 05 Nov 2009 10:13:58 +0000

Most applications require config of some description and it is considered good practice to wrap any calls which retrieve configured values in a config class and pass that around rather than splattering the codebase with direct calls to the frameworks inbuilt static methods.

With all the applications configs neatly wrapped in one place the code starts to become more maintainable. Yet are we just replacing one evil with another, if somewhat lesser, one? The problem I often see is this Config class finds itself passed from class to class flouting it's promiscuity and leading writers of articles on config objects down paths dangerous and full of inappropriate metaphors more commonly favoured by the ruby crowd.

There is no doubt that it is useful to collate all of the configurable elements together in one (or more) common classes. What should be avoided is leaking this concept through the whole domain and kicking it from object to object like a dirty old data bag which everyone rumages through, unchecked, pulling out stuff on their own whim. Config is an implementation detail which the majority of the application should have no concept of and (like any other such implementation details) it needs to be locked firmly away like a lump of kryptonite in a lead cased layer so it can no longer leak and permeate and weaken your SuperApp.

Let's think about this in a BDD fashion. When your class want's a ghostbusting url who's it gonna call (they have a webpage now dinyuknow)? string Config.GhostBusterUrl? Or perhaps the GhostBusterUrl class? If your class needs a typed collaborator with certain logic and behaviour (even if it is just supplying a valid url) then that's what your class should get. Not some smelly generic config object that dishes out dirty unparsed strings. The tests should be enough to tell you I'm telling you the right thing: several lines of priming the mockConfig are replaced with the simple supply of a GhostbusterUrl.

So how do we get the GhostBusterUrl from a line in config to those poor desperate classes who are being terrorized by spooks? With a little Tell don't ask and a container. Turn the config object inside out, make its role to inject into the application the dependencies it wants to supply. If your config believes it has a GhostBusterUrl then get it to construct one and register it (along with anything else it thinks it might have of use) into the container when the application tells it to. Not only does the config object gain some of its dignity back (some other classes were calling it nasty names, I know, it's the new millennium, but some people still hold the old fashioned ideas) and is safely kept right to the very edges of your application where no one can get at it.

Another positive side effect is that now your config object is giving birth to loads of lovely typed objects that actually do real stuff rather than having wandering hands pluck at its primitives (I know but I did warn it was a dangerous path laden with tasteless innuendos, I was bound to trip). Though of course, be careful not to pollute your codebase with a million classes that simply represent strings and do nothing else (it's a fine line and one you'll need to argue between me, myself and I). It's also one of the easiest refactorings you can do to your code. Give it a go (and if you object on the grounds of their being loads of small types then please find the closet crumbling procedural bridge and throw yourself into the polluted sequential river below).

Simon Brunning: Links for 2009-11-04 [del.icio.us]

Thu, 05 Nov 2009 08:00:00 +0000

ThoughtWorks Studios Rolls Out New Version Of Mingle, Integrates With Google Wave
Game review | Borderlands

Oooooh
The death of Agile

At least he's nice about us.
Why Git is Better Than X

James Crisp: Percent Number in Apache Rewrite Rules (mod_rewrite)

Thu, 05 Nov 2009 01:16:49 +0000

What do the %1 %2 in a Rewrite rule mean? The Apache guide does not help, nor does any other documentation I found. I came across the %1, %2 etc in some complex and arcane rules. Google ignores percent signs, which makes it hard to get an easy answer.

We'll use the rules from my last post as an example.

RewriteCond %{HTTP_HOST} !^www\. [NC] RewriteCond %{HTTP_HOST} ^([a-z.]+)$ [NC] RewriteRule ^/(.*)$ http://www.%1/$1 [R=301,L]

The %1 refers to the capture group in a previous RewriteCond. This differentiates it from the $1 which refers to a capture group in the current RewriteRule.

Hopefully I have littered this post with enough keywords that future googlers will find the answer to the %1 %2 in ReWrite rules more easily

James Crisp: Adding WWW to domains, and Apache Rewrite Rules (mod_rewrite)

Thu, 05 Nov 2009 00:54:45 +0000

Browse to http://google.com. Then look at the address bar. You're not really at http://google.com. You've been redirected to http://www.google.com. Try the same on w3c, Facebook, Sydney Morning Herald etc.

Why WWW?

Why do all these sites redirect you to a www form? Well, the main reason is because it is advantageous to have a canonical URL, and, if your have to choose one URL, you might as well go with what people seem to expect, which is to include a 'www'.

What's so great about having one canonical URL?

Cookies: if your users can access the site at www.domain.com and domain.com, you can end up with some horrible cookie and session problems depending on the browser and web framework (behaviour is different between Firefox and IE). Stay tuned for another post with more details on this.
Certificates for HTTPS: certificates are usually for a single domain. If your site is available with and without 'www', your site will need a certificate for each or a multi-domain certificate (ie, more money and config).
Caching: if you have two URLS, any HTTP caching will only be half as effective
SEO: your page rank may be split between links to both possible URLs (though Google Webmaster tools seems to let you combine it)

How?

Right so, now you're probably just hoping there is an easy way to implement this forced 'www' business! Well the good news is that it's quite easy if you're using Apache with mod_rewrite. I googled around to try and find some good rules, but the ones I found were tied to a single hard coded domain (no good for me where I have multiple domains pointing to the same server for different countries). See below for what I came up with. It seems to work quite well. You can put it in your virtual host configuration file or even .htaccess file.

RewriteEngine on RewriteCond %{HTTP_HOST} !^www\. [NC] RewriteCond %{HTTP_HOST} ^([a-z.]+)$ [NC] RewriteRule ^/(.*)$ http://www.%1/$1 [R=301,L]

Line 1: Are you coming to the site without www. at the start of the host? [NC] means ignore case.

Line 2: Does your domain comprise of letters and dots (this means that going to the IP address will not fire the rewrite rule). Grab the domain in a capture group.

Line 3: Rewrite the URL with a www at the front, and keep the hostname from the previous condition (%1) and the path after the domain ($1). Use a status code 301, to tell the client that this is a permanent redirect.

Chad Wathington: Google Wave Integration

Wed, 04 Nov 2009 18:45:22 +0000

Today, I presented at Enterprise 2.0 during the keynote with Greg D'alesandre from Google on Mingle Wave integration. You can learn more about the integration here:

http://studios.thoughtworks.com/mingle-agile-project-management/mingle-and-google-wave

Planet TW

Simon Brunning: Links for 2009-11-13 [del.icio.us]

Sumeet Moghe: DevLearn 2009 - The Changing Learning Function: Rethinking how your organization works

What I learnt

Mark Needham: Mercurial: hg bisec

Sumeet Moghe: DevLearn 2009: Yawn-Proof Your e-Learning without Busting the Bank

Key Takeaways

Sumeet Moghe: DevLearn 2009 - Leo Laporte's keynote on New Media

Patric Fornasier: Lessons Learned (Part 2: Performance Testing and Garbage Collection)

Mark Needham: TDD: Combining the when and then steps

Jie Xiong: 三人成众

Patric Fornasier: RSpec and TextMate

Simon Brunning: Links for 2009-11-12 [del.icio.us]

Felix Leipold: Using Extension Methods

Sumeet Moghe: DevLearn 2009 - Web 2.0 and Performance: What's working for Google employees

Key Takeaways

Sumeet Moghe: DevLearn 2009: Catch the WAVE: Google WAVE and e-Learning Applications

So what should you know about Google Wave

A few things that people may not know about Wave

Mark Needham: Adapting our approach for the context

Immutability

Confidence changing code

Final thoughts

Dan North: The lady in the taxi – a parable of metrics

Sumeet Moghe: DevLearn 2009 - Eric Zimmerman's Keynote on "Meaningful Play"

Paulo Caroli: Most if-statements are evil

Ola Bini: QCon San Francisco, RubyConf and JRubyConf

Simon Brunning: Links for 2009-11-11 [del.icio.us]

Patrick Kua: What they don’t tell you about user stories

James Crisp: HTML to PDF Conversion Plugin For Rails (A fork of wicked pdf)

Sumeet Moghe: DevLearn 2009: Kim Zibrick's session on Business Alignment: Focus on the Workplace ...Not the Classroom!

What did I learn?

Sumeet Moghe: DevLearn 2009 - Ruth Clark's session on Evidence Based Training

What did I learn?

Sumeet Moghe: DevLearn 2009 - Andrew McAfee's Keynote. Enterprise 2.0 - the state of the art

What did I learn?

The Definition of Enterprise 2.0

The State of the Art

Altruism

Process

Innovation

Intelligence

Benefits

Impact

Things to Avoid

Sumeet Moghe: DevLearn 2009 - Actions Speak Louder than Words, by Ethan Edwards

What did I learn?

Ross Pettit: Restructuring IT: Organizing for Results

Mark Needham: Coding: Pushing the logic back

Simon Brunning: Links for 2009-11-10 [del.icio.us]

Sumeet Moghe: DevLearn 2009 - Ruth Clark's workshop on Scenario Based Learning

What did I learn?

Simon Brunning: Links for 2009-11-09 [del.icio.us]

Dahlia Bock: Working Effectively with Legacy Code (Robert C. Martin Series)

Mark Needham: Legacy Code: Sensing

Jie Xiong: 测试驱动咨询

Thomas Czarniecki: HTTP method primer for RESTful web services

Ola Bini: A week at Øredev

Joe Poon: The Last Mile

James Crisp: Presentation Zen by Garr Reynolds

Ye Zheng: 我们很忙

Mark Needham: Coding: The agent noun class

Simon Brunning: Links for 2009-11-07 [del.icio.us]

Mark Needham: Knowing when to persevere and when to change approach

Sumeet Moghe: Looking forward to DevLearn 2009

Sumeet Moghe: Put your learners on a diet - consider a pull-based learning approach

Most training experiences push learning to the learner

Learners need to be self aware

Self aware learners can pull the learning they need

Steven List: With Blame Goes Guilt

Related posts

Liang Qiao: where is the first step in Lean thinking

Kai Hu: 5个为什么

Liang Qiao: 如何使用企业持续集成成熟度模型？

Liang Qiao: 企业持续集成成熟度模型简介之四——报告

Simon Brunning: Links for 2009-11-06 [del.icio.us]

Patrick Kua: Fixing Notepad++ 5.5 Langs.xml

Jie Xiong: Sponsor的价值所在

Mark Needham: TDD: Useful when new on a project

Simon Brunning: Links for 2009-11-05 [del.icio.us]