gistfile1.txt

1) Hello Chris! It's great to have another Basho Erlanger here! Can you
introduce yourself please?

It's great to be here!  My name is Christopher Meiklejohn, and I'm
currently a software engineer at Basho Technologies, Inc., where I work
on our distributed datastore, Riak.  In addition to that, I'm also a
graduate student at Brown University, in Providence, RI, where I study
distributed computing.

2) Before joining Basho you were working in a different company (i.e.,
Swipely) where you dealt with Ruby code. Did you already know Erlang
when you started at Basho? How would you describe the switch between
these two languages?

During the time I was at Swipely they had Riak deployed in production,
which was what initially got me interested in Basho, Riak, in
particular, Erlang.  When I joined Basho, I knew very little Erlang and
spent my first few weeks at the company learning it.

That said, I love Erlang as a language and as platform to build
application on.  I wouldn't necessarily say that the change from Ruby to
Erlang was anything that was unexpected, specifically because I already
had functional programming experience using languages like Scheme and
Haskell.

3) Rubyists tend to be addicted to TDD. Were you able to maintain such a
good practice also when coding Erlang?

Well, I'll start with a disclaimer.  I was primarily responsible for the
introduction of behavior driven development at Swipely for feature
development, in addition to promoting pair programming within the
development team.

That said, testing and verification of software is a very interesting
topic to me.

While I believe that all software should be properly tested, I've never
been particuarly dogmatic about when in the cycle of development testing
is performed: whether it's done during development to guide the design
of the software or whether it's done afterwards to validate the authored
components.  I do, however, have one major exception to this rule: when
attempting to reproduce a customer issue and validate a fix for the
issue.

This is purely a pragmatic decision that's come from working on large
scale distributed systems: testing and verification of distrubed systems
is extremely hard given the number of cooperating components involved in
completing a task.

At Basho, we take two major approaches to testing Riak: integrating
testing using a open source test harness we've developed that allow us
to validate high level operations of the system, and QuickCheck for
randomized testing of smaller pieces of functionality.

4) At the upcoming Erlang Factory in San Francisco you will give the
following talk: "Verified Vector Clocks: An Experience Report". Can you
introduce in a few words the arguments you will treat during the talk?

5) Who should be interested in following your talk and why?

6) Lamport's vector clocks are well known by people working in fields
connected to distributed systems. Can you explain briefly what they are
and in what fields they can be used?

7) About the application vvclocks, are you planning to keep the
development on? If so how can people contribute?

At this point, the project mainly serves as a playground for exploring
how we might begin to approach building verifiable software components
in Erlang.  What has been done so far is available on GitHub, it's
actively being worked on by myself as my time allows, and if you're
interested in helping to explore this further, feel free to reach out to
me via e-mail or on Twitter.