On technology leadership

What does it mean to be a technology leader? This has been and still is a perpetual question for me. In this post, I’d like to reflect on what I learned about technology leadership in my experience as the creator of Jenkins and as the CTO of CloudBees.

Leading by Code

When a software engineer rises in prominence through the popularity of their work, the first phase of the leadership is what I call “leading by code.” People around you notice that you are doing some great work, and they start paying more attention to you. By this point, you own a lot of code, meaning you’ve probably written quite a bit of code of the said software yourself, including the heart of the design and the architecture. Owning code gives you upper hand in many ways, which you can use to influence others:

  • You probably are the most knowledgeable person for many parts of the system, so whenever somebody tries to build something anywhere, they want your input, approvals, or maybe even some matching change from you.
  • Your code, coding style, and how you produce it all become the baseline for everyone. In trying to do “monkey see monkey do,” they seek your input and approvals.

In essence, you lead by being “a better doer.” I remember that this felt great. Engineers close to me did not need a title change to know the influence I was radiating, but now my boss, my distant friends, and people who are looking at my LinkedIn resume knows that I’m a leader! I also obviously believed that my way of doing something is great, and I was helping others do it better. I wasn’t really changing anything I was doing before – I kept writing code, just more often together with other people. When I wanted something to be done in a certain way, it was usually followed. Everyone wanted my input. What’s not to like!?!?

Limit of Leading by Code

I think “leading by code” comes naturally to everyone. I’ve seen many senior engineers who perpetually stayed in this comfortable mode. But today I believe it breaks down at a certain size of a team. I now think, perhaps selfishly, trekking beyond this comfort zone is what differentiates a technology leader from a better software engineer.

Why does “leading by code” break down? Simply put, you become a bottleneck.

  • Bandwidth: if everyone needs your attention and focus to get their job done, then you run out of time. When people start doing things increasingly on their own as a result, you feel threatened, because you feel your control is slipping away and other people are developing deep expertise in various pockets.
  • Creativity: when you influence others by basically controlling what & how they do, either directly by telling so, or indirectly by controlling a tribal custom, it naturally limits other people’s creativity. This is a hard one to see when you are in the middle of it, because there’s always some room of creativity that you can point to.

That is me in 2019 speaking. I didn’t have a perspective back then to think in these terms. So I’ve probably stayed in this mode of leadership for too long, feeling increasingly unhappy and disappointed at myself. There were a few signs that this leadership style was hitting a limit.

  • At one point, I wanted to design and write an interface between two subsystems myself, because “owning code” was how I was exercising the influence. People implementing the two subsystems weren’t happy at all that I was lagging behind, producing something different from what they wanted. It didn’t help me either because I lost some credibility in their eyes, rather than gaining influence!
  • I was in a design fight with somebody under me, and I couldn’t resolve it in an amicable manner and ended up just overriding him. I remember him saying “I’ll reserve the right to tell you I-told-you-so.” I had some reasons for doing that, but really that’s beside the point. He got demotivated, and it created “my way or your way” framing. He’s also now rooting for you to be wrong, and sooner or later, you WILL be wrong!

So I started exploring other mode of technology leadership.

Launching a New Project

One of the things that worked was to focus on launching a new project/product/effort. The idea is that you basically get embedded into a team for a while, then transition out when the time is right. I’ve done this several times, and I think it suited me well for several reasons:

  • I could “lead by code” with all its benefits without much of its downsides because new things start small. I could steer a team toward a general direction without making people feel like you are telling them what they do.
  • New things benefit from an executive sponsor who communicates progress upward, keeps unwanted disruptions at the bay, builds bridges to where necessary, brings input, context, and perspectives from other parts of the org.
  • When a new team is formed to take on a new thing, which I suspect is a norm in a startup, I can help the forming and norming phases. I bring in “how things are done around here” naturally thanks to the title, and speed up initial decision making. Just don’t forget that you will be wrong on some of those decisions, and you got to let the team take over and fix some of those. That used to feel embarrassing, but now I take it as a sign of a maturity of the team.
  • I suspect one of the things that keep the CTO role influential is being on the side of change, as opposed to being the defender of the reality on the ground. Being seen as a part of new projects is helpful with this regard.
  • And new things are fun, so it kept me engaged!

Storytelling

