<![CDATA[Dan Yoder · Storify]]>http://storify.com/dyoderNodeJS RSS ModuleThu, 23 May 2013 19:54:36 GMT<![CDATA[How Not To Do A Spin-Out]]>

Or: Why I left spire.io

Storified by Dan Yoder · Sun, Jun 17 2012 02:11:21

burning the galley · dominique.walterson
Almost a year ago now, I began working with Laura Weidman (now with CODE: 2040) to develop a business plan to spin out a new company from a failed social media startup. Shortly afterward, I began working with Matthew King to develop an initial prototype for what would become spire.io. In the fall, Jason Campbell and Carlo Flores began working with us. In January, we administered the last rites to the social media parent company and moved the entire engineering team over to the spin-out.
By the beginning of June, spire.io had launched two APIs, had interest from investors and customers, and gotten coverage from TechCrunch. We'd also made the front page of HackerNews twice.
Spire.io: A New Platform For Serverless Apps That Work On Web & Mobile | TechCrunchSpire.io: A New Platform For Serverless Apps That Work On Web & Mobile | TechCrunch
undefined
 We subsequently announced that I would move into the CEO role. Shortly thereafter, I resigned.
There were a lot of good people who put their time and energy into what we were doing. These include the team behind spire.io and lots of people who enthusiastically supported what we were doing.
To them, I feel I owe an explanation from my resignation.

The Valley Of Death

The short, simple answer is that we ran out of money. We did not have enough cash to make payroll after May 31st. Given the momentum we had, our investors had picked a curious moment to get gun shy. Be that as it may, the fact was that we were out of money, and, on that basis alone, all bets are off. No one is obligated to work for free, obviously.
However, the situation was actually even worse than that. We had never agreed with investors on the terms of the spin out from the parent company. Or rather, I hadn't.
In fact, this was a big part of how I ended up as CEO, however briefly. For two weeks, I tried to negotiate something that was appealing to me from a compensation standpoint and something I felt I could take to the team as well.

The Opportunity Cost

Keep in mind, this is in a startup climate where I have weekly requests from entrepreneurs and investors asking me if I know any good candidates for technical co-founders. And I had a team of senior engineers, all of whom could credibly fill many of those roles. I didn't want to agree to something where I actually felt we would all be better off somewhere else.
Of course, there's more to life than money. I was willing to concede a substantial amount if we could keep the team together, because I think we all valued that. And I negotiated in good faith - contrary to some slanderous accusations that have since been irresponsibly flung around - trying to get a deal done. In fact, the deal I had on the table was, by the standards of most angel-financed startups, stupidly generous, especially considering the precarious financial position we were in.

Walking Away

With the investors still balking at putting in more money and no agreement on the terms of the spin-out, I was pretty much fed up. And so I resigned. Among other things, this made it possible for the company to move forward. The investors could go back to the terms they originally negotiated with the former CEO, Diego, and then perhaps put up more cash. The team members were free to make their own decisions about the risk and upside. My resignation made my own assessment of the situation pretty clear.

Hindsight Is 20/20

In hindsight, it's pretty obvious that I should have been much more strident in insisting on being a part of the negotiation process from the beginning. Instead, I told Diego what I thought was a reasonable basis for the spin-out and then pestered him about it once in awhile. But we should have established that from the start.
Powered by Storify
]]>http://storify.com/dyoder/why-i-left-spire-iohttp://storify.com/dyoder/why-i-left-spire-ioSun, 17 Jun 2012 09:11:21 GMT<![CDATA[Digital creation myths and geopolitical mathematics]]>

Great interview with George Dyson in Wired.

Storified by Dan Yoder · Tue, Mar 13 2012 09:53:58

