Disqus - Latest Comments for pom

Re: How Travis CI Uses Heroku to Scale Their Platform

Mathias Meyer — Tue, 03 Sep 2013 17:22:37 -0000

All of our infrastructure serving websites, handling build requests, processing logs and all that is hosted on Heroku. We're using Blue Box' VM infrastructure to run the actual tests.

Re: npm Registry Caching Proxy

Mathias Meyer — Mon, 02 Sep 2013 12:41:37 -0000

Thanks for putting this out, almost worked a treat.

i didn't actually get nginx (1.1.19 on Ubuntu 12.04) to cache anything before adding something like the following line:

proxy_cache npm;

After that line, it started caching like a champ.

Re: paperplanes. Storing User Timelines in Riak

Mathias Meyer — Tue, 03 Jan 2012 03:35:59 -0000

How you handle the updates is up to you. It's just a library that manages storage and conflict resolution for you. How and when you add new entries and how you manage followership is up to you.

Re: paperplanes. MySQL No-Nos: ORDER BY RAND()

Mathias Meyer — Fri, 29 Jul 2011 16:13:06 -0000

IS_ACTIVE is simply a column specific to this particular use case, nothing that's required to implement this way of random queries. Leave it out or use a where clause that's specific to your use case.

Re: The Basho Blog: Why MapReduce Is Hard

Mathias Meyer — Thu, 21 Apr 2011 05:03:16 -0000

William,

that's a great idea actually. Though I'd be careful not to log too verbosely because that log would be growing like crazy when there's lots of MapReduce jobs. But yeah, you could certainly tell something like rsyslog to feed the log into Riaktant.

Re: The Basho Blog: Why MapReduce is Easy

Mathias Meyer — Wed, 30 Mar 2011 16:01:36 -0000

Doug,

the Ruby and Python examples were mostly just to show how easy MapReduce is to use in application code. Unfortunately neither are supported for MapReduce jobs in Riak. The only other option aside from JavaScript is Erlang.

As for sort/shuffle, Riak doesn't have a notion of that, the reducer's part is simply to run the reduce phase, there's no guarantee on the order.

Re: The Basho Blog: Why MapReduce is Easy

Mathias Meyer — Wed, 30 Mar 2011 15:12:53 -0000

Srdjan,

it's actually supposed to be an assignment in this case, taking advantage of the fact that 0 is considered false in JavaScript. So when the modulo returns 0 and assigns it to position, the condition will evaluate to false.

Re: paperplanes. A Collection Of Redis Use Cases

Mathias Meyer — Mon, 28 Mar 2011 05:19:04 -0000

Yep, in this case I'd say you need to make sure you properly authenticate the API making the calls into the system using Redis instead.

Re: paperplanes. A Collection Of Redis Use Cases

Mathias Meyer — Mon, 28 Mar 2011 05:14:51 -0000

Are there any other sources for requests other than your servers? Does anything else have access to their services or even Redis?

In general, our token is generated and stored in Redis (based on the service requested) before a request is sent. When it's received, the service on the other end can check if the token exists and consumes it accordingly, or rejects the request. We did all this though, because there are trusted and untrusted sources for requests, the scope of the latter needs to be restricted to only a certain set of services, hence the token.

If you only have internal traffic coming through the system, I'd say this is overkill though.

Re: paperplanes. A Collection Of Redis Use Cases

Mathias Meyer — Mon, 28 Mar 2011 05:04:11 -0000

It's pretty simple really. It's based on both the fact that you need well-known keys in Redis and that most operations are somewhat atomic. Can't think of a decent write-up for this, but I guess it's because it's a rather simple use case. If you can tell me a bit more about what it is you're trying to achieve, I'm sure I could give you an example.

Re: paperplanes. A Simple Redis Use Case for Sorted Sets

Mathias Meyer — Mon, 29 Nov 2010 12:42:02 -0000

In the article I wrote the reason why I'm storing it this way, simply because we're only querying the API in certain intervals. As these are fixed, it doesn't make sense for us to make it this fine-grained, as we simly don't have it.

But in general, of course that kind of information in that particular would be useful and should be stored accordingly when required. Depends on the use case, as always.

Re: paperplanes. Relational Data, Document Databases and Schema Design

Mathias Meyer — Thu, 26 Aug 2010 04:04:06 -0000

Did I say it's bad? Did I say it should be abandonded? Did I say data should be assumed to be inconsistent all the time? I think I didn't. Thanks for your valuable addition to this discussion.

Re: paperplanes. An Inconvenient Caveat about MongoDB's Replica Sets

Mathias Meyer — Thu, 12 Aug 2010 11:06:32 -0000

Great! My apologies for causing such a stir then, the original design just really struck a bad chord with me. I'll update the post accordingly.

