The Changelog: Software Development, Open Source - Riak Revisited (Interview)

Episode Date: November 9, 2010

Wynn sat down with Andy Gross and Mark Phillips of Basho and John Nunemaker of Ordered List to talk about Riak, Riak Search, and moving an open source community to GitHub.

Welcome to the ChangeLog episode 0.4.0. I'm Adam Stachowiak. And I'm Winn Netherland. This is the ChangeLog. We cover what's fresh and new in the world of open source. If you found us on iTunes, we're also on the web at thechangelog.com. We're also up on GitHub. Head to github.com slash explore. You'll find some training repos, some feature repos from our blog, as well as the audio podcast. If you're on Twitter, follow Change Log Show. As well as me, I'm Adam Stack.

And I'm Penguin, P-E-N-G-W-Y-N-N. Fun episode this week. Talked to the guys at REAC for the second time to see what's new with their NoSQL store. And probably more versed in this space after the NoSQL Smackdown from South by Southwest last time, which I think we chatted with them right before that event back in March. Yeah, it was kind of an unexpected surprise, really,

to run into that NoSQL Smackdown. And you got to participate, which was fun. But excited to revisit that scenario, too. Yeah, we need to run into that no sequel SmackDown and you got to participate, which was fun, but, uh, excited to revisit that scenario too. Yeah, we need to do that. Especially now that the, uh,

the field has, um, I guess expanded a bit. There's more players in the, in the space and see how they, they stack up, you know, a couple of questions that I didn't ask the react guys that I wish I had

of, you know, one of them is, are you web scale? Have you seen the, uh, MongoDB cartoons that made the internets? I hadn't seen them yet, no. I'll put that in the show notes. That'd be awesome.

It's the MySQL guy versus the Mongo guy. So I was curious of how React stands up to the scaling issue. But React is such a versatile player. It looks like it plays kind of at the low end against Mongo and definitely at the high end against Cassandra with some of its architecture. Just some amazing stuff. And they've got the new Riyak search that's out. So Mark and Andy give you the scoop on all things Riyak.

And John Newnemaker joins us for this episode. So he's been playing with Riyak I know. So I pulled him in to ask some tough pointed questions. And plus he's big in the Mongo space too. So he's kind of got a side-by-side picture of what to expect and good question to ask when comparing. Exactly. You know, I'll be out in California, I guess in a couple of weeks, and we're recording this first or second week of November.

I forget what day it is. I'll be out there in the 15th through the 19th. Hopefully we can line up some, some talks with some folks out in the Bay area. I'll be out there the 15th through the 19th. Hopefully we can line up some talks with some folks out in the Bay Area. That'd be exciting. If you've got somebody that you would like to see on The Change Log or hear on The Change Log to talk about a project near and dear to your heart, send us an email at ping at thechangelog.com.

We'll see if we can get them on the show. Absolutely. This is a good show. You want to get to it? Let's do it. We're joined today by Andy Gross and Mark Phillips from Basho, makers of the React NoSQL database. Andy, why don't you start and introduce yourself for the folks that didn't catch the first episode. Hi, Wynn. I'm Andy Gross. I'm VP of Engineering here at Basho. Like you said, we make the React NoSQL database. Among other things, we've actually just released React Search as well, and it's great to be here.

And Mark? Hey, guys. So this is Mark Phillips. I'm the Community Manager at Basho Technologies, and as Andy said, we have a whole slew of software that we're really excited about, React and React Search being the two primary. So thrilled to be here as well. Thanks for having us. And Mark, if I slip up and call you Fark, it's because that's what your Twitter handle is. You know what, Winn, that is totally acceptable.

And I should mention we're joined today by John Noonemaker, who's, I guess, of MongoMapper fame. John, why don't you say a quick hello? Hello, everyone. And you can introduce yourself for the folks that don't know. I'm John Neunemaker. I work at Ordered List and do a lot with Mongo, React, and other various NoSQL databases, and occasionally I'm forced to throw in my SQL in the loop. So I guess the last time we spoke to you guys, it was back in February when we first discovered React.

So tell us, I guess, what has changed in the React project since February. Sure. We've had a lot of stuff change, actually. We have released a bunch of usability improvements you can now download React as a binary build for various platforms Debian, Ubuntu, CentOS OpenSolaris, Solaris, etc

we've replaced some of the earlier storage backends with a brand new high performance storage backend called BitCask and we've also released React Search, which is a nice complement to the React key value store. Key value systems tend to have a somewhat limiting query model in that you can only look things

