Posts

Showing posts from July, 2013

This Blog Has Moved!

Right, so yes, five years ago I moved to github pages, and never bothered to redirect any of these pages there. Now I've moved on from there, and... Finally I am using my real domain, trishagee.com . My blog is now at trishagee.com/blog .  See you there!
Post a Comment
Read more

JavaOne Shanghai

Image
I was expecting this... So, I was in China last week.  It's not really what I expected, but then my knowledge of China comes almost entirely from visiting various Chinatowns and watching martial arts movies, so I guess I wasn't all that well prepared for a modern Asian city like Shanghai. ...and found this instead The city is, in my opinion, clean, modern, and attractive.  I was surprised by American-looking early skyscrapers, and really surprised that the city overall felt more European than American - with Marks & Spencer, Tesco, Carrefour, H & M, Zara, Costa Coffee, as well as the inevitable McDonalds, KFC and Pizza Hut. Some of the architecture reminded me more of New York than Europe or Asia I felt like they had the option to take the best of all worlds - the modern, high tech and sometimes downright weird influence of Japan; a care for heritage from Europe; the consumer choice of the US; and food from all over China and the world. OK, I di
2 comments
Read more

Can't. Take. Much. More.

Image
Inspired by Your App Makes Me Fat , I was going to write a blog post about decision fatigue.  It's a topic very close to my heart right now as I try to plan for my upcoming speaking engagements,  continue working on the new Java driver, try to finish the last couple of blogs on Spock , and last but not least plan for moving home this week. But since my cognitive resources are at a low point right now, I'll just leave you with a gif instead: What programming is like
Post a Comment
Read more

Spock passes the next test - Painless Stubbing

In the last post I talked about our need for some improved testing tools, our choice of Spock as something to spike, and how mocking looks in Spock. As that blog got rather long, I saved the next installment for a separate post. Today I want to look at stubbing. Stubbing Mocking is great for checking outputs - in the example in the last post, we're checking that the process of encoding an array calls the right things on the way out, if you like - that the right stuff gets poked onto the bsonWriter . Stubbing is great for faking your inputs (I don't know why this difference never occurred to me before, but  Colin's talk at Devoxx UK  (video doesn't seem to work but slides can be seen) made this really clear to me). One of the things we need to do in the compatibility layer of the new driver is to wrap all the new style Exceptions that can be thrown by the new architecture layer and turn them into old-style Exceptions, for backwards compatibility purposes.
6 comments
Read more

Spock is awesome! Seriously Simplified Mocking

We're constantly fighting a battle when developing the new MongoDB Java driver between using tools that will do heavy lifting for us and minimising the dependencies a user has to download in order to use our driver.  Ideally, we want the number of dependencies to be zero. This is not going to be the case when it comes to testing, however.  At the very least, we're going to use JUnit or TestNG (we used testng in the previous version, we've switched to JUnit for 3.0).  Up until recently, we worked hard to eliminate the need for a mocking framework - the driver is not a large application with interacting services, most stuff can be tested either as an integration test or with very simple stubs. Recently I was working on the serialisation layer - we're making quite big changes to the model for encoding and decoding between BSON and Java, we're hoping this will simplify our lives but also make things a lot easier for the ODMs (Object-Document Mappers) and third part
6 comments
Read more

Developers hate support, don't they?

Image
This is Dublin.  Honest. I'm at the end of my first official week doing support for 10gen .  My major achievements are: Learning how to work the coffee machine in the Dublin office.  It's taken me a week to get it, but now I can understand the machine's needs.  Even if my coffee did taste a bit of cleaning fluid this morning. Navigating around Dublin - I led the way to the pub, followed by two people who live here. Turns out I know the most efficient routes between work venues and pubs, even in a town that I've never been to before. Closing all outstanding  Java driver pull requests , except for the one we want to merge but needs to be updated.  This is a massive win for us, now we can actually stay on top of them instead of wondering which are valid and which ones we're actively ignoring.  I hope the CTO isn't peeved I closed one of his from two years ago. I got my highest scoring day on StackOverflow yesterday, receiving a "whopping" 67 poi
Post a Comment
Read more

Popular posts from this blog

Dissecting the Disruptor: What's so special about a ring buffer?

Image
Recently we open sourced the LMAX Disruptor , the key to what makes our exchange so fast.  Why did we open source it?  Well, we've realised that conventional wisdom around high performance programming is... a bit wrong. We've come up with a better, faster way to share data between threads, and it would be selfish not to share it with the world.  Plus it makes us look dead clever. On the site you can download a technical article explaining what the Disruptor is and why it's so clever and fast.  I even get a writing credit on it, which is gratifying when all I really did is insert commas and re-phrase sentences I didn't understand. However I find the whole thing a bit much to digest all at once, so I'm going to explain it in smaller pieces, as suits my  NADD audience. First up - the ring buffer.  Initially I was under the impression the Disruptor was just the ring buffer.  But I've come to realise that while this data structure is at the heart of the patte
Read more

Dissecting the Disruptor: Writing to the ring buffer

Image
This is the missing piece in the end-to-end view of the Disruptor.  Brace yourselves, it's quite long.  But I decided to keep it in a single blog so you could have the context in one place. The important areas are: not wrapping the ring; informing the consumers; batching for producers; and how multiple producers work. ProducerBarriers The Disruptor code has interfaces and helper classes for the Consumer s, but there's no interface for your producer, the thing that writes to the ring buffer.  That's because nothing else needs to access your producer, only you need to know about it.  However, like the consuming side, a ProducerBarrier is created by the ring buffer and your producer will use this to write to it. Writing to the ring buffer involves a two-phase commit.  First, your producer has to claim the next slot on the buffer.  Then, when the producer has finished writing to the slot, it will call commit on the ProducerBarrier . So let's look at the first bi
Read more

Dissecting the Disruptor: How do I read from the ring buffer?

Image
The next in the series of understanding the Disruptor pattern developed at LMAX . After the last post we all understand ring buffers and how awesome they are.  Unfortunately for you, I have not said anything about how to actually populate them or read from them when you're using the Disruptor. ConsumerBarriers and Consumers I'm going to approach this slightly backwards, because it's probably easier to understand in the long run.  Assuming that some magic has populated it: how do you read something from the ring buffer? (OK, I'm starting to regret using Paint/ Gimp .  Although it's an excellent excuse to purchase a graphics tablet if I do continue down this road.  Also UML gurus are probably cursing my name right now.) Your Consumer is the thread that wants to get something off the buffer.  It has access to a ConsumerBarrier , which is created by the RingBuffer and interacts with it on behalf of the Consumer .  While the ring buffer obviously needs a se
Read more