tyler

Most things certainly are simple in principle.

"Distant features"? It's launching tomorrow.

Personally, I'm not particularly picky about my forms of immortality.

Evan Miller's guide (already linked above) is great. But be prepared to dig into the Nginx code. Most things aren't documented, however, at least in my opinion, it has some of the cleanest large scale C code around. So, don't be scared to dig in.

The word "rape" has multiple meanings. At least one of which applies and is not necessarily connected with anything of a sexual nature. http://en.wiktionary.org/wiki/rape

The part I find particularly silly is where he writes:

  For example, assume that the hash table implementation
  shrinks the table if the number of full buckets drops
  below half, and grows the table if it becomes over full.
  If the table starts out with 100 buckets, and the number 
  of buckets falls to 49, the size is shrunk to 50.

I've never seen a hashtable that actually works this way. It's common knowledge that performance of hashtables degrades long before the "full" point. (I particularly like the explanation of that here: http://eigenclass.org/R2/writings/separate-chaining-vs-doubl...)

No insult intended at all. It was just that as I was reading down that list my brain was screaming "CAP! CAP!". I was glad to find that link there. Looks like an awesome project.

The description given on their Google Code page seems a bit sensationalistic to me. The author has a bit more reasonable look at the features and tradeoffs here: http://sbtourist.blogspot.com/2009/12/terrastore-and-cap-the...

In my opinion, that's a problem. If you don't understand what is actually going on under the hood, you're likely to get bitten when things don't go exactly as you expect.

ActiveRecord is the most obvious example of this. If you don't know what queries it's going to throw out for a particular call, it may work just fine in development but could easily bring down a site in seconds in production.

Routing is another example. If you have a particular action that needs to have as low latency as possible changing its position in the routing file is often one of the easiest and most effectual changes you can make. Someone who just codes in the framework and doesn't understand how it works is unlikely to realize that.

Ouch. "filters" wasn't the right word there. Sorry about that.

I tend to ask, not how you use the framework, but rather how the framework works. How does routing actually work? How do named scopes work? How would you implement the {before|after} filters on models... etc.

It's actually somewhat more difficult to tell whether someone knows how to use Rails well. My only suggestion is to sit down in front of an editor with them and work through actually building something small but meaningful.

You certainly could argue that, however, if it were true in most cases Google, a highly data-driven company, would be still be working that way.

What bothers me most is when a candidate gives off a "this is below me vibe". I tend to start with quick, easy questions and work toward much more difficult ones. Candidates often act as if answering these easier questions is below them... And then choke on the hard questions.

To me, acting haughty is a good indication that you're going to be a pain to work with. You're going to make a fuss when asked to do easy work, rather than just getting it done and moving on to the more interesting things.

That's my pet peeve and the pet peeve of several others I know, so apparently it's fairly common.

Right on. My point was simply that the type of Trie you use has an effect on the data's size in memory. A dual-array setup is pretty good at keeping the data small... There's very little pointer overhead and proximity is fairly good as well.

I've had the opposite experience with Tries v. Hash tables. Though that could be a result of the Trie implementation. Dual array tries have really impressive lookup times, especially compared to the naive implementation... Insertion is pretty bad though. (Though that can be mitigated: http://www.gongcaichun.info/PPT/21.pdf)

As a counterpoint, not every Ruby app is a Rails app. I've been using JRuby more and more lately for various text analysis projects. Calculating the mutual information over a huge set of tokens, for instance, was roughly 10 times faster in JRuby... And of course didn't suffer from the Unicode issues I was running into with Ruby (1.8). Regardless of whether or not it's suitable for Rails, it's absolutely suitable for other projects.

Nonsense. My multitudes of small web services, many of which have been running months without a restart and while taking up no more memory than they did at the start say you're wrong. Even if there are some obscure bugs, and there undoubtedly are, that doesn't make ruby an unsuitable language for systems programming.

From the article: "2) reducing the aggressiveness of our SEO, which reduces total traffic in the near term but increases the relevancy of Scribd links in search engine results"

Wow. Not many people would willingly say "I hope your startup fails and all the employees (fellow HNers) become jobless." Keep it classy, man.

The question he was asked was actually whether he would want someone to publish TC's documents. The answer is obviously no. However, that's completely separate from whether he would consider it news. It's news whether or not you want it to be.

They detect when you paste something and use a fixed-width font on it. Also, they truncate it and link to a full version.

I don't see why that is a problem. While I don't think that this is really the whitehouse taking a side, what if they were taking a side? They should.

I've been really looking forward to this mostly because of how bad ActiveSupport's implementation of this is. For instance, lookups require a linear scan. Definitely a welcome change.

That seems like a dangerous and foolish proposition to me. Just because IBM doesn't seem like a patent troll today, doesn't mean they won't tomorrow.

Not to mention, just like a real arms race... It's not the government officials who are really in danger, it's all of the common people, or in this case, programmers.

Yes. That's true. But that's not what is being discussed. What is being discussed is whether or not frameworks and high level languages exist solely to make the bottom 90% more productive.

My comment illustrates the fact that criticizing those two things in particular is beyond silly. Essentially, I'm saying: Where is the limit? Unless you code everything, from scratch, every time, in assembler... You're using a high level language or a framework.

And you should be... The main point of them is to save time. They don't solve all problems obviously, but they solve the kinds of problems that you don't want to solve over and over and over.

Okay great. Well, you go ahead and hack up your project in assembler, making sure to build everything (including the network stack) from scratch. Let's have a race. If only all of our competitors were as misled and arrogant as you. :)

Who is 280 North?

I think you're missing the point the author is attempting to make. 37Signals is a well-founded company which has several applications, each generating revenue. It's also well-known. The points which the author purports would make 37Signals tempting to Microsoft do not apply for 280 North.

This would be a much more interesting question if you were to give specific examples of how specific YC startups are "spineless", and perhaps how they could be less "spineless". Without that, I'd simple respond: "They're not."

If you keep scrolling there are some more non-pure-math algorithms. Including: pathfinding, heaps, and some threading stuff.

I like the reverse chronological order... It's like being transported back in time, and watching the history of CS fly by in fast-forward.

I was on the team that built http://bootleggers.r08.railsrumble.com

Think of it as election.twitter.com... except you make your own channels. And you can follow or fork other people's channels, and blah blah.

Oh and it's not just Twitter. :)