From the department of things that should throw exceptions...

    System.out.println("value: " + Math.abs(Integer.MIN_VALUE));

Try it out yourself! If this makes any kind of damn sense to you please enlighten me in the comments.

Someone should really fix that

Well there is a fantastic set of slides entitled: "Why python, ruby, and javascript are slow"


It is right here and you should go read it. but I can sum it up for you by copying a couple of slides

First: here is how you might define a point in C:

struct Point {
   double x;
   double y;
   double z;
};

Ok, thats nifty, lets do that in javascript:

var point = {
   'x':x,
   'y':y,
   'z':z
}

Correct so far, that is pretty much how you'd do that in javascript. But what you are really doing can be best explained by doing a literal translation of the javascript back into C:

std::hash_set<std::string, double> point;
point["x"] = x;
point["y"] = y;
point["z"] = z;

"If you put this in a code review, first your coworkers would laugh alot, and then they'd make mean jokes about you for the next year."

Nobody will laugh at you for doing it in javascript, because that is the best that we've got.

Someone should really fix that.

Is your development methodology wrong?

Agile is too unpredictable, we need more process!
Waterfall doesn't allow us to react to market changes fast enough, lets look at agile!

I hear this all the time in software and mostly ignore it, in general, if you are getting stuff done more or less on time, don't mess with your process, it is too much time for the benefit (assuming it doesn't make things worse).

There is a whole lot of meat in Sinofsky's most recent blog post about software methodology, and you should just go read it, but I'll pick out the hit list of Signs That Things are Going Off the Rails:

• Unpredictable.  Some efforts become unpredictable.  A team says they are going to be done on Friday and miss the date or the team says a feature is working but it isn’t.  Unpredictability is often a sign that the work is not fully understood—that the upfront planning was not adequate to begin the task.  What contributes to unpredictability is a two-steps forward, one-step back rhythm.  Almost always the answer to unpredictability is the need to slow down before speeding up.

• Lots of foundation, not a lot of feature.  There’s an old adage that great programmers spend 90% of the time on 10% of the problem (I once interviewed a student who wrote a compiler in a semester project but spent 11 of 12 weeks on the lexical phase).  You can overplan the foundation of a project and fail to leave time for the whole point of the foundation.  The checkpoint is a great time to take a break and make sure that there is breadth not just depth progress.  The luxury of time can often yield more foundation than the project needs.

• Partnerships not coming together.  In a project where two different teams are converging on a single goal, the checkpoint is the right time to sanity check their convergence.  Since everyone is over-booked you want to make sure that the changes happening on both sides of a partnership are being properly thought through and communicated.  It is easy for teams that are heads down to optimize locally and leave another team in a tough spot.

• Unable to make changes.  In any project changes need to be made.  Surprisingly both ends of the methodology spectrum can make changes difficult.  Teams moving at a high velocity have a lot of balls in the air so every new change gets tougher to juggle.  Teams that have done a lot of up front work have challenges making changes without going through that process.  In any case, if changes need to be made the rigidity of a methodology should not be the obstacle.

• Challenging user experience.  User interface is what most people see and judge a product by.  It is sometimes very difficult to separate out whether the UI is just not well done from a UI that does not fit well together.

• Throwing out code.  If you find you’re throwing out a lot of code you probably want to step back—it might be good or it might be a sign that some better alignment is needed.  We’re all aware that the neat part of software is the rapid pace at which you can start, start over, iterate, and so on.  At some point this “activity” fails to yield “progress”.  If you find all or parts of your project are throwing out more code, particularly in the same part/area of a project then it is a good time to check the methodology.  Are the goals clear?  Is there enough knowledge of the outcome or constraints?

• Missing the market. The biggest criticism of any “long” project schedule is the potential to miss the market.  You might be heads down executing when all of a sudden things change relative to the competition or a new product entry.  You can also be caught iterating rapidly in one direction and find competition in another.  The methodology used doesn’t prevent either case but a checkpoint offers you a chance to course correct.

That's pretty much it and if you are uncertain about what criteria you want to use for deciding when to revisit your team's process, you could do alot worse than to adopt this list.

Giving up on Java's Constructors

As much as I'm not always a fan of objective-c, I really like the method calling syntax:

    Merger merger = [[Merger alloc] initWithFirstString:"foo" andSecondString:"Bar" startingAt:1 suffleOutput:false lowercaseOutput:true];

If you wanted to write that in java, it would be fairly incomprehensible:

    Merger merger = new Merger("foo", "Bar", 1, false, true);

Just looking at this, who the hell knows what "foo" and "bar" are and why there is a number and a couple bools after it. You've have to look at the docs. Assuming you wrote docs... You could just nuke all the constructor params and create a whole lot of setters, and do this:

    Merger merger = new Merger();
    merger.setFirstString("foo");
    ...

But that sort of stinks too. First, it six lines of code for something that should go in one. Second, what if you want those parameters to be final?

