My Map: Places To Work Down-Town In Portland, OR

I finally put together a mini map of all the places a software developer might like to consider working at within a 2 mile radius of down-town Portland. Feel free to point out any I missed.


View Larger Map / See Full List

Email me at curious dot attempt dot bunny at gmail if you know of anything I've missed on this map.

PS My first reaction to Google's My Maps was: "why do I have to own this map?"

You Heard It Here First

I'd like to point out that Brian quoted Russ as saying: "The reason people are looking at Erlang is not because its beautiful syntax, great documentation, or up-to-date libraries. Trust me. It's because the Erlang VM can run for long periods of time, scaling linearly across cores or processors filling the same niche that Java does right now on the server."

STIQ It To The Bugs

At our XPDX meeting we had a relatively heated debate discussing the idea of "No Bugs". There were generally three camps of thought:
1. That's ridiculous you need a bugs database
2. I believe in "No Bugs" I just haven't seen it happen
3. It works for us

Along the way we touched on another favourite topic of mine: Acceptance Testing. Aaron mentioned an interesting tool that had surfaced at Agile 2007. I haven't looked at Story Test IQ (STIQ) yet but the concept sounds very promising:

"STIQ is a tool for creating Acceptance Tests or “Story Tests”, and combines open source browser-based testing, a simple command language, wiki-based editing and pluggable features. The tool is used for writing acceptance tests while developing web applications. STIQ is a combination of FitNesse and Selenium, popular open-source acceptance test tools." (InfoQ)

Edit: I had a play with STIQ this evening. I get the impression that it's not tested under Linux much as the shell script failed with Bad Interpreter (due to windows linefeeds). Oddly the -DSeleniumHtaRoot setting was different for the Linux script and broke the tests. Even once I corrected that their own release suite had 3 failures. A number of other UI details irritated me a bit like drilling down into test failures and then losing the result of the test run.

I guess I wasn't that impressed because what had gotten my attention to begin with were the 2.0 features that have been announced but not yet released:

"STIQ 2.0 advances testing beyond user-interface scripting with new features including domain-specific language support, enabling increased productivity, and better team-to-client collaboration."

PS I'm not in a great mood this evening so it probably wasn't the best time for me to be evaluating software. I would be interested to hear what other people think of STIQ though.

Google Test Automation Conference On YouTube

Videos of the conference are to be released here shortly.

Edit: you can find the playlist here. I've watched a couple of hours of the GTAC videos. So far there's not been anything novel enough to report on.

Edit: there's a good summary of GTAC here. I've since seen the Interaction Based Testing (or rather: Isolation Based Design) video which I highly recommend.

So You Just Hate All Agile Planning Tools...

At our local XP meeting last night Arlo was very vocal about hating pretty much all planning tools for one valid sounding reason or another. So it was interesting to read about someone else loathing various tools before settling on one they liked (BaseCamp).

Maybe I'm not so selective but I found Xplanner to be rather good. My only grumbles were:
1. the story & task units are in hours (although I think the upcoming release permits arbitrary units)
2. stories couldn't be grouped into categories (we were decomposing waterfall-style use cases into stories)
3. it wasn't easy to see what the changes were since the previous day

Hiring For An Agile Team

I guess this is true: "If you keep your questions short and focused on current or most recent projects, you're more likely to hear an answer to the question you wanted to ask." I'd always thought the key to a successful interview was to asked open ended questions. Read more.

The Art of Agile Development

Yay! This book is out in under a month now.
In the spirit of Agile the book was open for review online and incorporated feedback from the community via a discussion group. I also like that the authors weren't afraid to defer to other experts as demonstrated by the guest chapter on exploratory testing by Elisabeth Hendrickson.
Anyway, pre-order it. I'd be very surprised if you are disappointed.

Good Advice For XP Adoption

Manuel Klimek has some good suggestions for ways to increase your teams adoption of XP practices:

"Propose a "process improvement meeting", which is basically a retrospective. In this meeting our project lead asked the question: What is going badly at the moment?
Tadaaaa: you're silent. Yes, you know all the problems, but don't tell anybody.
Now when I said nothing, step by step each team member said one or two things that he found to run badly. And in the end (this is true) they had all but one point on the list of things that go wrong that I had come up with in the beginning.
Now the project lead asks: So, what are we gonna do about that? And now's your chance to take each of those problems and explain to the team how one or more practices of XP address those problems. And then the project lead says: well, why not try those things for a month and see if they work and what we're gonna keep.
...
Oh, and another trick that helped for us to get people to pair program: We have a high-end pair programming machine. Fast, lots of RAM, four Raptor drives giving two RAID-0s. Those machines are not personalized to one developer, so nobody feels "at home" or the "guest". You may only use the pair programming machine if you pair program."