up by keys. With React Search you can also search in a full-text fashion similar to Lucene or Solr. You can search by the values of your objects as well, so it makes data a lot more discoverable and gives you a much richer query interface. A couple other things. We've opened an office. The company's opened an office in San Francisco. We switched from Mercurial from Bitbucket to GitHub and a whole bunch of other things that we'll probably get to later in the podcast.

We'll dive down into the GitHub, the Git versus Mercurial switch in just a moment, but let's talk about React Search for a moment. Is it a standalone application, or does this have to be used with the Key Value Store? It can be used in a number of different ways, actually. You can use it, you can integrate it with the key value store. For React, it stores data in batches of keys and values called buckets, somewhat analogous to an RDBMS table. And with React Search, for individual buckets,

you can mark them as searchable. And just by side effect, everything that's put into that bucket has a full text search index. So you can use it in an integrated fashion with React key value. It also exports a solar, Apache solar compatible API,

so you can use it as if it was an Apache solar server. Use existing Solar clients, use that same RESTful API to treat it as if it were just a more scalable Apache Solar. What sort of languages are you seeing, I guess, buy into React as a NoSQL solution on the key value store side?

Yeah, sure. So obviously we do really well with the Erlang community. That's where we started, and that was the first interface we really supported heavily. Since then, you know, I think you guys had Sean back on in February, and he was writing the Ripple driver. And I'm sure, as John can tell you, that is a beautiful piece of code that is really taken with a lot of the Ruby community.

So we've seen a ton of adoption with Ruby and Ripple. Outside of that, Java, Python, and over the last two or three months, we've seen a ton of uptake with Node.js, thanks to a nifty little library written by somebody from the community called React.js, actually. And his name is Francisco Tricci, at Franco6 on Twitter. So a pretty good spread across the board. But Ruby, Node.js, Java, and Python, I would say, are the top four. That may be the fastest, other than the node episode itself that we've kept the node.js streak alive here in the changelog so john you're a mongo guy writing mongo mapper i was um actually

quite surprised to see you start to commit on some uh reoc wrapper uh commits on on github so you played with reoc any questions for these guys as far as comparing and contrasting? Yeah, so I guess, why don't you guys talk a little bit, I guess, from your point of view of, not necessarily, we can talk about data modeling as well, but just from an administration point of view,

maybe what are the benefits of using React? What kind of tools do you guys have that maybe other databases don't have or where you do things a little bit differently? Sure. So one of our main focuses, a lot of the people at Badshow came from Akamai Technologies where we operated, at the time, probably one of the larger distributed systems. Google came along and quickly eclipsed us. But one of the core sort of design philosophies about React is ease of operations. So we've spent a lot of time on making it, you know, easily elastic. So it scales both up and

down. So you add a node, it's a single command line to add a node. And when you add that node, you get a linear increase in throughput and storage capacity and it also scales down. You can run many nodes on your laptop. I can run easily in the tens, 50 React nodes on my MacBook here with no sort of loss of functionality. The other aspect to that is it's a truly sort of decentralized system in that no node is special. There's not both not a single point of failure, but it also means that

you don't have to pay special attention to a given node. They're all sort of fungible. They can come in and out of the network, and that's tolerated really well. So that's one of the main focuses of REAC is that it should be easy to operate. You know, in the way that you describe React, it's a lot of the same language that the Cassandra folks used to describe that platform. What distinctions could you draw between the two? So, yes, React and Cassandra are very similar. I'd say that if you were to sort of segment the NoSQL space, you'd have React, Cassandra, and Voldemort probably in the same group in their goals

in that they focus on scaling out. React is a little – Cassandra has a slightly different data model, a slightly more complex data model, and that's from its sort of Google Bigtable influence there. So React is much more of a sort of just traditional key value store at heart. It doesn't have the sort of column family model that comes from Bigtable. It also has a couple of interesting features that aren't found in Cassandra, like the link relationships

you can establish between objects and built-in JavaScript MapReduce. And in the future, we'll probably be releasing some more queryability improvements at the React meetup the other night here in San Francisco, we announced some improvements to MapReduce that allow you to sort of build some meaning into the values of your keys, and then perform regular expression matches of your keys in a MapReduce job. Cassandra has MapReduce as well,