So I've basically given up on constructors in java and added the following eclipse template to my tool belt:

            ${:import(com.google.common.base.Preconditions)}
            public static ${enclosing_type}Builder Builder() {
                return new ${enclosing_type}Builder();
            }

            public static class ${enclosing_type}Builder {
            private String property = null;

            @SuppressWarnings("synthetic-access")
            public ${enclosing_type} build() {
                Preconditions.checkState(this.property != null,
                    "property is required.");
                return new ${enclosing_type}(this.property);
            }

            public ${enclosing_type}Builder property(
                final String property) {
                this.property = property;
                return this;
            }
        }

It ends up being quite a bit longer than the original java code, but only slightly longer than objective-c. And I'm fairly certain that the next person that comes across my code is going to be very clear about what I was trying to do here.

If Eclipse templates had the support, I'd have it find all the members of constructors in the enclosing type for the builder and run checkState on all the final members but I'm fairly certain that would require plugin development.

What do you think?

Another Day, Another Java-In-The-Browser security hole

This one affects even fully patched, up to date browsers.
It works like so:

1. use any browser with java enabled
2. visit a page
3. owner of page can now execute arbitrary code on your computer

I love java, but, damn if it doesn't suck in the browser. This is just the latest, if you still have it enabled in your browser, now is the time to disable it. 

Do it now.

By convincing a user to visit a specially crafted HTML document, a remote attacker may be able to execute arbitrary code on a vulnerable system.

http://thenextweb.com/insider/2013/01/10/new-java-vulnerability-is-being-exploited-in-the-wild-disabling-java-is-currently-your-only-option/

Resume Visualization: What does your resume look like?

my resume, according to Tagxedo

I like to keep my resume up to date. Every time some new task comes along, I'll add that in there somewhere. Then if a new job comes up, I'll just edit out the old stuff, make a quick attempt at removing the irrelevant things, and mail it out. 

So what is my resume saying? 

Well on the advice of my wife I threw my resume into a word cloud generator. There are a few of them, but I picked tagxedo. 

So what does it say about me? Well not a whole lot about the technologies that I use, but a bunch about "management", "product", "design". I suppose that would be great if I were mostly focused on more management. Or if I were a product manager. But I'm probably not.

Now lets look at some of the jobs that I might be interested it.

I just took a stab in the dark: I like kindle, I like enterprise software, so I threw in the first job description from the kindle team that caught my eye. The result: a very different word cloud.

A Kindle SDE Job Description

Now I'm not saying you should lie on your resume: that will always come back to bite you very quickly. But your resume is basically just the sign on the front of a restaurant. I've done a bunch of things, and they'll all be reflected on my resume, but I am clearly spending much more time talking about things I've done that aren't relevant to the jobs I want than I should.

Because I'm in software and everybody needs them I get reasonably good responses when I apply for jobs, but I suspect now, that I'm getting this traction in-spite of my resume, not because of it.

Time to update.

Write your complicated, shared code once

write once, sorta runs everywhere

One of the deadly sins of software development is duplicating logic. I won't attempt a software engineering 101 class in a blog post: but you are more or less guaranteed to create bugs when you have logic doing the same thing implemented in two different places.


There was a time when this was easy: just don't cut and paste your code. Put everything in a library, then just use your library across projects. This time pretty much ended when we started using javascript to do Interesting Things on the web. When we started also doing interesting things on phones, it was long past.

Now we end up writing lots of code twice or more, because your server is probably written in java or .net, or php, or ruby and your phone is written in objective-c, or java, or something else.

Take a look at the fairly amazing diff-match-patch library used for keeping text documents in sync:

http://code.google.com/p/google-diff-match-patch/source/browse/#svn%2Ftrunk

Neil Fraser has written that library in python (both 2 and 3), java, javascript, c++, c#, lua, dart, and objective-c. While I have to admit a certain amount of awe for that guy's multilingual skills and the attention to detail necessary to get that stuff written in a way that all those implementations talk to each other correctly, I am not sure I want to spend that kind of time.

I also don't want to try to shoe-horn a project into a single common language. We tried that with Java once upon a time, we are currently trying it with javascript (in the form of node.js, and phonegap). These solutions always force you to accept some unacceptable compromise. Maybe phonegap and node.js works for your product. But chances are, someone else has something that is much better written in python and objective-c.

Write-once, run everywhere remains a non-starter in the general case.

What makes a whole lot more sense to me is to write only the code that must be shared once.

Figure out what your complicated, shared code is. If you are writing a shared text editor using diff-match-patch, it is that algorithm that is complicated, and must be shared across platforms.

Write _that_ in javascript.

Embed it in your code using a hidden WebView in IOS, Rhino in java, or maybe Ringo in Python.

There are a million embedded javascript solutions out there.

Then you are free to write the rest of your client and server independently of one another.