As the org grew, the number of people I needed to influence got larger, and I found myself leaning more and more toward a meaty, structured write-up, as opposed to email dialogs, or 1:1s with key individuals. This blog post itself is a good example of such a write-up, albeit too long.

A write-up can start with a recap of context, or cross references to earlier write-ups, which help larger number of people to “get it.” Writing down helps you organize your thoughts more clearly and think more thoroughly. Your message also won’t get lost in Chinese whisper game, when people forward your message to others. It takes more time to compose one, but the wider reach makes it worthwhile.

CEOs and managers of big orgs do this all the time, but I think technology leaders should do this more, too. And you don’t need to use the “unicorns and rainbows” voice that they use, either!

I started consciously doing this more and more after getting hooked to great storytelling podcasts like This American Life and Radiolab. Those podcasts got me thinking a lot about how to tell a story better. When it works, it makes your write-up more engaging, and it frames how people think about a certain thing. When you succeed in that, there’s no need to sell people a solution. I’ve sought some help from people who studied journalism, and I’m seriously wondering if there’s more training/class available in this area.

Aside from one-off write-ups, I’ve run two series of write-ups that have certain themes, and both had great tractions. One was a series of “portraits” of people who we are building our products for, and the other is things I’m noticing about what’s going on in the industry, such as event reports.

I’ve done most of this on Google Doc, and what I loved is that people can comment on my message to add more colors, which makes it a whole lot more valuable. OTOH, Google Doc sucked at helping people find your write-ups, and that took a lot of value away from it. If Confluence was more loveable experience, I would have switched.

1:1s with CTO

At around ~100 people, and as I developed a “storytelling” broadcast channels, my 1:1 interaction with engineers started to change in nature. It used to be “outbound” where I tried to influence key senior people. It now became more “inbound” where I learn great ideas, interesting efforts, and/or their challenges from people. People were much more willing to talk about that in 1:1 and all I needed to do was to prime the pump and listen attentively.

So I started to encourage them, help them get more time working on them, and so on. Basically, find a pocket of excellence and try to lend my credibility to grow them.

It’s much easier to make something happen when there’s already somebody who’s thinking about it and passionate about it, even considering the downside that is “it’s not exactly how I wanted it.” I’d also like to think it creates a workplace that engineers want to be in.

I’m still trying to figure out how best to do this. When you skip reporting chains and go directly to ICs, it can be disruptive. You can’t create a change without creating any friction, but you want to minimize that. Also, not every ground-up effort pans out, and when they fail for one reason or another, it can be really disappointing for the person I encouraged. Expectation setting can be tricky, and so much depends on individual context and the personality. When an effort does pan out, the next stage of the project needs more serious organizational commitment, and I often struggled to bridge that smoothly.

Toward the end, I started thinking about creating a rotating position to do these “incubation” projects by pulling engineers out of their regular positions and time-boxing projects. This felt like a promising idea – it makes the whole thing a repeatable program that other people would recognize better, and hopefully that encourage more people to bring ideas to me and help with the “next stage” problem.

Architecture Forum

I’ve seen this done in many places, but I’m not sure if I cracked the nut. I’d love to hear from people who has done it successfully. The idea is that you have many teams with defined territories, and you drive the alignment/collaboration between them through meetings where people from those teams come, present, and talk to each other.

  • I thought the way to make this valuable is to ask them questions. What about observability? Have you thought about this failure mode that happens all the time? Help them tap into organizational memories. Bring concerns and realities from the field. But I felt one-hour session is too short for that, and there’s always somebody from other teams who ends up in the “let me design it for you” mode who speaks too much.
  • When I invited one person from every team to be on this forum, some people thought “hey how come Alice is invited but not me?” and that made them unhappy.
  • I suspect many engineers just don’t have the mindset of “there’s always something to be learned from new perspectives” baked into them, and those people don’t feel a real value from this setup. When enough people do not feel value, it’s too easy for this to become a bureaucratic formality.

In retrospect, I think a better way to do this is eng-org wide continuous education. I could have identified people who can speak to those concerns, perspectives, and context, and perhaps I could have a dialog with them and capture that into a presentation, a document, a podcast, or something. That way I can amplify a voice of somebody while still creating a crafted message that I want the org to hear, and I can influence everyone, not just tech leads. And so long as it sticks to somebody in a team and they speak up, the team will be doing the right thing.