but it's more of a traditional sort of Hadoop integration there. So you mentioned MapReduce and JavaScript. What sort of distinction did you draw to Couch? So Couch is actually very similar to Couch, at least in the implementation. We both embed the SpiderMonkey JavaScript virtual machine. It's different from Couch in that Couch does sort of incremental MapReduce in that every time you write to the database, it maintains an index for you. React's MapReduce is much more focused as a sort of ad hoc query mechanism

in that React doesn't automatically run MapReduce when you write to the database. You issue a MapReduce job as a query, you get the result back, and React doesn't save that for you. If you want to save that, you put it back into the database yourself. So ours is,

Couch's MapReduce is more of a sort of internal query mechanism where ours is an external user-facing means of querying the database. So you mentioned links a little bit. Why don't you go into a little bit of the benefit of that? I see, when I look at it a little bit, a little hint of the graph side of the database world and stuff.

Maybe where are some distinctions between there or what the benefits are? Sure. So links are basically a tag you can put on an object any object can have a list of links to other um to other objects other keys and values in the react database uh it's a three tuple uh of bucket key and tag so by uh this allows you to have sort of ad hoc flexible lightweight relationships between objects it's not quite a full fledged graph database

nor is it meant to be but you can model things like you know a social networking example would be a user has friends and those friends have you know wall posts you know Facebook wall updates or whatever and you can has friends, and those friends have wall posts,

Facebook wall updates or whatever, and you can, from the HTTP side of things, you can craft together a URL that just basically says slash users slash win slash friends, and then you can put a tag on those, friends in Texas. So it doesn't have full sort of graph traversal features, but it's a nice way, and like I said before, accessing stuff by key and values can be somewhat limiting, so we added the link feature to allow you to easily add a little more

riches to your data and a little richer query interface by being able to dynamically establish these relationships between objects. It seems like a venting is the new hotness in web application architecture. Node is built that way from the ground up. What about the other drivers for React? Which of these support that sort of asynchronous architecture? So all of the drivers are the API to React. We have two of them, actually.

I think the first time we talked, we only had one, which was the HTTP interface. We find that the HTTP interface goes a long way in that any language can talk HTTP. But we've recently added, or maybe not recently, but definitely since the last time we were on, a protocol buffers interface, which is a sort of binary protocol that doesn't have some of the parsing overhead of HTTP. As far as, I said Node.js is probably the most sort of event callback-driven driver that we have. The other ones provide a relatively synchronous interface to React. So I don't think there's, maybe the Erlang one does as well, the Erlang one.

Node and Erlang are kind of similar in their design. Node is probably the most event-driven one. We also have a native JavaScript interface that's not integrated with Node. It's more of a sort of proof of concept that we provide, but all the other ones are a relatively synchronous interface. Talk to us about BitCask. BitCask. So BitCask is really cool, and that's another thing that's happened since the last time we were on. Eric Brewer, father of the CAP theorem and arguably sort of grandfather of NoSQL, joined Bachelors Board of Directors this past year. And when we were talking about storage backends, he came up with a really interesting idea with BitCask in that you can, if you have the capacity to keep all your keys in memory,

which a lot of use cases you can do that, you can have a really simple, easy to design, easy to implement, relatively easy to implement storage system that uses basically the commit log as the database itself. So BitCask is an append only file format where when you write a value to the database, you write it to disk and then update a pointer in memory that points to the file and offset in the file on disk. And by keeping the keys in memory, you guarantee that for a read, you only have to do one file I.O. It's a very fast memory lookup in a hash table that points

at a file, and then you find that file and seek to a certain point to read the value. And for writes, it's just a simple append to a file. So BitCask offers very, very predictable latency, given that if you can keep all your keys in memory, we actually recommend that people use BitCask as opposed to our previous recommended storage backend, which was embedded in ODB. And like I said, the latency is very, very predictable since you don't have to do a whole lot of random seeking

around in a file to read a value. It's guaranteed one disk IO for a read and a simple append for a write. And it allows us to also leverage the file system cache in the kernel to allow us not to have to provide any sort of complicated caching layer in React itself. So for a lot of use cases, or for at least the use cases that you can guarantee you can keep all your keys in memory, and this is just the keys, this isn't the whole value, BitCask is the recommended back-end. And nowadays we really only recommend InnoStore for use cases where you have so many keys that the memory requirement of BitCask isn't going to work. So we talked a little bit about administration

