jnunemaker

Glad different types of seats is working for you!

We started down that path with free billing seats. But in the end, per seat just never felt right.

As a business owner (I have some other companies) my favorite software to pay for was everything that didn't charge per seat. I'd like my own software to be the same and thus the change.

Correct there are some limits still. At some point you have to make a decision, but at least not with every seat. The hope is to keep increasing those limits.

I'm the founder. Appreciate it.

The files aren’t stored in the database. This is just a record of a download. Things like ip, user agent, which episode, etc.

Solving the dilemma of warming up a "cold" cache cluster via feature flags without causing chaos.

Correct. We also had two other products, which they sold within a year of acquisition (and we didn't buy back).

The only thing that made it an acquisition more than an acquihire is that we had products that were generating revenue, so they couldn't just give us jobs and regular options packages.

Our employees started at GitHub with regular options packages, but Steve and I got a little more because we were the owners.

We chose kestrel mostly just from usage/familiarity. We've been satisfied with it, but are currently researching/testing kafka.

Yep, http://gaug.es was built from the ground up as an API. That definitely made the API better in the long run.

Permissions fixed. Sorry!

The article starts with reporting/graphing but then goes on to how I analyzed those reports/graphs to actually fix an issue.

Steve just posted on the constraints he used to design Gauges: http://orderedlist.com/blog/articles/design-focus-and-constr...

Figured that is related so I should mention it here.

At the risk of being seen as a rails douche, my response is that there is a strong culture in ruby and rails on authoring styles so it is not as painful. Beyond that, I am not saying that 100% of your problems are solved just looking at code. What I was trying to point out is that reading code is important and often times the answer. Google should not be your own tool. Hope that clarifies! :)

I view untested functionality that way but not undocumented. That said, you are right, documentation is very important.

Exactly!

Exactly. Except I would not use inflammatory as the word. More I use titles like that to get people to read something that might not have, not to anger them. :)

I definitely feel the opposite. While there is a lot of crappy code out there, if you look, you can also find a lot of good code, which you can learn from.

Definitely.

"One of the traits was that winners compete against themselves, not others."

Awesome!

Yes, but you didn't have that from the start. Taste comes with practice too.

Touché.

Commercial. Monthly subscription per account (which can have multiple sites). Most likely based on tiered pageviews. Pageviews are what cost us so that is how we'll charge. :)

They are so responsive on the mailing list. You can mention features/bugs and see them in the next nightly.

Totally agree about the array key. It's amazing how your code gets more simple with a simple tweak like that.

Glad you found it interesting!

Awesome comment.

Exactly. :)

I can promise I wasn't being arrogant. The title was just meant to catch eyes and only targeted at Ruby devs.