3 ms·

This is a little off topic, but I was actually the first user of Heroku [1]. It emerged from the terrible experience of trying to run Ruby apps at a consulting

This is a little off topic, but I was actually the first user of Heroku [1]. It emerged from the terrible experience of trying to run Ruby apps at a consulting company I worked at called Bitscribe back in '06-'07. The three founders of Bitscribe (Adam Wiggins, Orion Henry, James Lindenbaum) spun off to build a web IDE with automatic app building and hosting, which eventually became Heroku. The old idea was that you could use Git to download your code from the web IDE, and eventually got developed into the experience we all love(d?). Adam Wiggins, one of the three founders, was one of my favorite software engineering mentors back when we called it programming - as an example, he wrote an early rails plugin called "axeman" for the consultancy that would list controllers and actions by least-often-used, so that we could remove functionality that wasn't worth clients paying for. He also got me introduced to Vim, and another coworker there (Hi Simon Michael) demonstrated for me the orchestral nature of a true Emacs master operating at peak capacity, so I blame them to some degree for being stuck in the DMZ at the middle of the IDE war. [1] The reason I know I was the first user was that in October 2008, Adam sent me an invite to try out Heroku and there was a classic rails error - they forgot to skip the before_filter for authentication on the "accept invite" controller and action. Bug quickly fixed, but definitely a funny anecdote. Even on day one it was obvious they were going places - I would have blind invested money into whatever venture those three were working on regardless of what it was.

lloydatkinson 4y ago
I really love that idea of pruning unused and redundant usage of endpoints. You could take that functionality and apply to to whole application features in the UI too for example. It’s inspired me a lot. I assume this axeman had to integrate with either logs or analytics to get the usage counts? I’m not sure such an idea would even work these days at large organisations following the Big Agile TM nonsense, imagine trying to explain that to a dozen or so product owners and scrum masters…
- jaggederest 4y ago
  This shows you how wild and wooly the "early" days of rails was - I forget whether it ran its own instance of sqlite, or was just a completely in-memory hash of hit counts ala counts[controller][action] += 1 that you had to retrieve. Either way it was extremely primitive, predating really what we think of as monitoring and analytics data being its own process and pipeline. But that was also part of the genius of it - as you say, you'd be hard pressed to hack something together that solved a real problem for customers in an afternoon that way these days. I do think it would be a great thing to incorporate into a monitoring and observability tool - my day job at the moment is related and I hope to work in that area of research a bit. Necessary Disclaimer time: my opinions are my own personal opinions, not professional opinions or those of my employer or anyone else.
adamwiggins 4y ago
Heya Justin :-) Thanks for the walk down memory lane (I had totally forgotten about axeman!) and the kind words. A bit of nuance on the "terrible experience of trying to run Ruby apps" bit. I'd argue that the setup process for Ruby/Rails in 2006 was not all that much worse than other web stacks at the time e.g. Java/WAR or Perl/cgi-bin. (Although PHP+Apache+mod_php deserves a nod for being notably smoother than most others.) What inspired us to start Heroku was that once we switched from building apps in other languages and frameworks, development time was reduced by a factor of 2 or 3; but deployment time stayed the same. That is, before Rails we'd spent maybe three months developing the first version of the client's project, and then 4-6 weeks on deployment. (This was usually buying and installing a rackmount server into their office or colocation facility, but sometimes also waiting for a managed hosting service to do the same for us. For small projects we could use Slicehost but those were infrequent because our clients usually needed a powerful database server.) Once we were developing with Rails, we found v1 could be done in a month or even less. It felt incongruent to spend a month on developing the app (the differentiated part of our work) and then longer than that getting it deployed (the undifferentiated part). There's many other inspirations that were part of the story (end-user programming / citizen developer, which led to the web IDE you talked about) but this was the "deployment pain" part of it. It sticks in my mind because we frequently had to answer the question from prospective investors: "Is Rails really that hard to install?" And we'd say, no, the game has changed--development is so much faster and joyful now, that by comparison our existing ways of deploying feel slow, error-prone, and boring.
- xena 4y ago
  Hey, author of the article here. Thank you for making Heroku a thing. It is single-handedly one of the most significant catalysts for making my career happen. Without Heroku's free tier, I would have never been able to get started in tech. Please continue to create amazing things.
