mfenniak

Woohoo, I out RethinkDB'd RethinkDB! :-D

Aside from that detail, this is a cool post. I like seeing the power of ReQL.

Slava, why "r.table('fib').orderBy('id').nth(x.sub(1))"? It looks like "r.table('fib').get(x.sub(1))" would be the same behavior but more efficient, using a primary-key lookup rather than retrieving the entire table and ordering by it.

What am I missing? :-)

Professional photographers know they need to backup their photos.

It looks like your product targeted consumers, but professionals seem like they'd be a better market. And it should have been priced way, way higher; the more it cost, the more secure it looks. I'd have a hard time trusting my money-making business assets to a $9/month service.

Of course, I'm not a professional photographer nor do I have your experience in trying to build this business, so who knows what my opinion is worth. :-)

According to this article (http://www.reuters.com/article/2013/06/21/us-tesla-swap-idUS...):

    A battery pack swap will cost between $60 and $80,
    about the same as filling up a 15-gallon gas tank,
    Musk said. Drivers who choose to swap must reclaim
    their original battery on their return trip or pay
    the difference in cost for the new pack.

So, I think they're not quite tackling the battery quality problem like you're suggesting. I think your idea makes a lot more sense than coming back to reclaim your battery later, though. I find that very odd.

I think it'd be a hard sell. You'd need to find some real, concrete pain points that people suffer from, and then address them, and then market it towards people suffering from those issues.

I'm a desktop Linux user (Mint), and I find it to be quite developer-friendly, and it has a nice UI, and Debian has the best package management. So, personally, I'm not sold yet. :-)

I think this advice is correct, but if I follow it I'm going to have a hard time ever getting the most important thing done. Why would I want to work on that, when I can work on the most interested thing instead? :-)

I guess at some point one needs some discipline... but that's not very fun.

Most https clients support server name indication (http://en.wikipedia.org/wiki/Server_Name_Indication), which effectively allows the "Host" header content to be presented before a server-side certificate is chosen (and therefore before the session is encrypted), to supported name-based virtual hosting.

Amazon actually regularly sends you e-mails letting you know if your configuration can be optimized to reduce it's price by moving to reserved instances. This suggests to me that they favor the reduced revenue but predictable capacity planning of reduced instances.

I'm the author of a .NET RethinkDB client (https://github.com/mfenniak/rethinkdb-net), and I can add that RethinkDB's lambda functions were very easy to implement in .NET by using C#'s expression tree feature (http://msdn.microsoft.com/en-us/library/bb397951.aspx). With that feature, a lambda can automatically be converted to an AST by creating a function that takes an Expression<Func<...>> parameter, which can easily be traversed and converted into RethinkDB's expression tree.

Expression trees were introduced at the same time as LINQ, to support LINQ.

Hi Joe,

I just wanted to pipe in and say that's excellent reasoning for this design, especially since the ability to create indexes on arbitrary ReQL expressions would make an intelligent query planner into a lot of work. I'm looking forward to giving these a try.

Here's Brennan's e-mail newsletter signup page: http://freelancersweekly.com/

"410 Gone" is probably preferable to 404, as it would indicate there used to be a resource at that URL.

Thanks for the feedback. There are usability issues, and as you point out, the importance of the links is not evident at a first glance. I like the popover idea; I'll have to give that a try.

Thanks!

The enterprise integration patterns links are interesting to me; thanks for point those out. I can definitely see how they could use a connection to reality. I can look at a random one and see what it is, but understanding why you'd use it is a mile above my head.

I have absolutely considered adding weights. But, it quickly leads to the idea that my priorities are not necessarily the same as everyone else's, and that leads to user-customizing, and that leads to... well, it got to some cool ideas, but I figured first I should shove this out the door in a simple form and see if people like the concept. If the concept is well-received, I'll continue to develop it and explore other API best practices in a similar manner.

These spreadsheets are nice little tools. An increase in traffic vs. an increase in conversion rate vs. an increase in product price are not directly comparable, but when you convert them to revenue they sure are. Handy.

old-gregg makes a great observation here. The addition of a ZFS benchmark without-compression is needed to isolate the compression as a factor in the speedup.

That aside, I thought this was a wonderful article with non-intuitive findings. Very interesting, CirtusDB [edit: er, CitusDB]. :-)

Ooh, very interesting questions. :-) I'm not sure I have the answers for these questions, but I do have some ideas.

Most APIs don't want to provide data analysis capabilities. They want to provide data. Data analysis is a really hard problem space. For the FBI example, the FBI doesn't want to build an analytics tool for you to use; that's not their core business, and it's not something that helps them achieve their goals.

Data analysis versus data are two different problems with different classes of solutions; for example, a valid approach to delivering data might be an API to retrieve compressed, batch (nightly) downloads of events or deltas. That's not the only solution, of course, but I just mean to create an example that's a different point-of-view.

