1. Sep 21st, 2007

    Rounded Corners - 151 (Life is messy)

    The other side of Yahoo. Some of their stuff rocks (Flickr), some not so much (Mash and the recent spam). But kudos on its open source efforts. Doug Cutting on Hadoop. And I’m hearing there are more killer features down the line.

    No setup necessary. James Newkirk explains why you shouldn’t use SetUp and TearDown in NUnit:

    The first and primary complaint is that when I am reading each test I have to glance up to BeforeTest() to see the values that are being used in the test. Worse yet if there was a TearDown method I would need to look in 3 methods. The second issue is that BeforeTest() initializes member variables for all 3 tests which complicates BeforeTest() and makes it violate the single responsibility pattern.

    I don’t have any clear-cut decision, but I’m also experiencing the same dislike for prepping the test in the setup. I’m starting to think setup is only about the environment.

    Life is messy, deal. Bill de hÓra on the search for Java synchronize blocks on Amazon’s S3 service (I put my bet on SETI):

    The way I look at it is that compensating action or dealing with out of order events is kind of like dealing with domain business “logic”, insofar as there is that real world messiness to contend with.

    script/generate undo. I’d like to see more of that.

    So how much in zero, exactly? Handy guide to calculate how much trans fat you can fit in food products labeled with “0g Trans Fat”.

    Above, Dave Astels has a “Microsoft moment”. 

    1. Sep 24th, 2007

      DAR

      Hi. I’m the author of the comment on the S3 forum (”What about if I PUT X and then DELETE X? Am I guaranteed that these operations will be performed in the correct order? (i.e., am I guaranteed that the object will eventually be deleted?)”)

      He writes: “Ian Davis is right; it’s tricky to explain or justify this to devs who have grown up on strong consistency”

      Yes, I agree. I have no problem with justifying this issue - I understand why it occurs. But from a practical standpoint, if I don’t have *some* minimal guarantees of consistency then that removes a huge number of potential applications from being implemented on S3. Yes, we can do append-writes, instead of updates, turning writes into an atomic operation. But if I can’t reliably know at any given time whether a particular write will be picked up by a subsequent read, then S3 is providing no reliability whatsoever as storage, and that makes it much less useful to everyone. You can’t use it for storing a sequential counter, for storing logs, etc.

      So yes, I really can use this explained, but more from the standpoint of: how on earth do I work around this?!?!? S3 is an incredibly powerful service, but from a practical standpoint this issue is a huge problem that needs to somehow get addressed - and soon.

    2. Sep 24th, 2007

      DAR

      Sounds like perhaps S3 needs something like a Chubby locking service (http://labs.google.com/papers/chubby.html): “We describe our experiences with the Chubby lock service, which is intended to provide coarse-grained locking as well as reliable (though low-volume) storage for a loosely-coupled distributed system. Chubby provides an interface much like a distributed file system with advisory locks, but the design emphasis is on availability and reliability, as opposed to high performance”

      In other words, if Amazon provided some storage space that guaranteed some reliability, but sacrificed the performance and scalability of S3, perhaps the problem could be solved.

    3. Sep 24th, 2007

      Assaf

      DAR,

      You have some minimal guarantee of consistency. But it’s not the minimal guarantee of consistency you would get from doing these operations in memory, or against a RDBMS (locks and all). I think the minimal guarantee of consistency you are looking for is write consistency, what you get is more like read consistency. Here’s my take on the difference.

    Your comment, here ⇓

    Or using OpenID