gwf

I was there as well, also as an intern. Around the same time, Mandelbrot also stopped by CNLS to give a talk. CNLS in the late 80s was truly a magical place.

worst. porn. ever.

The cardinality of the reals has been known to be strictly greater than the cardinality of the naturals since Cantor. What the Continuum Hypothesis considers is the cardinality of the reals and the cardinality of the power set of the naturals. The power set of another set is the set of unique subsets of the first set. If the first set has cardinality of N, then the power set has cardinality 2^N. Thus, the reals can be considered to be exponentially more dense than the naturals.

Some intuition: while there may be N unique stocks on the NYSE, there could in theory be 2^N unique mutual funds that are based on the different combinations of stocks.

Thanks so much! Here's the funny thing ... I had no idea there was a kindle version until just now (your comment prompted me to go look). I am pretty sure that it's new because -- while I don't follow the sales closely -- I also like to look at the breakdown of sales every year and I can't recall there ever being a kindle or digital category. So, yes, that's my guess.

I am going to go buy a copy now just, well, because I can.

Thanks. That was an explicit goal of mine, so I am glad that it worked out that way for you.

Thanks for making the recommendation for CBofN (I am the author). I should also add that the naming of my book was clearly inspired by ABofP (or ripped-off, depending on your point of view). ABofP was a real inspiration to me.

@zaguis, can you point me to anyone else besides @colabi that is claiming that their video has not been viewed? I genuinely want to investigate this, but after searching for a week I can't find anything concrete.

Since you are confidentially asserting that you believe that salesforce employees are lying, it would help everyone if you could identify just a couple of the dozens of developers that you reference.

If you do so, I will investigate their specific situation directly.

Can you point me in a direction where I can find contestants that are claiming this? I work at Salesforce and I would like to investigate this further.