Conclusions

This post is really more of a progress report of mine than a guide book for others. Your mileage will vary.

That said, if there’s any take away for others, I think it’s that the PDCA cycle works. That is, you try something, notice that it seems to be working, so you build/adjust a mental model of why that works, then that helps you plot the next move. What started as a random search and blind shots gradually become more systematic hypothesis testing over time. You never really find answers (at least I didn’t find one), but you do find questions that are worth asking.

It was uncomfortable at the beginning, but once I felt that the cycle was going, I felt happier because I was making a progress. Then the rest became easy.

I hope you’ll find some of this useful, and I’d love to hear from people what worked for them and didn’t.

My personal journey around diversity

Today, in the software development industry, the issue of gender, racial, and other diversities is widely accepted. But I also think this is still largely understood as “social value,” as opposed to “business value.” As a result, the awareness is not leading to enough actions, because it loses out in the crucial fight over priority. Like all other good things, it never get acted on.

This is a story of my personal experience that helped me develop new perspectives on this issue, to more clearly see why it’s in your business interest to tackle this.

Where I started

I’m a left-leaning man born to Japanese parents, who spent equal time between the U.S. and Japan. In other words, I’m generally on the side of increasing diversity in any given team. I’m also a father to a daughter. So I’ve always felt very sympathetic to the gender diversity issue. it was obviously a good value to uphold.

I was also very proud of the geographical and cultural diversity of the Jenkins community and CloudBees. I remember in one dinner we had, I looked around the table and realized that this group of 8 people represented 6 countries and 6 native languages, and I loved it.

I’ve been feeling like I was a supporter of the cause, a part of the solution.

What made me pause

Then I hired Tracy Miranda as a new community manager to my team at CloudBees. She was going to help us grow the Jenkins community. She was very passionate about the issue of diversity, she led that effort in the Eclipse foundation. So it was no surprise that in one of the planning meetings, she proposed that our team prioritize tackling the gender diversity problem.

A surprise was my own reaction. I found myself not really buying into it. The question wasn’t whether that is a good thing to do. It obviously is. The question was whether it’s better than all the other good things we can do.

I didn’t feel like she gave me that rationale, I couldn’t answer this myself, and I felt other people in the team had the same question.

That’s when I realized maybe I wasn’t a part of the solution, I was a part of the problem, a part of the system that created inertia.

What I run into

That realization wasn’t a pleasant one to face, but it also gave me an important question — what is the business value of the diversity? Fortunately, within a relatively short period of time, I randomly came across two great stories that helped me explore this question.

  • The story of Arlan Hamilton: This series of podcasts tells a story of a gay black woman trying to start a venture capital. She makes the observation that startup founders are not reflecting the general population balance, and therefore her core investment thesis is that there’s a untapped business opportunity in investing in minority founders. It was interesting that she doesn’t see her work as a social responsibility or charity work. It’s simply a space the competition was failing to dominate, an untapped field, and she was going to win that space.
  • Curb cuts: This 99% invisible episode talks about ‘curb cut,’ which is a slope from a pedestrian walk to a road. This was originally done to make roads more accessible to wheelchairs, but when it happened, it turned out that everybody benefited. Parents with strollers, people with suitcases, etc. What I got thinking is that when we make a community accessible to one under-represented group, the effort will have a ripple effect to other under-represented groups. This is a very common thing in software engineering. When we solve one use case, we often solve it in a bit more generalized way, and that helps other use cases.

What I learned

From these stories, I started to see the issue of diversity differently.

It’s like opening a new bar and in a new town. You build a bar that you like, you hang the “open” sign, and you wait for people to show up. Some people wonder in, the place gets busier, your regulars give you feedback, and you improve your bar, which brings more customers. Things are going great.

But at some point, this kind of growth will plateau, because you are self-selecting your customer base. At some point, to ignite the next growth, you need to do something else.

What you do is to go out on the street, see people who are not coming to your bar today, then think about what it takes to make them your customers. You might notice that there are a lot of Hispanic people walking around in your neighborhood. Maybe you’ll prepare a menu in Spanish, or put pictures in the menu. And you repeat this cycle to win more customers.

If you think about it this way, it’s obvious. Don’t sit and wait. Reach out. In marketing, for example, people do this all the time. But among software companies or open-source projects, too many people are still in the “open a bar and hope people show up” mode, and not realizing the lost business opportunities.