If you intend to provide data analysis from your API, I would say that is the "intent" of your API and you should design it as such, with the appropriate flexibility and user-defined behaviour that is required to answer arbitrary queries from users. This is a hard API to design, build, and scale.

When designing a data analysis API, you should address scenarios like a user making a valid API request that can't be delivered in real-time; is it your intention to make your API accessible in real-time, in which case you have to either crash horribly or tell this request to piss off? Or is it your intent to provide the analysis no matter what, in which case perhaps it would be valid to queue such queries, process them in batches with limited concurrency, and deliver the results when completed.

Regarding the unmet needs of users, you should always provide a feedback mechanism for your API. This is something that varies a lot depending upon your customer; a lot of developers work in "enterprise" software, where the feedback channel is usually pretty apparent. Public APIs with an undefined audience will have a harder time getting that feedback, but usually you can bet that the importance of an issue is proportional to the number of times you hear about it.

Ah, thank-you for pointing that out. That's definitely a mistake in the article. I've amended point #4 with another possible approach.

Intent-driven design reduces the fragility of your API, gives you a wider variety of changes that you can make to your API that are backwards compatible.

If it's done perfectly, and your software solves the same business problem tomorrow as it does today, then you will never need to increment your API version number. The reality is that it will never be designed perfectly, and requirements are never that stable, so having a versioned API is a practical and prudent choice.

Hi Pete,

When I read your comment, I'm left with the distinct impression that we agree on 90% of what you're saying.

Of course you're going to document your API and define the format of what comes back from your requests. An API is a contract. Yeah, you isolate complexity in your API. You design an API, which is a difficult job, rather than just saying to your user, "here's a mapping to my database, do whatever you want with it."

This article does not say that APIs "should be vague about what they provide." It says the opposite, they should be very specific about what they provide.

You design an API by providing specific tools for your users. You give them hammers, not chunks of metal that they can mould however they want. You don't throw "features" into your API, you provide capabilities that your users need.

Mathieu

Hi Alex,

I never advocated breaking compatibility by adding, removing, or renaming fields in this article. Would you please let me know what gave you that impression so that I can clarify it?

I also did not state that having a versioned API is a bad thing. GitHub's API was a great example because it's both well-designed and versioned. Good design is going to make your API less fragile and far less prone to version changes, but I'm strongly in favour of versioning your API.

Mathieu

Awesome, I'm so glad to hear that. Thanks for your feedback. :-)

Ouch. I think I would've quit that job when I found out there was an "open source review board". That reeks of bureaucracy.

An ASIC is an application-specific integrated circuit. Basically, dedicated hardware like this: http://www.butterflylabs.com/

I've got the Zenbook UX32VD as well. I've replaced the HDD with an SDD (a Samsung 840 Pro 256GB). I love it.

You have to run a bit of cutting-edge software, but there's lots of good documentation on the Ubuntu wiki about how to support this laptop. The discrete video chipset does work, and it does work well. I enjoy playing games like X-Plane 10 and Kerbal Space Program on it, as well as having access to a growing selection of additional Linux games via Steam.

I replaced a MacBook Air with this machine, and I am very happy with the selection. It is the best laptop I've ever owned.

EDIT: One additional required upgrade: a combo Gigabit Ethernet and USB 3.0 hub (http://ca.startech.com/Networking-IO/Adapter-Cards/USB-3-to-...). The included 100 Mbit USB Ethernet adapter did not satisfy me. :-)

I think the advice in point #1 only makes sense with a caveat: When performance is an issue, if you can calculate or process it at the application layer _without adding load to the database layer_, then take it out of the database layer.

For example, order-by w/ limit/offset? If you do that at the application layer, you've increased the I/O usage on the database server, and clearly this advice doesn't make sense.

On the other hand, group-by (assuming no HAVING)? If you do that at the application layer, you've reduced the load on the database server, increased the load on the network, and you've probably made a justifiable performance vs. scalability trade-off. If you measure it and back it up with data.

I think the advice here in the article is too broad, but I can see a kernel of wisdom in it that is non-intuitive.

Chrome will probably never make this the default, unfortunately. But, this is an option in Chrome.

Settings > Show Advanced > Privacy > Content settings... > Block third-party cookies and site data.

It's not exactly obvious, of course. :-)

Thanks for posting the fixed link; I copied it from another computer, and missed a path. Doh.

I would say it's far more difficult if you want to support the full range of capabilities that the Accept header supports. Accept can support more than a single mime-type, and can also include priorities on each mime-type accepted. If you combine that with multiple clients, I think caching based upon that header would be pretty difficult (or you'd have to make some simplifying assumptions).

Impossible? No, not really.

Worthwhile? My opinion is no. I haven't seen the practical benefits of the content-negotiation approach over the URL approach, but I have seen the practical difficulties, so I'm convinced.

I love this point of view. If every business person thought like this, and could visualize far enough down the road to see the effects their actions have, capitalism wouldn't have a bad reputation. :-)