dhh

J2EE's sins include far more than just EJB. See http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Editi.... Servlets got just started running with a bad crowd, even though deep down it was a good kid.

Let me translate it for you, then. Wankery: Complexity brought on by the love of an abstract idea without meaningful practical benefit.

By definition I don't see the point in architectural exploits that can be labelled wankery.

Not every new architectural idea is a good one. Lots fell by the wayside over the years. See J2EE or Naked Objects (I actually kinda liked that one). Bad ideas fail faster when criticism is brought forward which opens the floor to new, better ideas.

That's essentially my beef with most query objects. Wrapping a query in an object like that is usually too much ceremony for something that's just a method.

It doesn't get any better by having Viewer.new(current_account.posts, current_user).visibles or #execute or whatever else you'd do in a query object.

That's exactly the idea.

We built Basecamp while I was working from Copenhagen, Denmark. I currently live and work and wrote that piece from Spain. Out of some 35 people, only about a third has base in Chicago. Out of that third, maybe half of them go to the office every day.

I apologize for not getting back to you. That's not cool in general and triple uncool when you've out this much effort into it. I will make sure we write back to all applicants in the future to let them know when we've made a decision (this does some time take a while though, we've taken 4-6 weeks in the past to make a decision, but it will be done).

You TDD your goals. Square could certainly have started with modest goals, like we did with Basecamp, such as "get to $4K/month in revenues". That probably wouldn't have floated for them, given all the VC they took. But there are many grays between that and "unseat every POS ever".

That's like saying your first test would be "complete project management system". That's not what you do. My first test for driving was "gentleman mid-pack", for biz, it was "$4K/month revenue". For Basecamp, the first test was probably "add a single post".

You're right that if your server is very slow at generating the response, turbolinks is not going to add much in terms of perceived performance. Same is true if you download multi-megabyte pages. So don't use it for either of those cases!

We use it for pages that have low latency (50-100ms) and a light weight (<100KB) for Basecamp. It makes a big different for apps built like that. This is a project that works with and encourages you to build apps like that.

Correct. You can opt-out links with data-no-turbolink. Or, of course, you can opt out of the whole thing by removing the turbolinks gem from your Gemfile.

This is now fixed.

Rails is great for fat-client JS apps as it stands today. Everything on the controller and model side of things makes for a wonderful backend for fat-client JS apps.

But if you're going to use Rails for the view, the focus will remain on making Basecamp-style apps (turbolinks, russian caching dolls, etc).

If you don't flush every line, you'll lose lines in a crash. You often need those lines when trying to debug such a problem, so that's the worst possible time to lose said lines.

We added tagged logging to deal with the "not in order" problem. Find the process id of the request you're trying to follow, grep for that.

Both problems solved.

Emails are like async views. The model should not be responsible for rendering views. That's the responsibility of the controller. Which is why Action Mailer itself is modelled on Action Controller, uses Action View, and so forth.

Don't change a thing, mate.

I used it as an example of what people who just modify an existing code base would use. Not Wordpress, the product, itself. I'm sure that's nicely done.

You have no idea? You launched wild accusations that we were just playing everyone with our proposal and that we actually just had a buyer all along. If we had a buyer at $480K, we would not have bothered listing it again. We would just have sold it.

I think the only reason why you consider my attitude an outlier is because I state it. Every business have a cut off point where a potential return is not worth the hassle. $480K was that number for us. I'll guarantee you that it's much, much higher for most other businesses.

Do you think Apple is going to fiddle through $200K purchase negotiations if they want to diverse themselves of a product? Of course not. Just not worth their time.

I'm happy how things have worked out for me so far, but thanks for caring.

Bitter? No. Offended? Sure. We share everything that's going on with the sale. Multiple write-ups. And yet still the default HN hive-mind behavior is to jump to a conspiracy theory!? Come on.

Here's another wild theory: The buyers contacted us directly, got the answers to the questions they sought, and closed the deal.

Also, this is not out of the blue. We lost interest in considering all sorts of complicated deals a while back. So we told everyone that the price was $480K and that the deadline for closing a deal was July 1st: http://37signals.com/svn/posts/3172-sortfolio-going-once-goi...

So there was really no "bidding" after that point. It was quite simple: Give us $480K and the site is yours. The new buyer's did just that. End of story.

Yeah, you got us figured out. We had an offer, sat on it, invented this story to see if we could get more, and played the world for a fool. BUT YOU BUSTED US. OH NOOOOES!

Or, of course, the simpler explanation: We thought the site was worth at least 2x the previous year's take. And if we didn't get that, it wasn't worth our time to deal with the transaction.

Yes, despite the HN peanut gallery's perception of the world, there is actually a market for profitable businesses. It's surely less exciting than selling your no-revenue photo service for a billion dollars, but that's ok.

We'll be sure to follow the life of Sortfolio after the sale.

You're behind the times. We jumped the shark seven years ago: http://37signals.com/svn/archives2/have_we_jumped_the_shark.....

This is exactly the point of the original post. That if you're willing to redo Rails because a predicate method does not return singletons, you're a rookie who don't know the value of time.

Of course, people don't actually do this. They talk about doing it, but don't actually carry through.

Dude, that's deep. You're bike shedding the bike shed. So meta. Turtles all the way down. Touché!

You're a real charmer, aren't you? We can't wait to have you as a customer!

We weren't happy with the time tracking integration in Classic. It was usable, but it wasn't great. We want to take our time to either come up with a better built-in solution or an integration with another tool or something else.

This is a big part of why we're keeping Basecamp Classic around for a very long time. Basecamp Next was not going to launch with all the features that Classic already has. So it's OK that it's not a perfect fit for all existing customers on Day 1.

The iPhone didn't have copy'n'paste for a while, either. There's just so much you can do for launch, if you want to ship.

We're launching with a great set of features we could do in a reasonable amount of time. If we had tried to reimplement every single Basecamp Classic feature in Basecamp Next before we launched, it would have taken a very long time.

Basecamp Classic originally launched without even file uploads!

We'll be busy bees making Basecamp Next fill in gaps all over the place in the coming months. Looking into how we can solve people's time tracking needs with a great workflow in Basecamp Next is high on that list!

Which is why in our case we're keeping both the old and the new product around.

If you rewrite your code base to do the same things as the old code base was doing, yes, you're doing it wrong. If you rewrite your code base to do different things, you might very well be very right. (Depending on whether the market is more interested in those new things than the old things).