Triage

One of the things that I think is important to do with any ticketing system is to triage any issues. What issues are we working on, what are we putting off until later, what ones have been discussed and are not going to be fixed. Be clear what's actually being done.

I think that this is a hard thing to do well. It takes time and dedication. Not only do you have to triage new tickets, but you have to occasionally check older tickets to address them if their status has changed: is it no longer relevant? Should the status / priority be escalated? Let's call this "re-triage".

I find that people are more often frustrated with lack of information than with lack of action. Knowing where in the queue you are is a comfort.

Having said that, you can't queue people's issue forever. But that's where the re-triage comes in. ;-)

CLI and me

The other day I asked Ryan what is a good GUI based ftp client for a mac. Why graphical? Since I've used windows for so long that's just my first thought.

I don't know why exactly and I'm sort of ashamed as a developer that is the case.

I'm using OS X. Based on unix. I use cygwin on windows.

I had never used ftp via command line, but that learning curve on that one was about 1 minute (mget damnit!).

*sigh*

Toasty warm!

I figured out how to make sure that I'm warm with my macbook: run "fink update-all".

That's hot.

Wow.

Too funny. And that's all I have to say about that.

My notes on "What makes code beautiful?"

I'm blogging some notes here so that I can remember some key points from the 65 minute presentation What makes code beautiful? (via Hey! Heads Up)

"You should write code like the person maintaining your code is a homicidal maniac and knows where you live."

PIC: Proportion, Integrity, and Clarity is the theme of what makes code beautiful.

Negative laws are easier to follow, eg. "don't kill", "don't steal", etc. These allow anything else to be allowed, which provides more freedom since the original authors can't think of everything. Along those lines, it might be a lot easier to follow the maxim "don't write ugly code" rather than "write beautiful code".

In the end, it's just KISS.

How far does style go before it's "wrong"

While thinking about Kibbee's post (which is a response to Ryan's post) I was thinking about how dumb users are. Like Kibbee was saying when you ask for feedback on functionality, and all they can "see" are the fonts, colours, and other things that are really not that "important".

Let me digress for a moment. People generally recognize minor differences of how people act as dress as "style". No one agrees on style, but there is a pseudo "safe area" that people are able to slightly deviate from before it's "wrong". Let me provide some examples:
- wearing a baseball hat sideways is "style", wearing it on your foot is "wrong"
- wearing sandals to work is "style", wearing them with socks is "wrong"
These things are "wrong" because they are far enough away from my definition of style.

When I come across code to understand it, it has to conform to what I consider "correct" (or close enough) for me to understand it. I guess some people would call it style since the code could work the same way (from the api level) as something that I'd write. However, if the style of code is far enough out of my comfort zone, all I can see is "wrongness". If someone asks me to just ignore that "unimportant" thing, I have can't.

So when you're dealing with alpha testers, it may not be that they don't "get it" when it comes to providing quality feedback, it might just be that what you are showing them is so far out of their comfort zone that all they see is "wrongness". I can see how it's easy to get bogged down with the little tweaks, but if those are what is causing the barrier that's preventing your testers from giving useful feedback you're got 2 options: 1) get other testers or 2) just do the tweak. I suspect doing the tweak will take much less time than finding new testers.

That bug was groovy! Yay!

It is awesome to be able to access the code to figure out problems. I was playing around with using the maven groovy plugin and tried to follow the examples to execute a local script. No dice. It barfed on me with an exception that didn't really help me out. So I took at look at the source and took a guess at how it should be working. Bingo.

Of course I opened a bug so that 1) google searches will turn up better results than I got and 2) so the developers can actually fix the problem. ;-)

Update: it turns out that since at work maven pulls from snapshot repos, I was using an alpha version. Mental note to myself: always use the version that's documented on the site.

Update 2: Well, as it turned out I was using the wrong groupId as well as the wrong version. How could I have confused org.codehaus.mojo with org.codehaus.mojo.groovy, I mean really!?! Well, I changed the groupId and the version and then just ran into another bug (that now appears to be fixed?). Who knows. I'll just use the old groupId with the alpha and the config that I know to work. There is a reason why they call it the "bleeding edge" :-/

Software development: art or science?

There's a ton of discussions about if software development / engineering is "art" or "science". I've always sided on the "science" side of the debate. There's no splashy colours, or impressionist applications, it's gotta be science.

Recently I heard an argument that really made me think. It went something like this: "Software development is like sculpting: you get a team of skilled craftsmen (people, whatever), give them a client and a huge block of marble. They use their tools to chisel away at the block until you have your sculpture."

That was one of the best analogy's that I've heard for making software.

So let's assume that it is an "art" (with quotes). Like art, you have some naturally skilled people, people who can be taught / mentored to be skilled, and others that no matter what you do, they won't ever be a star. And like art, so many of an application's qualities are difficult to quantify.