Re: paperplanes. An Inconvenient Caveat about MongoDB's Replica Sets

Mathias Meyer — Thu, 12 Aug 2010 11:03:22 -0000

I consider that somewhat of a poll. It's still up to the client to issue a second command to wait for a successful write on the cluster.

Re: paperplanes. An Inconvenient Caveat about MongoDB's Replica Sets

Mathias Meyer — Thu, 12 Aug 2010 11:00:43 -0000

That slide pretty much says what I wrote above. Mike's comment though made this issue a lot more of a non-issue, moving deleted data elsewhere sounds much better than deleting it.

Re: paperplanes. An Inconvenient Caveat about MongoDB's Replica Sets

Mathias Meyer — Thu, 12 Aug 2010 10:59:54 -0000

May I humbly suggest then that you update the documentation accordingly. Just as I did, people could get wrong ideas about what works and what doesn't. As it seems that even made it into 1.6.0, and is surely a step foreward to simply deleting data.

Re: paperplanes. A Collection Of Redis Use Cases

Mathias Meyer — Sat, 07 Aug 2010 17:21:37 -0000

Great! Though back when I first tried it, the session support didn't work for me in Rails 2, so I whipped my own version (http://github.com/mattmatt/..., which eventually got included in redis-store, as far as I remember.

Re: CouchDB Case Study: CouchDB for Reporting and More

Mathias Meyer — Thu, 05 Aug 2010 04:47:55 -0000

Just because views are updated on read doesn't mean they can't be used for reporting, that's a flawed assumptions. Given the right set of views it's quite feasable to get reporting data out of CouchDB. Not everyone needs to resort to Hadoop to analyze their data. It's not even easy to pass this judgement on them, because the case study doesn't specifically mention what kind of reporting is run on how much data.

I wouldn't say that free schema is bad for reporting in general. Especially not in CouchDB. Sure, you have define the views on that data upfront, but you're flexible enough in defining the views in ways that are open for different kinds of range queries, extending them for particular needs. I sure wish there'd be more detail on this too, but I wouldn't rule out per se that free schema and reporting are not a fit.

And if it works for them, why argue?

Re: Scalarium: Beta Update: Simplified And Automated Monitoring with Ganglia

Mathias Meyer — Tue, 03 Aug 2010 15:46:18 -0000

That's odd. I'll look into that tomorrow. Could you open a support ticket for that and describe any other things the database master might've been responsible for? Thanks very much.

Re: paperplanes. Vim - A Never-ending Love Story

Mathias Meyer — Tue, 27 Jul 2010 12:45:22 -0000

You mean TextMate's snippets? Sure thing, there's snipMate (http://www.vim.org/scripts/... and a collection of accompanying/extendings snippets available (http://github.com/scrooloos...

Hope this helps.

Re: paperplanes. 10 Annoying Things About CouchDB

Mathias Meyer — Mon, 26 Jul 2010 16:20:44 -0000

Ha! Now that'd be swell, wouldn't it? Thanks, fixed it.

Re: paperplanes. When To Redis

Mathias Meyer — Fri, 09 Jul 2010 03:51:35 -0000

I'd say this is the wrong place to ask this question. Personally, I haven't heard anything in that regard, but I reckon with Redis < 2.0 (without the VM) it could happen. 4GB is somewhat of a magic boundary on 32bit systems, but it's probably safest to ask on the #redis IRC channel or the mailing list.

Re: paperplanes. Relational Data, Document Databases and Schema Design

Mathias Meyer — Tue, 06 Jul 2010 16:48:48 -0000

I mention it in every single one of my talks. To which I linked, for your convenience, right at the top of the article.

Re: paperplanes. Relational Data, Document Databases and Schema Design

Mathias Meyer — Mon, 05 Jul 2010 14:28:43 -0000

I think this goes to show that there is no one solution for the same use case even. And I'm not implying it should be done this way, if you thought I'm stating fact, clearly I my intention came across wrong in this particular case, it was merely a suggestion.

If you've built ecommerce apps without having to resort to denormalization, that's cool. I've found the opposite to be the way to go in my experience. What you're saying surely is possible, I'm arguing that it's about the pain of living with that normalization vs. simply storing the data together with the order. Both work, both may or may not have trade-offs.

Examples on e-commerce (focused on MongoDB): http://kylebanker.com/blog/..., http://codeascraft.etsy.com... and http://codeascraft.etsy.com...

Re: paperplanes. Relational Data, Document Databases and Schema Design

Mathias Meyer — Mon, 05 Jul 2010 13:48:40 -0000

I did, just a couple of lines below:
"Shipping and billing address, payment data used, product price and taxes, and so on."

That's pretty much off the top of my head, the basic data I found to be duplicated with every order, simply to have a full track record in case the user changes any of that data at some point after an order.