And that’s because this is also hard. It’s hard to think about and understand people who are different, who you don’t see.

How I connected dots

And on the point of how hard it is to think about and understand people you don’t see, I have a lot of personal experience.

I grew up in Japan, so I’m well connected in the software development scene over there. I know countless faces of great software engineers, team leaders, and open-source people over there. It’s the number 3 economy in the world, after all! But here in the west, they are just not on the radar. The open-source people I interact in the U.S. and Europe simply don’t know that these people exist, and so they don’t know what they are missing. That’s something I felt personally passionate about, and I realized the structure of this is exactly the same with the gender diversity.

I had another “aha” moment of this exact same structure from another angle, when I visited China and saw its thriving tech scene. I realized many obstacles we unknowingly set up in the Jenkins community. Our mailing lists are on Google Groups. Too bad, Chinese firewall blocks them. Our official twitter feed was similarly blocked. If we hope to reach Chinese users, we need to be on their social network that none of us knew. Something that I was completely unaware of, that became totally obvious once I met them and talked to them.

Conclusion

As the software engineering community, we need more good engineers to join our teams, our communities. And a rational way to do so is to build a new muscle to seek out untapped engineers and win them. Find, talk, and understand a group of people different from you. Accommodate and win them. As with everything else, if you’ve never done it before, doing it for the first time is hard. But you will get a hang of it pretty quickly.

I think any group of people would do. When you solve it for one group, you are already halfway there solving it for other groups.

Gender just happens to be a relatively “obvious” one to tackle first. It just acts as a concrete goal of the otherwise abstract idea of “reaching out.” One, the total addressable market (TAM) is pretty big — it’ll basically double your current TAM. There’s no firewall, no time zone difference, no language barrier. It’s also a very visible group that everyone can see, which makes reaching out much easier. On top of that, it’s a well trodden path with a lot of collective experience to tap from.

So that’s where I stand in 2019. Hopefully my journey is useful to others going through the same journey. Looking forward to hearing from people who have thought more about this.

Software is eating the world all right, but is everyone becoming software business?

As CTO of CloudBees, and the founder of the Jenkins project, I often take a podium in front of a room full of senior technology leaders and make a pitch that software is eating the world and that every business will have to transform into a software business, or they get eaten by those who transformed.

When I talk about this, I have companies like Uber, Netflix, Amazon, and Google in mind. They all seem to be disrupting some established industries by fundamentally being a technology company. Google is my favorite example of all, because I used to think their core competency is a killer search engine, but it’s actually their software design, engineering, & operation practice.

But I started thinking lately that maybe this is a naive view, biased by highly visible supernovas and their effective engineering branding campaign. Hear me out.

Airline Industry

First, think about Sabre. This is originally American Airlines’ booking system (the thing that connects passengers and airplanes.) Then they spin it off to a separate company, and now it’s used by half the airlines around the world. The other half runs on Amadeus, which came from Air France & Lufthansa. So here is the industry where most business seem to have outsourced the heart of their technology to 3rd party provider, instead of transforming themselves to the technology business like I’ve been claiming. And they seem be doing fine.

And it makes sense. If you are a “small” national airline, like, say Japan Airlines (JAL), they seem to be making a choice that being a part of Sabre and pooling the development cost with other airlines get them better technology cheaper than “transforming themselves into software business.” Presumably JAL won’t be able to offer unique, killer customer experience that technology enables, in ways that UBer can,  but you also won’t get left behind too badly, and that lets you choose something else as a differentiator. And what choice do you really have? It’s going to cost prohibitively to build air booking system from scratch. And the risk it involves!

Core Banking

Next, think about core banking. That’s the part of banking where they safeguard consumers’ money and help us receive paychecks and handle payment to buy groceries. There are ~4000 banks in the US alone, and clearly most of them can’t afford to “transform themselves into software business,” so instead many seem to run software like Flexcube.

And again, it makes sense. It’s a commodity that you have to have as a bank, but it’s not a differentiator. You’d rather pay somebody else to run it for you than you run it.

Insurance Platform

