patkua@work

The intersection of technology and leadership

Page 20 of 53

Coaching Tool: Coaching DOJO

October 10, 2011 / / 0 Comments

Short Description:Group of people getting together and coaching each other potentially using GROW model. Use short rounds with time limits.

How to run it

  • Seeker (a role that rotates) shares the problem with 2 other coaches and 2 other observers watching. Time boxed to 5 minutes.
  • 2 coaches comment in an active coaching role. Time boxed to 10 minutes
  • 2 observers then comment about the interactions. Time boxed to 10 minutes.

Original Source:
Sergey Dimiticus in Oslo and Rachel Davies

Where it’s been used
In agile coaching camps, learning together to generate coaching ideas and developing coaching skills.

Contributed from the participants of my XP2011 workshop

RESTEasy could not find writer for content-type application/xml type…

October 8, 2011 / / 0 Comments

I had been spiking around with RESTEasy in order to use some of the JAX-RS stuff for dealing with remote endpoints. We had a client library that already wrapped some of these end points and some DTOs that mapped to the XML the remote end point wanted. We wanted to use the JAX-B annotations to deal with the automatic conversions but kept getting the dreaded… 

java.lang.RuntimeException: could not find writer for content-type application/xml type: [.... Dto]

The secret to getting this to work was to ensure that you have the correct runtime libraries in the classpath, or more specifically the following jar.

GroupID: org.jboss.resteasy
ArtifactID: resteasy-jaxb-provider

Thanks to this thread for the help on that.

Running Scalatra Tests with JUnit (in a maven or ant build)

October 7, 2011 / / 0 Comments

I’ve been playing around with Scalatra and one of the things that wasn’t quite obvious was when I had it running as part of a test run build (using the JUnit) runner, these tests weren’t getting picked up.

The key to this was ensuring you annotate the class with the @RunWith(classOf[JUnitRunner]) attribute as part of the build.

package com.thekua.scala.example

import org.scalatra.test.scalatest.ScalatraFunSuite
import org.scalatest.matchers.ShouldMatchers
import org.scalatest.junit.{JUnitRunner, JUnitSuite}
import org.junit.runner.RunWith

@RunWith(classOf[JUnitRunner])
class JsonScalatraTest extends ScalatraFunSuite with ShouldMatchers {
  val servletHolder = addServlet(classOf[JsonifiedServlet], "/*")
  servletHolder.setInitOrder(1) // force load on startup

  test("JSON support test") {
    get("/") {
      status should equal (200)
    }
  }
}

Smooth Scala XML APIs

October 5, 2011 / / 2 Comments

As an alternative to using JAXB for reading input, we thought we’d try simply wrapping an XML document in a class structure. XML is a first class citizen in scala, so we thought we’d have a look at what it would be. Note that we don’t expect very large XML documents (they all easily fit into memory) but the external structure is a little bit ugly.

We inject the XML document into the class via the constructor and then using scala X-Path equivalents, we pull out the interesting fields. I have to admit it’s better than dealing with XML xpath in the java world, and the code is pretty simple.

I’ve written an equivalent to give you an idea of what we evolved from.

Given we have an XML document that looks like this (domain made up here)

<profile>
  <names>
     <defaultName>Harry Potter</defaultName>
     <alternativeNames>
        <name>Harry</name>
        <name>Mr Potter</name>
     </alternativeNames>
  </names>
  <contact>
     <email>harry.potter@hogwarts.com</email>
     <website>http://hogwarts.com</website>
     <phone>http://hogwarts.com</phone>     
  </contact>
</profile>

We ended up with a class that looks like this

import xml.Node
class Profile (xml: Node) {
  def name = {
    (xml \ "names" \ "defaultName").text
  }

  def email = {
    (xml \ "contact" \ "email").text
  }

  def website = {
    (xml \ "contact" \ "website").text
  }

  def phone = {
    (xml \ "contact" \ "phone").text
  }
}

We can apply a couple of small refactorings here. Simple one line expressions do not need curly braces. The class now becomes:

import xml.Node
class Profile (xml: Node) {
  def name =  (xml \ "names" \ "defaultName").text
  def email = (xml \ "contact" \ "email").text
  def website = (xml \ "contact" \ "website").text
  def phone = (xml \ "contact" \ "phone").text
}

Maybe we also wanted to remove a little bit of duplication in the xpath. Though this increases the size of the class a bit: 

import xml.Node
class Profile (xml: Node) {
  def name =  (xml \ "names" \ "defaultName").text
  def email = (contact \ "email").text
  def website = (contact \ "website").text
  def phone = (contact \ "phone").text

  private def contact = (xml \ "contact")
}

Since our XML structure will now change, we also had some feedback that we could use the lazy val option to cache the results. The code now looks like this:

import xml.Node
class Profile (xml: Node) {
  lazy val name =  (xml \ "names" \ "defaultName").text
  lazy val email = (contact \ "email").text
  lazy val website = (contact \ "website").text
  lazy val phone = (contact \ "phone").text

  lazy val contact = (xml \ "contact")
}