and how you guys are real big on making that easy. We've talked a little bit about data modeling, and I guess I'd be kind of curious about going into that a little bit more. So pretty much right now you have key and value and then MapReduce for dynamic lookups. Maybe we could talk now a little bit about search and how that fits into the equation of getting at your data. So, like we talked about before, key and value access is sort of the React default. We then added MapReduce on to have a slightly more rich query model, but it's

still, there's some overhead in sort of walking through your entire bucket to find out about data. Interesting story about search. Search was really born out of one of our engineers, John Mueller-Lally's frustration with the limitation of the key value model. If you

guys have seen that NoSQL cartoon of the three guys in the office complaining about distributed MapReduce and Erlang, that was actually written by a Basho guy. And that was sort of the day that search was born out of a desire to have a much more queryable interface to React. So search from the outside looks a lot like, well, Apache Solar in its API and Apache Lucene in its query syntax. So the Lucene sort of query syntax has become kind of a standard, a semi-standard in information retrieval. So in addition to the existing types of MapReduce

jobs, where you either pass in a list of buckets and keys, or pass in just a bucket and iterate through the whole thing, with search, you can insert a MapReduce job that is formed as a Lucene-style query. So you could say, you know, podcast and changelog show and get all the documents whose values matched that in some way and then pass those documents on to a next phase of the MapReduce. So I think you'll probably see, whereas before people would go through a lot of effort to sort of know the keys ahead of time or have to go through an entire bucket to find what they wanted. Now users can simply write in a full text search query and start their MapReduce jobs off that way or insert that kind of query to any point in the MapReduce

job. So that's how you can access it from the key value store side by just by adding another MapReduce job type, Lucene search. And it's not actually, sorry, it's not actually implemented in Lucene. It exposes the API and we do have a little bit of Apache solar code for text analysis, but on the backend, it's all written in Erlang in the same sort of style as, as the React key value store. analysis, but on the back end, it's all written in Erlang in the same sort of style as, um, as the react key value store. And so is that, is it content aware or is it like, what does it kind of assume as a value? Like if you store Jason, can you index it in, you know,

kind of search on an individual key in Jason, or do you need to have that actually as a separate react key or, um, you can actually make schemas um for your uh for for individual buckets um so uh you can define different fields uh it's it's i believe it's xml or json uh from the solar interface um so you can say you know this field is a date this field is a time this field is a number this field is a string, and get the right sort of indexing semantics there. So it's not quite the solar schema format. It's our own sort of format

for the schema file, but you have a lot of flexibility in defining what fields are what data type and which ones get indexed and which don't. So you guys mentioned earlier that you made the move from Bitbucket over to GitHub, so Mark, I guess building a community around any project is crucial.

What went into the decision to go to GitHub? So the decision to go to GitHub was not one that we made easily and hastily. You know, we, since before we open sourced React, it was developed using Mercurial in-house. That was something that we were used to in all our developers, though they were both versed in Git and Mercurial. They stuck with Mercurial because that's what we knew,

and that's what we were accustomed to. So we open-sourced back in August of last year and didn't think much of it. We were, to be honest, focused much more on pushing out consistent releases that just made the code stronger. And we weren't really pushing for that type of community involvement that's really advantageous to a large open-source project. So the move to GitHub was, driven not by, you know,

need for better version control technology. Mercurial was a great system, and, you know, all our guys, all our hackers liked it just fine. But, you know, the way that GitHub has taken Git and put so much momentum behind it is just something that you can't ignore. So for me, as a community manager and for the entire company, looking for that deep level of community involvement, it was just something that was inevitable for us. Yeah, I mean, there's been a huge uptick in pull requests since we moved to Git.

Mark, I'd say maybe, what was it, four or five months back we started mirroring onto GitHub. And that was probably what did it for us. Once we did that, people expected to be able to submit pull requests and have them integrated quickly and easily. So it was really about the community and about desire

for ease of external code contributions that made us move to GitHub. Yeah, and before, when you asked about where we're seeing the most developer uptake, so Sean Cribbs' Ripple library and the React.js library that was contributed from the community

are both hosted on GitHub and have always been there. And just judging by numbers of followers, granted that doesn't actually indicate code quality, those far surpass any driver that we have. And actually, Sean's driver code surpasses that of the React repo itself. But I don't suspect it'll be like that much longer now that we've switched. So it was primarily for community involvement and the exposure that GitHub offers.

So as users of both Git and Mercurial, what contrast could you make between those two? I think, I mean, they're really, they both provide the same real features. People have compared the two and sort of done a side-by-side comparison. There's some things that are easier in one, some things that are easier in another.