And the last week, the last data point happened in the hallway of Linux Foundation Open-source Leadership Summit. I randomly sat next to a CTO of Allianz spin off where he said insurance companies are getting together to spin off what they consider “the commodity part of their business” into a common open-source platform, so that the industry can pool the cost of developing and maintaining the necessary evil, and divert the resource to what matters, such as providing a great customer experience when they have car accidents. (Notice how car insurance commercials often start with a scene of accident where somebody is making a frantic phone call that gets answered by a calm,  assuring agent? That’s the differentiator!)

Common Thread

I feel like there’s a common trend that connects these. The role that technology plays in any business is going up (aka “software is eating the world”), but there are more and more services like Sabre, Amadeus, Flexcube, and million others in every domain, then not to mention cross-cutting services like LivePerson or Finicity. Collectively they are the turtles growing under every business that raises them higher. It’s like how software development has shifted more toward “just integrating services” so to speak at our level, albeit at a wholly different abstraction altitude.

So it’s not inconceivable for me to imagine a future where more and more software that business relies on come as services from startups, vendors, and industry consortiums, and all that’s left to do is some glueing and wiring, ala “just hook up webhooks from here to that service over there.” Maybe with a bit of serverless thrown in here & there.

That is the world where most business is not software business.

(This is obviously just a combination of guessing, speculating, and over-simplifying based on a small anecdotal experience. But for me, it was an eye-opening thought. I’d love to hear from people who are actually in these worlds on how I’m wrong!)

Groovy folks, time to start agreeing

I wrote about the drama unfolding in the Groovy project a month ago.

I left that topic for a while, but I was pleased to find out today that the question is no longer whether they need to move to a foundation, but rather which foundation it should be. There’s an email thread that has 188 messages and counting, going for more than 2 weeks, where the community is trying to figure out where to go.

I feel a bit of deja-vu, and I feel like I know exactly what’s going on. And no, I don’t mean the Jenkins drama, though we were in a relatable situation. Instead, I was thinking when I and my wife bought a house 5 years ago.

So there were two houses we really liked. The white house and the beige house. Like any informed buyer would do, my wife and I start disecting pros and cons. The white house felt a lot brighter and airy than the beige house, but the beige house has a bigger backyard. The white house is closer to a hospital, which might mean more noise. The beige house has a big tree nearby, and the gutter might fill up. List like that went on and on.

Now, the thing is, at a certain point, a list like this gets more confusing than helpful. I can add up all the pros and cons, but it doesn’t help me getting any closer to the decision making. In fact I’m no longer sure if the white house I wanted was really such a good idea. After all, it has no less than a dozen things listed under “cons”. I can see that my wife is getting just as confused as I am. The conversation starts to go in circles. I was lucky enough that our parents were living in the other side of the Pacific ocean, so we kept this conversation to ourselves. Otherwise, I’m sure it would have been even worse. They mean well, but sometimes too many opinions are more harmful than helpful.

In 1am in one of those long nights, I finally realized that agreeing on something, anything, is more important than figuring out the absolute best house out of two. So like every husband would do, I started trying to talk myself out of the white house I originally wanted, and speak about things I liked about the beige house that my wife originally wanted. I tried to downplay the concerns she had about the beige house.

Even though I started doing this consciously, the strange thing is that I started getting convinced by my own arguments that I didn’t fully believe in. Sure, the beige house doesn’t have the attic room that’s going to be my LEGO room, but I can get a brighter office and maybe I should keep my LEGO there so that I can occupy myself if meetings get boring. And in the end, we bought the beige house and we still live there mostly happily.

I feel like it’s time for Groovy guys to start doing this “let’s agree, whatever it is” dance. Judging from the conversations, I think they’ve figured out that they can live in any of these three foundations. The trick is not to get caught up on all the gory details, because there will be always something you don’t like. Yes, voting might be burdensome. Yes, losing @author tag might be annoying. Yes, infra migration would be painful. But you’ll be all right, and you’ll get used to it sooner than you think.

It’s time for people in the community to give the project leaders a blank check. I think we should be able to all trust them that they have the best interest of the project in mind.

And more importantly, it’s time for the project leaders to start converging. You guys need to sense where your consensus is heading to, and try to talk yourself into it. Try to create an echo chamber.

Engineers aren’t the best people to do this, but you guys really need to do this, because the clock is ticking. The difference between foundations is relatively small, but the difference between moving forward and procrastinating is huge. It’s a part of the leadership responsibility to form a consensus and then turn around and sell that to everyone, so that everyone feels better about what’s being done.