I’m not so sure if the last two refactorings give much more than the second refactoring, but it certainly helped me learn a a bit more scala. I think we had some pretty good wins by dealing with XML the scala way. Our tests are very readable because you don’t have weird string concatenation or sucking in XML from a file to test it, and I think the code is quite readable. I would have preferred closer XPath-y syntax, but I guess learning the scala XML syntax for traversing XML isn’t too bad. The other good thing about this is that you don’t have to worry about null or non existant nodes – you simply get back an empty string. Pretty decent default behaviour for at least our use case.

We do “TDD.” Oh really?

August 21, 2011 / / 20 Comments

During Agile 2011 I tried to speak to people about what technical practices they did, and to what degree as well. Unfortunately I left the conference slightly disappointed and now understand why Uncle Bob champions the Software Craftsmanship movement as a way of addressing a balance the agile community at large has lost.

Don’t get me wrong. I appreciate that we need to focus on people and system issues in software development just as well. However, it’s laughable to think that software development is the easy part. I’m not the only one who feels this way. In order to succeed at real agility, you need just as much discipline and attention to detail to the technical practices, tools and methods just as you do everything else. It seemed like people were trying to be a good sports team, by finding the best people, hiring the best coaches, and then forgetting to schedule time for the drills and training.

One particular conversation stuck with me. We had this in the airport lounge at Salt Lake City before departing for Chicago. It kind of went something like this:

Other: We only tend to TDD the happy path
Me: Oh? Out of interest, what sort of test coverage do you end up with?
Other: About 20 or 30%. Why, how about you?
Me: Depends on what sort of application. Adding up the different types of tests (unit, integration, acceptance), I’d probably guess in the high 80s to 90s.
Other: Wow. That’s really high.

This conversation got me thinking about whether the other person’s team really benefits from doing TDD. I’m guessing not. They are probably getting some value from the tests, but probably equal value by doing test after. If you really wanted to be a pedant, you could argue, how do you do TDD without actually driving (most of) the code with tests? I’m not a TDD zealot. I’ve even blogged about when to skip TDD, however one of the biggest benefits of writing tests is the feedback they give and the way that it changes the way that you design code. I’m guessing by skipping the “unhappy paths”, there’s plenty of feedback they miss out on.

Reflecting on Agile 2011

August 12, 2011 / / 0 Comments

This US-based series of conferences are quite different from the XP20xx series I normally attend. I last spoke at, and hence attended the 2009 one held in Chicago. The related Grand and Little America Hotels hosted this year’s conference in Salt Lake City turning into a pretty good host for the 1600+ registrants that descended upon Utah.

I think it worked very well as a conference venue because people spent more time at the venue than at surrounding attractions and the small but wide corridors and spaces helped make it feel more conversational than faceless crowd.

General Thoughts
An impressive eighteen concurrent track ran almost entirely throughout the five day period offering many choices for all types of participants from novice to experts. Like 2009, I found that there weren’t that many sessions that really provoked new thoughts, challenges, or entirely new areas to explore yet I enjoyed meeting many old friends and meeting many new ones as well.

Highlights for me included the initial keynote, sitting in a systems thinking session and the general vibe of the conference. I particularly liked the fact many new things were tried (experimentation and willing to fail all part of this) such as the “Dinner with a stranger” program or the way “Park Bench” setting in the very popular Open Jam space.

The rest of summaries of some of the sessions that I attended.

First day keynote, “Why Care About Positive Emotions?”
Interestingly many people, including myself were a bit taken aback when Dr Barbara Fredrickson first took the stage. Introduced as an academic and taking a softer style, I wasn’t quite sure how she was going to be as a keynote speaker, however both the topic and relevance to the way that we work really made a huge impact and I came away really enjoying it.

Fredrickson talked about why we should care about positive emotions, particularly in the way that we work and commented on the succinct yet ever-relevant Agile Manifesto over their more verbose one. She focused on two key facts about positive emotions:

  1. Positive emotions open us
  2. Positive emotions transform us

What the research indicates is that it creates more possibilities, more creativity, more resilience, and better performance. She also notes about the fairly well known ratio of 3 positive events to outweigh 1 negative event (and more is good) however in a very balanced statement pointed out that we also equally need negative events. Taking the “be positive” saying as an edict is not only harmful to the heart, but it masks negative emotion and produces insincere positivity.

I liked the way that she presented it as thinking about “nutritional value” and thinking about whether or not we’re meeting our daily doses closing with the advice of “creating the mindset for positivity”, not just pretending to have it.

One thing I plan on trying for the next two weeks is starting my day with a “Morning Appreciation” to reflect on what positive things I already have in my life.

Ron and Chet’s Lessons Learned
I dropped into Ron and Chet very raw and honest look at what they recommended as part of XP, and what they would change. I liked the way that they looked at some of the ways people took some of their recommended methods in XP and how they would modify it now understanding the passage of time.

Practices and principles they would still keep included frequent releases, simplicity, solid technical practices, reality based management and cross functional teams. The things they would revisit included the estimation and planning process (using points and velocity for planning) because it didn’t change people’s mindsets – only worked to satisfy people’s questions “when would it be done” and that “agile” was a bad name because it was too good.