From now on you may address me as The Artist Formally Known As Jim.

Finding all property files on the classpath

Property files are widely used in java applications for internationalization. This usually means several files have to have their keys kept in sync. There are other pitfalls with property files as well: duplicate keys within the same file, trailing white space after the line continuation character and other wonderful things that I am sure will come up at some point.

I've got a test class that will take a directory on the classpath and look for all property files there and do comparisons and checks on them. The very first version of this tool used hard coded, absolute paths to the file, but that was close to 4 years ago. In recent version I pumped up logging on it and noticed that it ran fine in eclipse, but when you run it in maven it wasn't finding any of the files if the same directory existed in the src/test/resources as in src/main/resources (or if you just were looking at the "root" of src/main/resources). Like most PITA things in java, it was a classpath issue.

Maven's pretty smart. The path of the classloader (for surefire) is src/test first, then anything in src/main, then the dependencies. That makes sense. After running mvn eclipse:eclipse, the .classpath it's src/main first. Wonderful. :-(

The way the code ran before asked the testing class for the resource like this:
URL url = getClass().getResource(resource);
That worked great in eclipse... not so great in maven.

Then I thought "oh course! The classpath is a system variable!" and tried code like this:
String classpath = System.getProperty("java.class.path");
String[] paths = classpath.split(File.pathSeparator);
No luck either. When surefire runs it does not include any of the project's folder in the classpath. Only the .jar files of the dependencies.

Then after much fruitless digging on forums (where this question seems to have been asked many different ways and times), I found the solution. You have use the classloader of the testing class in order to get the proper paths:
Enumeration<URL> enumeration = getClass().getClassLoader().getResources(resource);
In my testing so far that works both in eclipse and maven and will give you the target/test-classes/ and target/classes/ folders.

The thing that frustrated me was that there are many different ways to get the classloader, and only this one seemed to work the way that I was expecting. I'm just glad that I can move on from this issue that's been hanging on far longer than it needed to.

Right or wrong, I am still the Captain!

The title of the post is something that I never understood for years. When I was little, there was a key chain attached to the key of the boat at the cottage. When you're 8, you don't understand things like that. Only later did I realize that it was along the lines of "either way I'm in command and you have to do what I tell you". Only later in life do you realize how important that can be.

In life most people don't have that kind of military discipline drilled into them. They key to getting things done as you want is to find people who will do it that way by default. That's something that I figured out when we were doing all the work for the wedding. For example, Laura wanted tulips for the wedding, but most flower people we spoke to tried to re-direct us to some other type of flower. We didn't go with those flower people. We spoke to several photographers and discussed how we wanted quick, informal pictures. One photographer said that he typically wants 3-5 hours to take pictures. We didn't choose him. We went with someone who described what they do and it matched what we wanted.

If you don't want to fight the people you interact with, find people who share the same goals and methods. Life is a lot easier when you can do that.

There are always exceptions. Sometimes you are able to teach people and they adopt the same goals and methods as you. I owe my passion for testing to Ryan who showed me the light. I was part of the interview team for one of the more test driven people I work with. I asked him about unit testing to which he said that he didn't like it and thought that it was a waste of time. I thought that I could get him to drink the testing kool-aid and I was right. But I think that situations like those are rare.

Working in a team is always a tricky thing. You have to account for the fact that people are in the end, still people, with ego's and all the other rest. But for a team to be efficient, the players need to be working toward the same goal, using the same means. When you look for new people to integrate into the team, you should be looking for people that already "line up" with the other members to ensure a smooth integration. Likewise, when you are in a team you must make sure that your goals and how to achieve them line up with the other members. You must follow what the leader is saying and work accordingly. If you have any concerns or ideas, you bring them up, but in the end it's still the "Captain" that has the final call. Then there are 2 choices: follow the rules that have been set down or get out.

In the end it's pretty simple.

Mood

I'm not sure if the weather reflects my mood, or my mood reflects the weather. Either way it's a gray, miserable day. :-(

Update: throughout the day there was storms, thunder and lightning. It was very, very frightening. Then it ended up sunny and nice. Both my mood and weather.

Mocking interfaces that use generics

Something that I had trouble today was writing a test case for an interface that uses generics. I wanted to mock out the object that uses the interface using EasyMock. Since I find examples are the best, here goes. First the interface under test then the test code.


public interface DataAccessService {
public <T> List<T> findResultsByNamedQuery(String namedQuery);
}

public class MyTest {
@Test
public UseMockDataSource() {
TomJones request = new TomJones();
List<TomJones> requests = new ArrayList<TomJones>();
requests.add(request);

// mock out the data source
DataAccessService mockDAS = createMock(DataAccessService.class);
requestPreProcessor.setDataAccessService(mockDAS);
expect(mockDAS.<TomJones> findResultsByNamedQuery("request.findByStatus")).andReturn(requests);
replay(mockDAS);
...
}
}


Through trial and error I figured out where to put the generic declaration. :-/

Update: I'm a dummy and forgot to escape the less than and greater than signs so they would show up in html. Ooops.

Chinese acrobatics

Chinese acrobatics are awesome. Check out the video from this site.

Classic Rock

Something that I've never noticed until this summer: the music that came out while I was in high school is now called "classic rock". Nothing else has ever made me feel old quite like that. Getting married, being in the working world, having nieces and nephews, buying a house... none of those had the effect of hearing a radio announcer say the music I was listening to (and remembered so fondly) was "classic rock". Classic rock is something that old people listen to and talk about how it came out while they where in high school. I'm still hip, I'm cool... tucka, tucka, tucka...

*sigh* Ah well. I just hope that when we move into the house the neighborhood kids will stay off my lawn. If not I'll just shout "Damn kids stay off my lawn!!" and then I'll shake my fists at them.

Old man bike

I went out today and bought a new bike. It's a Giant Cypress which looks like an old man bike. Why? Well, because it is. I don't go on dirt trails, so there isn't any point in getting a mountain bike. I don't need the super speed of a race bike. I just use the bike to get to work 'cause it's cheaper than taking the bus and I enjoy it so much more.

I even got fenders and a back rack for it. Totally ridiculous. If you see me biking around, feel free to point and laugh. I'll be laughing too.

That's a paddling...

In one of the simpson's episodes the character Jasper Beardley is brought in to the school as a supply teacher. He gives a speech that goes like this:

Talking out of turn...that's a paddling. Looking out the window...that's a paddling. Staring at my sandals...that's a paddling. Paddling the school canoe...ooh, you better believe that's a paddling.

On my last co-op my manager took me aside at the start and gave me his "speech". He had 3 rules, and if you broke them, he'd fire you. They were 1) looking at porn at work 2) you had to come to work in presentable clothes. Jeans were okay, just not shredded ones and 3) come to work clean (shower, etc)

Both of those situations might seem a little ridiculous, but I think that they are both wonderful for what they are trying to do: establish ground rules at the start so that everyone is on the same page. After that you have an idea what is acceptable and what is not. I think that doing that is a great practice.

Think for a second before reading on what your "that's a paddling" list would be. What would you make the ground rules for your job?

Mine would include the following. It's funnier if you say "... that's a paddling" after each point:

• commenting out relevant test cases
• being abusive to your co-workers
• breaking the build
• merging out your co-workers code
• dumbassery in general
• breaking windows (see theory)
• not fixing broken windows that you come across
• not doing the best that you currently know how to do
• not being open to new ideas
• not doing your best to help your co-workers
• not writing tests

The list goes on... I'd love to give a speech like that...

QotD - 2007-08-08

Too clever is dumb. -- Ogden Nash

Common code leads to common tests

Since I can't seem to think of a good way to explain this problem in conversation tone, I'll just explain it the clearest way that I can think of.

Notes:
1) this is computer stuff, so if you're not a programmer you might as well stop reading now.
2) this is discussion of a java project being built with maven.

