jbrechtel

Yea. For me it was like two hands... :)

Now though, any other editor that's not Vim or Emacs feels like that...

............says the guy currently kicking everyone else's tail.

(nice work by the way)

Here's the post mortem by the winner of the subsequent AI contest: http://quotenil.com/Planet-Wars-Post-Mortem.html

"Remember when XP came out? (oh god, did I just age myself) " No, but unfortunately you aged me by implying that remembering that might age you.

IIRC 'Programming in Scala' doesn't talk much about the JVM.

As far as dependency management goes SBT can consume Maven dependencies, Apache Ivy dependencies or just manually added JARs to a 'lib' directory.

I'd agree that refactoring for clarity can't reasonably fall under a wide 'correctness' umbrella. Definitely more reasons to change code than correctness.

I put the word in quotes to try to express a much wider than usual connotation for the word (air quotes, if you will..). It's a shame that language is all we have to communicate on the internet.... :)

I also agree that we shouldn't precisely define tradeoffs before continuing on a single, specific, problem.

I just think that, in the macro sense, we can and should get better at defining the factors that would inform such a precise weighing of the tradeoffs for clarify, efficiency, expediency, etc... Doing so would give us better instincts for single instances where doing a precise comparison would be absurd.

"...it is a mistake to spend too much time clarifying something that might not be correct.."

I think the problem is that too many people disagree on what is 'too much time'. Not trying to nit-pick but obviously it is a mistake to spend 'too much time' doing anything. That's implied in the too much. That may come off as being pedantic, but I don't mean it to be so. I think defining 'too much time' is right at the heart of the problem. And it's a hard problem to be sure.

I'd also disagree that the possibility of something being incorrect is a reason to spend less time clarifying it...I'd say just the opposite.

By clarifying code you're making it easier to comprehend and thus change in the future. I'd say you should write code with change in mind.

Regarding 'incorrectness' itself...that's the only reason code is ever changed. Whether the code is fundamentally incorrect (the type I believe you were referring to) or temporally incorrect, the incorrectness of the code is always the reason for the change.

Could you please elaborate on why you perceive a correlation (or causation?) between TDD and haphazard development?

This echos my experiences exactly. I've found little value in state machines as a frequently used pattern. Abuses abound and I've also ran into the multi-page-html-form-as-a-state-machine anti-pattern. It's horrid and should not be done.

I'd be surprised if you heard about ThoughtWorks' professional services as cruel, hierarchical and underpaid.

I imagine we're more the source of the 'so disorganized they never even get back to you' part, right? If so, I apologize for that. If you really did just get dropped by recruiting then shoot me an email and I can rouse the right people.

I totally agree that non-coders contribute mightily to a project...especially good BAs. However, if there were really only two developers (which is admittedly unclear from the description) then it sounds like the staffing was absurdly out of whack. Unless this is a tiny floor and we're talking one PM and BA for the two devs....

Just for anyone wondering, not all consultancies operate this way. I've been at ThoughtWorks for 2 years now and it's nothing like this. It's quite literally the opposite on every negative point mentioned above.

Unfortunately, I have yet to write the promised testing post. The main ground I wanted to cover there was the legwork getting IntelliJ to run focused tests and whatnot.

Overall the situation has gotten much better thanks to the awesome guys working on the IntelliJ Scala plugin (details: http://blog.jetbrains.com/scala/).

Great, so the incentive to create content is not intrinsically coupled to the need to control sharing of that content. That's a great point that we often miss, I think.

However, how do you propose content creators become incented to create content?

Sorry, I'm still not following. What exactly do you mean by 'control over his brain state' ?

J is just an abstract concept. The concrete demands come from individual Jerfs which could contradict each other.

I must be missing something.

Perhaps a concrete example would be helpful?

In case you're interested....I've written a few articles detailing getting up and running with Scala+Android+IntelliJ. http://bit.ly/msXMZN http://bit.ly/lIDHRs and http://bit.ly/kgiAqZ

Yea, setting that up by hand can be a PITA. jberkel's plugin helps out a lot.

Also, if you're interested in using Robolectric with Scala then this helps (warning, shameless plug) https://github.com/jbrechtel/robospecs

InvalidCastException include the class name, doesn't it? That makes it order of magnitude easier to track down where it came from. The NullRef just tells you that it MAY have been that the 'as' failed, or it could have been a bona-fide NullRef.

Unfortunately, the real problem here is a broken API. A statically typed language whose standard library includes APIs that require downcasting is pretty embarrassing.

In general though, if the situation is truly exceptional (wrong type being passed) then counting the ticks used throwing the exception should be compared against the ongoing cost of the increased complexity to the codebase to handle the exception in another fashion (e.g. an if/else block).

Also, if you're just comparing the ticks of as+is VS invalid cast wouldn't you want to multiply each by the # of times they'll be executed? The as/is would be executed EVERY time the function in question was called. The invalid cast would, in this case, likely be executed once or twice ever and then the bug that is causing an InvalidCastException would be fixed.

This misses the author's point. In his example the bug you want to detect is that the referenced object in question is not a Customer (or a Foo in your example).

In your else block you can't report anymore information than the NullPointerException in the author's original example reported.

If you still use an 'as' operator at the callsite then you've lost all useful information. If you do a cast then you'll at least get an exception with WHAT it was you were trying to cast.

That sounds like a really great setup. I'm going to have to try this out one day. I've never really considered the specific benefits remote pairing would have over in-person pairing...generally the only things considered are the downsides.

Obviously, some of the things you mentioned with in-person pairing can be alleviated. At my current client, our setup includes multiple keyboards and mice. A friend of mine uses his own keyboard with a hardware switch to go between dvorak and qwerty.

You mention not being able to share a browser which makes me think of the times where it would have been convenient to look something up for a moment while my pair experimented (two pronged problem solving approach... :).

Also, what kind of pairing patterns do you use in this setup? Ping Pong TDD, driver/navigator, etc... ?

Also unlikely because if your phone had not been in the "off position" then your plane would have undoubtedly crashed.

That sounds like an interesting pairing setup. Would you mind expounding on the details, both technical and logistical, if possible?

Specifically, are you sharing a screen session with VIM in a terminal or what?

Do you rotate pairs or is it always the same person? How would you compare your remote pairing setup with live, in-person pairing?

I'd argue that Google would be terribly afraid of a lawsuit that might establish that the search market is something those laws apply to.

Why do you say that? We have about 2-3k and use Google Apps and it's a great fit. Just curious what you think would make it not a good fit if/when we start to approach 10k?

Statements like this are a result of our innate desire for everything to be black and white. Unfortunately, that's not the way things work. While the news networks are indeed in the business of providing what people want, they also have a hand in shaping their audience's desires.

To lay the blame of crappy news solely at the feet of the audience is about as short sighted as the conspiracy notion IMHO.

I'm pretty sure Sherashevsky (studied in the early 1900s) falls into the 'normal' people category. He certainly had problems but would be a very high functioning idiot savant at absolute worst.

http://www.amazon.com/Mind-Mnemonist-Little-about-Memory/dp/...