Seeing and Steering Systems
Hosted by Esther Derby, this session guided us through step by step building systems diagrams to look at inter-related effects. The steps were quite simple, but my Teachable Moment was ensuring that when drawing the things that effect each other, use Nouns or Noun Phrases. This made a whole lot of sense to me because describing things as negative, positive or increasing/decreasing makes the loops difficult to understand.

The steps I came away with included:

  1. Start with the problem – Draw related circles attached to that central node that are affected. When done, draw related circles to those other related circles and keep going until you have a “Shape of the problem”. Looking at a problem this way may surprise you at who and what is really impacted by the thing that concerns you.
  2. Start “Finding Factors” by looking at inner-to-outer, outer-to-inner, and bi-directional forces. Brainstorm these and filter to those that are most important. Be sure to use noun and noun phrases that are neutral (or positive is generally okay)
  3. Build the links – with amplifying, dampening cycles and you end up with your systems diagram.

Applying learning theory to a real language

August 1, 2011 / / 2 Comments

My current project work colleagues know I’m learning German while I’m here in Berlin. I doubt I’ll become fluent by the time I leave, but I feel I’ve learned plenty – even without being able to speak it full time at work, or with very few official German lessons.

I feel part of what has helped me successfully accelerate my learning is applying my understanding of learning styles to learning a “real” language (not a programming one for once!) Some of the lessons learned include:

Showing my ignorance – I talked a lot about this during my Beginner’s Mind talk. Being in Germany, I’m surrounded (mostly outside of project work) by people who are experts in the field of the German language. By attempting (and generally failing fast!), I can find out where the current limits of my vocabulary, sayings and articulation is. Trying again then lets me practice more and more.

Accepting that it is the way it is – The hardest things about learning other languages is the “nuances” that come along with the language. Real languages are “loose” with their meanings, and just because you say one thing in English doesn’t mean you can translate it word-for-word to another.

Find multiple “masters” – Just like there is no single “agile” way of working, and there is no “correct” philosophy, it’s good to have multiple teachers and sources of truths. I’d had a few official German lessons, I listen to Pimsleur audio guides, use Rosetta Stone for learning, (try to) read German magazines and try to use German where I can. Each source focuses on different things and all useful in different ones. Pretending that you can learn everything from a single source is destined for failure.

On the way to 10 000 hours – I believe learning real languages takes much longer than that, but trying to use it and practice it as much as possible has definitely improved my novice skills. Even native Germans have commented on how quickly they’ve noticed the language skills improve.

Vocabulary and grammar work as a system – Learning vocabulary without grammar makes you sound strange, and grammar without vocabulary really limits your conversations. Learning both at the same time forms an amplifying loop that allows you to learn more faster.

Align your passions – Anyone who knows me will know I enjoy my food and drink. I blog about it and love discovering neighbourhood gems in a new city. So much so my biggest asset in learning more German has been the Zitty Berlin Essen + Tricken (Food & Drink) magazine special that details restaurants, cafes, and bars around Berlin. I spend time translating each small review of each place and because I’m familiar with many of the places, I can better understand what they’re trying to say. Admittedly I’m not sure how much use all of the language is but it certainly is helping.

Systems Diagramming Tools

July 20, 2011 / / 2 Comments

Just a quick reminder to myself about a number of tools available to people interested in Systems Thinking:

  • Flying Logic (Commerical) – My favourite so far with nice looks, and an emphasis on building the diagram collaboratively instead of simply focusing on output. It automatically adjusts the layout when adding in nodes for minimal line-cross overs. Can be a be nauseating sometimes.
  • Graphviz (Free) – Simple looping diagram that’s easy to automate. Not was good representation for causal loops if you want to discriminate amplifying/dampening cycles, but good bang for buck
  • Omnigraffle (Commercial) – Diagramming tools that makes very snazzy diagrams. Less powerful on automatic layout than Flying Logic. Mostly manual.

Writing feedback as a conversation with the recipient

July 8, 2011 / / 4 Comments

We had a couple of people roll off our project recently. Even though we had been doing regularly feedback as a group, each person still wanted some written feedback to take with them to their next project. In writing down the feedback (and trying to collate all my thoughts from previous sessions) I found it was immensely useful to write the feedback as if I was talking to the person.

In past occasions, for some reason, I wrote a lot of feedback as if someone else was going to read it. For example, “I worked with <Joe> and noticed… It had this impact…”

Rather than as if I was writing feedback for someone else, I tried to write the feedback as if I was talking to the person. Framed in the context of the person who will benefit from receiving the feedback, I think it really changed the way that it made me think about it. It really focused my attention on feedback that would really help the person grow – reinforcing those behaviours that they should continue doing, and bringing to attention those behaviours that continued to puzzle me, or bringing to attention those behaviours that might take much more time than a single project to develop.

I found that writing feedback as if I was talking to the person also helped me humanise and personalise a lot more of the feedback I wrote down. Why don’t you give it a go next time?

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders Noren — Up ↑