So on the merits of technology, I'd say they're both about the same. I think we originally chose Mercurial because we're all sort of old Python guys in previous lives, and the notion that we could write sort of commit hooks and stuff in Python is what made Mercurial and therefore Bitbucket initially attractive. But we never actually ended up writing any, never ended up having to use that functionality. And so I had a little bit of a learning curve

getting used to Git, but it's really just a tool for us. And the community was the big driver for that, for the switch. And so for you guys, you talked about how you switched to GitHub and how you have contributions going up. Since Basho is kind of primarily the company behind React, what kind of percentage or feeling do you overall have of contributing from outside contributing from outside of basho and like contributing inside of basho so uh we we have i think there's like a thanks file in the reoc source code and there's probably at least 30 people now outside of basho who have contributed in some sort of meaningful way to the project um being in Erlang and being sort of a database, there is a somewhat high

bar to really making meaningful contributions to the core. But we're actually starting to see people do that now. So most of the contributions are, you know, bug fixes, documentation improvements, changes to the client libraries. And we don't really have that many developers contributing to the core. But we're seeing people starting to come up to speed enough with the sort of core, you know, distributed systems code and database, you know, storage system code where I wouldn't be surprised in the future, in the near future, if we had some external contributors actually making sort of large scale changes across the entire code base but until until now it's been mostly bug fixes and contributions to the

various client libraries so back in march at south by southwest i had the privilege of participating in the no sequel smackdown at south by and one of the exercises that we had to do was to kind of size up the competition, the other players in this space. And the only ones that were represented were Mongo, Cassandra, uh, couch.

And, um, I guess Amazon was, was represented even though it's not open source, um, their dynamo database technology. If you guys had to prepare for such a hypothetical competition, what distinctions

would you draw between RIOC and I guess the rest of the field? Where does RIOC shine? So it's really around both operational easy use and predictable latency is one of the ones that since we released BitCask, we're really sort of proud of the fact that, you know, there's not going to be wildly varying latency in your queries. So in these days where, you know, we're really moving towards sort of soft real-time systems where the correctness of a result has a direct relation to how quickly you can get that data, latency is really important. And especially when these databases are, you know, or users of React are building sort of, you know, service-oriented, you know, using React as a layer in another system, so every sort of millisecond of latency comes out of some sort of bottom line SLA for the rest of the system,

it's very important to be able to predict, well, REAC will always, 99.9% of the time, respond in this amount of time. So the sort of simplicity and elegance of the BitCast data model and some of the soft real-time properties of Erlang make it very suitable for latency-sensitive applications. And like I said before, we're always focusing on operational ease of use. So if you want really predictable scaling without headaches when you add and remove nodes, then I think that's really where React shines. So on the MongoDB side, they tell you up front that if you need transactions, it's probably not your store of choice. What caveats would you state with React?

Well, again, I think for most of the NoSQL projects, you know, transactions, joins, are just off the table to start with. With REOC, I'd add that, you know, it is a key value store at heart. So trying to bolt on more complex data models is, you know, just be aware of what the strengths of the system are.

That being said, with things like search, that sort of caveat is becoming more and more blurred, and we do plan to release other database products that have richer query models. But I would say just know that it's a key value store and design your app accordingly So I think my next question would be maybe for Mark more

obviously the developers that are listening to this are open source developers they're people who end up with their own little communities around projects and stuff and I was just wondering if Basho and React and how this is starting to be pretty well known and stuff, if you had any tips for someone who's managing their own project

like how to get the word out or how to manage community contributions and awareness and things like that. Maybe if you had any tips for the people that are listening. Certainly. Thanks. Thanks for asking that. I'm quite flattered you would do so. We've come a long way since we first open sourced,

and I think I took this position back in, maybe it was May or so, maybe April or May. And what I found to be the most effective, and we were lucky because we had a clean slate, but what I found to be most effective was just get the basics down. So I think when we were on the show last, or when Andy and Sean were on the show last in February, we didn't even have a wiki. Make sure you have a wiki up there. Something that I've done that for some reason has been remarkably successful

is I write something called the React Recap three days a week, so usually Monday, Wednesday, and Friday. And that is just a plain text email with anywhere from three to ten bullet points with what's been happening in the community over the last two days or three days. It goes through anything from blog posts written by people using React to new libraries that have appeared to bug fixes that have gone in to new Wiki pages to events happening in

