Friday, April 29, 2011

The value of a drop in a bucket

I frequently listen to the ESPN podcast "Baseball Today" with Eric Karabell and guests. It's not my favorite podcast, but the guy knows his baseball and his co-hosts are usually really good.
On a recent podcast Eric mentioned that the current decline in attendance at Dodgers games being partially blamed on fans wanting to protest the ownership was silly. He stated that a fan not going to a game to protest the ownership situation wouldn't even be noticed and that no real fan would want to do that.
This reminded me of something else that's been getting a lot of attention this (and every) election season, the value of one vote. On a larger scale the concept is often likened to a drop in a bucket, an idea worth looking at.

The price of a coffee:

If I asked you right now the exact maximum price you would pay for a coffee, to the penny, what would you say? Do you think you're guess is accurate? In my case I'd have to say no, it's just a ball-park of what I would expect, rather than an instantaneous reflection of how much I would actually pay. It's really hard to prove the exact price you would pay for something at any given time since any initial offer or haggling would likely change your perspective.
However, If I had 1000 clones of you, all of whom are exactly like you in every way and offered them all a different price for a cup of coffee then I could find out exactly what your maximum price would be. Consider the following example

Clone 1 is offered the coffee for $.01 and accepts
Clone 2 is offered the coffee for $.02 and accepts
Clone 143 is offered the coffee for $1.43 and accepts
Clone 144 is offered the coffee for $1.44 and declines

We can expect that since clone 144 declined to pay $1.44 for the coffee that all subsequent clones, being the same person effectively, would decline to pay more. At this point we know that the maximum price you (being the one who was cloned) would pay for a coffee at this time.

This kind of accuracy is impossible to get simply by offering a person the same coffee consecutive times since as I mentioned earlier previous offers can bias their perceived value of the coffee. It also doesn't last, ask me 5 minutes from now and I'd bet the number would have changed, particularly if I was still growing thirsty.

Now you might be thinking "Wow Brent you've wasted like 3 minutes of my day, thanks! Who cares how much I'd have payed for a coffee at a specific time, other than perhaps the man running the coffee shop at that time. Also, since this is a theoretical experiment I can't even find that price in the real world rendering this whole post useless. I hate you." Ouch. Well, maybe we can use this idea to help increase our perception on the value of one penny/vote/drop?

Consider that not every person would have the same "instantaneous maximum" for a given offer or question. The "Would you pay $1.73 for a cup of coffee." question could easily translate into "Do you consider Party X, who got 10,173 votes to be a valid party worthy of consideration in the next election?" or "173 people complained about a decision I made, is that number high enough to make me take their perspective into consideration?" All of these numbers could easily fall into the instantaneous maximums of people looking at them. For example:

Party A received 10,417 votes
Party B received 9,567 votes
Party X received 4,351 votes

Party A wins the seat, Party B supporters are disappointed about losing such a close race, but know they have a shot next election. Party X however didn't really come all that close, so they might be asking themselves a big question.

Did my vote count for anything?

One way to look at it is that in such a close race both of the top parties will be looking to gain votes in the following election, one way to do this is to make sufficient concessions toward an outside party's platform to woo some of their voters. For instance if Party X was really pro-environment then Party A or B might alter their platform a little to be more environmental in order to get a few of Party X's votes. This is at least a partial success since you are going to see some of your desires fulfilled.
Another view is that with any smaller party there is likely to be people who support the platform but don't want to "waste their vote" and vote strategically for whomever would be their choice of the front-runners. This seems to be a very popular way to vote, most people feel very strongly either in favor of or opposed to the incumbent and want to make sure "he/she does('nt) get back in". What can get lost in this is the idea that a third party that loses a lot of votes to strategic voting can end up looking much further out of the running than their actual support would be. Each vote for party X adds increased likelihood that when the results come out that party would look like they have a legitimate chance in a future election.

This is where the instantaneous maximum concept I mentioned above comes in. In the sense of voting, where everyone can see the resulting vote totals and decide for themselves if a party had enough to be considered a viable choice in future elections that's a lot of potential voters using their own maximums to make that call subconsciously.

As an example if I was a party X supporter, but voted A strategically and tuned in to see the vote totals I have a number, albeit a number I don't consciously know, where I would realize that party X might have a shot next election. Say that number was 4,352 then in the above example I wouldn't yet be convinced and would likely vote strategically next election, but I wouldn't know exactly how close I came to being convinced. Now consider there are a large number of people like me, but who's number is slightly (or significantly) different than mine. This means that instead of having one solid number (to win the election) that if you miss you feel like you've wasted your vote you actually have hundreds or even thousands of numbers where your single vote could influence the next election in a much more dramatic way.

This kind of thing can snowball too. If my vote this election catalyzes additional people to consider party X and maybe vote for them in the following election then their votes can do the same in subsequent elections.

In conclusion even though third party vote totals might not win them an election, the value of the actual vote count (or penny charged, or drop added) can have direct impact on results even if the number seems arbitrary.

I didn't really intend for this to become so much about voting, but it seemed a decent example, and I think it's important that people consider not only the short term outcomes of elections but use their votes as a path to the future that they want.


Thursday, March 3, 2011

Maven Release and Directory Locations

A co-worker of mine ran into a strange error while running a maven release:prepare goal on a new project we were setting up, and the issue is kind of odd.

When he ran the prepare goal he would quickly get (on the first module) this error:
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] null
[INFO] ------------------------------------------------------------------------
[INFO] Trace
at org.apache.maven.shared.release.util.ReleaseUtil.getBaseWorkingDirect
at org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.tran
at org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.tran

Google didn't really help much so I had a look at source for those classes and tried to figure out where the null was coming from. While I was looking around I remembered that he had checked out the project into his root directory, so the working directory was directly inside "C:\".

That is:
C:\project\pom.xml was the top level pom getting built.

Since the release plugin looks for some base and parent directories I wondered if this made a difference, if asking for the base directory and just getting "C:\" was an issue. I tried to run the same goal on my machine, with a more nested working directory and it finished successfully. We tried adding one level of directories between his root and his workspace (C:\blah\project\pom.xml) and that seemed to do the trick.

I've logged a bug report with the maven release plugin about this:, but in the interm if anyone runs into it just make sure you aren't doing your dev too close to root.


Thursday, February 24, 2011

Hudson/Jenkins and the missing key

A while back we began moving from one old hudson server to a new box with a newer version of hudson on it that could better handle the ever increasing load it was being given. For a while things were working fine, I do mostly AS3/Flex builds using flex-mojos and I moved a couple project to the new server with no issues. At some point (still unsure why) our flex jobs started failing. The error given was as follows:

[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] key can't be empty

[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: key can't be empty
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(
at org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(
at org.apache.maven.DefaultMaven.doExecute(
at org.apache.maven.DefaultMaven.execute(
at org.apache.maven.cli.MavenCli.main(

I found a couple references online to "missing key in Hudson" but none seemed to fit my situation.

Eventually I ended up creating a new test project as a multi-configuration project instead of my standard Maven 2 project, adding an empty shell script and the Maven 2 build step. This ended up solving the missing key issue, though I'm at a loss as to why.

Since I struggled with this for so long I figured I'd post it and hopefully save someone else some pain. It's quite possibly a flex-mojos bug since it didn't seem to affect the Java jobs on the server. If anyone can explain why this seems to happen I'd love to hear about it.

This occurred in a version of Hudson just before the start of the Jenkins project, so it would likely occur there as well and I thought it's worth mentioning.