martinkl

Awesome, I'd love a pull request! I've been looking at FoundationDB, but haven't had time to test it. Porting the tests to another database is (hopefully) a mostly mechanical exercise.

See also this blog post on the technology behind Intro: http://engineering.linkedin.com/mobile/linkedin-intro-doing-... https://news.ycombinator.com/item?id=6600597

Nice. Of course the approach quickly hits a limitation if the dataset is too big to be replicated on every app server, or if low-latency updates are required. But there is wisdom in knowing what is and what isn't important in your particular application, and stripping away everything that isn't. Once you've taken away everything that isn't needed, the resulting architecture may end up being startlingly simple.

Rich and Nathan are really leading the thinking in this area; they are doing great stuff. But you're completely right that it is currently much easier to throw together a side-effect-ful system with frameworks like Rails. That's not surprising: the RDBMS way of thinking has been with us for a long time, and so the tooling and people's understanding of the model has become very good.

The challenge for any new architecture is to create frameworks and tools that are even better (easier to understand and learn, more efficient to work with, easier to maintain, etc) than what is already out there. That's what will determine their adoption, and that's a good thing: we all want good tools to work with, so the bar should be high.

Agree, this is going in the same direction. How models and data stores are structured will always depend on the particular application. But your point of "channeling access to the data store through only discrete paths" is very like the "separating communication logic from business logic" that I argue for.

However, I would like to take it further. Even if you move the data store access into a separate API layer, that API is still written in an imperative language, which limits the transformations that a framework can perform on it. I dream of a fully declarative way of specifying the communication dependencies, which would open up completely new processing modes, such as running all the business logic in Hadoop.

Using pointer equality is fine, but doesn't help in the case where you have a custom equals() implementation. Maybe the JVM could inspect the implementation of equals() and spot certain patterns (e.g. it's the conjunction of equals() of a set of constituent objects), but doing it in general sounds impossible to me.

Recent versions of Ruby also use a much better hash function. Java's hash function on strings has a slightly less trivial process for generating collisions, but it's still very easy to generate enough of them to pose a DoS risk.

Edit: actually, Java's String.hashCode() has exactly the same problem — prepending null chars doesn't change the hash code. And because the hash function is actually part of the Java standard library docs, it will probably never be changed (unlike Ruby's).

Interesting. But wouldn't that require keys to have an ordering (e.g. implement Comparable)?

From what I know, success of a startup is influenced by many, many different facets. If you read something like "Founders at Work", you see that many startups were on the brink of failure at some point before later becoming wildly successful.

In such cases, where the outcome is highly variable and very sensitive to the inputs, it's wise to have as many good cards as you can get. You can't just bet on one thing; every bit of support or advantage you can get could be the thing that makes the difference. (Sorry for the weird mixing of metaphors.)

Honest criticism is encouraging, at least if you approach it with the right attitude. Sure, you might feel down for half an hour, but once you digest the criticism there are two possible responses:

1. "You have a point, I had a niggling feeling that my stuff wasn't good anyway, but now I have ideas on how to make it better."; or 2. "Thanks for your opinion, but you are wrong, and I'm going to prove it!"

Both are motivating outcomes of honest criticism.

Why did you choose the name "Y Combinator?"

The Y combinator is one of the coolest ideas in computer science. It's also a metaphor for what we do. It's a program that runs programs; we're a company that helps start companies.

http://ycombinator.com/faq.html

I wrote a Ruby gem for accounting stuff a while ago: https://github.com/ept/invoicing --- it's unmaintained at the moment, but it does a lot of things right, so anyone interested in taking it over would be most welcome to do so.

It's a simple formula: build a product that people love, have a basic free version, charge users money for advanced features. The product you see now will most likely stay free forever, but we are planning additional premium features based on what our users are asking for.

You can see our analysis of freemium business models on the Rapportive blog: http://blog.rapportive.com/is-freemium-right-for-you

Edit: looks like rahulvohra and I had a little race condition here ;-)

YC was (and is continuing to be) very valuable for us. Sachin Rekhi has written up a good summary, which I broadly agree with: http://www.sachinrekhi.com/blog/2009/02/26/the-value-of-the-... -- and I would add to the list of benefits the massive network of the YC partners, who will happily make valuable intros.