- jaggederest 4y ago
  Absolutely, I didn't mean to apply "terrible" comparatively to other languages at the time, just broadly in terms of "it was terrible compared to the eventual heroku setup" really. These days a lot of systems make it much easier than it was then, but it's not a specific Ruby problem that has been fixed. Hope you're doing well these days, it's been a long time but I still think fondly of the whole Bitscribe gang. In retrospect it was a really special place and time. Lars and his Saab, trying to explain to Morten why I liked Indian food so much (facepalm moment there), meeting Ricardo at 3am for 24h korean barbecue (and getting mixed up on which restaurant was which, since the signs were in hangul), hacking on the netflix prize, griping about Harpoon...

lloydatkinson 4y ago

I really love that idea of pruning unused and redundant usage of endpoints. You could take that functionality and apply to to whole application features in the UI too for example. It’s inspired me a lot. I assume this axeman had to integrate with either logs or analytics to get the usage counts? I’m not sure such an idea would even work these days at large organisations following the Big Agile TM nonsense, imagine trying to explain that to a dozen or so product owners and scrum masters…

jaggederest 4y ago
This shows you how wild and wooly the "early" days of rails was - I forget whether it ran its own instance of sqlite, or was just a completely in-memory hash of hit counts ala counts[controller][action] += 1 that you had to retrieve. Either way it was extremely primitive, predating really what we think of as monitoring and analytics data being its own process and pipeline. But that was also part of the genius of it - as you say, you'd be hard pressed to hack something together that solved a real problem for customers in an afternoon that way these days. I do think it would be a great thing to incorporate into a monitoring and observability tool - my day job at the moment is related and I hope to work in that area of research a bit. Necessary Disclaimer time: my opinions are my own personal opinions, not professional opinions or those of my employer or anyone else.

adamwiggins 4y ago

Heya Justin :-) Thanks for the walk down memory lane (I had totally forgotten about axeman!) and the kind words. A bit of nuance on the "terrible experience of trying to run Ruby apps" bit. I'd argue that the setup process for Ruby/Rails in 2006 was not all that much worse than other web stacks at the time e.g. Java/WAR or Perl/cgi-bin. (Although PHP+Apache+mod_php deserves a nod for being notably smoother than most others.) What inspired us to start Heroku was that once we switched from building apps in other languages and frameworks, development time was reduced by a factor of 2 or 3; but deployment time stayed the same. That is, before Rails we'd spent maybe three months developing the first version of the client's project, and then 4-6 weeks on deployment. (This was usually buying and installing a rackmount server into their office or colocation facility, but sometimes also waiting for a managed hosting service to do the same for us. For small projects we could use Slicehost but those were infrequent because our clients usually needed a powerful database server.) Once we were developing with Rails, we found v1 could be done in a month or even less. It felt incongruent to spend a month on developing the app (the differentiated part of our work) and then longer than that getting it deployed (the undifferentiated part). There's many other inspirations that were part of the story (end-user programming / citizen developer, which led to the web IDE you talked about) but this was the "deployment pain" part of it. It sticks in my mind because we frequently had to answer the question from prospective investors: "Is Rails really that hard to install?" And we'd say, no, the game has changed--development is so much faster and joyful now, that by comparison our existing ways of deploying feel slow, error-prone, and boring.

xena 4y ago
Hey, author of the article here. Thank you for making Heroku a thing. It is single-handedly one of the most significant catalysts for making my career happen. Without Heroku's free tier, I would have never been able to get started in tech. Please continue to create amazing things.
jaggederest 4y ago
Absolutely, I didn't mean to apply "terrible" comparatively to other languages at the time, just broadly in terms of "it was terrible compared to the eventual heroku setup" really. These days a lot of systems make it much easier than it was then, but it's not a specific Ruby problem that has been fixed. Hope you're doing well these days, it's been a long time but I still think fondly of the whole Bitscribe gang. In retrospect it was a really special place and time. Lars and his Saab, trying to explain to Morten why I liked Indian food so much (facepalm moment there), meeting Ricardo at 3am for 24h korean barbecue (and getting mixed up on which restaurant was which, since the signs were in hangul), hacking on the netflix prize, griping about Harpoon...