Remember, there’s really no wrong answer. Just different correct answers.

POTD: ExceptionInInitializerError logger

It’s been a while I’ve done a project of the day, but here it is, the fruit of my yak-shaving today.

The problem I was trying to solve today was java.lang.NoClassDefFoundError: Could not initialize class Xyz. When a Java class fails to initialize, the first attempt to do that causes ExceptionInInitializerError, but subsequent attempts to use that class results in this rather unhelpful java.lang.NoClassDefFoundError: Could not initialize class Xyz without the chained exception.

This problem has been rpeorted to Java for years, but probably JavaSE people doesn’t understand how painful this is in a large modular system, where the initial exception can be reported in so many places — such as one of the 1000 builds you’ve done today, or in an HTTP response to somebody, stderr, logging, or getting swallowed by empty catch block.

So I wrote a little Java agent that uses java.util.logging to log every ExceptionInInitializerError at the point of instantiation. In this way, even on a server, you have one place you can go to check for all errors of this kind. Through j.u.l, you can write a custom Handler to report errors elsewhere, if you want to.

The number of people who will find this tool useful would be probably small, but I hope they’ll really appreciate this little gem. May Google let them find this page.

Groovy project should have a clear governance structure

I just came back from Tokyo to learn that the Groovy project is looking for a new home. Related posts from the project leaders here, here, and here. Hacker News commentary is here.

This news hit close to home for me for several reasons. For one, I like Groovy a lot myself, to the point that I have developed several projects around it (like this and this.) Two, the Jenkins project uses Groovy a lot in various places. I think Groovy has a number of things going for them, such as great IDE support (and the optional static typing boosts this), greater compatibility with Java, and an existing ecosystem. So my best wishes to them.

One of the things I realizing while reading the news is that I actually don’t know the governance structure of the project. Is the name “Groovy” trademarked? If so, who owns it? How about the domain name? How is the decision making done? Who becomes committers?

Questions like this are important at times like this, because we don’t know how much is owned by Pivotal, and that determines how much is up in the air.

For example, had Groovy been an Apache project, then we’d know the answers to all of the questions above, and this news really just boils down to who would be willing to hire the team and let them work on the project. Maybe they won’t find a single company that is willing to hire everyone and put them all full time on open-source Groovy — I bet they talked to prospects in private before going public, so at this point I assume the chance of this happening is pretty low. But I have no doubt they will each find a gainful employment that does involve some open-source Groovy work.

In contrast, if Groovy is a company-sponsored open-source project like Spring was, in that the company owns all the key assets and dictates the development process, then we have a lot bigger problem at hand, because there’s greater uncertainty. The project would have a bigger risk of fragmentation (for example if the team gets hired by different competing companies.) Perhaps license would change.

This is why I think the ownership of the project should be thought separately from the ownership of the developers (i.e. who pays the salary of the key contributers of the project.) When the latter changes, having the former sorted out considerably reduces the impact. And this comes from my own personal experience dealing with Hudson/Jenkins. This is one of the reasons why the Jenkins project has a governance structure laid out.

So I’d like to encourage the Groovy project to sit down and clarify the governance. This should be a part of their “find a new home” plan. Maybe they could even just join Apache Software Foundation since the license is compatible, maybe they could come over to SPI, where Jenkins is.

At this point, I’d be very happy with a less active Groovy project without a corporate sponsorship. But I wouldn’t like to see a governance-less Groovy project. I think they can avoid that.

Update: I’ve written a follow-up post on this topic

今週末から日本にいきます

今週後半から来週末まで日本に行きます。

メインイベントは1/11のJenkins User Conference 東京です。まだまだ参加できますのでぜひ宜しくお願いします。懇親会もぜひ参加してください。

月曜日にはJUCにドイツはBMW Car ITから来てくれるゲストスピーカーと一緒に東京観光をしようと思っています。Jenkins界隈の人で一緒に遊びに行ける人はぜひご一報ください。

休みが明けた火曜日の夜にはJJUGのJenkins祭りが!日曜日はこれないよーという方はぜひこちらにお越しください。

その週はあちこちの会社を訪問してCloudBeesの日本上陸に奔走します。もしその手の話に興味がある方がおられればぜひ個人宛にメールしていただければと思います。