313/365 City bokeh · rennes.i
A few choice quotes to get you hooked:
"In some creation myths, life arises out of the earth; in others, life falls out of the sky. The creation myth of the digital universe entails both metaphors." - George Dyson
"You can’t predict how software will behave by inspecting it. The only way you can tell is to actually run it. And this fundamental unpredictability means you can never have a complete digital dictatorship with one government or company controlling our digital lives—not because of politics but because of mathematics." - George Dyson
Q&A: Hacker Historian George Dyson Sits Down With Wired’s Kevin KellyQ&A: Hacker Historian George Dyson Sits Down With Wired’s Kevin Kelly
The two most powerful technologies of the 20th century-the nuclear bomb and the computer-were invented at the same time and by the same g...
That's just the tip of the ice-berg. Go. Read the interview.
Powered by Storify
]]>http://storify.com/dyoder/digital-creation-myths-and-the-politics-of-mathemehttp://storify.com/dyoder/digital-creation-myths-and-the-politics-of-mathemeTue, 13 Mar 2012 16:53:58 GMT<![CDATA[Ruby On Ales]]>

Get your tickets early next year.

Storified by Dan Yoder · Thu, Mar 01 2012 14:03:27

Onales
So I'm in Bend, Oregon. Charming downtown. Snow crunching underfoot. Haven't felt that sensation - or the bracing cold - in a long time. Specifically, about a decade.
Why am I enduring the cold? As charming as Bend is ... I'm here for Ruby On Ales.
This is another Coby Randquist special. Coby leaves a trail of RubyConfs in his wake. He has a knack for it, too. And Ruby On Ales is quite possibly his masterpiece.
Great venue. Great crowd ... you have to be pretty determined to come here. Bend is out in the middle of nowhere. So the only people who are here are really into Ruby. And also drunk. Did I mention the venue?
Free beer. And it's good beer. And we're in a theater. I'm listening to presentation called "Dreaming Of The Freshies" who's quoting _why. We're throwing a party tonight. Hopefully I'll have a chance to catch up with friends like Coby. Snowboarding this weekend.
Life is good.
Powered by Storify
]]>http://storify.com/dyoder/ruby-on-aleshttp://storify.com/dyoder/ruby-on-alesThu, 01 Mar 2012 22:03:27 GMT<![CDATA[Appropriate Humility]]>

Engineering is a humbling endeavor. Embrace that.

Storified by Dan Yoder · Wed, Feb 29 2012 11:26:11

zen-garden · Spirit-Fire
A lot of things in this business annoy me. But I try to focus on the things that delight me, because that's more fun. So here's an example of what I call "appropriate humility":
If you read the page, it's a full-disclosure sort of thing. It isn't filled with a bunch of self-serving hyperbole about how amazing Redis security is. It's a sincere attempt to make sure this crucial information is available and accurate.
And, yet, Redis is a remarkable piece of software. Salvatore has every right to boast and brag, especially by the standards of Silicon Valley culture (that is, not limited to its geography), where it has sadly become routine to take credit for other people's hard work.
I much prefer the understated approach Salvatore takes. I think of it as "appropriate humility." Most of us routinely make use of thousands upon thousands of hours' worth of other people's work. All of us make the occasionally dumb mistake. I don't care how smart you are, engineering will humble you. It's just a question of whether you own up to it.
The best engineers I've ever worked with - and I've had the good fortune to work with some amazing people - were humble. They knew their work was made possible by many other people, most of them relatively anonymous. That taught me that we don't need to accept arrogance as a prerequisite for great engineering.
It's lesson the Valley culture has forgotten, if it ever learned it. And for those of you who, like Salvatore, simply focus on great engineering with appropriate humility, thank you.
Powered by Storify
]]>http://storify.com/dyoder/appropriate-humilityhttp://storify.com/dyoder/appropriate-humilityWed, 29 Feb 2012 19:26:11 GMT<![CDATA[You May Say I'm An HTTP Nerd]]>

But I'm not the only one.

Storified by Dan Yoder · Sun, Feb 26 2012 15:03:44