Joe Rainsberger's Greatest Misses 2000-2007

Joe Rainsberger's tutorial was by all accounts pretty popular at Agile 2007. So maybe you should take a reality check before risking being branded an 'XP fanboy' as he puts it...

Great Teams Are Rare

Cleve Gibbon writes an interesting post reflecting on the qualities of a great team. Give it a read.

No Thoughtworks In Portland

What a breath of fresh air: "Your unit tests, at least one for each class in your codebase, should be clean, decoupled from one another, and run ultra-fast. We think you should be able to run thousands of unit tests and get your green bar in a few seconds." (from Ashcroft).

Thoughtworks have a YouTube video that's both funny and sad. Check out 'Developer Abuse'. Have you considered setting up an office in Portland, Thoughtworks?

Busy Week In Portland

There's a lot to look forward to this week:

• Tuesday: Portland Java User Group Sun presents Java FX "the future of client Java"


• Wednesday: Extreme Programming Portland our second revival meet - this time with sponsored pizza and no cigarette smoke


• Thursday: BarCamp (Bar as in Foo not beer)

See you there if you're attending.

Maven 2: Webapp Setup for Tomcat

I had some difficulty finding good documentation on setting up Maven to deploy satisfactorily to Tomcat. I found a helpful post from Greg Vaughn on the topic. This allows me to take full advantage of the mvn tomcat:inplace target.

I had to edit Greg's config slightly (presumably the tomcat plugin has moved on since):

  <properties>
    <docbase.on.server>
      ${basedir}/src/main/webapp
    </docbase.on.server>
    <webapp.reloadable>true</webapp.reloadable>
  </properties>
  <build>
    <resources>
      <resource>
        <directory>src/main/resources</directory>
        <filtering>true</filtering>
      </resource>
    </resources>
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>tomcat-maven-plugin</artifactId>
        <configuration>
          <update>true</update>
          <mode>context</mode>
          <contextFile>
            ${basedir}/src/main/webapp/WEB-INF/classes/context.xml
          </contextFile>
        </configuration>
      </plugin>
      <plugin><!-- clean up from war:inplace  -->
        <artifactId>maven-clean-plugin</artifactId>
        <configuration>
          <filesets>
            <fileset>
              <directory>
                ${basedir}/src/main/webapp/WEB-INF/lib
              </directory>
            </fileset>
            <fileset>
              <directory>
                ${basedir}/src/main/webapp/WEB-INF/classes
              </directory>
            </fileset>
          </filesets>
        </configuration>
      </plugin>
    </plugins>
  </build>

Note that I have a context.xml in my src/main/resources folder:

<Context docBase="${docbase.on.server}" reloadable="${webapp.reloadable}"/>

Stop To Smell The Roses

Malcolm Anderson posted a list of past indicators for making agile adoption hard at a company on the scrumdevelopment group:

"1) No one to blame for a projects "failure".
2) Managers who think that 9 women can produce a baby in one month.
3) Developers who don't want to understand how their work makes money for
the company.
4) Developers who think automation is great for large projects but not all
that useful for small ones.
5) Managers who think that automation is nice, but don't want to pay for it.
6) Managers who think that TDD (115% test code to 100% production code) cuts
productivity by 50%
7) Managers who think that paired programming cuts productivity by another
50%
8) Managers who think that the answer to everything is, "Those lazy
developers just need to work harder""

See? Things aren't so bad...

How To Get People To Do What You Want

There are lots of gems to be found on George's blog. Here's a excerpt from his latest entry:

"If you want to get from other people what you want, you have first got to convince them that you really care about them. You’ve got to build relationships. And the next lesson, unless you’re really smooth, which is like one in a million of us, unless you’re really smooth, the only way you get somebody to believe that you care, is to actually care. Most of us are just not good enough to make people think we care when we’re just faking it.

It’s ironic, isn’t it? If you care about getting your way, you’ve got to learn to care about other people."