1/17, 1/18の土日はオフなので、久々の日本をエンジョイしたいと思っています。日帰りか一泊でスキーにでも行くか。誰か一緒に遊んでもいいという人がいればぜひ声をかけてください。

POTD: random but meaningful name generator

I’m working on the automated blackbox acceptance tests for Jenkins, where I often need to generate random unique names. The code has been using random number generator to generate such names, but as I was debugging test failures, it became painful to remember those random names.

For example, a test might create two new jenkins jobs “random_name_155230″ and “random_name_137204″. Now which one was supposed to be the upstream and which one is downstream? Aside from a few exceptions, humans are generally not good at remembering those random numbers.

So I thought it’d be a lot better if these names are more meaningful, like “constructive_carrot” or “flexible_designer”. That is, if I have a decent sized corpus of N English adjectives and M nouns, I can generate NxM unique names (and induce a few chuckles to whoever see the generated names.)

After a bit of googling, I came across wordnet, and I took a subset of its corpus to come up with a small library that generates human-friendly random names. It has about 600 adjectives and 2400 nouns, resulting in 1.5 million unique names before the generator wraps around.

You’d use this library like this:

RandomNameGenerator rnd = new RandomNameGenerator(0);

while (true)
    System.out.println(rnd.next());

The code is under the BSD license with no advertisement clause, and the library is on Maven Central. Hope you find it useful.

POTD: Application configuration via Guice binding + Groovy

Often I write my applications with Guice. I also often want to make those applications configurable externally. For example I might inject username and password for that app to talk to another app, I might configure some timeout value, and so on. I make these configuration values available in Guice, so that I can access them wherever I need them. All of this is pretty common in many other places, I’d imagine.

Given that all I’m doing here is to pass configuration values from left to right, I thought it’d be nice if I can write configuration directly as a Guice module by using Guice binder EDSL. Then I won’t have to parse and translate these configuration any more.

And that became my project of the day.

This little library allows you to write Guice binding definitions in a text file:

timeout = 3
bind Payment named "customer" to VisaPayment

From your program, you use GroovyWiringModule to load this configuration file:

Module config = new GroovyWiringModule(new File("/etc/myapp.conf"));
Injector i = Guice.createInjector(
  Modules.override( ... my application's modules ...)
    .with(config))

The end result is that the above script gets translated into the following binding:

bind(int.class).annotatedWith(Names.named("timeout")).toInstance(3)
bind(Payment.class).annotatedWith(Names.named("customer")).to(VisaPayment.class)

Using Groovy as the host language for DSL has other benefits. If you are using system properties or environment variables to configure something, you are basically stuck with strings as the only representation of the configuration. With Groovy, I can create a relatively complex object and bind them, or even put some logic to further obtain values from elsewhere:

bind Payment toInstance new VisaPayment(
  cardNumber: "1234-5678-9012-3456",
  expiration: new Date(System.currentTimeInMillis()+TimeUnit.DAYS.toMillis(30),
  cvv: new URL("http://secret.server/cvv").text) 

With the functionality in Guice to override definitions in one module by another, I can also even override bindings defined in programs, for example to get more logging, add a filter, etc.

POTD: cucumber annotation indexer

Cucumber for Java requires that you specify the packages in which your step definitions exist. At runtime, cucumber uses some hack to try to list all the classes in this package (it’s a hack because class loaders never really support the listing operation), loads them one by one, and finds those that have step definition annotations like @When and @Then. This is both poor user experience (can’t you just find my step definitions!?) and poor performance (loading all the classes under a package is expensive.)

So I wrote a library that offers a much better alternative. It uses annotation indexer to create an index of step definitions and hooks at compile time. Thanks to JSR-269, this happens automatically on Java 6 and later. With the index in /META-INF/annotations, runtime can load all the step definitions quite efficiently.

The library contains a Backend implementation, so you should be able to just add it to your project dependency, and cucumber should automatically find this (and thus all your step definitions and hooks.)

By the way, this horrible technique of scanning jar files, listing class files, and finding annotations from there is unfortunately commonly seen in many other libraries. This was a necessary evil in the days of Java 5, but it should really die in this day and age. If you realy on the classpath scanning, please switch to annotation indexer, which provides the backbone functionality of this POTD.