Computerhistory
Yesterday seemed like a day like any other. (Well, except for the fact that it was StartupWeekend/LA, but that's another post.) And then:
Innocent enough, right? This led Peter Cooper to pose a good question about HTTP:
The reason I say this is a good question is that it's representative of the frustration I think a lot of people feeling when trying to deal with HTTP. They're writing an application. They're thinking in terms of whatever idiom they're programming in. Meanwhile, HTTP is concerned with moving things around on a network in a useful way so applications can use them. Different problem.
This next Tweet from Tony Arcieri (it's not my fault; he keeps saying interesting things) gets to the heart of the matter:
I was in the middle of starting to try and argue about this in 140 character increments when I remembered that was why I had set up this Storify account:
What I was getting at was that application code is a level above HTTP. To make this more concrete, let's say we like object-oriented programming. Our client and server code wants to operate on objects. For example, to go back to Peter's original Tweet, we want to send a "paid" message to our "invoice" object. Right?
Well, this isn't HTTP's job. HTTP's job is to move the invoice object from the server to the client for you. Or, more precisely, a representation of the resource that you prefer to work with in the form of an object. Representational. State. Transfer.
Once you get ahold of it, you can do whatever you like with it. Like define a "paid" method that actually sends a POST to the invoice's payment URL with a description of the payment. Or whatever.
But why not just use objects directly, right?
We could totally do this! Just define a protocol that sends messages to objects. Instead of transferring state, we transfer messages. In fact ... we did do this, more or less. It was called CORBA. It was, in the grand scheme of things, a failure. I mean, no one is arguing about how Rails isn't really CORBA-compliant. But, hey, maybe it's an idea whose time has come -
Except for one thing. There's a reason HTTP transfers state and not messages. A very good reason.
Performance.
Now, HTTP was designed with documents in mind. The thing is, though, "documents" aren't that different from "objects." I can still remember Venki Iyer trying to explain this to me back in 1996. "You could use HTTP for anything!" he exclaimed, knocking over his beer in the process. It took me about a decade to understand what he was talking about.
Here's a common application scenario: editing an object. To go back to Peter's example again ... before I pay that invoice, I want to review it. So my client application needs to retrieve it. Do I want to do that field by field, line-item by line-item? Of course not. I'd have to make dozens of requests. It's much more efficient to send me the entire invoice. Just like a document.
Powered by Storify
]]>http://storify.com/dyoder/how-i-learned-to-stop-worrying-and-love-httphttp://storify.com/dyoder/how-i-learned-to-stop-worrying-and-love-httpSun, 26 Feb 2012 23:03:44 GMT<![CDATA[Ruby Is Still Cool]]>

And Node's rise has nothing to do with Rails.

Storified by Dan Yoder · Sat, Feb 25 2012 21:04:01

Ruby Collection · luisvilla
Here I thought perhaps Giles was just getting quiet in his old age. And then he went and brilliantly trolled the entire hipster hacker "community."
Giles Bowkett: Rails Went Off The Rails: Why I'm Rebuilding Archaeopteryx In CoffeeScriptGiles Bowkett: Rails Went Off The Rails: Why I'm Rebuilding Archaeopteryx In CoffeeScript
Ever been to one of those parties where your work friends and your college friends don't talk ? I posted a great video on my Tumblr which...
My response:
The fact that the hipsters have moved on to Node is meaningless to Ruby. Yes, fewer people will develop apps in Ruby. But Ruby isn't going anywhere. In fact, there is a lot of very interesting work going on in the Ruby community - and much of it has nothing to do with Rails. The reality is, and always was, that Ruby is what made Rails cool, not the other way around.
Furthermore, Node's emergence is a completely separate thing. Developers are using Node because it's Javascript, it provides a really solid set of libraries for using evented I/O, and because server-side MVC frameworks are being replaced by client-side MVC frameworks calling REST APIs. This literally has absolutely nothing to do with Rails, except arguably the bit about REST APIs. But Rails' strong point was never as a way to build APIs. Developers flocked to it for the server-side MVC.
Technology gets better - on the whole - and old things become obsolete. It's not some indictment of older technologies. It's the nature of technology itself. But that's not nearly as fun to argue about, I guess.
Powered by Storify
]]>http://storify.com/dyoder/ruby-is-still-coolhttp://storify.com/dyoder/ruby-is-still-coolSun, 26 Feb 2012 05:04:01 GMT<![CDATA[Disruptor: 100K TPS at Less Than 1ms Latency]]>