I already commented on an earlier thread (https://news.ycombinator.com/item?id=6784782), and so far I can find only one person that is claiming that their video was not shown (@colabi). While every complaint deserves to be investigated, I think colabi's has been heard multiple times already and I'd like to see if there is some other cause for concern.

I honestly can't speak to the specific allegations because I am not in a position to know the facts one way or another. But I can tell you three things for certain.

First, salesforce is taking this very seriously and there is an ongoing discussion at the highest ranks to evaluate the complaints. Literally, the entire executive team is watching this.

Second, there were close to a hundred people that were internally part of the judging process. Each of these judges looked at a dozen or two entries. I could see little opportunity or motivation for collusion.

Finally, salesforce is one of the most self-critical companies that I've ever been a part of when it comes to evaluating ourselves in terms of trust and integrity. Nearly every internal communication begins and ends with a statement around how trust is our most important value. And while some our doubting our credibility in this moment, there's a reason why so many large and small companies trust us to hold their data; it's because we never compromise on any issue of integrity and if we make a mistake we investigate it and own up to it.

No problem. Will do in a second...

Your first link doesn't contain a single complaint claiming that people's videos were not viewed. It does, however, link to the second link, and the other two links it contains make no references to this sort of complaint.

The second link has exactly one person clearly stating that they've received zero launches and zero video plays. There is a second person that states "Yeah, same here. We had a workflow setup to send us notifications if any new used the app and received none." Notice that he/she doesn't mention video plays.

So, in total, we have exactly one person that says that they've received zero launches and zero video plays. If I've unfairly characterized the data behind your links, please let me know. But that's all that I can find.

In trying to find out if they have a valid complaint, I've discovered that the person behind that complaint is responsible for a significant portion of all of the discussions and complaints at the challenge site.

One thing is clear: their submission is in the same area as the winning entry. In their shoes, I might be disappointed for that reason alone. But for the sake of transparency, here are the two entries:

The winning entry (which is admittedly being evaluated to see if they conformed to all rules):

    http://salesforce1million.challengepost.com/submissions/18552-healthcare-love

The entry for the person or group that claimed that their video was never viewed:

    http://vimeo.com/79921465

In any case, I encourage you to look at the two videos and tell me if you think there was an injustice with the rank ordering.

I honestly haven't seen a single complaint like that. Can you point me to one? FWIW, I am pretty sure that each entry was reviewed at least twice.

I am saying that there is a misunderstanding. The earliest rounds of judging looked at the videos of the apps that contestants produced as well as a code review as a sanity check. This was done most likely so that each app could be viewed in the best possible light as well as to help the judges scale to the number of entries.

So, no, the people complaining are not lying but they and anyone else would be incorrect to conclude that their app was not evaluated. Every app was evaluated. All by videos. Some by code review. And a few through every reasonable means.

I work at salesforce but I am not a spokesperson for salesforce nor do I have any authority to speak for the company. What I write here, I write as a member of HNN only.

I did not have any part in the hackathon process, but I had and still do have quite a bit of visibility on how the process was run. I can assure you that an enormous amount of effort went into the judging and that it was entirely unbiased. There were literally dozens of the most senior executives and engineers within the company that worked on the earlier judging rounds behind the scenes. I actually declined to be part of that process because it was too much of a commitment for me to make. I know, for example, that the next-to-final round judges were up until the early AM reviewing the submissions and that each judge looked at on the order of 20 different submissions per rounds.

Sadly, whenever something like $1M is on the line, there is always going to be someone that is unhappy with the outcome. People will speculate and make claims that are outright false. But please keep an open mind as you read more about this event. There will soon be some official communication on this topic from salesforce. I suspect that the more actual facts you learn about the process, the more reasonable it will seem.

I managed to clip the isitdownrightnow.com status while it was down:

http://clipboard.com/clip/LQOyBd-lpIMCZzlmvYHqted7GrrQ3zkJis...

You may want to consider http://clipboard.com/ as well. It allows you to save almost any type of web clipping (text, whole pages, parts of a page, reader view, etc.). Disclaimer: I am the founder of Clipboard.

I am the founder/CEO of Clipboard. Thanks for taking the time to read our privacy policy. I'll do my best to answer each question, but please let me know if you think that I missed anything.

1. Web beacons are typically understood to be any sort of tracking mechanism. We track emails via Sendgrid to see how effective they are. We use Google analytics to see where and how people are using the site. We use mixpanel to better understand how people use individual features. All of this is pretty standard stuff.

A non-standard thing that we do is that we put in place a secret key on the client local storage of your Web browser which we use to protect our user's accounts. Here's how it works... we can transmit the secret one time over HTTPS. Then, when you create a clip on a 3rd party site, we can redirect the clip payload via XDM to our own domain, and then digitally sign the API call with the secret key. This (a) prohibits a bad guy from spamming your clip account, and (b) makes it so no one else can see the shared secret (even though this partially runs on other domains).

2. Re. the buy / sell language ... we do not now nor have we ever sold any information to any 3rd party about anything, nor do we have any intention of doing so. The first sentence is meant to make that clear. The second sentence says that we my buy or sell more general assets (for example, we purchased some patents last year and with it came a user database with emails from a retired service).

So, our stated intension is to never sell any personal information about any customers. I think that it is possible that some day we may sell aggregated data, but we're not there yet. And if we made any change, then we would clearly owe our users an update on the change in policy.

I, nor any other CEO, cannot guarantee what happens if we are ever sold. We can do our best to have a outcome that's good for everyone, but in this there can be no guarantees. FWIW, we destroyed the database that came with that earlier deal because it seemed like the right thing to do.

3. Our privacy policy and ToS have been the same for over a year. I think we may have fixed a typo once or twice during that time. If we ever do a major update -- one that materially changes the terms for anyone -- I think we'll send such an update via email. However, I suspect that most users do not welcome such emails, so we're trying to walk the line that is clear, transparent, and not annoying.

4. We don't have a bulk export tool, nor do we have an external API, but we'll get there soon. The API is fairly mature, but we still need to add an OATH2 layer. However, here's a stop gap: Suppose you want to export a clip, like this one: http://clipboard.com/clip/LQYHMLUq21-yNhdiYu1BUYzGdFQOUfUFEQ.... If you change the URL to http://clipboard.com/api/v1/clips/LQYHMLUq21-yNhdiYu1BUYzGdF..., then you'll get the JSON for the clip. And if you take the blob GUID from that clip object, you could hit http://clipboard.com/api/v2/blobs/BLOGGUID. But, trust me, we'll make this better for hackers before the year is out.

5. Money. Like most a lot of startups, our evolution is designed to go from launch -> growth -> monetization. We're only now entering the growth phase, so we're not going to focus on significant revenue at this time if it will hurt growth. The exception to this is that we may offer some pro features sooner rather than later (e.g., Clipboard for teams). Right now, we are having a lot of conversations with some of the biggest commerce and media companies in the world around ways to monetize Clipboard in a manner that is good for everyone. But it will take time.

To be clear, we lose money every day -- but we're supposed to at this phase. Your options are pretty clear. You could bet on us, taking the risk that we don't last; or you can wait until we're profitable, which means that you'll be a late adopter. It's up to you. But I think that if you take a look at our team, our track record, and the choices that we've made over the past 18 months, you may find that we have the makings of a good group of people to bet on.

http://zoom.it/ is much older, seems much faster, and you can create your own.

Does this mean we can finally have semicolons?

Here's the thing ... we don't actually need 3rd party cookies. However, in most browsers you need to have 3rd party cookies enabled in order to read client local storage (not a cookie!) within an iframe that's in a different domain. We so this to digitally sign the API calls so that malicious 3rd party sites can neither spoof nor read the shared secret used for the digital signature.

So the irony is that we make our API calls digitally signed (more secure) but to do so from the context of a bookmarklet you have to enable 3rd party cookies because browsers bundle that switch to the capability that we really need (i.e., there is no "enable loading of cross domain iframes that can read client local storage securely" option because its unfortunately pairs with 3rd party cookies).

You can clip almost arbitrary parts of web pages. See http://clipboard.com/gary/boards/examples for a whole bunch. This makes a big difference because instead of simply having pretty pictures of food, you can save actual recipes and search over ingredients. You'll probably find http://clipboard.com/category/Programming interesting as well.

We started using our logo about a year ago (which came from a great collaboration with the awesome Jackson Fish Market team). It's kind of unfortunate, but these things happens. We registered our trademarks quite some time ago, including the single logo. So, no, we did not consult with them nor they with us. We think they are good folks, and are inclined to live-and-let-live. So for me, as long as we are in very different spaces (which we are) I see it as mostly a non-issue.

We worked with the awesome Jackson Fish Market for the logo about a year ago. Someone pointed out the Charm logo to me later on, and I thought it was best to just live-and-let-live, since the two services have no similarity. I know that we came up with logo independently, and I can only assume that given their reputation that they came up with it independently as well. So it goes; stuff happens; you move on.

That said, I like our logo and I think it makes sense in that the union of the heart and paperclip strongly relates to the act of saving. But I don't quite get the Charm logo; for me, it doesn't really connect to what I understand their product to be. In any case, it's all good.

I bought it around January of 2011, when I knew I was going to move forward with the concept. It seems kind of tacky to share the amount, but it cost about 5-10x less than what most people guess, as the previous owner was extremely reasonable.

Clipboard also allows you to clip almost arbitrary parts of web pages (text, images, embeds) with the style and most functionality preserved. See http://www.clipboard.com/site/ycombinator.com for examples of things clipped from Hacker News.

Disclaimer: I am the founder of Clipboard.com.

To be clear, operations in our test corpus that took X ms on average took 100X ms. Is that the statement you are looking for?

One thing that I think you're missing is that while we experienced a 100x gain for our application, our findings aren't strictly empirical in the sense that the gain is always 100x. In many applications it will be more. The insight in the blog post is analytical, not empirical. Specifically, most people (I think) would assume a text index to be document partitioned. In Riak it's not. On a fundamental level this means that AND operations take time O(max(|A|,|B|)) instead of O(min(|A|,|B|) where |A| and |B| are the sizes of results that match query A and B, respectively. If you pick words at random from a power law distribution (which is typical in all natural languages) you will more often than not see many orders of magnitude difference in the |A| and |B|. If you sample queries from real query streams, you will see the same. For some intuition, just think about a query which has a common tag (like "funny" used in the example) and something restricted (like a particular user). The first will typically be an understood fraction of the size of your corpus while the second will have size that is more like a constant.

Putting this all together, the savings that we find for moving the intersection where we did will only grow on a relative basis as we get more users and clips. This hack costs 2x the storage size but always give O(min(|A|,|B|) complexity results instead of O(max(|A|,|B|)). 100x win is just shorthand for saying that those two set sizes typically varied by two orders of magnitude because of power law distributions. But in academia, we refer to that as "really fucking big".

The "presort" option that we added will scale differently, but have equally dramatic impact because pagination is effectively broken in Riak search if you do not use relevance sort. In this case, the O(.) argument is murkier because one version is done entirely within the index (which is usually in RAM) and the other has to hit the disk. In formal engineering circles, we refer to this type of boost as "unfucking real".

So, we could have measured things with more precision, but this was such an obvious win that it was almost pointless to calibrate it further.

The baseline was a substantial test corpus that we scaled several orders of magnitude over a series of runs, all meant to simulate typical clip size with typical word frequencies. The 10-100x gains had two contributions that each was in the 3-10x range. We tested it against the standard search which incorrectly performed pagination because of the misorder on sort versus slice. We also tested in on two types of map/reduce jobs that correctly implemented the sort and slice (and had been in production).

Ideally, we would have kept the data around to give a fuller a report. But the truth is we did this over 9 months ago and didn't save the data. After informally sharing the impact with a lot of people, we heard a lot of encouragement to share the techniques.

And you're right, this is not hard core science nor engineering. But it is a good tip, which you can take or leave.

The hive mind is cute when it's temperamental.

It really isn't all that bad. When you compare what we had to do compared to keeping two big data systems in sync (instead of Riak, which is a breeze), I think we got off easy.

Hey Josh!