Many other companies in our batch soon launched too, so we soon all ended up at pretty much the same stage.

Yes. The guys at Heroku were incredibly helpful, to name just one example.

Yes, we probably were doing something wrong. That's the point of the post: to explain how easy it is to get into a situation where you are making little progress, and our story of getting out of it. I sincerely hope that others will be able to cope better when faced with a similar situation.

It's easier said than done, though. Development takes significant ramp-up time; if you spend 10 hours a day on it, you get much more than 5 times as much done than if you spend 2 hours a day. We already did what we could in terms of distributing workload amongst people to minimize context-switching.

I was planning another post on that topic :) in a nutshell, we got H-1B visas. With a good attorney the paperwork is mostly tedium, but lots and lots of tedium. The process is very opaque and full of uncertainties.

Nothing is fun when it goes beyond a certain level. User support is interesting, but it gets a bit repetitive if you need to do it all day long. Scaling is really interesting, but getting no sleep because the database is on fire is not fun. Fixing bugs is not fun if they happen on other people's weird configurations that you can't reproduce. And raising capital... sure, it's glamorous, but in the end it's pretty tedious.

The amazing thing about a startup is that you can quickly translate your intuitions about a product you think that people want into an actual product. Making a good product and making people happy is what I care about. The other things are enablers.

[Edit - grammar fix]

Facebook is an example of a product with distinct modes of use for different audiences (the users and the advertisers). One audience pays, the other does not.

Nothing that deep. I just thought that I had come to an intuitive understanding of what I think of as intuition (meta!), and I wanted to share it. The analogy isn't scientific at all; it is just an attempt to communicate, in the hope that others might find the thoughts useful or inspiring.

Your definitions are pretty close.

no lead = there's no one investor who particularly stands out (e.g. by taking >30% of the round); a lead would usually drum up the other investors; with no lead, it's the entrepreneur who drums up the others.

no fixed amounts, no closing: with convertible notes (as opposed to straightforward sale of shares, aka priced round) the entrepreneur can be a lot more flexible. The round doesn't technically have a valuation, but it does have a valuation cap: see my write-up http://www.yes-no-cancel.co.uk/2010/05/05/valuation-caps-on-... for an explanation. The amount raised can also be flexible.

This doesn't require any more of a leap of faith or any lower valuation than a priced round, and the paperwork is simpler. That's why convertible notes are very popular for seed rounds these days.

Great feedback, thanks!

We find that the coverage varies a lot -- some users get a great experience, for others very little is found. We really want to improve that, and covering those 10% of emails which come from organisations is a first step.

Would this be sufficient to make you turn Rapportive on again? :)

Please contact support@rapportive.com and we'll send the documentation. For now we want to work closely with developers to make sure we're heading in the right direction.

We're have lots of ideas for Raplets which would be useful, and talking to lots of people. But anyone can write a Raplet!

Just to give one example, http://favstar.fm should be coming soon, letting you see the person's most-favourited tweets :)

I tried to find someone else to hand it over to, but it's hard. It's more than just understanding the code. A large part is also the vision, the gut feeling for the right thing to do, the personal contacts to early users etc. Those things can't so easily be passed on to another person.

It was a very very hard decision. I was working on Rapportive (rapportive.com) as a side-project, when suddenly a few big blogs got hold of it and we found ourselves with 10,000 users in 24 hours (and continuing to grow). It became clear that Rapportive is a huge opportunity. Go Test It is a good product, but Rapportive is just in a completely different category. And dividing my attention between the two looked like it would just be harmful to both.

It's hard to kill off something you love, but sometimes it's the right decision. I am very sorry though.

Martin (Founder of Go Test It)

Notes in themselves are only barely CRM, but we plan to allow you to share them with your team. And that's about as much as Highrise allows you to do! (Ok, there are also tasks, deals, cases etc. but who actually uses those?)

Sorry to hear about that bug -- we will look into it. For now, you can disable Rapportive by choosing Window -> Extensions from the menu, and clicking the 'disable' link on Rapportive.

Yes, we're planning to be very transparent about what we do. At the moment it's really just a matter of staying on top of all of the unexpected press!

Our users' trust is absolutely crucial to what we're doing, so you can expect detailed information on exactly what we do with your private data; and we may also make some things opt-in/opt-out. We have no intention of hiding anything.