"[Disruptor's performance] is very close to the theoretical limit of a modern processor to exchange data between cores."

Storified by Dan Yoder · Thu, Feb 23 2012 23:28:35

Vulcan · Ryan Somma
Just when you thought it was safe to embrace co-operative multitasking, some Java guys have basically proven that, given today's hardware (multicore with large and sophisticated RAM caches), the problem isn't threads at all. 
It's queues.
With some ignorance sprinkled in about how best to take advantage of today's hardware.
disruptor - High Performance Inter-Thread Messaging Library - Google Project Hostingdisruptor - High Performance Inter-Thread Messaging Library - Google Project Hosting
To understand the problem the Disruptor is trying to solve, and to get a feel for why this concurrency framework is so fast, read the Tec...
TLDR is that they use a ring instead of a queue and do some optimizations around making sure that events are cached in L2. The result is that threads pass messages back and forth and it's astonishingly fast.
How fast?
I think there's general agreement that, for HTTP/TCP servers, Erlang > Node > [ Ruby, Python ]. That is (as I've recently learned), it's a K-sorted list, where the value of K is the only thing in dispute. There's some preliminary results that suggest Lua and Go are faster than Erlang, but, even if you throw them in the mix, we're generally talking about throughput on the order of 1,000 to 10,000 requests per second, and latency between 1 and 10 milliseconds.
Disrupter claims to be an order of magnitude faster in both dimensions.
Tony Arcieri (again!) who's been doing some quick-and-dirty benchmarks to test Celluloid, his Ruby concurrency gem, found the Disrupter claims are credible.
The comparison is flawed in many respects, but, at the very least, it suggests that Disrupter, which, again, is using an old-fashioned pre-emptive multitasking model, certainly belongs in the discussion with all these cooperative-multitasking execution environments.
Of course, this isn't really all that shocking, since, under the covers, this is pretty similar to what they're doing under the covers. And the complexity of the solution (from the application programmer's perspective) is comparable to Go's channels. But, still, it's really interesting because you can use this same approach with languages we already know and love. It turns out the key isn't co-routines at all, but message passing in combination with understanding things like how L2 caching works.
Theory: that's why the solutions initially have all taking the form of new execution environments (primarily in the form of languages). Because that's where the knowledge about these things is concentrated.
As an aside, this talk, given by the Disruptor authors just a couple of days ago, is absolutely a must-see:
InfoQ: LMAX Disruptor: 100K TPS at Less than 1ms LatencyInfoQ: LMAX Disruptor: 100K TPS at Less than 1ms Latency
David Neal introduces RavenDB, a document-oriented database with .NET, Silverlight, JavaScript and REST APIs. Alan Shalloway discusses th...
Powered by Storify
]]>http://storify.com/dyoder/disruptor-100k-tps-at-less-than-1ms-latencyhttp://storify.com/dyoder/disruptor-100k-tps-at-less-than-1ms-latencyFri, 24 Feb 2012 07:28:35 GMT<![CDATA[I Say Method, You Say Function]]>

Is the rise of Javascript leading to misconceptions about object-oriented programming?

Storified by Dan Yoder · Wed, Feb 22 2012 16:50:48