So we have a common module (common) that is being used by 2 other modules (desktop and web). We want to put some helpers for generating filled out model classes in our common project where the model is, but we don't want to include that code in our production build. So we put that code in src/test/java. Now we want to reuse that code in our desktop and web module, but since it's not in the src/main/java branch, the code is never put into the final jar.

One (bad) solution is to just move this code into src/main/java, but like most things with maven there is an easier way to do it. We simply create a test-jar using the jar plugin as shown in the guide to using attached tests.

One "gotcha" that I found was I tried to quickly get this going so I used the switch -Dmaven.test.skip=true. This switch doesn't compile or run the tests. However, if you don't at least compile the tests, when you package them up you'll not have them in the test jar! So, if you have the unfortunate situation of having failing tests you can use the switch -Dmaven.test.failure.ignore=true.

Squeak, squeak, clunk

Lately I've been having a harder and harder time biking. I was wondering if I was out of shape or something, but that didn't make sense. I didn't really know what it was until I was biking home on Friday and my rear wheel feel off. Well, I guess the wheel just came apart from the axle, but it sucks when you have to walk your bike home.

I guess that the difficulty biking should have indicated to me that the bearing was going. I don't seem to pick up on these types of things until I have gone through it once. :-/ It's probably time that I buy a new(er) bike that will use all the gears and be able to brake well. My plan right now is to strip down the other bike, repaint it and build it up with new parts. It's a super comfy frame for me, it's just the parts on it are not super. Now I have a winter project and I'll have a house this winter to do the work in. :-D