any corner of the globe. I even go into our, we log our IRC channel, and I go and kind of curate conversations that may not appear in the wiki, and I kind of dig through there for tidbits that people might want, and also for things that help us update the wiki. Other than that, I send a lot of emails to people who have expressed interest here and who have a question that didn't get a follow up maybe a few days ago

so it's a lot of one on one stuff that isn't really happening in the public forum which generates a bigger buzz maybe a week or a month down the line other than that, stay up to date on the space. I spend a lot of time reading blogs about Mongo and Cassandra and the other players in the space, and MySQL and Postgres and all those guys.

So I guess that would be some advice to offer. So it's not just about grabbing developer mindshare. You also need some wins and, I guess, demonstrating adoption of the platform. You know, John's living proof with Mongo that they're using it over with Harmony, their CMS application. What big wins do you have with Basho? So open source, I would say the one we're most proud of these days is probably the Mozilla use case. And maybe Andy can speak more to the specific stuff they're doing with querying and whatnot.

But they're running several React clusters, one of which is to kind of log data given through their test pilot project. So we've worked those guys pretty extensively. There's some great blog posts by them both on just using React and kind of benchmarking and performance, stuff like that.

There's another nifty little startup out of Amsterdam we're pretty excited about called Widescript. And Frank Francisco-Tricci, who wrote the React.js library, is kind of the lead dev on that project. And those guys are not out of beta yet, but I'm really excited to see what they do with that. So Mozilla,

Widescript, there's actually a page on our wiki called Who is Using React? So if you go to wiki.basher.com and on the left column there you'll see who is using React. There's about 15 companies that we know of open source. There's another great company called Inagist which is using actually

React and React Search right now. We just found out a few days ago. And oddly enough, I'm getting a lot of emails out of the blue that just say, oh, by the way, we have React in production, which is really nice because you know that the database is rock solid.

And these are people we've never heard from on the mailing list, or never seen in IRC, or never tweeted about using React. And I think it kind of speaks to the simplicity of getting a three or five node cluster running and just starting to pump data into it and serve requests out of it. So that's that.

Well, this is the part of the show where we turn it upside down and ask what's on your developer radar. It seems like through the magic of Scott, we may have lost Andy. We'll see if we can get him back. But if not, Mark, why don't you go ahead and answer the question. What out there in the world of open source has got you excited that you just can't wait to play with? Oh, geez. So a bit of a tough question for me because I'm focused more on the promoting and the code development rather than actually the usage.

So I'm sure everybody has answered Node. We're pretty excited about Node as a technology. We partnered with Joint to use to kind of build cookie cutter and really powerful React machines on their platform and through that

we've been talking to a few of the guys over there Ryan Dahl and I believe Isaac is his name who who did NPM, about better ways to integrate React with Node. So a lot of our developers have been checking out Node and seeing where we can kind of contribute to that. Other than that, I'm actually just pretty filled

about the other NoSQL databases. You know, a lot of people see us as in competition, but we're good friends with a lot of those guys, and they write really good software as a rule, and a lot of the people that we see using React are actually using React alongside of, you know, a MongoDB or alongside of a Redis.

Your Redis seems to pop up in every single application. And so, you know, just seeing that the other players in the space do really well is something that is good for the space, but also something that we're all interested in. So, you know just seeing the other players in the space do really well is something that is good for the space but also something that we're all interested in so you know if we come off as cut throat it's it's it's not the way it is we're excited about redis too we're trying to get anti-res on the uh the show yeah he's uh if if the amount of code that he writes is any indication i don't think you'll be seeing him for any time. One second. Let me drag Andy back in. All right.

So, Andy, we're just at the radar question, so I'll pose it to you as well. Andy, what's got you excited in the world of open source to play with? Oh, God. Lots of stuff that I don't have time to play with. I think some of the new JVM languages, well, I guess they're not so new anymore, but things like Scala and Clojure are very interesting to me.

And, you know, they're sort of the top of my queue of things to investigate and learn. Other than that, I'm really excited about Node.js. I've gotten a little time to play with it since the React.js library was released, but doing more things with that but mostly this may sound unoriginal and kind of lame

but React of all the things that I do and all the open source projects I've been involved with I really look forward to some of the stuff we have in the pipe for React and exciting new stuff as well Thanks so much for joining us today Thanks for having us. I see it in my eyes So how could I forget when

I found myself for the first time Safe in your arms As the dark passion shines