Gale_CE_2 · cenews
An interesting little sidebar broke out on Twitter yesterday. It started with Gregory Moeck venting:
I get this. The variant I learned was "encapsulation, polymorphism, and inheritance." (I'm not a big fan of inheritance; I'm just saying that's the definition I learned in the late 80s.) To me, message passing and polymorphism are sort of redundant. In any event, the idea is that you aren't directly invoking a function any more.
Tony Arcieri, who, for some reason, has been getting my attention a lot recently, chimed in:
This cuts to the chase. It's those FP guys. And this is an old debate. Alexander Stepanov, who wrote the vastly under-appreciated STL libraries for C++, called object-oriented programming a "hoax."
STLport: An Interview with A. StepanovSTLport: An Interview with A. Stepanov
(But, you ask, isn't C++ object-oriented? Yes. But the STL, in it's essence, was more about functional programming. That's a huge oversimplification, but I'm already on the brink of writing a different post.)
Languages with exemplars (aka prototypes), like Javascript, do encapsulation pretty well. But it's also fair to say that unless they do polymorphism and have at least some first-class notion of delegation, all you really have is data structures with properties whose values are functions. That's kind of neat and simple, but it's a stretch to talk in terms of object-oriented anything.
I've always found the idea of melding the two worlds fascinating. I used to play around with stack-based languages, trying to build up more complex abstractions from the simplest starting point, and then eventually get to something that looks object-oriented. But there's also something powerful about saying, hey, we're going to make objects and messages primitives, so deal with it.
That's one of the things I love about Tony's work on Celluloid. (I told you he's sort of got my attention these days.) It fully leverages the idea of message passing and yet it looks like normal Ruby code. To do this in Javascript, you'd have to resort to an interface that looks like EventEmitter. Maybe that's okay. But it's a significant difference that can't just be ignored.
celluloidcelluloid
"I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages" --Ala...
UPDATE: Daniel Hengeveld pointed me to this entertaining koan (at the end of the message, after the asterisks):
RE: What's so cool about Scheme?
Powered by Storify
]]>http://storify.com/dyoder/i-say-method-you-say-functionhttp://storify.com/dyoder/i-say-method-you-say-functionThu, 23 Feb 2012 00:50:48 GMT<![CDATA[Capability Security For Web Apps]]>

We've rolled an implementation of capabilities for Web applications in our spire.io API.

Storified by Dan Yoder · Wed, Feb 22 2012 16:52:13

Car Key · Damian Powell
First, the blog post, with comments from Discus:
Web Capabilities: A Better Way To Secure Your Apps | spire.ioWeb Capabilities: A Better Way To Secure Your Apps | spire.io
Capability security provides an authorization model that works like keys on a keychain. A given capability provides privileges for access...
We've also started a conversation on Hacker News:
Request for comments: capability security for Web applications | Hacker News
And on the Node mailing list:
Capability security for Web apps: request for comment. - nodejs | Google Groups
Our Web API uses a form of capability security. It's still evolving, but I've written about what we've done thus far here: http://www.spi...
I hope you'll participate in one or all of these discussions and let us know what you think of this idea.
Powered by Storify
]]>http://storify.com/dyoder/capability-security-for-web-appshttp://storify.com/dyoder/capability-security-for-web-appsThu, 23 Feb 2012 00:52:13 GMT<![CDATA[Benchmark: Ruby Evented I/O]]>

Tony Arcieri's work on making evented I/O more practical in Ruby continues.

Storified by Dan Yoder · Wed, Feb 22 2012 16:54:13

DSC_0991 · 68photobug
Ruby has had evented I/O support for awhile. However, it was kind of an all or nothing thing. And, compared to Node.js, it really wasn't all that fast.
Tony Arcieri apparently decided to try and solve these problems.
celluloid-iocelluloid-io
README.md You don't have to choose between threaded and evented IO! Celluloid::IO provides an event-driven IO system for building fast, s...
One nice thing about Celluloid IO is that it's basically transparent to you as the developer. It's a very elegant non-intrusive design.
Next, Tony wrote a simple Web server framework.
reelreel
Or, indent your code 4 spaces
Then he benchmarked it.
Charles Nutter thinks he can get the JRuby number up.
Obviously, this is a pretty simple-minded benchmark, but it jives with our experience at spire.io. (At least in terms of the relative performance of Node and Ruby.) To get the ratio for Node to Ruby down to less than 2:1 is pretty interesting.
UPDATE: From Tony:
Our (more complex) benchmark hadn't shown Thin to be that close to Node. I wonder if Reel can get there, too.
ANOTHER UPDATE: The Thin benchmark was flawed. So it's actually closer than even 3/4.
This surprises me, but then our benchmarks were different. Tony believes that he can get better performance out of Reel as well.
Powered by Storify
]]>http://storify.com/dyoder/benchmark-ruby-evented-i-ohttp://storify.com/dyoder/benchmark-ruby-evented-i-oThu, 23 Feb 2012 00:54:13 GMT