Cloud Out Loud

Cloud Out Loud | Ruby http://feeds.feedburner.com/CloudOutLoudRuby 2011 Engine Yard, Inc. All rights reserved. Ruby, Open source and cloud related podcast by Engine Yard Engine Yard Ruby, Open source and cloud related podcast by Engine Yard Cloud Out Loud is a weekly discussion forum for a variety of Ruby, open source and cloud related topics. Interesting conversations with passionate folks who dedicate their time and energy to advancing open source technology they believe in. Engine Yard pandas@engineyard.com 2011 Engine Yard, Inc. All rights reserved.no Developer Evangelism at New Relic, Craft, Burritos Engine Yard Developer Evangelism at New Relic, Craft, Burritos Elaine Greenberg interviews New Relic Developer Evangelist Chris Kelly about conferences, getting developers to speak up, and the subtleties of San Francisco burritos. <ul> <li>0:36 All About Chris</li> <li>3:30 Getting new speakers at conferences</li> <li>9:30 San Francisco burritos vs. San Diego burritos</li> <li>13:00 Being an evangelist at New Relic</li> <li>15:00 What makes a great evangelist</li> <li>16:00 Combining philosophy and technology</li> <li>19:00 Chris' current projects</li> <li>25:00 New Relic in 2013</li> <li>28:00 The future of Ruby and Rails</li> </ul> Chris on Twitter: <a href="https://twitter.com/amateurhuman">https://twitter.com/amateurhuman</a> Chris on GitHub: <a href="https://github.com/amateurhuman">https://github.com/amateurhuman</a> Chris' website: <a href="http://amateurhuman.com/">http://amateurhuman.com/</a> Links RubyFuza: <a href="http://rubyfuza.org/">http://rubyfuza.org/</a> Ruby There: <a href="http://rubythere.com/">http://rubythere.com/</a> Cheat: <a href="https://github.com/defunkt/cheat">https://github.com/defunkt/cheat</a> Jekyll: <a href="https://github.com/mojombo/jekyll">https://github.com/mojombo/jekyll</a> Rubygems: <a href="http://rubygems.org/">http://rubygems.org/</a> Riak: <a href="http://docs.basho.com/">http://docs.basho.com/</a> RubyConf Australia: <a href="http://www.rubyconf.org.au/">http://www.rubyconf.org.au/</a> Railsberry: <a href="http://railsberry.com/">http://railsberry.com/</a> Bacon: <a href="http://devslovebacon.com/">http://devslovebacon.com/</a> Jessica Allen's DIY Standing Desk: <a href="http://www.youtube.com/watch?v=st9J29bS7ak">http://www.youtube.com/watch?v=st9J29bS7ak</a> OSCON: <a href="http://www.oscon.com/oscon2013">http://www.oscon.com/oscon2013</a> Brian Ford's Toward A Design for Ruby talk: <a href="http://www.youtube.com/watch?v=BagNfTbXn3w">http://www.youtube.com/watch?v=BagNfTbXn3w</a> Rubinius: <a href="http://rubini.us/">http://rubini.us/</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/99/chriskelly.mp3?1356129532 Fri, 21 Dec 2012 22:36:58 +0000 no RubyTapas, Ruby Rogues and the Future for Avdi Grimm Engine Yard RubyTapas, Ruby Rogues and the Future for Avdi Grimm Michael Brodhead talks to Avdi Grimm of RubyTapas fame about joining Ruby Rogues, creating Exceptional Ruby and why he uses Emacs <ul> <li>1:00 All about Avdi</li> <li>9:45 Advice for Python users learning Ruby</li> <li>19:00 Exceptional Ruby</li> <li>20:30 RubyTapas</li> <li>24:00 Working on Ruby Rogues</li> <li>27:00 Challenges with remote working</li> <li>38:00 Why Emacs</li> <li>52:00 What's next</li> </ul> Avdi on Twitter: <a href="https://twitter.com/avdi">https://twitter.com/avdi</a> Avdi on GitHub: <a href="https://github.com/avdi">https://github.com/avdi</a> Avdi's website: <a href="http://about.avdi.org/">http://about.avdi.org/</a> Links RubyTapas: <a href="http://devblog.avdi.org/rubytapas/">http://devblog.avdi.org/rubytapas/</a> Expect-tcl: <a href="http://www.tcl.tk/man/expect5.31/expect.1.html">http://www.tcl.tk/man/expect5.31/expect.1.html</a> Ruby Rogues: <a href="http://rubyrogues.com/">http://rubyrogues.com/</a> Wide Teams: <a href="http://www.wideteams.com/">http://www.wideteams.com/</a> yuuguu: <a href="https://www.yuuguu.com/s/home">https://www.yuuguu.com/s/home</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/97/avdigrimm.mp3?1356036823 Thu, 20 Dec 2012 20:53:43 +0000 no Working with Unix Processes, Testing and Shopify Engine Yard Working with Unix Processes, Testing and Shopify Michael Brodhead talks to Jesse Storimer of Shopify about his upcoming book releases, and the company's roots in Rails. <ul> <li>0:45 All about Jesse</li> <li>4:00 Where Jesse started</li> <li>9:00 Upcoming projects, including writing about threading</li> <li>11:45 The importance of testing</li> <li>14:00 The process of self-publishing</li> <li>17:45 Shopify's roots in Rails</li> </ul> Jesse on Twitter: <a href="https://twitter.com/jstorimer">https://twitter.com/jstorimer</a> Jesse on GitHub: <a href="https://github.com/jstorimer">https://github.com/jstorimer</a> Jesse's website: <a href="http://jstorimer.com">http://jstorimer.com</a> Links Working with Unix Processes: <a href="http://workingwithunixprocesses.com/">http://workingwithunixprocesses.com/</a> Working with TCP Sockets: <a href="http://workingwithtcpsockets.com/">http://workingwithtcpsockets.com/</a> Shopify: <a href="http://www.shopify.com/">http://www.shopify.com/</a> Teamviewer: <a href="http://www.teamviewer.com/en/index.aspx">http://www.teamviewer.com/en/index.aspx</a> Textmate: <a href="http://macromates.com/">http://macromates.com/</a> Vim: <a href="http://www.vim.org/">http://www.vim.org/</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/96/jessestorimer.mp3?1355766233 Mon, 17 Dec 2012 17:43:54 +0000 no Gaslight, QCMerge, Mastering Backbone Engine Yard Gaslight, QCMerge, Mastering Backbone Elizabeth Naramore interviews Chris Nelson of Gaslight about testing, using Backbone, and organizing QCMerge. <ul> <li>0:30 All about Chris</li> <li>5:00 What's Next at Gaslight</li> <li>11:30 The Gaslight Podcasts</li> <li>13:20 Organizing QCMerge</li> </ul> Chris on Twitter: <a href="https://twitter.com/superchris">https://twitter.com/superchris</a> Chris on GitHub: <a href="https://github.com/superchris">https://github.com/superchris</a> Chris' website: <a href="http://mysterycoder.blogspot.com">http://mysterycoder.blogspot.com</a> Links QCMerge: <a href="http://www.qcmerge.com/">http://www.qcmerge.com/</a> Gaslight: <a href="http://gaslight.co/home">http://gaslight.co/home</a> Mastering Backbone: <a href="http://www.masteringbackbone.com/">http://www.masteringbackbone.com/</a> CoffeeScript: <a href="http://coffeescript.org/">http://coffeescript.org/</a> Jasmine: <a href="http://pivotal.github.com/jasmine/">http://pivotal.github.com/jasmine/</a> mocha: <a href="http://visionmedia.github.com/mocha/">http://visionmedia.github.com/mocha/</a> CodeMash: <a href="http://codemash.org/">http://codemash.org/</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/95/ChrisNelson.mp3?1354306677 Fri, 30 Nov 2012 20:17:58 +0000 no Agile Communication with Angela Harms Engine Yard Agile Communication with Angela Harms Our own Michael Brodhead talks to Angela Harms about pair programming practices, meditation and more. <ul> <li>0:25 All about Angela</li> <li>11:15 Pairing, and how to improve</li> <li>14:35 The role of an Agile Coach</li> <li>25:00 Finding a balance</li> <li>30:00 The benefits of meditation and how to do it</li> </ul> Angela on Twitter: <a href="https://twitter.com/angelaharms">https://twitter.com/angelaharms</a> Angela on GitHub: <a href="https://github.com/angelaharms">https://github.com/angelaharms</a> Angela's blog: <a href="http://angelaharms.com/">http://angelaharms.com/</a> Angela's website: <a href="http://myagileeducation.com/">http://myagileeducation.com/</a> Links LeanDog: <a href="http://leandog.com/">http://leandog.com/</a> Brené Brown TED talk: <a href="http://www.ted.com/talks/brene_brown_on_vulnerability.html">http://www.ted.com/talks/brene_brown_on_vulnerability.html</a> Stop Stealing Dreams: <a href="http://www.sethgodin.com/sg/docs/stopstealingdreamsscreen.pdf">http://www.sethgodin.com/sg/docs/stopstealingdreamsscreen.pdf</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/94/angelaharms.mp3?1354230165 Thu, 29 Nov 2012 23:02:47 +0000 no Therapeutic Refactoring Engine Yard Therapeutic Refactoring Our own Michael Brodhead talks to Katrina Owen of Bengler about the joys of refactoring. <ul> <li>0:30 All about Katrina</li> <li>6:45 Tools for distant pairing</li> <li>10:00 Getting started with refactoring, adding tests</li> <li>17:00 Isolating the method in a different environment</li> <li>20:55 What's next for Katrina</li> </ul> Katrina on Twitter: <a href="https://twitter.com/kytrinyx">https://twitter.com/kytrinyx</a> Katrina on GitHub: <a href="https://github.com/kytrinyx">https://github.com/kytrinyx</a> Links Therapeutic Refactoring: <a href="http://www.youtube.com/watch?v=J4dlF0kcThQ">http://www.youtube.com/watch?v=J4dlF0kcThQ</a> Bengler: <a href="http://bengler.no/">http://bengler.no/</a> Petroglyph: <a href="http://rubygems.org/gems/petroglyph">http://rubygems.org/gems/petroglyph</a> rabl: <a href="https://github.com/nesquena/rabl">https://github.com/nesquena/rabl</a> Riak: <a href="http://wiki.basho.com/">http://wiki.basho.com/</a> JSON: <a href="http://www.json.org/">http://www.json.org/</a> Erlang: <a href="http://www.erlang.org/">http://www.erlang.org/</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/92/katrinaowen.mp3?1353012620 Thu, 15 Nov 2012 20:50:21 +0000 no Vimcasts, Practical Vim and Honing your Craft Engine Yard Vimcasts, Practical Vim and Honing your Craft Our own Jason Hansen interviews Vimcasts' Drew Neil about getting started with Vim, writing his book and playing VimGolf. <ul> <li>0:30 All about Drew</li> <li>1:00 Collective Nouns</li> <li>3:15 How Drew got involved with Vim</li> <li>9:50 Writing the book</li> <li>12:20 Honing your Vim craft, mastering the dot command </li> <li>18:30 Other tools in Drew's toolkit</li> <li>20:45 Advice for Vim users </li> <li>23:20 The driving interest in Vim</li> </ul> Drew's website: <a href="http://drewneil.com/">http://drewneil.com/</a> Drew on Twitter: <a href="https://twitter.com/nelstrom">https://twitter.com/nelstrom</a> Drew on GitHub: <a href="https://github.com/nelstrom">https://github.com/nelstrom</a> Links Collective Nouns: <a href="http://all-sorts.org/">http://all-sorts.org/</a> Vimcasts: <a href="http://vimcasts.org/">http://vimcasts.org/</a> TextMate: <a href="http://macromates.com/">http://macromates.com/</a> Sublime Text: <a href="http://www.sublimetext.com/">http://www.sublimetext.com/</a> VimGolf: <a href="http://vimgolf.com/">http://vimgolf.com/</a> Angular.js: <a href="http://angularjs.org/">http://angularjs.org/</a> Practical Vim (Drew's book): <a href="http://pragprog.com/book/dnvim/practical-vim">http://pragprog.com/book/dnvim/practical-vim</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/91/drewneil.mp3?1350606772 Fri, 19 Oct 2012 00:32:52 +0000 no Social Oppression, Ruby and Codes of Conduct Engine Yard Social Oppression, Ruby and Codes of Conduct Our own Jason Hansen interviews Steve Klabnik and Lindsey Bieda about taking on Ruby projects and the gender bias in programming. <ul> <li>0:00 All about Steve and Lindsey</li> <li>2:50 Working on Hackety Hack</li> <li>6:00 Social oppression</li> <li>16:00 The urgency of the topic today</li> <li>25:35 Codes of conduct becoming the norm</li> </ul> Steve's Twitter: <a href="https://twitter.com/steveklabnik">https://twitter.com/steveklabnik</a> Lindsey's Twitter: <a href="https://twitter.com/lindseybieda">https://twitter.com/lindseybieda</a> Steve's Github: <a href="https://github.com/steveklabnik">https://github.com/steveklabnik</a> Lindsey's Github: <a href="https://github.com/LindseyB">https://github.com/LindseyB</a> Steve's website: <a href="http://steveklabnik.com/">http://steveklabnik.com/</a> Lindsey's website: <a href="http://rarlindseysmash.com/">http://rarlindseysmash.com/</a> Additional resources Why's (Poignant) Guide to Ruby: <a href="http://mislav.uniqpath.com/poignant-guide/">http://mislav.uniqpath.com/poignant-guide/</a> Open Source Game Coding Competition: <a href="http://osgcc.org/">http://osgcc.org/</a> Hackety Hack!: <a href="http://hackety.com/">http://hackety.com/</a> Shoes: <a href="http://shoesrb.com/">http://shoesrb.com/</a> Girl Develop It: <a href="http://girldevelopit.com/">http://girldevelopit.com/</a> Geek Feminism: <a href="http://geekfeminism.wikia.com/wiki/Timeline_of_incidents">http://geekfeminism.wikia.com/wiki/Timeline_of_incidents</a> The Microagressions Project: <a href="http://www.microaggressions.com/">http://www.microaggressions.com/</a> Programmers Being Dicks: <a href="http://programmersbeingdicks.tumblr.com/">http://programmersbeingdicks.tumblr.com/</a> Code of Conduct, Steel City Ruby: <a href="http://steelcityrubyconf.org/policies#antiharassment">http://steelcityrubyconf.org/policies#antiharassment</a> rstat.us: <a href="http://github.com/hotsh/rstat.us">http://github.com/hotsh/rstat.us</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/89/stevelindsey.mp3?1348871106 Fri, 28 Sep 2012 22:25:07 +0000 no Bendyworks, Madison Ruby Conference Engine Yard Bendyworks, Madison Ruby Conference Our own Anthony Accomazzo talks to Bendyworks' Jim Remsik about Open Source and planning conferences. <ul> <li>0:10 All about Jim</li> <li>1:30 Jim's role at Bendyworks</li> <li>2:30 Bendyworks' uniqueness</li> <li>6:25 Talking at and planning conferences</li> <li>13:30 Open (Source) Wounds</li> <li>14:45 How to get started with Open Source</li> </ul> Jim's website: <a href="http://bigtiger.github.com/">http://bigtiger.github.com/</a> Jim on Twitter: <a href="https://twitter.com/jremsikjr">https://twitter.com/jremsikjr</a> Jim's GitHub: <a href="https://github.com/bigtiger">https://github.com/bigtiger</a> Links: Madison Ruby User Group: <a href="https://groups.google.com/forum/?fromgroups#!forum/mad-railers">https://groups.google.com/forum/?fromgroups#!forum/mad-railers</a> Bendyworks: <a href="http://bendyworks.com/">http://bendyworks.com/</a> Madison Ruby Conf: <a href="http://madisonruby.org/">http://madisonruby.org/</a> UXMad: <a href="http://uxmad.com/">http://uxmad.com/</a> Travis CI: <a href="http://travis-ci.org/">http://travis-ci.org/</a> JRuby Conf: <a href="http://jrubyconf.com/">http://jrubyconf.com/</a> Windy City Rails: <a href="http://windycityrails.org/">http://windycityrails.org/</a> Open (Source) Wounds: <a href="https://vimeo.com/45673516">https://vimeo.com/45673516</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/87/cloud-out-loud-jim-remsick.mp3?1348182902 Thu, 20 Sep 2012 23:15:02 +0000 no Chicks that Rip: Elise Worthy, LivingSocial Engine Yard Chicks that Rip: Elise Worthy, LivingSocial Our own Jessica Allen interviews LivingSocial engineer and Hungry Academy graduate Elise Worthy about the program, learning Rails and living in Washington DC. <ul> <li>0:00 All about Elise</li> <li>1:45 How Elise got into technology marketing</li> <li>3:20 How to market to developers</li> <li>4:45 Getting into Hungry Academy</li> <li>6:15 A typical Hungry Academy day</li> <li>8:20 Finding a good way to learn Rails</li> <li>10:30 Avoiding burnout</li> <li>13:30 Elise's new role at LivingSocial</li> </ul> Elise's website: <a href="http://bebrandworthy.com/">http://bebrandworthy.com/</a> Elise on Twitter: <a href="https://twitter.com/eliseworthy">https://twitter.com/eliseworthy</a> Links: Hungry Academy: <a href="http://hungryacademy.com/">http://hungryacademy.com/</a> JumpstartLab: <a href="http://jumpstartlab.com/">http://jumpstartlab.com/</a> Rails Hotline: <a href="http://rails.pockethotline.com/">http://rails.pockethotline.com/</a> PeepCode: <a href="https://peepcode.com/">https://peepcode.com/</a> RailsCasts: <a href="http://railscasts.com/">http://railscasts.com/</a> jQuery: <a href="http://jquery.com/">http://jquery.com/</a> D3: <a href="http://d3js.org/">http://d3js.org/</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/86/eliseworthy.mp3?1346884243 Wed, 05 Sep 2012 22:29:16 +0000 no Community at Twilio Engine Yard Community at Twilio Elaine Greenberg interviews Meghan Murphy, Community Manager at Twilio, about working with different language communities, learning to code and planning TwilioCon. <ul> <li>0:00 All About Meghan</li> <li>1:20 How Meghan got into Community</li> <li>2:11 Learning to code</li> <li>4:00 Meghan's favorite events</li> <li>9:05 Trends at conferences</li> <li>10:30 Twilio con</li> <li>14:50 being involved in different communities</li> <li>16:10 The challenges of Community</li> </ul> Meghan's website: <a href="http://about.me/meghanmurphy">http://about.me/meghanmurphy</a> Meghan on Twitter: <a href="https://twitter.com/megmurph">https://twitter.com/megmurph</a> Links: TwilioCon: <a href="http://www.twilio.com/conference">http://www.twilio.com/conference</a> The Escapist: <a href="http://www.escapistmagazine.com/">http://www.escapistmagazine.com/</a> TechStars: <a href="http://www.techstars.com/">http://www.techstars.com/</a> Code for America: <a href="http://codeforamerica.org/">http://codeforamerica.org/</a> South by Southwest: <a href="http://sxsw.com/">http://sxsw.com/</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/84/meghantwilio.mp3?1344374118 Tue, 07 Aug 2012 21:15:19 +0000 no Data-Based, Part 3: Tom Wilkie, Acunu and Cassandra Engine Yard Data-Based, Part 3: Tom Wilkie, Acunu and Cassandra Ines Sombra interviews Tom Wilkie, the founder and VP of Engineering of Acunu about Cassandra, how to deal with frequent issues and future projects. Tom on Twitter: <a href="https://twitter.com/#!/tom_wilkie">https://twitter.com/#!/tom_wilkie</a> Acunu: <a href="http://www.acunu.com/">http://www.acunu.com/</a> Discussion * 0:20 All About Tom * 2:00 About Acunu * 3:30 Using Cassandra * 10:35 Contributing to the data/Cassandra community * 12:30 Areas that need improvement in the space * 18:20 Sneak peeks at Acunu * 20:00 Frequent mistakes in dealing with Cassandra Links * Camel - <a href="http://camel.apache.org/language.html">http://camel.apache.org/language.html</a> * Hadoop - <a href="http://hadoop.apache.org/">http://hadoop.apache.org/</a> * Cassandra - <a href="http://cassandra.apache.org/">http://cassandra.apache.org/</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/82/Tomwilkie.mp3?1341878233 Mon, 09 Jul 2012 23:57:13 +0000 no Chicks (and Dudes) that Rip: We Are All Awesome Engine Yard Chicks (and Dudes) that Rip: We Are All Awesome Elizabeth Naramore talks to Jan Lehnardt and Tiffany Conroy about their weareallaweso.me project. We Are All Awesome: <a href="http://weareallaweso.me/">http://weareallaweso.me/</a> Tiffany on Twitter: <a href="https://twitter.com/#!/theophani">https://twitter.com/#!/theophani</a> Tiffany on Github: <a href="https://github.com/theophani">https://github.com/theophani</a> Jan on Twitter: <a href="https://twitter.com/#!/janl">https://twitter.com/#!/janl</a> Discussion <ul> <li>0:00 All about Jan and Tiffany</li> <li>1:30 How weareallaweso.me got started</li> <li>8:00 The breakdown of the website, a call to action</li> <li>13:00 Reactions and pushback</li> <li>28:00 What's next?</li> </ul> Links Soundcloud: <a href="http://soundcloud.com/">http://soundcloud.com/</a> JSConf EU: <a href="http://2012.jsconf.eu/">http://2012.jsconf.eu/</a> devChix: <a href="http://www.devchix.com/">http://www.devchix.com/</a> Programmers Being Dicks: <a href="http://programmersbeingdicks.tumblr.com/">http://programmersbeingdicks.tumblr.com/</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/81/janlehrtiff.mp3?1341248257 Fri, 29 Jun 2012 14:56:16 +0000 no Data-Based, Part 2: Andreas Kollegger and Neo4j Engine Yard Data-Based, Part 2: Andreas Kollegger and Neo4j Our own Ines Sombra interviews Andreas Kollegger about the present and future of Neo4j, how to get started, and a likely Graph Conference in San Francisco. Andreas on Twitter: <a href="https://twitter.com/#!/akollegger">https://twitter.com/#!/akollegger</a> Neo Technology: <a href="http://www.neotechnology.com/">http://www.neotechnology.com/</a> Discussion * 0:00 All about Andreas * 3:00 Working with graphs * 5:00 Trends with Neoj4 * 6:00 Mistakes people make with Neo4j * 8:45 Areas of improvement for Graph Databases * 14:00 Getting started with Neo4j for Ruby and PHP * 15:45 What's coming up in the Neo4j world * 22:30 Neo4j user groups * 23:15 Cat's out of the bag: Graph Conference in SF Links * Neo4j - <a href="http://neo4j.org/">http://neo4j.org/</a> * Neograph by Max de Marzi - <a href="https://github.com/maxdemarzi/neography">https://github.com/maxdemarzi/neography</a> * NoSQL - <a href="http://nosql-database.org/">http://nosql-database.org/</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/79/AndreasK.mp3?1339110547 Thu, 07 Jun 2012 18:02:31 +0000 no Githubris and HTTParty Engine Yard Githubris and HTTParty "You'll probably never be angry at Ruby." Michael Brodhead interviews 18-year-old Isaac Sanders, veteran intern of EdgeCase and Groupon about his Open Source projects, going to college and what inspired him to start programming. Isaac on Twitter: <a href="https://twitter.com/#!/isaacsanders">https://twitter.com/#!/isaacsanders</a> Isaac's Website: <a href="http://isaacbfsanders.com/">http://isaacbfsanders.com/</a> Derick on Github: <a href="https://github.com/isaacsanders">https://github.com/isaacsanders</a> HTTParty: <a href="http://johnnunemaker.com/httparty/">http://johnnunemaker.com/httparty/</a> Githubris: <a href="https://github.com/isaacsanders/githubris">https://github.com/isaacsanders/githubris</a> Emptying Your Cup: <a href="http://isaacbfsanders.com/blog/2012/05/07/emptying-your-cup-revisited/">http://isaacbfsanders.com/blog/2012/05/07/emptying-your-cup-revisited/</a> Discussion *0:30 All about Isaac * 3:30 Contributing to Rails, Ruby, JRuby and Rubinius * 7:20 Getting started with programming * 13:30 Githubris and other projects * 16:30 Linworth's alternative program Links A Whole New Mind: Moving from the Information Age to the Conceptual Age: <a href="http://www.amazon.com/Whole-New-Mind-Information-Conceptual/dp/1573223085">http://www.amazon.com/Whole-New-Mind-Information-Conceptual/dp/1573223085</a> Apprenticeship Patterns: <a href="http://shop.oreilly.com/product/9780596518387.do">http://shop.oreilly.com/product/9780596518387.do</a> Eloquent Ruby: <a href="http://www.amazon.com/Eloquent-Ruby-Addison-Wesley-Professional-Series/dp/0321584104">http://www.amazon.com/Eloquent-Ruby-Addison-Wesley-Professional-Series/dp/0321584104</a> Pragmatic Thinking and Learning: <a href="http://pragprog.com/book/ahptl/pragmatic-thinking-and-learning">http://pragprog.com/book/ahptl/pragmatic-thinking-and-learning</a> Linworth Alternative Program: <a href="http://www.linworth.org/">http://www.linworth.org/</a> Leandog: <a href="http://leandog.com/">http://leandog.com/</a> EdgeCase: edgecase.com CodeMash: <a href="http://codemash.org/">http://codemash.org/</a> Agile and Beyond: <a href="http://agileandbeyond.org/">http://agileandbeyond.org/</a> RailsConf: <a href="http://railsconf2012.com/">http://railsconf2012.com/</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/78/isaacsanders.mp3?1338331227 Tue, 29 May 2012 22:40:28 +0000 no Black Girls Code Engine Yard Black Girls Code Elaine Greenberg interviews Kimberly Bryant, founder of Black Girls Code about impacting the community around you, getting girls involved and the current landscape of diversity in tech. Kimberly on Twitter: <a href="https://twitter.com/#!/6gems">https://twitter.com/#!/6gems</a> Kimberly's Website: <a href="http://about.me/kimberlybryant">http://about.me/kimberlybryant</a> Black Girls Code: <a href="http://www.blackgirlscode.com/">http://www.blackgirlscode.com/</a> Black Girls Code on Twitter: <a href="https://twitter.com/#!/BlackGirlsCode">https://twitter.com/#!/BlackGirlsCode</a> Discussion * 0:15 All about Kimberly * 1:10 How Kimberly got into programming * 2:15 Starting Black Girls Code * 5:30 The structure of Black Girls Code * 8:45 Getting girls engaged as early as possible * 13:30 Combining tech and civics * 14:40 the changing landscape of diversity in tech * 21: 50 Success stories * 24:00 Call for volunteers for Black Girls Code Links KidsRuby: <a href="http://kidsruby.com/">http://kidsruby.com/</a> Scratch: <a href="http://scratch.mit.edu/">http://scratch.mit.edu/</a> Alice: <a href="http://www.alice.org/">http://www.alice.org/</a> Code for America: <a href="http://codeforamerica.org/">http://codeforamerica.org/</a> RailsBridge: <a href="http://railsbridge.org/en">http://railsbridge.org/en</a> Women 2.0: <a href="http://www.women2.com/">http://www.women2.com/</a> Black Founders: <a href="http://www.blackfounders.com/">http://www.blackfounders.com/</a> Golden Gate Ruby Conference: <a href="http://gogaruco.com/">http://gogaruco.com/</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/77/kimberlybryant.mp3?1337380161 Fri, 18 May 2012 22:29:21 +0000 no Chicks that Rip: Kami Lott, Github Community Manager Engine Yard Chicks that Rip: Kami Lott, Github Community Manager Elizabeth Naramore interviews Github Community Manager Kami Lott about her experiences in organizing events for developers, the importance of community, and open source knitting patterns. Kami on Twitter: <a href="https://twitter.com/#!/_kamzilla">https://twitter.com/#!/_kamzilla</a> Kami's Website: <a href="http://kamilott.com/">http://kamilott.com/</a> Kami on Github: <a href="https://github.com/kamzilla">https://github.com/kamzilla</a> Discussion * 0:10 All about Kami * 2:00 Why community is so important * 6:30 Github's open-office culture * 10:00 Getting into programming through community http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/75/kamilott.mp3?1336091380 Fri, 04 May 2012 00:29:41 +0000 no Data-Based, Part 1: Mathias Meyer and The Riak Handbook Engine Yard Data-Based, Part 1: Mathias Meyer and The Riak Handbook Our own Ines Sombra interviews Mathias Meyer, the author of the Riak Handbook and Infrastructure Engineer at Travis-CI. Mathias on Twitter: <a href="https://twitter.com/#!/roidrage">https://twitter.com/#!/roidrage</a> Mathias' Website: <a href="http://www.paperplanes.de/">http://www.paperplanes.de/</a> Discussion * 0:20 All about Mathias * 2:45 The Riak handbook * 6:30 Using specific DBs for different use cases * 9:30 Postgres and why it's exciting * 14:30 The challenges that big data stores will face and the future of databases * 20:00 Advice for people getting started Promotions Buy the Riak Handbook here, and enter code EYDATA to get 20% off through May 17: <a href="http://riakhandbook.com/">http://riakhandbook.com/</a> Links * Riak - <a href="http://basho.com/products/riak-overview/">http://basho.com/products/riak-overview/</a> * CouchDB -<a href="http://couchdb.apache.org/">http://couchdb.apache.org/</a> * MongoDB - <a href="http://www.mongodb.org/">http://www.mongodb.org/</a> * Redis - <a href="http://redis.io/">http://redis.io/</a> * Percona - <a href="http://www.percona.com/">http://www.percona.com/</a> * MongoDB Best Practices - <a href="http://www.engineyard.com/blog/2011/mongodb-best-practices/">http://www.engineyard.com/blog/2011/mongodb-best-practices/</a> * Travis-CI - <a href="http://travis-ci.org/">http://travis-ci.org/</a> * Martin Fowler's Polyglot Persistence Blog Post - <a href="http://martinfowler.com/bliki/PolyglotPersistence.html">http://martinfowler.com/bliki/PolyglotPersistence.html</a> * Cassandra - <a href="http://cassandra.apache.org/">http://cassandra.apache.org/</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/74/mathiasmeyer.mp3?1335813083 Mon, 30 Apr 2012 18:44:29 +0000 no Badgeville Engine Yard Badgeville Tasha Drew and Ines Sombra interview Wedge Martin, Jimmy Zhang and Ken Bibb of Badgeville about using MongoDB, Redis, Engine Yard and future of the company. <ul> <li>0:40 All about Badgeville</li> <li>2:20 Badgeville's technology stack</li> <li>3:00 Starting and ramping up Badgeville</li> <li>4:10 Using MongoDB </li> <li>13:00 Using 10gen</li> <li>13:45 The future of Badgeville</li> </ul> Website: <a href="http://badgeville.com/">http://badgeville.com/</a> Twitter: <a href="https://twitter.com/#!/badgeville">https://twitter.com/#!/badgeville</a> Links MongoDB: <a href="http://www.mongodb.org/">http://www.mongodb.org/</a> Redis: <a href="http://redis.io/">http://redis.io/</a> MySQL: <a href="http://mysql.com/">http://mysql.com/</a> Unicorn: <a href="http://unicorn.bogomips.org/">http://unicorn.bogomips.org/</a> 10gen: <a href="http://www.10gen.com/">http://www.10gen.com/</a> MongoDB Best Practices: <a href="http://www.engineyard.com/blog/2011/mongodb-best-practices/">http://www.engineyard.com/blog/2011/mongodb-best-practices/</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/73/badgeville.mp3?1334963439 Fri, 20 Apr 2012 23:00:30 +0000 no Sidekiq, The Clymb, Motorcycles Engine Yard Sidekiq, The Clymb, Motorcycles Our own Michael Brodhead talks to Mike Perham, the maintainer and creator of Sidekiq. Listen in as they talk about Open Source, The Clymb, Motorcycles and Portland. <ul> <li>0:30 All about Mike</li> <li>1:00 How Clymb works so snappily, upgrading to Rails 3.2</li> <li>4:00 Sidekiq</li> <li>11:00 Fibers making sense, when to use them</li> <li>13:00 Using threads</li> <li>16:00 Motorcycle racing</li> <li>23:00 Programmers and meetings</li> <li>29:00 SF vs. PDX: lifestyles and tech scenes</li> </ul> Mike Perham on: Twitter: <a href="http://twitter.com/#!/mperham">http://twitter.com/#!/mperham</a> GitHub: <a href="https://github.com/mperham">https://github.com/mperham</a> Blog :<a href="http://www.mikeperham.com/">http://www.mikeperham.com/</a> Links The Clymb: <a href="http://www.theclymb.com/">http://www.theclymb.com/</a> Sidekiq: <a href="http://mperham.github.com/sidekiq/">http://mperham.github.com/sidekiq/</a> Sidekiq's Pledgie: <a href="http://pledgie.com/campaigns/16623">http://pledgie.com/campaigns/16623</a> Dalli: <a href="https://github.com/mperham/dalli">https://github.com/mperham/dalli</a> Girlfriday: <a href="https://github.com/mperham/girl">https://github.com/mperham/girl</a>friday http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/72/MikePerham.mp3?1334360161 Fri, 13 Apr 2012 22:59:54 +0000 no S02E12: Engine Yard Support Engine Yard S02E12: Engine Yard Support Tasha Drew, our Success Manager interviews some of our awesome Support Engineers: John Yerhot, Adam Holt, Erik Jones, James Paterni. <ul> <li>1:15: Support’s different roles on the team</li> <li>6:15: Spare time with support: user groups, open source</li> <li>8:55: How customers scale</li> <li>15:30: How support at EY has evolved, customer engagement</li> </ul> Links <a href="https://twitter.com/#!/yerhot">John’s Twitter</a> <a href="https://twitter.com/#!/tashadrew">Tasha’s Twitter</a> <a href="https://twitter.com/#!/a_minion">James’ Twitter</a> <a href="https://twitter.com/#!/mage2k">Erik’s Twitter</a> <a href="https://twitter.com/#!/adamholt">Adam’s Twitter</a> <a href="http://railsbridge.org/en">RailsBridge</a> <a href="http://newrelic.com/">New Relic</a> <a href="http://ruby.mn/">Ruby Users of Minnesota</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/70/SupportcloudOutLoud.mp3?1333146994 Fri, 30 Mar 2012 22:36:35 +0000 no S02E10: Miso and Padrino Engine Yard S02E10: Miso and Padrino Our very own Danish Khan interviews Miso’s Josh Hull. <ul> <li>0:00 All about Josh</li> <li>4:20 Miso’s show and tell</li> <li>10:00 The Renee framework</li> <li>18:00 Test frameworks and Ruby</li> <li>19:00 CommonTest</li> <li>24:00 Padrino vs Rails 3</li> </ul> Links About Josh <a href="https://twitter.com/#!/joshbuddy">Twitter</a> <a href="https://github.com/joshbuddy">Github</a> <a href="http://gomiso.com/">Miso</a> <a href="http://www.padrinorb.com/">Padrino</a> <a href="https://github.com/bazaarlabs/common_test">CommonTest</a> <a href="https://github.com/tmm1/em-spec">em-spec</a> <a href="http://reneerb.com/">Renee</a> <a href="http://burlingtonruby.com/">Burlington Ruby Conference</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/68/josh_hull_podcast.mp3?1332881062 Wed, 21 Mar 2012 18:16:45 +0000 no S02E09: Girl Develop It Engine Yard S02E09: Girl Develop It Elizabeth Naramore interviews Jen Myers, the founder of Cincinnati’s Girl Develop It chapter about being both a designer and a developer, teaching programming to beginners. <ul> <li>0:00 All about Jen Myers</li> <li>0:55 About Girl Develop It</li> <li>6:00 Advice for designers and developers</li> <li>9:10 What the future holds for women in tech</li> <li>12:50 Looking forward</li> <li>17:30 Getting involved with Girl Develop It</li> </ul> Links <a href="https://twitter.com/#!/antiheroine">Twitter</a> <a href="http://jenmyers.net">Website</a> <a href="http://girldevelopit.com/">Girl Develop It</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/65/jen_myers_chicks_that_rip.mp3?1332883208 Fri, 09 Mar 2012 18:15:45 +0000 no S02E08: Design at Twilio Engine Yard S02E08: Design at Twilio Engine Yard’s Ines Sombra interviews Twilio designer Nina Mehta about inspiration, working with HCI and the changing landscape of tech journalism. <ul> <li>0:00 All about Nina</li> <li>1:00 HCI and Journalism</li> <li>2:00 The Twilio Mission</li> <li>4:00 Working with HCI and why it’s important</li> <li>8:00 Nina’s influences</li> <li>9:30 Personal projects</li> <li>11:00 Challenges in design and HCI</li> <li>13:30 HCI and Design expanding to different industries</li> <li>15:00 Tips for budding designers</li> <li>18:00 The current state of tech journalism</li> </ul> Links About Nina Mehta <a href="https://twitter.com/#!/ninamehta">Twitter</a> <a href="http://ninamehta.com/">Website</a> Mentioned content <a href="http://www.twilio.com/">Twilio</a> <a href="http://instagram.com/">Instagram</a> <a href="http://soundcloud.com/">Soundcloud</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/64/nina_mehta.mp3?1332883345 Mon, 05 Mar 2012 22:54:49 +0000 no S02E04: Hotel Tonight Engine Yard S02E04: Hotel Tonight Chris Tosswill talks to Hotel Tonight CTO Chris Bailey about <ul> <li>0:15 All about Hotel Tonight</li> <li>3:30 Testing and feedback at HT</li> <li>4:50 HTML5 vs. Native</li> <li>8:00 HT’s Rails stack (open sourcing to come!)</li> <li>10:15 Backing up your data with Rails</li> <li>11:15 HT is hiring!</li> <li>13:00 Using Scala and Clojure</li> <li>13:30 Coffeescript</li> <li>15:00 Rails and the asset pipeline</li> <li>16:20: Interfacing with hotels for rates</li> </ul> Links About Chris Bailey <a href="https://twitter.com/chrisrbailey">Twitter</a> <a href="http://hoteltonight.com/">Website</a> <a href="https://github.com/hoteltonight">Github</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/60/Chris_Bailey.mp3?1332885305 Fri, 27 Jan 2012 17:39:23 +0000 no S02E03: Vagrant, Kiip and the Engine Yard OSS Grant Engine Yard S02E03: Vagrant, Kiip and the Engine Yard OSS Grant Dr. Nic Williams talks to Mitchell Hashimoto about Vagrant. <ul> <li>0:20 All about Mitchell</li> <li>3:45 The OSS grant: Vagrant</li> <li>6:00 How Vagrant works</li> <li>7:15 Networking options for Vagrant</li> <li>8:45 Who uses Vagrant?</li> <li>12:00 When should you use Vagrant?</li> <li>12:45 Fog and Vagrant</li> <li>18:25 Kiip</li> </ul> Links About Mitchell Hashimoto <a href="https://twitter.com/mitchellh">Twitter</a> <a href="http://mitchellhashimoto.com/">Website</a> <a href="https://github.com/mitchellh">Github</a> <a href="http://vimeo.com/9976342">Vagrant</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/59/Mitchell_Hashimoto.mp3?1332885487 Fri, 20 Jan 2012 04:28:47 +0000 no S02E02: Jonan Scheffler Engine Yard S02E02: Jonan Scheffler Our very own Michael Brodhead interviews Jonan Scheffler of G5 in Oregon, the creator of the walking desk. <ul> <li>0:00 All about Jonan</li> <li>8:15 Jonan’s development process at G5</li> <li>11:00 TextMate vs. Vim</li> <li>12:45 Working from home vs. working at work</li> <li>13:50 The origins of the walking desk</li> <li>18:00 How the walking desk works</li> <li>28:00 How to make your own walking desk</li> </ul> Links About Jonan Scheffler <a href="https://twitter.com/#!/1337807">Twitter</a> <a href="http://www.1337807.com/">Website</a> <a href="https://github.com/1337807">Github</a> <a href="http://www.g5platform.com/">G5</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/58/Jonan_Scheffler.mp3?1326477318 Fri, 13 Jan 2012 17:47:49 +0000 no S02E01: Thomas Shafer Engine Yard S02E01: Thomas Shafer Danish Khan interviews Thomas Shafer, a developer at change.org <ul> <li>0:00 All about Thomas</li> <li>0:30 The technology stack at change.org</li> <li>1:40 Migrating to Rails 3.0</li> <li>2:30 How they widgetized the Rails view</li> <li>6:45 How they redesigned the site in 3 weeks on the user side</li> <li>7:50 Split testing frameworks</li> <li>9:40 Testing code path changes</li> <li>12:30 What change.org does</li> </ul> Links About Thomas Shafer <a href="http://www.change.org/members/thomas">Change.org profile</a> <a href="http://www.change.org/">Change.org official website</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/57/Thomas_Shafer_Change_org.mp3?1325876475 Fri, 06 Jan 2012 18:42:02 +0000 no S01E50: Erica Kwan Engine Yard S01E50: Erica Kwan <ul> <li>0:00 About about Erica Kwan</li> <li>1:00 All about Square</li> <li>3:15 Watching and playing videogames</li> <li>4:30 Getting into Ruby</li> <li>7:30 Erica’s development process: pairing and releasing</li> <li>9:30 Ruby on Windows</li> <li>11:40 Women in Ruby</li> <li>13:14 “Don’t use development tools as side projects”</li> <li>14:50 The Checklist Manifesto and its takeaways</li> <li>16:20 Post-mortems</li> <li>18:25 Testing for iOS and Android development</li> </ul> Links About Erica Kwan <a href="http://twitter.com/#!/pui_ling">Twitter:</a> <a href="https://github.com/pui">Github:</a> <a href="http://www.dumb-bunny.com">Blog:</a> <a href="https://squareup.com">Square</a> RubyConf 2011 <a href="http://confreaks.net/videos/649-gogaruco2011-failing-fast-stuff-we-should-have-done-better-at-square">1. Erica Kwan’s presentation – Failing Fast: Stuff We Should have Done Better at Square</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/53/50S01E50_EricaKwan.mp3?1323990897 Mon, 12 Dec 2011 21:25:12 +0000 no S01E49: Chicks That Rip: Elizabeth Naramore Engine Yard S01E49: Chicks That Rip: Elizabeth Naramore In this very special podcast, Paul Reinheimer interviews Engine Yard and Orchestra’s very own new PHP Community Manager, Elizabeth Naramore. <ul> <li>0:00 How Elizabeth got into PHP</li> <li>3:00 How she got involved into the community</li> <li>5:00 What she’s doing and how she’s interacting in the PHP community now</li> <li>5:20 Mini/local PHP communities</li> <li>6:20 Why the community is vital to the success of a project, especially open source</li> <li>9:00 Advice for someone who wants to join the community</li> <li>12:00 PHP and women</li> <li>13:35 Mentorship and partnership programs</li> <li>15:52 Advice for communities</li> </ul> Links About Elizabeth Naramore <a href="https://twitter.com/#!/ElizabethN">Twitter:</a> <a href="http://www.naramore.net/blog">Blog.</a> <a href="http://www.phpwomen.org/">phpwomen</a> <a href="http://oink-pug.org/">oink-pug</a> <a href="http://phpcommunity.org/">PHP Community</a> <a href="http://framework.zend.com/">Zend Framework</a> <a href="http://www.symfony-project.org/">symfony</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/51/49S01E49_ElizabethNaramore.mp3?1322854960 Fri, 02 Dec 2011 19:42:40 +0000 no S01E48: Xavier Shay Engine Yard S01E48: Xavier Shay <ul> <li>0:00 About about Xavier Shay</li> <li>0:38 Xavier’s introduction to open source</li> <li>1:19 What is DataMapper? What are the goals of DataMapper?</li> <li>2:52 Xavier’s work on the analytics team at Square</li> <li>3:55 Technologies Square uses: Ruby, JVM, Cube, D3</li> <li>4:50 Impressions of and use for various JVMs: Rubinius, MRI, JRuby</li> <li>6:10 Xavier’s interest in speeding up Rails startup time</li> <li>8:20 Protecting yourself from data integrity problems and the importance of using foreign keys</li> <li>12:35 Considering tradeoffs of various databases</li> <li>14:41 Xavier’s favorite talks from RubyConf 2011</li> </ul> Links About Xavier Shay <a href="http://twitter.com/#!/xshay">Twitter:</a> <a href="https://github.com/xaviershay">Github:</a> <a href="http://datamapper.org/">DataMapper</a> <a href="https://squareup.com">Square</a> <a href="http://square.github.com/cube/">Cube</a> <a href="http://mbostock.github.com/d3/">d3.js</a> <a href="http://rubini.us/">Rubinius</a> <a href="http://www.ruby-lang.org/en/">MRI</a> <a href="http://jruby.org/">JRuby</a> <a href="http://rhnh.net/2011/05/28/speeding-up-rails-startup-time">Xavier Shay’s Blog Post “Speeding up Rails Startup Time”</a> <a href="http://www.dbisyourfriend.com/">Xavier’s Workshop “Database is your friend”</a> RubyConf 2011 <a href="http://confreaks.net/videos/659-rubyconf2011-why-you-don-t-get-mock-objects">1. Greg Moeck’s “Why You Don’t Get Mock Objects” presentation</a> <a href="http://confreaks.net/videos/691-rubyconf2011-nikita-the-ruby-secret-agent">2. Brian Ford’s presentation on improving tooling for Ruby “Nikita: The Ruby Secret Agent”</a> <a href="http://rubyconf.org/presentations/18">3. Dr. Nic’s “Threading versus Evented”</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/49/48S01E48_XavierShay.mp3?1321647566 Fri, 18 Nov 2011 20:19:26 +0000 no S01E47: Wes Beary Engine Yard S01E47: Wes Beary <ul> <li>0:00 Who is Wes?</li> <li>0:50 The humble beginnings of fog, the Ruby cloud services library</li> <li>3:25 The current goal of fog and the state of the project</li> <li>4:33 Ensuring a base level of fog functionality while catering to different cloud systems</li> <li>6:03 Finally, fog 1.0!</li> <li>7:19 Working through old assumptions leading up to fog 1.0</li> <li>8:05 fog adoption and contributors</li> <li>11:48 Additions and changes to fog coming soon</li> <li>15:43 Good places to begin contributing to fog</li> <li>17:30 fog, mocks and testing</li> <li>19:47 Parallels between game design and usable software design</li> <li>21:45 Wes’ ISRU asteroid mining game</li> </ul> Links Wes on <a href="http://twitter.com/#!/geemus">Twitter</a> and <a href="https://github.com/geemus">GitHub</a> fog <a href="http://fog.io/">website</a> fog <a href="https://github.com/fog/fog">on GitHub</a> <a href="http://en.wikipedia.org/wiki/In-situ_resource_utilization" title="ISRU">In-Situ Resource Utilization</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/48/47S01E47_Wes%20Beary.mp3?1321039609 Fri, 11 Nov 2011 19:26:49 +0000 no S01E46: Christopher Bertels Engine Yard S01E46: Christopher Bertels <ul> <li>0:30 Introduction: Chris and Fancy</li> <li>1:27 When to use Fancy</li> <li>2:40 Fancy and Ruby similarities and differences</li> <li>3:50 Chris’ favorite thing about Fancy</li> <li>5:20 Why Fancy is built on top of the Rubinius VM</li> <li>7:44 Other language implementors building on top of the Rubinius VM</li> <li>8:31 Contributing to Fancy</li> <li>9:35 The contribution model for Fancy; areas where contribution is welcomed</li> <li>10:50 Getting started with Fancy</li> <li>11:46 Chris’ interest in distributed computing</li> <li>13:00 Working at Twitter: what Chris does, the technologies uses at Twitter</li> <li>14:36 Batman or Spiderman?</li> <li>14:55 If you were guaranteed not to fail…</li> </ul> Links <ul> <li>Christopher Bertels on <a href="https://github.com/bakkdoor">github</a> on <a href="http://twitter.com/#!/bakkdoor/">Twitter</a></li> </ul> <ul> <li>Fancy <a href="http://www.fancy-lang.org/">Fancy website</a> <a href="https://github.com/bakkdoor/fancy">Fancy on github</a></li> </ul> <ul> <li><a href="https://github.com/vito">Alex Suraci on github</a></li> </ul> <ul> <li><a href="https://github.com/vito/atomy">Atomy project on github</a></li> </ul> <ul> <li><a href="http://clojure.org/">Clojure</a></li> </ul> <ul> <li><a href="https://github.com/nathanmarz/cascalog">Cascalog</a></li> </ul> <ul> <li><a href="http://en.wikipedia.org/wiki/Distributed_computing">Distributed computing</a></li> </ul> <ul> <li><a href="http://www.python.org/">Python</a></li> </ul> <ul> <li><a href="http://rubini.us/">Rubinius</a></li> </ul> <ul> <li><a href="http://rubini.us/2011/08/03/rbxday-in-real-life/" title="#rbxday">Rubinius Hack Day</a></li> </ul> <ul> <li><a href="https://github.com/nathanmarz/storm">Storm – distributed and fault tolerant realtime computation</a></li> </ul> <ul> <li><a href="https://dev.twitter.com/blog/introducing-twitter-web-analytics">Twitter Analytics</a></li> </ul> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/47/46S01E46_ChristopherBertels.mp3?1320425634 Fri, 04 Nov 2011 16:53:55 +0000 no S01E45: Zach Tellman Engine Yard S01E45: Zach Tellman <ul> <li>0:00 Introduction: runa and Zach</li> <li>2:00 How runa leverages Clojure</li> <li>3:41 What led Zach to Clojure</li> <li>5:10 Wrapping libraries with Clojure</li> <li>6:20 Clojure and Lisp</li> <li>7:27 The evolution of graphics programming “Shader Programs” GLSL</li> <li>10:30 Penumbra library</li> <li>13:40 Create wrappers for libraries</li> <li>16:15 REPL</li> <li>18:20 Tools to work with Clojure</li> <li>20:15 Phil’s starter kit</li> </ul> Zach Tellman on: <a href="http://twitter.com/#!/ztellman">Twitter</a> <a href="https://github.com/ztellman">GitHub</a> his <a href="http://ideolalia.com/">blog</a> Links <ul> <li><a href="http://www.runa.com/">runa</a></li> <li><a href="http://clojure.org/">Clojure</a></li> <li><a href="http://www.3vr.com/">3VR</a></li> <li><a href="http://en.wikipedia.org/wiki/C_Sharp_(programming_language)">C#</a></li> <li><a href="http://caml.inria.fr/ocaml/">OCaml</a></li> <li><a href="http://twitter.com/#!/tomfaulhaber">Tom Fallhaber on Twitter</a></li> <li><a href="http://en.wikipedia.org/wiki/GLSL">GLSL</a></li> <li><a href="https://github.com/ztellman/penumbra">Penumbra</a></li> <li><a href="https://github.com/clojure/clojurescript">ClojureScript</a></li> <li><a href="http://en.wikipedia.org/wiki/WebGL">WebGL</a></li> <li><a href="https://github.com/technomancy">Phil Hagelberg “technomancy” on GitHub</a></li> </ul> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/46/S01E45_ZachTellman.mp3?1319823699 Fri, 28 Oct 2011 17:41:39 +0000 no S01E44: Vince Baskerville Engine Yard S01E44: Vince Baskerville <ul> <li>0:30 – About TripLingo</li> <li>1:55 – Vince’s role at TripLingo</li> <li>3:28 – Metrics used in UX</li> <li>4:49 – A/B testing for the TripLingo mobile platform</li> <li>6:30 – Finding a balance between design and code</li> <li>7:32 – Business-agile: One step ahead, no more, no less</li> <li>9:21 – Life before TripLingo</li> <li>10:30 – UX for the web versus mobile UX</li> <li>11:37 – Why Vince loves mobile</li> <li>4:18 – Resources for those interested in UX</li> <li>17:05 – Understanding the user experience</li> </ul> Links <ul> <li><a href="http://www.triplingo.com">TripLingo</a></li> <li><a href="http://en.wikipedia.org/wiki/Agile_software_development">Agile Software Development</a></li> <li><a href="http://www.crazyegg.com/">Crazy Egg</a></li> <li><a href="http://www.kissmetrics.com/">Kiss Metrics</a></li> <li><a href="http://www.kissinsights.com/">Kiss Insights</a></li> <li><a href="http://www.morehouse.edu/">Morehouse College</a></li> <li><a href="http://www.smashingmagazine.com/">Smashing Magazine</a></li> <li><a href="http://www.amazon.com/Dont-Make-Me-Think-Usability/dp/0321344758/ref=pd_bxgy_b_img_b">Steven Krug, Don’t make me think</a></li> <li><a href="http://www.amazon.com/Rocket-Surgery-Made-Easy-Yourself/dp/0321657292">Steven Krug, Rocket surgery made simple</a></li> </ul> More about Vince Baskerville <ul> <li><a href="http://twitter.com/#!/whoisvince">Twitter</a></li> <li><a href="http://www.linkedin.com/in/whoisvince">Linkedin</a></li> </ul> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/45/S01E44_VinceBaskerville.mp3?1318636341 Fri, 14 Oct 2011 23:52:22 +0000 no S01E43: Chris Nelson Engine Yard S01E43: Chris Nelson <ul> <li>2:00 How MVC is shifting from server side to client side</li> <li>2:53 Backbone.js and CoffeeScript revolutionizing front end development</li> <li>4:35 Seamlessly structuring client side code with Backbone.js</li> <li>6:18 The origin of Backbone.js and why it fits naturally with Rails</li> <li>8:34 How CoffeeScript changed Chris’ approach to front end development</li> <li>9:00 CoffeeScript as a better syntax for JavaScript</li> <li>10:00 Where to begin? CoffeeScript for n00bs</li> <li>11:00 Jasmine: BDD for JavaScript</li> <li>11:42 Why Jasmine + CoffeeScript = crazy delicious</li> <li>12:30 The Beautiful Front End Code training course</li> <li>13:37 How Steve Jobs and the Apple IIe shaped Chris’ introduction to programming</li> <li>19:15 Chris’ interest in node.js</li> <li>20:20 Rails 3.1 asset pipeline for managing dependencies in JavaScript</li> <li>20:40 The npm_assets gem to add npm modules to your Rails asset path</li> </ul> Links <ul> <li>Training: <a href="http://training.gaslightsoftware.com/">Beautiful Front End Code with Backbone and CoffeeScript</a>, November 7-8, 2011 in San Francisco, CA</li> <li><a href="http://documentcloud.github.com/backbone/">Backbone.js</a></li> <li><a href="https://github.com/jashkenas">Jeremy Ashkenas of Backbone.js on GitHub</a></li> <li><a href="http://jashkenas.github.com/coffee-script/">CoffeeScript</a></li> <li><a href="http://pivotal.github.com/jasmine/">Jasmine</a></li> <li><a href="https://github.com/nkallen/screw-unit">Screw Unit</a></li> <li><a href="http://rubyconf.org/">RubyConf 2011</a></li> <li><a href="http://nodejs.org/">node.js</a></li> <li><a href="http://guides.rubyonrails.org/asset_pipeline.html">Rails 3.1 asset pipeline Rails Guide</a></li> <li><a href="https://github.com/gaslight/npm_assets">npm_assets gem</a></li> </ul> More about Chris Nelson: <ul> <li><a href="http://twitter.com/#!/superchris">Twitter</a></li> <li><a href="https://github.com/superchris">GitHub</a></li> <li><a href="http://mysterycoder.blogspot.com/">MysteryCoder blog</a></li> <li><a href="http://gaslightsoftware.com/">Gaslight Software</a></li> </ul> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/44/43S01E43_ChrisNelson.mp3?1318017593 Fri, 07 Oct 2011 19:59:53 +0000 no S01E42: Konstantin Haase Engine Yard S01E42: Konstantin Haase Konstantin Haase discusses his involvement with Sinatra and Rubinius. <ul> <li>0:00 Intro, the momentum of Ruby in Europe</li> <li>3:15 Opportunities to improve Ruby</li> <li>4:30 BitHug project</li> <li>4:55 Contributions to Sinatra</li> <li>6:40 Involvement with Rubinius</li> <li>10:50 Impression of the US</li> <li>11:41 RubyConf 2011 “Message in a Bottle” talk</li> <li>12:29 Portland love</li> <li>13:08 Batman or Spiderman?</li> </ul> Links: Konstantin Haase on <a href="http://twitter.com/#!/konstantinhaase">Twitter</a> and <a href="https://github.com/rkh">GitHub</a> <a href="https://github.com/rkh/bithug">BitHug</a> <a href="http://www.sinatrarb.com/">Sinatra</a> <a href="http://rubini.us/">Rubinius</a> <a href="http://gogaruco.com/">Golden Gate Ruby Conference (GoGaRuCo) 2011</a> <a href="http://rockymtnruby.com/">Rocky Mountain Ruby Conference 2011</a> <a href="http://rubyconf.org/">RubyConf 2011</a> <a href="http://en.wikipedia.org/wiki/Food_cart#Portland.27s_food_carts">Portland food carts</a> <a href="http://www.fantasy-illustration.com/illustration/batman_art.jpg">Batman</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/43/KonstantinHaase.mp3?1317415818 Fri, 30 Sep 2011 19:28:48 +0000 no S01E41: Nathan Verrill Engine Yard S01E41: Nathan Verrill Nathan Verril discusses using Rails as the backend for the NY Public Library centennial blended reality game. <ul> <li>0:00 Introductions</li> <li>1:20 The concept of “blended reality” games</li> <li>5:40 The New York Public Library “Find the Future” blended reality game</li> <li>7:29 The technology behind the game</li> <li>8:36 Why Rails was used for the back end of the game</li> <li>11:43 Rails control over the implementation of the user interface</li> <li>16:13 The “Heart Chase” for the American Heart Association project</li> <li>19:45 Using the Engine Yard Cloud platform</li> <li>21:46 Final thoughts</li> </ul> Links: <a href="http://natronbaxter.com/">Natron Baxter Applied Gaming</a> <a href="http://game.nypl.org/#home">Find the Future NYPL</a> <a href="http://www.heartchase.org">Heart Chase</a> <a href="http://www.heartchase.org/about">Heart Chase Video</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/42/NathanVerril.mp3?1317421465 Fri, 23 Sep 2011 00:18:44 +0000 no S01E40: Gary Bernhardt Engine Yard S01E40: Gary Bernhardt Gary Bernhardt of Destroy All Software speaks about his passion for test driven development. <ul> <li>0:00 Introductions</li> <li>5:05 Rewriting unit tests</li> <li>3:04 Destroy All Software screencasts and the focus on testing</li> <li>7:30 Frameworks for Rails testing</li> <li>10:44 The Test Driven Development (TDD) cycle in Rails</li> <li>12:38 The ‘London School’ vs. the ‘Detroit School’ of Test Driven Development</li> <li>14:24 Unix and Gary’s saying “half-assed is good enough if it’s the right half of the ass”</li> <li>17:13 How Destroy All Software screencasts fit into the screencast ecosystem</li> <li>18:27 Gary’s passion for the software building cycle, Object-Oriented Design (OOD), Test Driven Development</li> <li>20:49 Resources and techniques for learning Test Driven Development</li> <li>22:39 Learning via experienced peers and user groups</li> </ul> Links: <ul> <li>Gary Bernhardt on <a href="https://github.com/garybernhardt">GitHub</a> and <a href="http://twitter.com/#!/garybernhardt">on Twitter</a></li> <li><a href="http://cascadiaruby.com/">Cascadia Ruby Conf</a></li> <li><a href="http://www.meetup.com/ClevelandRuby/">Cleveland Ruby Brigade</a></li> <li><a href="https://www.destroyallsoftware.com/screencasts">Destroy All Software: Screencasts for serious developers</a></li> <li><a href="https://www.destroyallsoftware.com/screencasts/catalog/extracting-domain-objects">Extracting Domain Objects screencast</a></li> <li><a href="https://github.com/thoughtbot/factory_girl">Factory Girl</a></li> <li><a href="http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627">Growing Object-Oriented Software Guided by Tests</a></li> <li><a href="http://rspec.info/">RSpec</a></li> <li><a href="http://www.seattlerb.org/" title="seattle.rb">Seattle Ruby Brigade</a></li> <li><a href="http://confreaks.net/videos/615-cascadiaruby2011-the-unix-chainsaw">The Unix Chainsaw – Gary’s Cascadia Ruby Conf presentation</a></li> </ul> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/41/S01E40.mp3?1316130276 Thu, 15 Sep 2011 23:44:36 +0000 no S01E39: Stephen Robinson Engine Yard S01E39: Stephen Robinson Stephen Robinson of Avity and Eye & Mind Blog talks about entrepreneurship and Rails development. <ul> <li>Moving from a developer/academic background to an entrepreneurial role</li> <li>Entrepreneurship vs. Development</li> <li>In-house vs. geographically distributed development teams</li> <li>Starting the Eye and Mind blog and goal</li> <li>Mobile development on the rise</li> <li>When to use Ruby on Rails vs. other languages</li> <li>Getting in touch with Ruby on Rails</li> <li>Training staff</li> </ul> Links: <ul> <li><a href="http://vimeo.com/19687547">A Brief History of Steve video</a></li> <li><a href="http://www.eyeandmind.com">Eye and Mind blog</a></li> <li><a href="http://www.dreamstaffing.com/">Dream Staffing</a></li> <li><a href="http://www.avity.com/">Avity</a></li> <li><a href="http://www.appcelerator.com/">Appcelerator</a></li> <li><a href="http://www.engineyard.com/blog/2011/engine-yard-and-orchestra-join-forces/">Engine Yard and PHP announcement</a></li> <li><a href="http://www.amazon.com/Goal-Process-Ongoing-Improvement/dp/0884270610">The Goal: A Process of Ongoing Improvement</a> (book)</li> </ul> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/40/SE01E39.mp3?1315524722 Thu, 08 Sep 2011 23:32:02 +0000 no S01E38: Santiago Pastorino (English Version) Engine Yard S01E38: Santiago Pastorino (English Version) Santiago Pastorino of WyeWorks talks about Rails and the Ruby community in Uruguay. <ul> <li>00:20: Introduction</li> <li>00:45: <a href="http://www.wyeworks.com/">WyeWorks</a></li> <li>01:40: How Santiago started contributing to Rails</li> <li>03:52: What work Santiago did for the Rails 3 release</li> <li>05:36: Making the switch from Java to Ruby</li> <li>07:20: Metaprogramming</li> <li>09:32: Plans for <a href="http://rubyconfuruguay.org/">RubyConf Uruguay 2011</a></li> <li>10:50: Why should people attend RubyConf Uruguay 2011</li> </ul> <a href="https://github.com/spastorino">Santiago Pastorino on GitHub</a> <a href="http://twitter.com/#!/spastorino">Santiago Pastorino on Twitter</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/39/cloud_out_loud_santiago_english_version.mp3?1314924029 Fri, 02 Sep 2011 00:40:29 +0000 no S01E38: Santiago Pastorino (Spanish Version) Engine Yard S01E38: Santiago Pastorino (Spanish Version) Santiago Pastorino de WyeWorks nos habla sobre su participacion en Rails Core y la comunidad de Ruby en Uruguay. " Santiago Pastorino on GitHub":https://github.com/spastorino <a href="http://twitter.com/#!/spastorino">Santiago Pastorino on Twitter</a> <a href="http://www.wyeworks.com/">WyeWorks</a> <a href="http://rubyconfuruguay.org/">RubyConf Uruguay 2011</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/38/cloud_out_loud_santiago_spanish_version.mp3?1314923436 Fri, 02 Sep 2011 00:30:36 +0000 no S01E37: Hal Helms Engine Yard S01E37: Hal Helms Hal Helms discusses his Cold Fusion background and his interest in Ruby and Rails. <ul> <li>0:10 Introduction</li> <li>0:55 Finding ColdFusion</li> <li>03:05 Finding Ruby on Rails</li> <li>05:10 Taking on Ruby on Rails as a ColdFusion programmer</li> <li>07:40 Modern programming practices and changes in agility and velocity</li> <li>10:33 Blogging about Ruby on Rails</li> <li>12:00 Using agile in a consulting practice</li> <li>13:55 Outreach to the ColdFusion community</li> </ul> Links: <a href="http://halhelms.com/">Hal Helms Inc.</a> <a href="http://ruby.railstutorial.org/">Ruby on Rails Tutorial by Michael Hartl</a> <a href="www.ajax.org">Ajax</a> <a href="http://www.adobe.com/products/coldfusion-family.html">ColdFusion</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/37/cloud_out_loud_hal_helms.mp3?1314334357 Fri, 26 Aug 2011 04:52:38 +0000 no S01E36: Darcy Laycock Engine Yard S01E36: Darcy Laycock This week on Cloud Out Loud Darcy Laycock discusses API Smith and RailsRumble. <ul> <li>00:10 Introduction</li> <li>01:35 Balancing school, work, and volunteering</li> <li>02:15 Current work at The Frontier Group</li> <li>03:13 Coding time spent pairing vs. solo</li> <li>04:32 Why Coffeescript? Why Javascript?</li> <li>08:00 Ruby as Darcy’s first language</li> <li>9:10 Languages used at University</li> <li>11:40 RailsRumble</li> <li>16:15 Genesis of API Smith library</li> <li>20:40 Pebble</li> <li>25:38 Smeg-Head</li> </ul> Links: <a href="http://sutto.net/">Darcy Laycock</a> <a href="https://github.com/filtersquad/api_smith">API Smith</a> <a href="http://www.engineyard.com/blog/2011/building-structured-api-clients-with-api-smith/">Building Structured API Clients with API Smith</a> <a href="http://www.thefrontiergroup.com.au/">The Frontier Group</a> <a href="http://railsrumble.com/">Rails Rumble 2010</a> <a href="http://www.ruby-lang.org/en/news/2010/03/26/ruby-summer-of-code-2010/">Ruby Summer of Code 2010</a> <a href="http://youthtree.org.au/">Youth Tree</a> <a href="https://github.com/Sutto/Pebble">Pebble</a> <a href="https://github.com/socketstream/socketstream">Socketstream</a> <a href="https://github.com/thefrontiergroup/smeg-head">Smeg-Head</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/36/cloud_out_loud_darcy_laycock.mp3?1313728273 Fri, 19 Aug 2011 04:31:13 +0000 no S01E35: Luis Lavena Engine Yard S01E35: Luis Lavena Luis Lavena discusses Ruby on Windows and Ruby Installer. <ul> <li>00:05 Introduction</li> <li>01:29 Ruby Installer for Windows</li> <li>03:14 Difference Between Running on Windows vs Mac</li> <li>05:22 Why Ruby for Windows?</li> <li>07:42 What Can The Community Do To Make Ruby For Windows Better?</li> <li>09:10 Using Ruby for Windows Without Windows</li> <li>12:22 Why Ruby?</li> <li>15:16 Windows for Ruby in the Enterprise Community</li> <li>16:58 Involvement in RubyGems and RubyCore</li> <li>20:55 Events Luis is Attending/ Ways to Reach Luis</li> </ul> Links: <a href="http://rubyinstaller.org/">Ruby Installer For Windows</a> <a href="http://www.area17.com/">Area17</a> <a href="http://en.oreilly.com/rails2011/public/schedule/speaker/87070">RailsConf 2011 Talk</a> <a href="http://rubygems.org/">RubyGems</a> <a href="http://rubyconfargentina.org/en">RubyConf Argentina</a> <a href="http://groups.google.com/group/rubyinstaller">RubyInstaller Google Group</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/35/cloud_out_loud_luis_lavena.mp3?1313126160 Fri, 12 Aug 2011 05:16:01 +0000 no Node.js, Rails & ESPN (feat. Cody Swann) Engine Yard Node.js, Rails & ESPN (feat. Cody Swann) Cody Swann discusses Ruby on Rails 3.1, Node.js and the Rails project he worked on for ESPN. <ul> <li>00:10 Introduction</li> <li>01:25 How Cody’s Experience at ESPN Shaped the Culture at Gunner Technology</li> <li>03:10 Ruby on Rails taking root in large corporations</li> <li>07:40 How Rails was received at ESPN</li> <li>11:10 Scaling with Rails</li> <li>14:15 Nginx extension</li> <li>16:10 Cody’s recent projects</li> <li>19:15 Projects in Node.js</li> <li>21:10 Comparing Node.js to Rails</li> <li>23:00 CoffeeScript</li> <li>25:00 Rails 3.1 release</li> </ul> Links: <a href="http://gunnertech.com/">Gunner Technology</a> <a href="http://www.mysql.com/">MySQL</a> <a href="http://nodejs.org/">node.js</a> <a href="http://jashkenas.github.com/coffee-script/">CoffeeScript</a> <a href="http://weblog.rubyonrails.org/2011/5/22/rails-3-1-release-candidate">Rails 3.1 Release</a> <a href="https://www.djangoproject.com/">Django</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/34/cloud_out_loud_cody_swann.mp3?1345496070 Fri, 05 Aug 2011 00:52:35 +0000 no S01E33: Arthur Chiu & Nathan Esquenazi Engine Yard S01E33: Arthur Chiu & Nathan Esquenazi Arthur Chiu and Nathan Esquenazi of the Padrino core team discuss Padrino, Sinatra and Rails. <ul> <li>0:01 Introduction</li> <li>01:40 What is Padrino?</li> <li>04:30 Why Padrino?</li> <li>11:25 How Arthur uses Padrino at GaiKai</li> <li>12:00 How Nathan uses Padrino at Miso</li> <li>16:33 Selenium tests on the iPhone simulator</li> <li>18:51 How Padrino compares to Sinatra</li> <li>21:30 Using Padrino and Sinatra</li> <li>22:40 Padrino 1.0 release</li> <li>23:40 Padrino recipes</li> <li>26:25 Upcoming speaking engagements</li> </ul> Links: <a href="http://www.padrinorb.com/">Padrino</a> <a href="http://www.gaikai.com/">GaiKai</a> <a href="http://gomiso.com/">Miso</a> <a href="http://www.sinatrarb.com/">Sinatra</a> <a href="http://datamapper.org/">DataMapper</a> <a href="http://mongomapper.com/">MongoMapper</a> <a href="http://cukes.info/">Cucumber</a> <a href="http://seleniumhq.org/">Selenium</a> <a href="https://github.com/kyledrake/sinatra-synchrony">Sinatra Synchrony</a> <a href="https://github.com/therabidbanana/padrino-recipes">Padrino Recipes</a> <a href="http://gogaruco.com/">GoGaRuCo 2011</a> <a href="http://rubywebconf.org/">Ruby Web Conference 2011</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/33/cloud_out_loud_padrino.mp3?1311928007 Fri, 29 Jul 2011 08:26:48 +0000 no S01E32: Ian Dees Engine Yard S01E32: Ian Dees Ian Dees discusses the Using JRuby book and JRubyConf. <ul> <li>0:00 Introduction</li> <li>0:55 How Ian got involved with Ruby</li> <li>2:15 Authoring books</li> <li>2:55 The “Using JRuby” book</li> <li>9:55 The JRubyConf conference series</li> <li>10:35 Ian’s presentation at JRubyConf 2011</li> <li>11:45 JRuby as a vehicle to explore computer science</li> <li>18:40 The future of JRuby</li> <li>19:50 Warbler</li> <li>21:15 Why JRuby?</li> </ul> Links: <a href="http://pragprog.com/book/jruby/using-jruby">Using JRuby Bringing Ruby to Java</a> <a href="http://www.tek.com/">Tektronix</a> <a href="http://olabini.com/">Ola Bini</a> <a href="http://rubygems.org/gems/bitescript">Bitescript</a> <a href="http://www.mirah.org/">Mirah</a> <a href="http://www.scala-lang.org/">Scala</a> <a href="http://www.oscon.com/oscon2011">OSCON 2011</a> <a href="http://opensourcebridge.org/">Open Source Bridge 2011</a> <a href="http://vimeo.com/groups/87639/videos/16517560">Keavy McMinn’s Must Try Harder presentation from JRubyConf 2010.</a> <a href="http://jrubyconf.com/">JRubyConf 2011</a> <a href="http://jrubyconf.com/#talks">JRubyConf Talks</a> <a href="http://redcareditor.com/">Redcar</a> <a href="http://kenai.com/projects/warbler/pages/Home">Warbler</a> <a href="http://torquebox.org/">TorqueBox</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/32/Ian_Dees.mp3?1311286726 Thu, 21 Jul 2011 22:18:47 +0000 no S01E31: Shane Becker Engine Yard S01E31: Shane Becker Shane Becker discusses Rubinius and the inaugural Cascadia Ruby Conf. <ul> <li>00:15 Introduction</li> <li>0:50 Background</li> <li>05:30 Getting Started with Ruby on Rails</li> <li>08:00 Friends and connections in Seattle</li> <li>10:00 Cascadia Ruby Conf</li> <li>17:45 Organizing regional events</li> <li>23:00 Working at Engine Yard</li> <li>29:30 Life as a remote employee</li> <li>32:45 Recent projects</li> <li>36:15 Rubinius 2.0</li> </ul> Links: <a href="https://github.com/homesteading">Homesteading</a> <a href="http://zinedistro.org/zines">ZineDistro</a> <a href="http://farmhouse.la/">Farmhouse Conf</a> <a href="http://gogaruco.com/">GoGaRuCo</a> <a href="http://www.cascadiarubyconf.com">Cascadia Ruby Conf</a> <a href="http://peepcode.com/">Peepcode</a> <a href="http://rubini.us/2011/06/07/inside-rubinius-20-preview/">Developer Preview: Rubinius 2.0</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/31/cloud_out_loud_shane_becker.mp3?1310682663 Thu, 14 Jul 2011 22:31:03 +0000 no S01E30: David Keener Engine Yard S01E30: David Keener David Keener discusses use of Ruby in the government space and the RubyNation DC conference. <ul> <li>00:00 Introduction</li> <li>00:20 Background</li> <li>00:50 General Dynamics</li> <li>01:35 Government projects leveraging Ruby on Rails</li> <li>03:30 Issues with using Ruby on Rails for Government Projects</li> <li>04:50 Section 508 Compliance</li> <li>05:20 Utilizing HTML5</li> <li>06:50 Why Ruby on Rails for Government Projects?</li> <li>08:15 Balancing Back End and Front End Work</li> <li>10:15 Rails 3.0 and 3.1</li> <li>10:45 Saas vs Scss</li> <li>11:30 Ruby Nation Conference in DC</li> <li>12:40 Advice for Conference Organizers</li> <li>14:15 Challenges of Rails Development on Windows</li> <li>16:15 Using Rails for Facebook Application Development</li> <li>17:30 Eloquent Ruby</li> <li>19:50 Git and GitFlow</li> <li>21:10 Advice for Speakers at Ruby/Tech Conferences</li> </ul> Links: <a href="http://www.gd-ais.com/">General Dynamics Advanced Information Systems</a> <a href="http://www.generaldynamics.com/">General Dynamics</a> <a href="http://www.section508.gov/">Section 508</a> <a href="http://sass-lang.com/">Saas</a> <a href="http://www.rubynation.org/">Ruby Nation</a> <a href="http://jashkenas.github.com/coffee-script/">CoffeeScript</a> <a href="http://www.rubyinside.com/a-review-of-eloquent-ruby-by-russ-olsen-it-rocks-4432.html">Eloquent Ruby Review</a> <a href="http://www.amazon.com/Eloquent-Ruby-Addison-Wesley-Professional/dp/0321584104">Buy Eloquent Ruby</a> <a href="http://git-scm.com/">Git</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/30/cloud_out_loud_david_keener.mp3?1310073129 Thu, 07 Jul 2011 21:12:09 +0000 no S01E29: Anthony Eden Engine Yard S01E29: Anthony Eden Anthony Eden discusses DNS, Ruby, and living in France. <ul> <li>00:10 Introduction</li> <li>02:00 Where Anthony has lived in the past</li> <li>04:10 Current Work at LivingSocial and DNSimple</li> <li>04:40 Understanding DNS</li> <li>08:15 DNSSEC</li> <li>11:46 NAPTR Records</li> <li>14:20 IPv6</li> <li>18:50 Favorite Open Source projects</li> <li>19:05 Active Warehouse</li> <li>20:25 JPublish</li> <li>24:03 Balancing working at LivingSocial and being an entrepreneur</li> <li>26:01 When and why Anthony came to Ruby</li> <li>28:29 Why Work at Living Social?</li> </ul> Links: <a href="http://www.livingsocial.com/">LivingSocial</a> <a href="https://dnsimple.com/">DNSimple</a> <a href="http://www.dnssec.net/">DNSSEC</a> <a href="http://www.tekelec.com/SIPReferenceGuide/NAPTR_records.asp">NAPTR Records</a> <a href="http://ipv6.com/">IPv6</a> <a href="http://activewarehouse.rubyforge.org/">Active Warehouse</a> <a href="http://code.google.com/p/jpublish/">JPublish</a> <a href="http://www.apache.org/">Apache</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/29/cloud_out_loud_anthony_eden.mp3?1309470591 Thu, 30 Jun 2011 21:49:52 +0000 no S01E28: Chris Eppstein Engine Yard S01E28: Chris Eppstein Chris Eppstein talks with us about Compass and SASS. <ul> <li>00:10 Introductions</li> <li>01:10 Current projects for Caring.com</li> <li>02:06 History of working with Ruby</li> <li>02:49 Getting involved with Sass</li> <li>05:02 Importance of Sass</li> <li>06:05 Eppstein’s RailsConf 2011 talk</li> <li>08:15 History of Compass</li> <li>11:30 Ways to contribute to Compass</li> <li>13:30 Eppstein’s contributions to Sass</li> <li>15:20 Sass vs Scss syntaxes</li> <li>20:00 Less vs Sass</li> <li>23:00 Frameworks outside of blueprint</li> <li>24:50 First steps for integrating Sass or Compass</li> <li>27:30 Mixin vs Class</li> <li>31:45 New features of Sass and Compass</li> </ul> Links: <a href="http://www.caring.com/">Caring.com</a> <a href="http://sass-lang.com/">Sass</a> <a href="http://en.oreilly.com/rails2011/public/schedule/detail/19066">RailsConf 2011 talk</a> <a href="http://compass-style.org/">Compass</a> <a href="http://compass-style.org/index/mixins/">Compass Mixins</a> <a href="http://compass-style.org/help/tutorials/contributing/">Contribute to Compass</a> <a href="http://www.blueprintcss.org/">Blueprint</a> <a href="http://nanoc.stoneship.org/">Nanoc</a> <a href="http://susy.oddbird.net/">Susy</a> <a href="http://lesscss.org/">Less</a> <a href="http://haml-lang.com/">Haml</a> <a href="http://chriseppstein.github.com/blog/2010/09/11/compass-merging-with-lemonade/">Merge of Compass and Lemonade</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/28/cloud_out_loud_chris_eppstein.mp3?1308878223 Fri, 24 Jun 2011 01:17:04 +0000 no S01E27: Matt Kern & Michael Taus Engine Yard S01E27: Matt Kern & Michael Taus Matt Kern and Michael Taus of Codebenders discuss Ruby on Ales. <ul> <li>00:10 Introduction</li> <li>01:10 Complimentary skills Mike and Matt bring to Codebenders</li> <li>03:25 Codebenders’ approach to business</li> <li>04:25 Codebenders’ approach to development</li> <li>07:20 Why Ruby on Rails?</li> <li>09:37 The Rails community in Bend, Oregon</li> <li>11:15 Ruby on Ales</li> <li>13:08 Ruby on Ales 2012</li> <li>13:25 Web on Ales</li> <li>14:21 KidsRuby (Ruby programming classes for kids)</li> </ul> Links: <ul> <li><a href="http://www.codebenders.com/">Codebenders</a></li> <li><a href="http://www.codebenders.com/people/matt-kern/">Matt Kern</a></li> <li><a href="http://www.codebenders.com/people/michael-taus/">Michael Taus</a></li> <li><a href="http://www.codebenders.com/services/#post-869">Codebenders’ Services</a></li> <li><a href="http://ruby.onales.com/">Ruby on Ales</a></li> <li><a href="http://kidsruby.com/">KidsRuby</a></li> </ul> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/27/cloud_out_loud_codebenders.mp3?1308273638 Fri, 17 Jun 2011 01:20:39 +0000 no S01E26: Fabio Akita Engine Yard S01E26: Fabio Akita Fabio Akita discusses RubyConf Brazil, Rails 3.1 and more. <ul> <li>00:10: Introduction</li> <li>01:45: How Fabio got involved in the RoR community in Brazil</li> <li>05:20: How the Ruby community grew in Brazil</li> <li>09:20: Speaking at events</li> <li>13:35: How events in Brazil differ from events in other places</li> <li>15:40: The tech Industry in Brazil</li> <li>17:35: History of RubyConf Brazil</li> <li>23:10: RubyConf Brazil, November 3 – 4, 2011</li> <li>24:15: Thoughts on Rails 3.1</li> <li>27:05: Recent work</li> <li>30:00: Fabio’s book</li> <li>33:35: English/Portuguese language barrier</li> </ul> Links: <a href="http://akitaonrails.com">Akita on Rails Blog</a> <a href="http://www.gonow.com.br/gonow/">GoNow Consulting</a> <a href="http://www.locaweb.com.br/default.html/">Locaweb</a> <a href="http://akitaonrails.com/2007/12/10/agile-web-development-with-rails-in-brazil/">Agile Development in Brazil</a> <a href="http://www.akitaonrails.com/2008/05/27/rumo-railsconf-2008/">RailsConf 2008</a> <a href="http://akitaonrails.com/2008/07/13/rails-summit-latin-america-2008/">Rails Summit Latin America 2008</a> <a href="http://akitaonrails.com/2009/07/30/rails-summit-latin-america-2009/">Rails Summit Latin America 2009</a> <a href="http://rubyconf2011.akitaonrails.com/">RubyConf Brazil 2011</a> <a href="http://www.saas.com/ta/hp.jsp/">Saas</a> <a href="http://www.akitaonrails.com/files/Rails-03.pdf/">Ruby On Rails Book Preview</a> <a href="http://gettingreal.37signals.com/">Getting Real: The Book by 37 Signals</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/26/cloud_out_loud_fabio_akita.mp3?1307671573 Fri, 10 Jun 2011 02:06:14 +0000 no S01E25: Wesley Beary (geemus) Engine Yard S01E25: Wesley Beary (geemus) Wesley Beary discusses fog, the cloud and board games <ul> <li>01:11 - What fog is</li> <li>01:53 - The libraries that cloud providers have</li> <li>03:37 - Fog primary use case</li> <li>06:05 - Using fog at Engine Yard</li> <li>08:27 - Near and long term future of fog</li> <li>12:05 - What Wesley would like to see before fog hits 1.0</li> <li>14:30 - Fog website</li> <li>17:53 - Best way to contribute to fog</li> <li>20:40 - Board games and Vibram Five Fingers</li> <li>28:34 - Wes's side projects</li> <li>30:37 - Leaving the Bay Area</li> <li>32:01 - Cool swag that you get from contributing to fog</li> <li>34:20 - What it's like to work for Dr.Nic</li> </ul> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/25/cloud_out_loud_geemus.mp3?1307041810 Thu, 02 Jun 2011 19:10:10 +0000 no S01E23: Jeremy Hinegardner Engine Yard S01E23: Jeremy Hinegardner Jeremy Hinegardner talks about Hadoop, Ruby 2.0 and the Boulder tech community this week on Cloud Out Loud. <ul> <li>00:25 – Introductions</li> <li>01:20 – What has changed in Ruby over time</li> <li>02:30 – Some of the new features in Ruby 2.0</li> <li>03:30 – Projects Jeremy has been working on</li> <li>04:35 – Working with JRuby and MRI</li> <li>05:55 – Why <a href="http://hadoop.apache.org/">Hadoop</a></li> <li>07:30 – Tech scene in Boulder, Colorado</li> <li>09:05 – Next trends in tech</li> <li>10:25 – Getting started with data analysis</li> <li>11:15 – Jeremy’s Scottish Ruby presentation</li> <li>13:45 – Ruby as a mainstream development language</li> </ul> Additional Links: <a href="https://github.com/copiousfreetime/ashbe">Ashbe</a> <a href="http://hbase.apache.org/">HBase</a> <a href="http://www.techstars.org">Tech Stars</a> <a href="http://confreaks.net/events/scotlandruby2011">Confreaks Recorded Presentations: Scottish Ruby Conf 2011</a> <a href="http://confreaks.net/videos/557-scotlandruby2011-data-stories">Jeremy’s Data Stories presentation from Scottish Ruby Conf 2011</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/23/cloud_out_loud_jeremy_hinegardner.mp3?1305247147 Fri, 13 May 2011 00:39:07 +0000 no S01E22: Chad Pytel Engine Yard S01E22: Chad Pytel Chad Pytel of thoughtbot discusses Rails AntiPatterns and thoughtbot. <ul> <li>00:30 – Chad introduces himself and talks about thoughtbot</li> <li>02:00 – What is an antipattern?</li> <li>03:15 – Keeping up to date with Rails</li> <li>06:30 – Changes that have occurred in Rails</li> <li>07:45 – PHPitis = Combine code with HTML</li> <li>09:15 – Ways to keep the view code clean</li> <li>11:45 – Common antipatterns</li> <li>13:30 – What impact does streamlining your views and controllers have on the models?</li> <li>16:13 – Creating a culture of sound development practices</li> <li>18:30 – The AntiPatterns training course</li> </ul> <a href="http://ey.io/railsanti">Rails AntiPatterns Webinar</a> on Thursday, May 12, 2011 <a href="http://www.engineyard.com/university">Rails AntiPatterns Training Course</a> in Boston June 6, 2011 and in San Francisco June 13, 2011 http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/22/cloud_out_loud_chad_pytel.mp3?1304631950 Thu, 05 May 2011 21:45:50 +0000 no S01E21: Ron Evans Engine Yard S01E21: Ron Evans Ron Evans discusses Kids Ruby and the correlation between music and programming <ul> <li>0:16 - Ron gives some background info about Hybrid Group and himself</li> <li>1:20 - Hybrid Group's involvement in the Ruby community</li> <li>2:50 - Correlation between working with groups of musicians and a team of programmers</li> <li>4:15 - The LA Ruby community</li> <li>6:15 - Kid's Ruby Project</li> <li>12:25 - Kid's Ruby Installer</li> <li>14:10 - How music and programming relate</li> </ul> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/21/cloud_out_loud_ron_evans.mp3?1304036870 Fri, 29 Apr 2011 00:27:50 +0000 no S01E20: Brad Grzesiak Engine Yard S01E20: Brad Grzesiak Brad Grzesiak discusses Bendyworks, open source projects and RedDirt RubyConf. <ul> <li>0:15: Introductions</li> <li>1:40: The Ruby ecosystem</li> <li>2:15: Ruby on Ales 2011</li> <li>3:45: The Ruby Work Environment</li> <li>5:40: MadRailers user group</li> <li>8:35: Brad and open source</li> <li>10:15: Differences between the Ruby ecosystem and other ecosystems</li> <li>11:10: What is voicerally.com?</li> <li>14:05: The Madison, Wisconsin tech scene</li> <li>17:25: RedDirt RubyConf presentation on haml and compass</li> </ul> Links <a href="https://login.engineyard.com/signup">Engine Yard Trial</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/20/cloud_out_loud_brad_grzesiak.mp3?1303426624 Thu, 21 Apr 2011 22:57:04 +0000 no S01E19: Matt Aimonetti Engine Yard S01E19: Matt Aimonetti Matt Aimonetti talks about MacRuby and iOS this week on Cloud Out Loud. <ul> <li>0:30 Thoughts on how MacRuby is doing now</li> <li>1:15 Will Apple open their code to the public?</li> <li>2:10 Background of MacRuby</li> <li>3:00 Status of MacRuby and iOS</li> <li>5:00 The MacRuby book</li> <li>7:20 Xcode support for MacRuby</li> <li>8:00 The Ruby movement as compared to an art movement</li> <li>10:00 Matt talks about different languages he has been looking at</li> <li>13:30 What Matt does at Sony and how Ruby is used there</li> <li>17:30 The GoldenGate RubyConf talk Matt gave 2 years ago</li> <li>21:20 Andy talks about what his talk at Ruby Kaigi will cover</li> </ul> Links <a href="http://rubylearning.com/blog/2010/09/28/the-ruby-movement/">The Ruby Movement blog post</a> <a href="http://www.macruby.org/">MacRuby</a> <a href="http://oreilly.com/catalog/9780596515171">Masterminds of Programming book</a> <a href="http://merbist.com/2011/02/22/concurrency-in-ruby-explained/">Concurrency in Ruby explained blog post</a> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/19/cloud_out_loud_matt_aimonetti.mp3?1302857706 Fri, 15 Apr 2011 08:55:06 +0000 no S01E18: Tung Nguyen Engine Yard S01E18: Tung Nguyen Tung Nguyen of Bleacher Report talks about their explosive growth, REE, and plans to upgrade to Rails 3. <ul> <li>1:24 What is Bleacher Report?</li> <li>1:55 Growth from 50k to 18 million uniques per month</li> <li>2:25 Performance optimization/monitoring tools</li> <li>2:56 Their Ruby on Rails performance review</li> <li>3:22 Recommendation to upgrade to Ruby Enterprise Edition</li> <li>3:29 What REE is and why it’s important</li> <li>7:06 Future plans to upgrade to Rails 3</li> <li>10:00 Fatherhood and learning to hold your newborn while typing with one hand</li> <li>10:47 Closing: tearful goodbye</li> <li>11:42 Outro: Partnerpedia Ruby/Rails Job, Matt Aimonetti podcast coming next week</li> </ul> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/18/cloud_out_loud_tung_nguyen.mp3?1302275065 Fri, 08 Apr 2011 15:04:25 +0000 no S01E17: Josh Knowles Engine Yard S01E17: Josh Knowles Josh Knowles of Pivotal Labs NY discusses Gotham Ruby Conference (GoRuCo) and hiring Ruby on Rails developers. <ul> <li><a href="https://github.com/pivotal">Open Source projects</a> Pivotal works on</li> <li>The <a href="http://en.wikipedia.org/wiki/E-3_visa">E3 Visa</a></li> <li>The <a href="http://www.startupvisa.com/">Startup Visa</a></li> <li><a href="http://goruco.com/">Gotham Ruby Conf</a></li> <li><a href="http://www.youtube.com/watch?v=iMA5_op9aOA">Gotham Ruby Conf talk videos</a></li> </ul> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/17/cloud_out_loud_josh_knowles.mp3?1301616382 Fri, 01 Apr 2011 00:06:22 +0000 no S01E16: Baq Haidri Engine Yard S01E16: Baq Haidri Baq Haidri discusses how LinkedIn uses JRuby. <ul> <li><a href="http://www.linkedin.com/">LinkedIn</a></li> <li><a href="http://www.linkedin.com/skills/">LinkedIn Skills</a> – a projects written in JRuby</li> <li><a href="http://www.jruby.org/">JRuby.org site</a></li> <li>Baq’s presentation: <a href="http://ontwik.com/ruby/how-linkedin-uses-jruby-on-its-front-end/">JRubifying LinkedIn’s frontend</a></li> </ul> http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/16/cloud_out_loud_baq_haidri.mp3?1301014514 Fri, 25 Mar 2011 00:55:14 +0000 no S01E15: Ray Hightower Engine Yard S01E15: Ray Hightower We interview Ray Hightower and talk to him about all the cool conferences he organizes and his take on the Ruby ecosystem Susan: Welcome to Engine Yard’s Cloud Out Loud Podcast. I’m Susan Layman. Our guest today is Ray Hightower, the founder of WisdomGroup and the organizer of Chicago Ruby group. Welcome Ray. Ray: Thank you very much Susan. Thanks for having me. Susan: Your welcome. Thanks for coming and chatting with us today. Ray: Appreciate the invitation. Susan: Great. So let’s get started. Let’s talk a little bit about your own background and how you became involved in tech generally and Ruby on Rails specifically. Ray: Yea ok sure. I have an eclectic background and I find that a lot of people in the Ruby community have come from all different walks of life. I have a CS degree but I was in college in the 80s so of course Ruby didn’t exist back then, object-oriented programming barely existed and I have a CS degree, I worked for IBM for a number of years, I did commercial real estate and after that in 1994 I started WisdomGroup. And we did networking with Novell Networks and Microsoft Windows NT, later to be Windows 2000 and eventually XP and they’ve changed the names of their operating systems a couple of times and we got into Rails really because we were doing web development. People liked what we were doing with networking, they gave us permission to do some projects for them on the web. We did our first few in ASP and PHP and one day an intern working for my company said, “Hey, Ray I’m working with something called Ruby on Rails” and I said, “What’s Ruby on Rails” and that’s how we got into Rails. Susan: Wow, that’s quite a background. Ray: Very secuitous. Susan: That’s right. Ray: Yea. Susan: So, let me switch gears a little bit. What does community mean to you and what makes Ruby on Rails community unique? Ray: Wow. Big difference between the rails community and what we experienced when we were working mainly with the Microsoft and Novell networking technologies. Everybody’s very engaging and everybody’s helping each other, we’re all helping each other. And, if I ask my self, “What is it that has--what is it that’s fundamentally different there?” and I think a lot of that is due to the open source roots of Ruby and the open source roots of Rails. You know there’s just--everybody--you know I heard somebody say its like a big hippie commune. I don’t think of it like that, that’s kind of like a tongue and cheek way to look at it but yea, everybody, we’re all helping each other from the meetups to the conferences, everything across the board, we’re all helping each other. So yea we definitely--I think a community is a group of people with common interests and common goals who help each other. Susan: That’s great. And they all come from different backgrounds. Ray: Oh goodness, all over the place, We have people who have business backgrounds, we have people who have PhDs in physics or material science or mathematics, we have MBAs, we have lawyers and law students, there are some physicians, there are dentists, there are people all over the place. I met a plastic surgeon at a Ruby conference 2 years ago and he was just there because he like the technology and you know, yea, all over the place. Susan: Right. Ruby makes it very easy, I suppose, to get involved in programming for a lot of, I would say, non-programmers. Ray: Yea, for starting up I would say yea, yes. Its a tool that’s really easy to get started. You know, its kind of like chess. You can learn the basic moves of chess in a few hours but it can take a lifetime to master it and I think Ruby’s a lot like that. You can learn basic moves but you could spend a lot of time just mastering, you know, learning the idioms and design patterns and all of the things you can do. It’s just wonderful. Very expressive. Susan: Great, thanks. Now in one of our previous podcasts, Sarah Allen talked a bit about the Ruby ecosystem. Now would you say that the Ruby community has become more of an ecosystem. Ray: Uh, you could say that. I suppose I should give you what I think an ecosystem is before I start tossing the word around. But, I think an ecosystem is a--you could say its a community where people within the community are dependent upon each other and helping each other and because we all exists and we’re dependent on each other, we’re able to do things that none of us individually could do. We’re able to accomplish more than any of us could accomplish as individuals. So, for example, you’ve got some companies that provide training and they also provide consulting. Sometimes they compete with some people that they’re doing consulting for, sometimes they cooperate if a project is big enough. There are certain companies here in Chicago that hire consultants from a variety of companies and those companies are actually cooperating to keep that customer happy because its good for everybody. So, you know, there’s an ecosystem in that sometimes we’re competing with each other but most of the time we’re cooperating with each other because there’s just so much opportunity out here that it just makes sense for us to all help each other. Susan: Right. And that ties back into your last point regarding helping one another but at the same time moving the technology forward, evangelizing the technology into different types of opportunities and different kinds of markets because people from all works of life are part of the community. Ray: Oh yea. You know a good example of that? There’s this guy Corey Haines who you’ve probably met in the community who did a tour of the planet--pair programming with people all over the planet. Well he started working with Obtiva and Aflight and they do craftsmanship swaps, EdgeCase has gotten involved with that, Relevance has gotten involved with that, where they swap craftsmen and share best practices in all of their studios. I think LeanDog has been part of that. LeanDog in Cleveland has been part of that also. So yea----there’s so much opportunity and we’re still all defining what excellence means, you know what I mean? Yea, we’re still defining what excellence means because the tools are constantly evolving and the needs of the clients are constantly evolving and as we develop new tools, clients are say, “oh you can do that” and I got a new way for you--you know something else you can do with that and its just--its a real cool upward spiral. So, yea there are a lot of companies here in Chicago and a lot of other cities that are participating in those craftsmanship swaps and I think that’s exciting. Susan: That is exciting. Ray: Yea. Susan: So let’s talk a little bit about the community events you participate in or have organized in the past. Tell me a little bit about these events and why they’re so crucial to the community and have you seen the community change in the past few years. Ray: Oh yea. You know, what has changed in the community is that 2 or 3 years ago, if there was an event you wanted to go to, you could just go. Now, if you want to go to an event, you’re looking at your calendar and you see there are multiple events on a given night or a given day, all of which are good, all of which that you want to go to and you kind of have to pick and choose which ones to go to and its hard because there’s so much good stuff happening at the same time. There’s the Chicago Project Management Group here, there’s ChicagoDb which is all about NoSQL database, there’s ChicagoRuby which my team and I run. There’s all over the place, so many things happening at once. There’s a Chicago Javascript group and if one thing has changed, I would say there are a lot more people organizing a lot more high quality events and so much good stuff is going on. Last night I was at the Chicago CoCa Heads Group. It was wonderful. People who are passionate about MacOS X program, and an iOS program on the iPhone and the iPad so there’s a lot going on. Susan: Right. A lot of sharing, a lot of swapping of knowledge. Ray: Yes, yes. And we all have to swap knowledge because you know what? The NoSQL database people of course, there’s got to be a front end. You’ve got to have a front end for your database or else its just data sitting there You got to have some way to get to it so your front end people can be your Ruby your Rails people, could be Javascript people on the front end or if you’ve got a mobile front end, then you’re pulling in your iOS people, your Android people, Java people, now web OS people. If you see the announcement that HP just made, so everybody--everybody is specializing in their niche and then we’re all sharing across the board. Susan: Right, that’s interesting because the vendors may be competing but the developers really aren’t competing. Ray: Yea, you know, and we all joke about it sometimes but yea there’s competition. Its kind of like sibling competition. I think about my brother--my brother’s name is Edward and growing up--we’re a year apart in age and we fiercely competed with each other but I think we both did better because we each had the other to compete with and that’s kind of what’s happening and its a friendly competition. I don’t see any back-stabbing out there. We share stuff with each other. I go to Obtiva’s Geekfest and they welcome me there, i welcome them to the events that I’m responsible for and we all have a good time because there's so--there’s too much stuff out there. It's like we’re in a huge ocean with all of these fish and we only have a few boats in this huge ocean so its better to help your fellow fisherman gather the fish than to try to fight over fish. There's too many fish, you know what I mean. There’s just a lot of opportunity there. Susan: I understand. So tell me a little bit about the challenges you’ve encountered as an active community organizer. What are some of the lessons that you’ve learned? Ray: You know what, we actually posted a bunch of our lessons in our GitHub repo. If you go to GitHub and look at ChicagoRuby in GitHub, just spell it out, Chicago-Ruby-in-GitHub you’ll see our guidelines for organizers and we did that to increase our truck number and basically what we have there was a bunch of things we wish we had known when we were starting off and a bunch of things that we want to pass on to the next group of organizers if we all go off to other parts of the world to live on tropical islands somewhere, right. But some of the things that--the biggest challenge, you want to make sure that if you’re running a group, make sure it is extremely easy to find in Goggle. That advice was given to me by a guy named Ryan Platty who at the time ran CHURB which was the Chicago Ruby group at the time. So you absolutely want to make sure that you’re really easy to find in Google. You want to make sure you welcome new people coming into the group. You got somebody who just moved to Chicago, they’re interested in Ruby, you want to make sure that--I try to make it a point to go up, shake everybody’s hand, myself, ask them where they’re from and that type of thing. I try to remember everybody, I can’t. We have over 1000 members but I really try hard to remember as many as I can. But just make people feel welcome and let people know that there’s an opportunity for them to contribute. We’ve got amazing developers here, especially in Chicago. I don’t know if you have developers in Silicon Valley. I’m just kidding. But we’ve got some amazing one here and let them know that there are plenty of opportunities for them to contribute make them feel welcome, make sure you’re very easy to find on Google, and I think everything else kind of like, comes from those. I think those are the root things you want to make sure you do. Susan: That’s great. Thanks. So, what advice can you offer someone new to the community who’s organizing, perhaps in a leadership position that might want to help cultivate their local community? Where should they start and are there any resources for newbies? Ray: Yea. One of the first things I would look at is, like I said, the files we’ve posted in the ChicagoRuby GitHub repo about organizing groups because that’s all about lessons learned, things we wish we had done. We call that, How Chicago Ruby Works and there’s an org chart there but--and things we’ve done that work really well for us. There are some other organizers I know that have written up similar guides and I’m not remembering right now which ones and where but you know, every now and then like at RailsConf we’ll get together and we’ll meet and we’ll talk about what everybody’s doing so I would get together with other organizers, international conferences or national conferences or even regional conferences and learn from other people triumphs and other people’s mistakes. And we’re all making mistakes--that How Chicago Ruby Works document, a lot of that is “o yea, this is what I wish I had done” that kind of things so, that’s where we get our lessons from. Susan: That’s great. Ray: Yea. Susan: That’s great. Okay, so let’s switch gears just a little bit here. You know, in your mind what’s the relationship between technology and entrepreneurship? Ray: I think technology--what’s the best way to say this? Technology accelerates entrepreneurship, and I say that because, and I’ll say specifically information technology because we could talk about technology in general but I’ll say information technology since that’s the area that I know. Information technology accelerates entrepreneurship because it enable us to communicate, really, really fast. You and I are 2000 miles apart right now, we’re communicating over the Internet via voice over IP, packets going out over the Internet and my goodness, some years ago a call like this would’ve been very expensive but we’re doing it over Skype right now and its not very expensive doing it over Skype. So that’s one way that technology accelerates entrepreneurship because you and I are able to communicate on things. We’re a customer of Engine Yard and Engine Yard is a sponsor of WindCity Rails and our other conferences, WindyCity Go and WindyCityDB so we’re each other’s customer and that’s accelerated because we’re able to trade information about what you want as Engine Yard and what we want with WindyCity Go or WindyCity Rails via email or Google Docs or Skype or what have you. It accelerates it or if you look at--could Groupon have existed if the web didn’t exist or? It couldn’t have. Technology has accelerated the growth of Groupon and of Apple and Microsoft and of the consulting companies here. I would say ultimately technology must serve entrepreneurship because its really the entrepreneurs that are steering the boat and technology is commander Scot in the engine room saying, “Yes captain, let’s make sure we get plenty of di-lithium crystals in the warp core so we can achieve warp factor 28 or whatever, if the warp numbers go that high, I don’t think they go that high but you know what I mean. So, you can say technology is like the team of engineers and engineering you know, making sure that warp core is stable and putting out energy and the entrepreneurs on the bridge saying, “ahead warp factor 8” and the entrepreneurs don’t know the details of how all that happens. You know, Captain Kirk could never go down to the engine room and do thing number 1 with a warp core, he wouldn’t know. Right? Susan: That’s right, that’s right. Ray: Could you imagine that? Or Jean-Luc Picard couldn’t or Kathryn Janeway--and I get into Star Trek if you can tell. So, each person on the team plays their role and if we all work together really well, we achieve some really excellent things. No one of us, I think it was Woodrow Wilson that said this, “No one of us is as smart as all of us” and you know we all come together and achieve some great stuff. So yea, technology accelerates entrepreneurship. Susan: Yea then you add in the community and you’ve got something that is going blazing fast. Ray: Oh yes. Absolutely, absolutely. Yes. Susan: Okay so you’re passionate about exposing young people to cutting edge technologies. Why is it so important to do so? Ray: Because, you know what, because its cool to watch them learn and grow and absorb this stuff and its fun to watch them learn and they challenge us, you know. There’s a kid--I call him a kid because I’ve known him since he was an infant but he’s now 16--well he’s 16, he’s still a kid. Anybody under 30 is a kid as far as I’m concerned, right? So this guy in my boyscout troop just made eagle. For his eagle service project, built an Ubuntu lab at our church and he is so passionate this stuff. We put it in front of him, showed him how to download Ubuntu and install it and now he’s going off in Google just to find new places to learn more about Ubuntu. He’s sharing it with other scouts in the scout troop and now there’s like a group of scouts talking trash with each other about what they can do with Ubuntu on their computers. And you know what’s so refreshing about that? Kids do that naturally when it comes to sports, when it comes to physical things but to have them do that with an intellectual pursuit, with something like an Ubuntu installation or an Ubuntu configuration and then to go off, and they’re talkin--but its all in good fun because they’re pushing each other and competing and because they’re competing they’re all getting better and it pushes me as one of the leaders to keep getting better myself because, my goodness, what am I going to teach these guy next? You know what I mean? You gotta do that. I won’t always be a--its an honor to me when they pass me--one of the guys that works for my company now is--grew up in my scout troop. He’s like 25, 26 years old and he’s doing amazing things with networking that’s so far beyond what I know how to do and I’m so proud and I learn from him now. He came in as a--where I was a mentor and all that and now I watch him do this stuff and I learn from him. So, when we teach our children or our teenagers or our youth in our communities--I do it in the boy scouts, I do it in my church, when we share that with them, they in turn come up with new ways to do stuff that we never even thought of. They challenge us, we all grow, our brains stay active. It's wonderful. Susan: Right. They’re going to be our leaders when we’re-- Ray: They are going to be our leaders. The kid who did the Ubuntu lab, he--we have another leader who was having problems with his laptop and the young man who did the Ubuntu lab wiped out Windows on this leader’s laptop, installed Ubuntu--now that leader--this is a businessman--a very successful business man who has used Windows all the time that he’s been using computers, now he is very, very excited about Ubuntu because this teenager introduced him to Ubuntu. And he’s able to take care of things he needs to do businesswise and not deal with virus issues or malware issues and he told me Monday, he says, “Hey, man this is faster than it was when it was running Windows.” This was done for him by a teenager who just got introduced to Ubuntu last year, last November, December of last year. Susan: That’s really cool. Ray: Yea, so, I get hyper about this stuff Susan. Is that okay if I get hyper? Susan: Absolutely, I love it. It's very infectious. Ray: Yea, right. Susan: And finally, you’re committed to making Chicago synonymous with high tech. Can you talk a bit about some of the innovation that’s taking place there now? Ray: Yea, well you what, one that has gotten a whole lot of press, well recently with their superbowl ads, you know, Groupon. That’s just wonderful. There are so many other companies here. You know I think of software development companies like ThoughtWorks is based here, they are a global software development company. Obtiva is based here. Aflight is based here. WisdomGroup, my company, is based here. What’s exciting is that many of us are bringing on interns or apprentices and helping them to grow and when they have ideas about what we can do with technology, they can approach entrepreneurs who, “Whoa, gee I hadn’t thought of that. Let’s do this and let’s grow a business from it.” I keep mentioning Groupon because they’re in the press but its really exciting because I don’t know how their business model could have existed in the days of just newspapers and mainframes. You know? And they were grown right here in Chicago. They started off Andrew Mason and the guys at LightBank were originally doing The Point and they did a pivot--pivot classic Steve Blank from Four Steps to the Epiphany. They need a pivot from The Point to Groupon and they’ve grown and there are other companies like that that are not as well known, that are not getting as much publicity but who are still doing some great things here. And it's only beginning Susan, it's only beginning. Susan: That’s great. Sounds like you guys are becoming the next Silicon Valley so to speak. Ray: Maybe so or some people say Silicon Prairie or whatever but, you know what I like? Yea, you can say that but I think each region of the country offers something a little bit different--maybe a little bit different twist in the way they approach things. Like when you read Steve Blank’s History of Silicon Valley, its interesting to see how a lot of that grew out of the defense industry. Its interesting to see how in the Midwest, because there’s farmers roots and all that stuff, how there’s a different approach here--more of the 37signals. I’ve got to mention 37signals, the birthplace of Rails. The 37signals approach where you are growing organically and based on having customers and you’re using the profits from, your customers’ profits, from satisfied customers to grow your business. I think that’s a very much Chicago-type model and something that 37signals popularizes through their books, through Rework and Getting Real. We’re growing. Rails started in Chicago and of course in Denmark. David Heinemeier Hansson is from Denmark so him and Jason collaborated over the web. So, yea, Chicago is only at the beginning of this. Its really exciting to see all of the things we’ve achieved and then we’re not opposed to partnering with people who are outside of Chicago. I mean, there’s this company called Engine Yard. That’s not in Chicago that we happen to like very much, that we work closely with and that there are several companies in the Chicago area that work with you guys because the whole elasticity thing is--just being able to grow without throwing iron, without throwing hardware to your app, to be able to deal with a publicity spike at the snap of a finger, that’s awesome. That’s awesome. I’m thinking of a few clients we have--one in particular that we have with you--this is, the name of the company is Singles Travel International and my goodness, we moved them from a single server that was breaking--it was really having some trouble and we took them over from another consulting team and we immediately moved them to Engine Yard and they’ve been very happy with the response. We’re using multiple servers in the Engine Yard cloud and when we want to try out new features and show the clients new stuff that we’re thinking about doing there. We just spin up a new server, put it there, it does not effect production at all and when we’re done with it, we just make that test server, that staging server disappear. So we partner with companies outside of Chicago too, just like Engine Yard. Susan: Thanks so much. Ray: Yea. Susan: Well thanks a lot Ray, for spending this time with us, we appreciate it. Ray: Thank you. Susan: And we thank you for your time. Ray: Thank you so much Susan, thank you for having me. http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/15/cloud_out_loud_ray_hightower.mp3?1300477945 Fri, 18 Mar 2011 00:15:17 +0000 no S01E14: Kent Langley Engine Yard S01E14: Kent Langley Kent Langley on why he thinks Ruby is going to be so disruptive and the importance of scalability. Danish: Today we have Kent Langley with us from SolutionSet. So Kent, can you introduce yourself please. Kent: Hi, yes, my name is Kent Langley. I’m a senior director at SolutionSet here in San Francisco. Thank you guys for having me on today. Danish: Thank you for joining us. So could you take a little bit of time to talk to us about your background and what made you so passionate about tech? Kent: Yea, certainly. Well I think, you know, in general I just think I was made this way or born this way. I’m definitely a technology advocate and something of a geek but I kind of have this entrepreneurial itch that I have to scratch or I get a little bit unhappy. Over the past years I’ve been focusing really heavily on cloud computing, I would say starting probably in early 2006 and, sorry there’s a little background noise over there, and today I am working for a company called SolutionSet doing primarily web systems engineering and operations and large scale deployments for our client base. Once things stop working so much, you get a little bit of success and things can go a little sideways and that's kind of one of the areas I specialize in. My passion for tech just--somebody handed me a computer when I was a little kid and my dad bought me a computer before they were a commodity item and it was just love, you know, it was just a good love affair from there. Danish: Ok. So can you tell us a little bit about SolutionSet and the history behind it? Kent: Oh, sure. SolutionSet is the 4th largest independent marketing services company in North America. There are 4 divisions--direct, local, data, and digital. I personally work for the digital division, that division was founded in 2003. There are about 110 people, I think, working for this division out of the total of little over 400 that work for SolutionSet, 6 offices, and the developers here are of all flavors. Ruby, of course, PHP, Python, .NET, Java--we have all those and there’s whole teams of systems engineers, user interface experts, project managers, creatives--that do a lot of the beautiful designs that you see on our work and in general we just have people across the board in the marketing but my focus here is primarily on the digital side. Danish: Ok. So what does--what is your business philosophy? Do you guys use open source products? What does open source mean to you guys? Kent: Ok. Business philosophy here at SolutionSet is really simple--its relationships and client value creation. Our best clients are the ones that have been with us for a long period of time, we do project after project with them and I think that because we have such focus on client value creation and integrity, that’s what lends itself to that. You know, it makes me happy when we have a client that comes back again and again--I know I’m doing something right so that’s very important to us. So philosophically, I would say relationships and client value creation. When it comes to open source, yes we absolutely support open source and we do it in a pretty big way because I don’t even think what we do would be as possible in a closed source world. We use just about every open source stack you can imagine in here. And, philosophically, open source is about creation of aggregate value, far beyond your individual contribution or company. And I think that’s where it has its best potential, globally, not just here at SolutionSet. But when you create something that can be shared, improved upon, and then used to create business value in turn and that’s a virtual cycle, you know open source does that better than any other systems of code creation that I know of. Danish: Ok. So I know you were saying earlier that at SolutionSet, you guys do Java, .NET, and PHP so I’m curious how you guys became involved with Ruby and what steps you guys take to implement Ruby in your business. Kent: So the way SolutionSet has become involved with Ruby over time is number 1 because our clients are asking for it and so we’re going to help do--we’re going to provide what our clients need. Number 2, its because I happen to personally happen to have quite a love for Ruby and used both in--I would say my use primarily in systems engineering and operations but also I’ve done some interesting projects with development partners over the years and I’ve just not found another community like Ruby that has such a momentum and such a huge number of really bright people contributing, you know, constantly, almost as fast as you can think of something, it seems like you can find a gem for it in a week or so and it doesn’t even matter if you tell anybody about it. You just don’t find that anywhere else, at the moment so I got involved with Ruby personally by just wanting a more solid way to automate system configuration and systems--website deployment in particular with Capistrano, a number years ago. Good work by James Buck there originally and that’s how I found myself digging deeper and deeper and deeper into Ruby. Danish: Very cool. So I know when we talked before about getting you to do the podcast, scalability was really important to you so if you could tell us, what to your mind, is the significance of scalability and what is a scalability architect and why is this role so crucial. Kent: Sure. So scalability, there are 2 things that are really important to me about scalability and its not always just about technology, its just as much about people and organizations as it is technology so I think the most scalable systems that are ever build were built from scalable organizations, right, that understand how to get things to scale, right. And in most cases and in my world, it tends to be a website. You hear about web-scale everyday and I think that web-scale, what that really means is that if you have an idea these days that;s pretty straight forward, that execution is the key and when you ask what a scalability architect is, its a scalability architect that takes that little step back and takes a look at systems as a whole, not just the tech but the people too and makes sure that you’re not painting yourself into a corner is the analogy I like to use a lot because you need to make sure you have options. And then there’s a common misconception that scalability is expensive or too expensive, prohibitively expensive to even think of and to avoid premature scaling at all costs. Well its kind of--it can be expensive to scale and grow but--and its true you should scale prematurely but its absolutely not true that you shouldn’t think about it. You need to have a plan to grow and I think that’s where scalability architects come into play. I don’t even know, yet, if that’s truly a title that’s common out in the world but I do know that I’m starting to see a lot more trends of people talking about it and I’m please to see that because scalability architect--you don’t get that from a book you get that from experience and you get that from really loving what you do and being able to look at systems as a whole and make sure that as they grow, they have a way to scale. It doesn’t mean they wont fail sometimes. Sometimes they do, but it means you’ll have options when they do. Danish: Ok. So, I know with scalability a lot of people talk about databases and I read this great post on HackerNews that discussed key differences between few of the no-sequel databases and their pros and cons, so I was curious, which no-sequel databases have peaked your interest the most and why? Kent: So, definitely read that article as well and there are numerous other out there doing those comparisons now and I’m really pleased. The most important thing they do on those comparisons is they talk about when you should use something and why, not just how it works and what it is. And so I tend to favor articles that have the whens and whys and--there are 2, really, that have caught my attention and not just my attention but my time, meaning that I’m actually actively building and installing and running systems that are using them. I have a tendency to use Redis fairly frequently. I have a tendency to use Riak. I’m doing a project right now for a substantial size customer where we needed something like Riak and there was just nothing else that had distributed data store at its core with scalable reads and writes, you know, meaning you just add another node of things get a little faster. So, the use case for Redis in my case are a little different. I needed about a 60:1 master slave scale out on a large read-heavy application and I needed it to be able to push data out to all of those slaves really, really quickly. Redice was a great fit for that and its simple and easy to implement as well. Developers can pick it up really, really quickly. Danish: Ok. I’m curious if you’ve dabbled in Mongo at all? That’s kind of my preference a little bit. Kent: Yup. Danish: But I know some people don’t like it. Kent: No, I do like Mongo actually. It would probably be the 3rd one on my list at the moment and the only reason that its 3rd on the list at the moment is because its horizontal scalability tech--what you have to do operationally to scale horizontally with the shard-ed replica set is pretty intense, right? I mean not just anyone can prop that up so it does have a little bit higher operational overhead but in cases--and this does come up for us quite a bit, especially the smaller e-commerce side, in cases where you do have developers and/or a highly relational data store, we found MongoDb to be the best sort of almost like a 1:1 port from traditional relational database world into a document oriented database world so, you know, I’m quite fond of that one as well to be honest with you. Danish: Ok. So there’s this recent acquisition that I think that went for $212 million for Heroku by Salesforce--has a lot of people talking about the relationship between Ruby, Rails, and enterprise, so I was curious if you could offer any insights that you have into that. Kent: Yea, I mean, I could tell you what we’re actually seeing, right. Is that, large corporations now, that we are potentially already doing business with in a lot of cases, who even 3 years ago wouldn’t have thought or maybe might have even laughed to me for suggesting that I was going to use Rails to prototype their application or build their application. That’s just not the case anymore, its completely flipped around. They’re asking me now, if I know how to use Rails and if I have developers that can help us deploy Rails and the Heroku acquisition only strengthens the position of any developer or any person out there that wants to suggest Rails as an alternative, right. And I think that for me, that’s what it means more than anything else and I don’t want to say legitimatizes; it was certainly already legitimate but it certainly moves it up market a little bit and makes it a little easier to sell. Danish: Definitely, that’s for sure. So, I know you stated you guys use Chef for your automation and I know that’s what we use here at Engine Yard. I haven’t really--I wasn’t ever really ever been exposed to anything more than Chef but I know when I did a little research, there’s other ones out there called Sprinkle and the other one’s Rudy. I was curious if you guys ever looked into other ones of it Chef was just--since it seems like its almost the de facto if you guys just decided on that you know opscode has done a really good job with it. Kent: Yea, you know, as I mentioned earlier, some of my first Ruby was dealing with automation of deployment so Capistrano so I got my hands on essentially a Ruby DSL for deployment very early on so moving to Chef for me was fairly easy and fairly natural and it just made sense. But in my opinion there are probably 2 leading options--there’s Chef and there’s Puppet. I do know Sprinkle, I don’t know Rudy, I would have to look that one up. But Chef for me, because of the--it all comes back to that same thing I said about open source and the same thing I feel about Ruby and the Rails community in general and the quality and passion behind what people are doing. Its all about community, right, and the momentum behind it. Just go search for the recipes. You can find a recipe for almost anything and it’ll give you a great starting point and reach out to the person who wrote it, they will answer you and they’ll be right there and I found that to be really nice. In terms of, not only using it but helping to train my team to use it. You know, there’s a learning curve for all that stuff. When you start talking about indempotent systems, people start to look at you kind of sideways but its certainly--in my world, Chef was the best fit, I’ve used Chef and Puppet and would recommend them equally, depending on which one was the best fit for the organization at hand. Danish: Why would you say for you guys, Chef seemed to be the better fit? I know like you said, there’s a lot of people that talk about Puppet as well but I’ve noticed a lot more people have been moving to Chef from Puppet if they were using it previously. Kent: I think that, again, the primary reason is that I’m focused on building a Ruby practice here so the re-usability of the native DSL for the configuration management platform is key. The types of things I want to build, its very quick and easy for me to modify and find recipes that I need or create our own. The fact that I can, you know, again with either one of them you can run your own servers or you can, you know actually I’m not sure--do you know right off the top if there’s a--is there a hosted Puppet service because we do use Opscode Platform and we do like that quite a bit. Danish: From what I know, I don’t think there is. i know a lot of people tend to harp a lot about how Opscode makes it really easy for having their chef server up for them. Kent: Yea. So what we did here was we started with the Opscode Platform then we fairly quickly realized that were wanted to run on our own server inside the firewall and Chef made that very, very easy, right. So I was able to get everybody trained up and then when I pull clients in, if they want to take over the Chef repository, right, all they need to do is set up an Opscode Platform and clone the Git repo and then we’re good to go. We’ve done our job and transferred the work. So that’s also important as well. Kent: Yea. In a consulting--you know we’re in a consulting and services business so many times our clients will want that type of portability. Danish: Do you feel though, when you kind of transfer I guess, the code base off to people, is it easier for them to understand Chef, you know? Do they ever have trouble using it if they need to change things or if they needed to do anything with it? Kent: My personal opinion, I think its easier to groc but--and its Ruby so you can go out and find a Ruby developer. Now, Puppet has its own internal DSL however, as of fairly recently, you can also write your manifest in Ruby so I can’t really argue that anymore, right. Its kind of again, it just really comes down to what fits your organization. Chef fits ours. Danish: Ok. Awesome. Well thanks a lot again for finding some time to talk with us Kent, I really appreciate it. Kent: Yea definitely. And as I mentioned earlier, I’m very excited about continuing to work with Engine Yard and I think that I love what you guys are doing and what you guys have done over years and years in the community to promote Ruby and Rails and even make it possible for me to build a profitable and successful Rails practice here so thank you, thank you. Danish: Glad we can help. Thanks a lot Kent. Kent: You bet, thank you. http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/14/cloud_out_loud_kent_langley.mp3?1299804132 Fri, 11 Mar 2011 00:42:13 +0000 no S01E13: Brian Ford & Evan Phoenix Engine Yard S01E13: Brian Ford & Evan Phoenix We interview Brian & Evan and talk to them about what the future of Rubinius looks like Danish: So today on Cloud Out Loud we have Evan Phoenix and Brian Ford with us, the guys on the Rubinius team. So can you guys introduce yourselves please? Evan: I’m Evan Phoenix. This is the sound of my voice. I’ve been working on Rubinius for the last 4ish years I guess, which sort of started as a hobby project and then Engine Yard Brought me in to keep working on it. Brian: Hi this is Brian Ford. I’ve also been working on Rubinius for a few years and--with Engine Yard and one of the notable projects that we spun out of Rubinius is RubySpec. Danish: Very cool. So, it seems to me recently that a lot of Ruby programmers are synonymous with Ruby is a really happy programming language and makes them happy compared to one that they talked about previously so I’m curious what you guys think about that and whether you kind of believe in that philosophy or not? Evan: We definitely do. I think we’ve--we go--really early on in the project we wanted to make it more user-friendly. So we--its funny, one of the simplest things that we did that was really just a lark one day was, I was debugging some code and it was very difficult to figure out what was going on. And so I added this thing where the back traces would be all pretty formatted and have all this other information and that was about a 15 minute thing and for years that was actually the thing that Rubinius was known for. Like, “Oh, the back traces are amazing” so it was this very simple thing but I guess its those kind of things that we try to find that people really like because those sort of neglected parts but they interact with them all the time and when they have to interact with them, they’re always sort of sad. Like back traces--if you see a back trace its one of those like, “Oh crap, now I have to go figure it out” so its nice, its pretty, and it gives you a lot of information, that makes them--that seems to make programmers a lot happier. It definitely makes me happier when I’m working on the code. Brian: So interesting, related to the back trace. So the very first Rubinius hack-a-thon, in Denver, and Wilson Bilkavich basically added that you’d see color codes for back traces--so we had colorized back traces, which was all in Ruby. Did it in about 30 minutes, I think, maybe, in the middle of--we were writing a ton of specs and doing all kinds of sorts of other stuff. But that was pretty interesting; it was one of those like, very early victories. Here we were, writing in Ruby, implementing Rubinus, adding something that made it really nice to deal with all the errors we were seeing as we were slowly implementing. We were--the thing about Ruby itself that makes me happy typically is, I’m happy when I’m accomplishing my goals and there is a very low level of frustration. And my experiences before with Python, with C or Tickle even, was that when I would go to do something the distance measured in time between when I would start trying to do something and when I would succeed was longer with more frustration. And when I started using Ruby, I found that I was writing code that expressed my intentions that worked and I had very little frustration and I think a lot of that has to do with 1) the syntax of the language 2) the facilities that are available--Array has a very nice API and you can do a lot of stuff with it. And then just, I think it big measure it was the Pick-Axe book--programming Ruby from the pragmatic programmers--tongue twister. There presentation on the first tutorial section of that book was immensely helpful. Evan: We do a lot of--or I like to do a lot of, going up to normal Ruby programmers and trying to see what they’re work flow is and ask them like, ok what about your work flow frustrates you? What are the things that you don’t really like? Because that’s how the back trace thing came about--was me being frustrated with work flow problems. So I like to talk to people who don’t even--aren’t really using Rubinius, maybe don’t even know what it is but are using Ruby just to find out what could we do to make that work flow better. So that’s something that I like to do often. Danish: Ok. So, I’m curious then, what brought about the Rubinius project? It seems like you guys were really big on Ruby, Ruby was really useful for you guys. Why go out and decided hey, I want to create this new, you know kind of thing on top of Ruby that’s supposed to kind of rival it and you know, I want people to start using it even though I really love Ruby. Evan: Sure yea. A little history. So, I--the--ok. Back in 2004, I hadn’t been to any RubyConfs yet, I was just sort of--I’d been doing Ruby for maybe a year or something like that but I had done C and C++ and sort of Perl in my background. And people had said, “Oh, you can’t add neothreads to 1.8....that’s actually--that was banted around and I wanted to know why that was. And so I started this long--this is a project that I was working on at home, that thing to keep sane from work because work was getting just really crappy at the time and I needed something that was sort of mentally engaging. So, its not going to sound mentally engaging, but I can assure you it was at the time. I decided I would go through and I would clean up the source for ⅛ so I actually went through and went through almost every line in there and basically made it so that it didn’t use a whole bunch of globals everywhere. The idea being, ok if I want to have threads, they can’t be using globals because then the execution won’t work, they’ll just stop on each other. So I went through and kind of cleaned it all up. At the end I had something like a 10,000 line diff and realized very quickly that--so at the end of this project it stopped because I realized that there was a whole bunch of fundamental things that would not allow me to add native threads any further. It wasn’t just a clean up thing, it was a semantic thing. So I got done with this 10,000 line patch and realized that it didn’t add any value, in fact, it just made stuff slower. It wasn’t really all that useful. So i sort of just deleted it--that was a projected called Sydney at the time. So I just sort of left that, i didn’t really go back to it and then a few months later I kind of--I still liked this idea so I kind of got the idea, “what if we started over from scratch?” So, I’m not going to design a language I’m not going to worry about the semantics or or even the syntax. I just want to say the ground underneath those syntax and semantics--build that back up on firmer ground if you will. So that’s kind of how it started. It started just as a hobby. I ended up getting some old smalltalk books and seeing how the original smalltalk VMs were implemented and just sort of copied that. And the first version of Rubinius was all written in Ruby it ran under 1.8 which was 1.8.3 or 1.8.4 at the time, it used Ruby in-line to access raw memory so it had--there’s was a garbage collector that was written in Ruby that would use raw memory to actually write out the object space--it was so slow but it was one of those things that was just really fun because it showed that those things could be accomplished. If you want to go look, those--that code is still in the Rubinius code base. It’s back, all the way at the beginning if you go look at the commits. One of the first few commits is all of that Ruby code to build--that is a Ruby VM in Ruby. So that’s kind of how it started. We could just--I had sort of hubris to think that I could do it better but it was also just sort of fun. I had always been interested in languages and more specifically in how languages run, the run time of the languages so this was a really good sort of fun project for me. I worked on it for a while and then, I think at RubyConf 2005 in Denver? Brian: 2006. Evan: 2006? So I’m off a year at this point. So, 2006, I decided--I got accepted to give a presentation about it and so I was real--that’s sort of when things got really real at that point. Like, ok people are going to want to see this thing--it can’t just be the thing that lives on my laptop, I have to actually show it to people so I started and I converted all the Ruby parts, simple Ruby parts, into C so that it was at least an order of magnitude slower instead of like 5 orders of magnitude slower. And that’s kind of how the people got interested and it kind of took on life from there because one of the big emphasises has always been write as much of it in Ruby as we can. Like, bootstrap it--if you can write it and the emphasis has always been to say if you can write it in Ruby, you should be writing it in Ruby. And its only in those very specific cases where you decide, no actually I need this in C, that actually you go out and extract the one piece and you do that one piece in C. So, that was very intriguing to Brian and Wilson and a lot of other people that were there and they kind of went from there with it. So that’s kind of how it started. And, its just kind of had a life of its own and taken on steam and people thought it was cool and Thom thought it was cool so that’s why I’ve had 4 years to work on it. Danish: Nice. So, I don’t know if you guys heard about this but I know when Matz came to San Francisco I didn’t go to the talk but I heard afterwards that he kind of briefed upon saying that he might use some parts of Rubinius or Ruby too or that he wasn’t opposed to it. So I’m curious if you guys did hear about that if you might elaborate on what he was actually talking about. I know when I heard that I was pretty surprised. Evan: I think I did hear about that, just I wasn’t there. Either I just had some friends that were there--its hard. I don’t know exactly what to make of it. I’ve certainly--I mean Matz and I are friends so I welcome him to use as much as he would like. Part of the project has always been, you know its BSD licensed so I’ve always sort of been of the mind that I love working on it, I’m going to try to make it better but I’m fine with people taking whatever they want from it and doing whatever they need. So, if he wants to do that, I’d be more than happy to figure out where we go with it. But, I don’t know if he has any specifics other than maybe he just thought about it, so I haven’t heard any specifics. Brian: Yea, I was at one of the talks. I think he did a couple and one of the tweets that I saw actually came out from his visit to VMware so I don’t know what happened there. But, at one of the talks he did here, the question was basically about the architecture of what he’s calling RITE or Ruby 2.0 and it sounds like the architecture with the new virtual machine, native threads, and also the possibility of using the restricted set of the normal Ruby libraries so you can make a smaller implementation that’s more suitable for an embedded environment, something like a TV or a set-top box, something like that. So, there’s--sounds like there’s, in the architecture Matz is imagining for 2.0, there’s a lot of similarities to some of the approaches that we’ve taken with Rubinius. But I think that would be a good question to explore. I mean, so far I don’t think we’ve seen any code for RITE or Ruby 2.0. What would be interesting is to sort of try to understand what Matz’s goals are and see if we couldn’t demonstrate the viability of some of those goals by taking what we’ve got in Rubinius and packaging it up or showing how it could do what Matz is interested in doing. Evan: You know but also, Matz aside, we’ve had Charlie on the JRuby team and the MagLev guys have actually used--the MagLev guys have actually--Charlie has played around with basically using part of Rubinius inside of JRuby and I don’t know where he is that but we’ve talked about that many times about like, oh it’d be nice because--the nice thing about having all that stuff through Ruby is that its sort of Agnostic. You know, its not coded in some lower level language so its easy to pull it through another thing. You just sort of have to establish what the sort of primitive operations are, right? So, I know that the MagLev guys, we talked about, a few times, when they were earlier on in the project they were basically just using a lot of the Ruby code we had and a lot of it got pulled in, I think probably they’ve customized it and done it up in the way that they want but Genesis started with us discussing like, “yea just take whatever you need” and you know, go from there. Brian: Yea, they value to the Ruby community of having an established set of Ruby libraries is huge, right? I mean Java is not known for having all these great libraries that are written in C++, right? So its sort of ridiculous and the situation we have right now in Ruby is if you have a library or if you have something you want to make--Nokigiri is a good example. There’s a C extension for Nokogiri, there’s a native Java port, I believe for Nokogiri, and is there some Ruby code in there as well? Evan: Well yea, let’s not go that far. There’s--because when that started, Aaron wanted to use libxml2 to be doing parsing. So there’s a lot of Ruby code in there too. There’s interface code too libxml2 to do the heavy lifting. Brian: So think that the next sort of frontier for Ruby in many ways is to create these really high quality libraries that exist in Ruby, that are coded in Ruby and that usable in any implementation as opposed to having to deal with interfacing with some other library. And there may--you know, XML may not be a good domain for that but there may be other ones. I think the maturity of the language will be in part measured y how many libraries are written in Ruby itself and how infrequently we have to go out and interface with other code. And I think that there’s an interesting objection to that which is that if the code already exists in this other library, why would you do it differently, why would you try to re-implement, why not use it? And one of the responses that I would suggest to that--there’s an interesting guy who blogs at Alarming Developments, that's the name of his blog, he recently posted about making a Darwinian licence. Basically, that he’s going to license his future software under this licence that makes it so that you can’t use it after a certain amount of time. His assertion is that because significant software is not re-written often enough, we’re burdened over time with the mistakes that were made previously. So, I think that's a very interesting perspective--that we learn everyday and we wouldn’t necessarily write a program today the way we wrote it 3 or 5 years ago. So in less, we’re actually trying in Ruby to re-write some of these libraries and do it with modern ideas and in a way that takes advantage of Ruby. I think we’re always sort of tying ourselves too much to the past. There’s definitely a balance but I think the idea that just because a library exists means that you need to use it is not the whole story. Evan: I guess the last thing I’ll say on one of the upsides of having Ruby--us using Ruby as much as we do and implementing a lot of the core parts in Ruby, I’ve had people come to me and tell me--this is before, I had never even mentioned this idea, people were doing this on there own. “Oh, well when I want to figure out how a particular method works in Ruby, I don’t bother to look at the Rdoc anymore, I just pull the source up in Rubinius that’s in Ruby and I just figure out, ‘oh ok if I--this method takes 2 arguments and an optional 3rd one and if the 2nd one is a string then it does this behavior’”and they can just read it in our Ruby and figure that out and that’s a huge upside because now that code is the documentation that a normal ruby programmer could read and that has not been true in the past. Either they have to drop down to C and they have to sort of extract out what information they get from that C code, now its in this language that they understand and like and they can get a lot further along with that. Danish: So I know about Rubinius 1.2 came out recently so I’m definitely curious, you know, what are you guys working on now for the next release. Do you know what’s kind of coming in the future? Evan: So, we’ve--the next big release, we actually had 3 things that we--very specifically--that we wanted to get out and originally we weren’t sure if they were all going to be in one release and it looks like now they are gonna sort of be in one big, big release. We don’t know what number that’s going to be. It might be 2.0, it might be1.5, I’m not really sure yet. But those are Windows support so we’ve sort of haven’t had Windows support because Brian and I and the rest of the community really didn’t have enough Windows knowledge to bring it up to date up til now. Danish: So is this because of Dr. Nic kind of? Evan: That didn’t hurt. That’s for sure, that didn’t hurt. So, with the support and you know, Brian’s doing a great job on that, basically slogging through and figuring out where we have a lot of Unix-isms and figure out how to make the code agnostics so that it can be used on Windows as well. 1.9 support and codings and syntax and the whole kit and caboodle for 1.9. The third one is real true concurrency. So, previous to now, Rubinius has had a global lock, sort of like 1/9 does so its used the inner threads but had a global lock that prevented code from actually running synchronously. So if you had 2 threads that were say, doing some math operation, only one of them would actually work in lock-stat because they’d actually have to be holding the lock in order to do the work. So we never really liked that--we always wanted to get away from the idea so we’ve really finally just bit the bullet and started on the process of tearing that out and replacing it with the ability to run those things concurrently and that means basically protecting the rest of the stuff with locks and going through and making the whole thing concurrent. So, those are sort of the 3 big ticket items for the next big release. Brian: Yea, I think this is one of the areas with Rubinius that is interesting. So, for a couple years now, we’ve been working on essentially, infrastructure. Making sure that the architecture of Rubinius is really solid. And I think one of the interesting things for me is Evan’s been doing all the concurrency work but I mean, when you initially mentioned that you were doing it, it seems like it was about 3 weeks of work--like heads down work and then most of the specs were running. And then over the last month or so, intermittently fixing some concurrency issues but now we have, like all the specs that run on master and are also running on a concurrency branch Hydra--we’re not seeing any significant thread issues after the recent work so the full concurrency in Rubinius is something that is going to be a great advantage to developers and the amount of work necessary to actually implement the feature was not tremendous given how much work went into the infrastructure. Evan: And maybe I shouldn’t say this in a public forum like this but I kind of did it--I have a bad predilection for doing things on a dare. So, the concurrency stuff actually kind of came as--we were on the IRC channel one day and it kind of came as a dare, like “I bet you can’t add concurrency.” It wasn’t a direct dare like that but it was basically like--it got me, we were talking about it and it got me thinking and I was like, “Well, I’ll just sort of do it as a spike and see how--how far can I get in the shortest amount of time” and if I can get a significant distance in say, a few days, then I know that its worth doing now and that’s sort of what happened. The architecture is always organized around--because we wanted to make it able--we don’t have this yet but we wanted to make it possible to embed Rubinius very cleanly in another application. That’s a feature we haven’t gotten to yet but I laid the foundation for that at the very beginning so because of that, that exact thing spilled over into the idea that it doesn’t--has almost no global data. It uses everything that’s thread global, it passes almost the entire state down the call-stat is doing things so all those things we had been planning to use all along sort of came to fruition when we actually wanted to make it concurrent. Brian: The interesting thing about that--on a dare, the JIT almost came along very much in the same way, right? It was like Rubinius uses llvm, the Low-level Version Machine project to generate native machine code and the advantage of that is we can get 2 or 4 X, so 200 or 400% better performance and there’s a lot of work left to be done on it but its very, very valuable. Its the thing that will make Ruby very fast. And a couple years ago before the current implementation, we had talked about in IRC and stuff like inlining like, “oh man, how do you inline methods?” so one day Evan just is like, “I’m going to go ahead and try inlining” and by the end of the day it was essentially working. Of course there were bugs to work but it was like, it was sort of on a dare and its an extremely valuable feature for Ruby, extremely important feature and it basically landed in a couple of days because Evan just thought, “You know what, I’m going to try this and see if it works” and it worked. Danish: Great. Well thank you guys. I really appreciate you guys taking the time to do this podcast for us. Evan: Thank you. Brian: Thank you very much. http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/13/cloud_out_loud_rubinius.mp3?1299203914 Fri, 04 Mar 2011 01:58:35 +0000 no S01E12: Mike Wolfe Engine Yard S01E12: Mike Wolfe We interview Mike Wolfe and talk to him about his new startup ccLoop and how he's been able to become such a successful entrepreneur Marcy: Hi I’m Marcy Campbell, vice president of sales and marketing communications here at Engine Yard and I’m with my really good friend Mike Wolfe who is CEO of a new start up called ccLoop who is also an Engine Yard customer. Mike and I have known each other for a long time, since-- Mike: I think 13 years? Marcy: Is it really? Mike: Yea. And we’re still young. Marcy: And we’ve worked at two companies together--Yes we’re very young--and on a board of a company where I was an advisor and you were actually a board member, right? Mike: Yea. Marcy: So, we have a lot of history together but for all of our listeners, maybe you can tell us a little bit about your background. Mike: I have--I’ve done almost entirely start ups in my career. I started computer science in college. I did a lot of teaching and actually considered becoming a professor and then realized that I hated research and was never--I have trouble writing a one page white paper now so I was never going to be a researcher-- Marcy: That wasn’t going to be a good choice. Mike: But, I did a lot of teaching, I had some internships and really loved that intersection of technology and application and business. How you take technology, build a product, get it to market, get good--that whole process I loved and it really fascinates me. I’ve done--this is my 4th start up. All 3 have been successful to different degrees. The first was a small Internet media company. I was employee number 2. It was back in 1994, one of the 1st Internet media companies that there was. Pretty successful. You know, built some great products. We were very, very early but--that was kind of right around the time of the Netscape IPO. Marcy: Right. Mike: Which you remember--you were there. Marcy: I was there. Mike: And really kind of got hooked. Did a company after that called KANA which was an email--basically an email CRM company. Marcy: And that’s where we met. Mike: Which is where Marcy and I know each other. Great story in terms of great team, great growth. Again, really feeling like not only is this--the web just a really great business opportunity but really feeling like--this is gonna sound corny--but really feeling like the world was changing. Really feeling like there’s pre-Internet and post-Internet and I think if you take the last 20 years, the--just the things we take for granted now, none of us were imagining, kind of, in 1993/94. So really got hooked and just kept doing it and decided after Vontu, which was my last company, which was a company I co-founded in 2002 and ended up selling the company in 2007 to Symantec and spent a couple years at Symantec on the executive team there. Decided that--I thought about doing a lot of different things--become an investor, there’s always different career paths, and I really just love the start up thing and decided to start another company. I went back to Benchmark Captial, I was an entrepreneur in residence. Benchmark funded my last 3 companies now so I have a good relationship with them, spent a year at the firm and ccLoop was the outcome of that and the companies about 4 months old and we’re doing great. Marcy: And what are you doing? Mike: So we’re still in stealth mode so we’re not getting into a lot of details about the solution availability just yet. But the problem that--one of the problems that always fascinated me is email so my 2nd company, KANA, was very much an email company. It was very much email marketing and email customer service. Vontu was very much around email security. It was very much around trying to keep data from escaping your company through email and through other web channels. And to me, email is the gift that keeps on giving. Email is--people--if you talk about email you get an emotional response from people. Marcy: I think that’s right. Mike: People love, people hate email--they say they hate email. They complain about too much email. They complain, especially when you’re working with sets of people, when you’re working with a team of people--they’re all replying to each other, attaching documents, you have this inbox full of stuff that you haven’t read. You get off the airplane and have 50 new emails--like we have all had that experience, so people hate email. But, people actually love email and they love email because they know how to use it, everybody that they work with knows how to use it, they have it on their phone now. It’s very personal--its their stuff in their inbox. So what we’re trying to do, we’re trying to let people work more effectively with other folks and get rid of the giant inbox, the multiple versions of the same attachment floating around, not having a shared archive of the work that you’re working on with other folks. But doing it in a way where we’re actually building on top of the email people already have. So we’re saying we’re going to make your email work better, especially better with other people. But we’re not going to do it by asking you to stop using email and go into some other collaboration system and move all your work there and then asking everyone that you work with to move their work there. That really--very few companies have really done that successfully and more and more companies are launched trying to tackle that problem. We would rather tackle the problem of making email better as opposed to telling people, throw your email away. Marcy: Yea, I think that’s not realistic. Yea, so email is platform to do collaboration? Mike: Right. Yea, online email is a platform. Marcy: Yea and we believe that. Mike: You can build great things on email but you don’t--like I look at Google Wave for example. Google Wave tried to do better email essentially but the 1st thing that Google Wave did was ask you to stop using email. Marcy: I know. Mike: And it was out of business 6 months later. We just don’t think that worked. Marcy: We don’t want to do that. Mike: So we’re not doing that--nothing like that. Marcy: When you were at--when we were at KANA and at Vontu, you--the technologies you chose to use at the time were leading edge right? So you were using, you said I think Java and Windows or-- Mike: Yea. Back at Vontu or at KANA, we were really one of the first enterprise software companies to use Java, way back in 1997. At the time, you know 13 years ago, that was quite cutting edge. No longer quite true. Marcy: So you went to Vontu and when you started Vontu you used Java as well, right? Mike: Right, right, right. Marcy: So what’s interesting to me is then you go back in as a entrepreneur in residence with Benchmark and you come out and you start using Ruby and Ruby on Rails. Why? Mike: Yea. So, I think that the more you do this--I think when you start your career you think that just building products is--if you just build a good product, people will buy it people will use it and just pick a tool that gets the job done. And I think that as you get more experience, what you discover is that the ability to first of all, get the best people on the team. The ability to get the best developers who love using the latest and greatest, they love using tools that kind of where the tool gets out of the way and the language kind of fades to the background and lets them just solve problems. The ability to build a great team by giving them the right tools. Its a virtuous cycle. You can bring in better people and those people are more productive because you’re using--if they’re willing to learn something new, which our team did. Our team was a lot of Java developers who all wanted to learn Ruby on Rails and I swear within a week, they were more productive on Ruby on Rails than they ever were in Java even though they had been doing it their entire career, just because they’re great guys and the characteristics of the framework. The other thing is that start ups are all about iteration. Its all about try something, get it out there, gather feedback, gather data, go back, change it, fix it, get it out there again. The more the--the easier it is to do those cycles, the more successful you’re going to be. So people talk a lot about rapid development which in Ruby on Rails you get the rapid development but what’s even more important we think is really these iterations. Its the ability to quickly try stuff, get it out there, make it work, make it scale, put it on Engine Yard. If you want to try something you just put it out there, you don’t spend a lot of time configuring and tinkering with it. And it makes the company act in basically a faster metabolism. It lets you just try stuff, experiment, get things in front of customers, in a way that these more established, kind of structural languages don’t. Those just tend to take--they’re more designed, there’s more code, more testing, more things to go wrong. So Rails--and its been great for us. We haven’t had a really--very few disappointments even though we’re all relatively new to the Ruby on Rails community. Marcy: Well we’re glad you’re a part of it. One of the things I wanted to ask you about was, through the differences you saw between building a company in 1997 and the differences in building a company now in 2010, well 2011. Mike: I think the differences are--there are a lot more people around that have seen this movie before. Folks who have been at a lot of companies, have seen what works, seen what doesn’t work and the community is just a lot smarter. There’s so many resources out there where you can learn about technical things, you can learn about how to raise money, how to operate a company, how to do customer development. The resources available are greater than ever so I feel like the ability to put together a team that’s really smart and connected is probably better than its ever been. Unfortunately, there’s so much demand for those people that that also the hardest part still, is to build a team. I also think this acceptance that start ups are not about coming up with a plan, spending a year building the product, launching it, selling it, and everything works out, that very seldomly happens as we all know, optimizing around this real experimentation and really trying things in rapid iterations. Like for example, we do weekly, really weekly sprints in our development process and monthly releases in terms of what we get out to customers. Not only does that facilitate the learning, but it just keeps the momentum going. And I remember back in ‘97 we were talking in terms of spending a year building a product, spend another year learning how to sell it, then you build the 2nd product a year later. Now its every week there’s something else going out there and we just see how the customers react to it and then go accordingly. And I’m kind of a short attention span person so I actually really enjoy that. Marcy: Yes, it works for you. Mike: I enjoy that constant feedback and constant iterations. Marcy: Yes and no more laser tag parties after the release of a product, huh? Mike: We’ll do that. We’ll still do that. Not every week though. Marcy: Not every week? Ok. So one of the things I’m sure our listeners want to know. You know, you’re an incredibly successful entrepreneur. The companies that--I know you’re very modest--but the companies that you’ve built from the ground up and I’ve been in the basement with you guys a couple of times building these things, have become enormous suceesess, where people all over the world know the products and know the companies and--why do this again? I mean, you have a lot of choices in your life right now. Why would you go and say, “Oh the next thing I’m going to do is start another one.” Mike: I’ll give, probably, kind of a long answer. Marcy: That’s fine. Mike: I--so for me, start ups are--there’s a certain amount of drama to a start up. In fact, there’s a lot of drama to a start up. I can tell by the way you’re laughing, I know that you’ve seen some of it at every company. And I’m not talking about the drama of things going wrong, even though that does happen. I’m talking about the drama of you get a bunch of people together, you’re trying to do something new, and there’s kind of a beginning, middle, and end. At the beginning you have all these ideas, there’s no legacy, no baggage, no politics, anything is possible. You get to work, try stuff, you tinker, you experiment--if that works , you kind of get to the middle part which is where you’re really building the company, getting customers happy, building the team, really getting the culture right. And usually there’s some kind of end and the end is hopefully the kind where the company just gets so big and successful its no longer a start up and you’re off and running or the company gets acquired or it could shut down, hopefully that doesn’t happen but it happens--it happens all the time. And first of all, I think the drama of being in a situation where you just don’t know what’s going to happen. I mean, the company could be a billing to our company in 5 years or it could be out of business in a year. I really enjoy the not knowing that. I think that--I think at a lot of big companies, if you do a great job, the world will be 1% better next year, if you do a bad job the world will be 1% worse. I love the idea that just--you just don’t know. There’s just all this uncertainty, all this risk, but it could be something great. And I think what that does is it brings out the best in people. You get people together who are so focused on making that happen that they spend all their time outwardly focused, trying to make customers happy, build great products, understand competitors, all kind of pulling together for a common cause. You see people, they do there best work, they take on new roles, they try new things. People at my companies have always said, “this is the best job I've ever had, I’m learning all this stuff, this is so great” and I feel like in bigger, more established situations, its a little more zero/sum game, kind of slicing up the pie so you end up with the--your enemy is in the next cubicle because you’re fighting over a budget and its very much of a--there’s a pie or even a shrinking pie in a lot of companies and who’s going to get the biggest piece. So I think that big companies can sort of turn--it can bring out the worst in people and small companies, I think, bring out the best in people. And when its really, really working there’s just nothing that--there’s nothing that’s more fun. Marcy: Yea I agree with that. I mean, I’m completely addicted to the smaller companies as well. Mike: I mean, once you’ve been in a really good one, you almost can’t do anything else. You almost just want to keep going back to it. Marcy: And so you just keep starting up. Right. any advice that you would give folks who are just starting out, just building out their companies, first time CEOs, or first time founders? Mike: I think--the first advice I always give people is--now, I’m a parent, you’re a parent and we know what that’s like and a lot-- Marcy: It’s wonderful. Mike: It’s wonderful. A lot of folks will say that there is never a good time to have a baby. There’s never going to be a time in your life when you have all this money and all this time and all this free--like, its just kind of like now is always the worst time, now is always the best time. And start ups are a little bit like that where, if you want to get in the start up world, you’re never going to have an idea that’s perfect, you’re never going to join a company that’s perfect, there’s never going to be a company that’s a sure thing, there’s never going to be a time when you have so much money in the bank that you can take any risk you want. There’s sort of--the right answer is almost always just to jump in and do it and do it now. Don't wait until it feels--don’t wait until a bunch of variables line up because they never will, you just have to do it. And that might mean joining a company. I’m a big fan of people who want to get in the start up game--you don’t have to start a company. You can find a small company, join, learn, get to know the people, then you can go start one later or you can jump right straight into starting one. And the second thing is once you’ve done that, its really, its all about the people you’re working with and most companies don’t work. The odds are very low, especially if its your first company, its going to work. So usually what you take away form that company is a bunch of experience, a bunch of friends, a bunch of people you might want to work with again. You want to get to know the Board of Directors, the investors, the customers--every situation is an opportunity to build that network and make sure that even if the company doesn’t succeed, you walk away feeling--with your reputation in tact, your network is growing, you’re getting smarter. So I think of it as a journey where you want to get something great out of every interaction with somebody and out of every situation because even if the situation you’re in right now doesn’t work, the next one probably will is long as your attitude is keep learning, keep getting to know people, it just gets easier and easier and the odds get better and better each time. Marcy: That’s fabulous. I think that is--exemplifies my experience as well and I’m someone who jumped into companies that already existed at a very small level and helped them grow. Marcy: Yea. One thing I didn’t ask you is ok. What is the most fun you’ve ever had starting a company. Give me an example. I want a story. Mike: I--its kind of like which of your kids do you love more. Its hard to pick and chose. Marcy: Yea, I got teenagers but go ahead. Mike: I would say that in terms of early stage, the stage my company is right now. Right now where we love the idea, it feels good, we’re making progress, everything feels good but there’s still all these unknowns ahead. At the early stage, right now is probably the most fun I’ve ever had at any company. I think the team is great. The idea feels big--its an idea that everybody relates to. Marcy: Yea. Mike: Its actually a challenge. Everybody I meet, i can pitch them the idea and they understand it and get it and want to become a customer. It’s almost everyone in the world--there’s 2 billion people using email right now. There are 100 trillion emails sent per year. Marcy: So that’s a big market. Mike: 300 billion emails per day. So, that is a problem that everybody relates to and everybody understands. So, this is probably the most fun I’m having early stage. I would say there’s something else that happens--when a company starts to work, you get 50 or 100 people, you get all the different cast of characters, you get the crazy outgoing sales people. Marcy: Yea? No.... Mike: You get the intense engineers and the crazy marketing people and the folks who travel and--there’s kind of a stew of different ingredients and personalities that even though they’re all different, it somehow just works and when its really firing in all cylinders, it just feels great. Like I remember when Vontu was about 60 people, we all went on a ski trip together. And it was just kind of--the company had already gone far enough that we knew we were going to have some level of success but it was still small, still a lot of upside. And i have just great memories of that--still that idea that anything is possible but also being with just this incredible mix of people whoa re all very different but were all there for the same reason, pulling in the same directions. When that’s really working--and that doesn’t last. A lot of companies that only lasts a year or 2. You usually don’t get that your entire career. Marcy: Right. Mike: But when its working, its just the greatest thing in the world, and you always want to get back to that. Marcy: You know, my husband and I were talking about that last night. For disclosure, Mike is a triathlete and a long distance runner, an ultra runner and my husband’s a triathlete and they’re friends and he was telling me its about being in the zone. Mike: Yea, that’s what I should have said. Marcy: Yea. Mike: Companies get--you always kind of are going in and out of the zone. Marcy: Yea. Mike: You have good weeks, bad--like even, like I had a good week a couple weeks ago. Last week I felt really bad, this week I feel really good. But sometimes companies get in the zone for 6 months or a year or 2 years or 3 years and it just kind of feels like everything is in balance and when you get there, you know it. Marcy: You know it, right. Mike: And you want to stay there. Marcy: Yea and you try to stay there. Well I really appreciate you taking the time to talk to us. This has been a great learning experience. We’ve known each other for a long time but, I’ve learned something new here so that was great. Mike: I learn something new every time I talk to you Marcy. Marcy: That’s kind of scary but, oh, ok. So great. http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/12/cloud_out_loud_mike_wolfe.mp3?1298600574 Fri, 25 Feb 2011 02:22:55 +0000 no S01E11: Obie Fernandez Engine Yard S01E11: Obie Fernandez We interview Obie Fernandez and talk to him about his new book The Rails 3 Way and how he started his consultancy Hashrocket Dr. Nic: I want to introduce today’s guest through a series of deep, probing questions. Obie Fernandez. Is Obie your real name? Obie: No. It’s not my real name. Although, what is real after all? Dr. Nic: That’s--perhaps you’ve got a reference for us, perhaps--Getting Real. I wonder if that’s covered--naming? Is naming covered in the Getting Real book? Obie: I don’t think that it is but its better to avoid trendy names, when naming. Dr. Nic: True. Well, unless its a trending name or you are the trend. Obie: Or it has trended. Dr. Nic: There are some classics from the early 1900s, there’s retro.....So where did Obie come from? Obie: Obi-Wan Kenobi I believe. Dr. Nic: So that’s--ok, so what your real name? Obie: Obed. Dr. Nic: How do you spell it? Obie: O-B-E-D. Dr. Nic: What’s your social security number? I’m sure I can look it up with the Internet. So, say hi to Obed. So how did it become Obi-Wan Kenobi? You wanted it? Did you make up your own name? Obie: No, because people kept asking me these questions about where my name came from and I got tired of it. Dr. Nic: I do remember you saying Obi-One--was that your IRC or something? Obie: Obi-Wan. Dr. Nic: Alright. Is there anything gratuitous you would like to promote to our listening audience? A new book perhaps? Obie: Yea, there’s this really big, its kind of obnoxiously big-- Dr. Nic: It is huge. You keep talking while I get a page count. Obie: Yea, the 4 hour body--It’s just a huge, huge book. Someone sent me 2 of them for Christmas. I’m not sure why they sent me 2 but I don’t actually know who it was because the gift card was missing. Dr. Nic: Someone sent you--are you referring to your own book or are you just trying to flog off stuff you got for Christmas at the moment? Obie: I was talking about Tim Ferris’ book but--Oh you meant my book? Dr. Nic: That’s right, let’s do a white elephant store--yea I got a whole bunch of stuff for Christmas I don’t want. Obie: Yea, The Rails 3 way--The Rails 3 Way, not the Rails Three-way. Apparently American audiences cannot hear three-way without thinking of sex. Dr. Nic: Only American audiences? I’m competent of that same thing. Obie: Perhaps Australian as well. Dr. Nic: We’ve all watched this--we’re all Americanized. That’s probably it. Obie: But I don’t get it. You don’t laugh when you talk about a three way switch. Dr. Nic: To be honest, we don’t talk about three way switches. Obie: We’re talking about my book. Dr. Nic: What is a three way switch? Obie: A three way switch is-- Dr. Nic: Oh, like one a wall. Obie: Like on a wall, yea. I figured the snicker or laugh would not be a bad thing because at least people would be-- Dr. Nic: So I’m flicking through the book and there’s no fold out section, which I would’ve thought a book on the three-way would have-- Obie: The centerfold has the table of response codes in there and their Rails equivalent. Dr. Nic: Yea its been a long time since I’ve read sort of--men’s literature, but would there be like an Obie profile of favorite--ya know, that’d be great for an interview such as this so I could just review and go, “What’s your favorite animal?” with having you--a spread out picture of Obie. Obie: It’s not The Obie Way--some people have said that the book should be called The Obie Way or the HashRocket way. Dr. Nic: It is--it does make a stance on certain topics. Doesn’t it? Obie: It is opinionated. Dr. Nic: It is opinionated. What-- Obie: I think Rails is not opinionated enough anymore. That is my opinion. Dr. Nic: Well, and some of them are different--they’re still defaults. So what are the differences? What are your opinions on what we should be doing as Rails developers other than the standard kit? Obie: In a nutshell? Rspec and Haml? Dr. Nic: Well not in 700 pages. Certainly not. I don’t want that. Sorry, Haml and-- Obie: Rspec? Dr. Nic: Rspec for unit testing or what? Or also for integration tests? Obie: I actually like Rspec integration test because it means I don’t have to internalize and know a whole other technology like Cucumber. Dr. Nic: Well, Cucumber is English so its not entirely another technology. Obie: Yea. Dr. Nic: And.....its not even about British English its Old English. Obie: Its considered another knowledge set that you have to--another mental mode that you have to be in. Dr. Nic: But I thought-- to me that’s-- Obie: Some people think that’s a good thing. Dr. Nic: That’s right. I mean, there’s a conversation that came up in Ren’s session at RubyConf and someone said it was helpful because you could--it actually facilitated you changing your mental perspective at the time of writing your integrations test. Obie: That’s right. Dr. Nic: Close to thinking like a user. I’m gonna say that someone else said it, but I was thinking the exactly same thing at the time. Obie: It sounds good. And I like that line of thinking--its good for talks and clients. Dr. Nic: Ok so clients. Why--I mean, I know that was actually one of the things when Rspec came out, excuse me Cucumber--”oh, you can give you Cucumber scenarios to the users--to the client to read them. We didn’t have a lot of success, I know, when we used to do that. It sounded good. Obie: It did sound good but, using history as an indicator at Hashrocket, I mean, that’s not generally what happens. Generally, even that, is too technical for the clients to digest on a regular basis. Dr. Nic: So where is--overall all the projects you run a consultancy through Hashrocket, you guys have had how many different clients? Obie: I think at last count its over 80. Dr. Nic: Over 80 clients, over 3 years? Obie: Yea. Dr. Nic: So, what has been the way you sort of end up interacting with clients on a regular basis? How do they know that the project is going they way it should--that they’re happy with where its at? Obie: Well Pivotal Tracker is the backbone tool and is the skeleton for the process methodology that we use. Dr. Nic: So like, you have a version on staging that they go through and accept they’re sources? Obie: Right. Yea, so very low ceremony iterations. There’s a back log that is constantly being worked on by the development team and their--as they finish functionality, they push it out to staging. Dr. Nic: The kick their asses better to accept things. Obie: So to speak. Yea, its really important to keep the clients engaged and accepting stories on a daily basis. That helps in a lot of other ways as well. Dr. Nic: Put in context for those listening, Obie runs Hashrocket--there’s a small little thing called Hashrocket that some people have heard of. I myself used to run a larger, more majestic consultancy called Mocra. Obie: That subcontracted to Hashrocket. Dr. Nic: Yea, so in a few words, just cover this. Because I think we should cover this competitive tension that, you know--rife. Just say a few words--why was my consultancy better than yours? Obie: Well you had to save our bacon. Dr. Nic: No, obviously its alright. That was just for my amusement, unless you have an answer. Obie: THat’s the best I could come up with and unfortunately it was a lie. Dr. Nic: Oh. That hurts. Obie that hurts in all many sorts of places. Is running a consultancy hard? Obie: Its hard enough. Its a constant treadmill. So, I would say if you like to have a--its certainly a job. I don’t know. What--elaborate on the question. You certainly know its hard. Dr. Nic: Its obviously loaded and I know some of the answers. In what ways--is it--why should people go--actually let’s do it in a positive sense. Obie: Ok. Dr. Nic: Engine Yard, I know, a bunch of our business comes from our development partners, amongst many of them Rails consultancies, others are digital consultancies and so they have a different intent. So, its in our best interest that they’re are more Rails developers evolving from just being developers to running their own consultancies and spreading the word, etc. Obie: Sure. Dr. Nic: But I know its not all just happy times. Obie: No. Dr. Nic: So, how does a developer go from being a developer to, ya know, starting a consultancy. Is there--how did you go about it with Hashrocket? How did other consultancies do it? Obie: It helps to have a backbone client. By which I mean an initial client that is supportive of the idea of you taking their team and turning it into a consultancy because they’re going to get some benefit from doing so, which is essentially what happened. We were--I was leading a team of 4 including myself, working on a product called CityClick and after about a year, that was frankly getting a little bit boring for me and I wanted to do something else. The book had just come out so we were celebrating that and I saw opportunities to leverage the notoriety I was getting from the book to get clients so I went to my client at the time and said, “Hey, now would be a good time to back me in starting a consultancy” and so that’s how that came about and I think that’s a fairly common story--for that to happen basically. If not directly going into business with your client basically using a particular backbone client to bootstrap a consultancy especially if you’re able to grow your team, just slightly above what you need to service that backbone client so that they--they mitigate your risk, the big client, then you’re able to start taking smaller projects on the side. An then the way that we really got off the ground was through some marketing slight of hand around the 3-2-1 Launch concept. Dr. Nic: That was exceptional. Obie: Yea. Dr. Nic: I don’t know if it made you any money but, you know-- Obie: It was kind of a wash money-wise because even though I wouldn’t have--I would have been hesitant to admit it to you at the time, it was trying to constrain all 3 variables of time, scope, and-- Dr. Nic: Which we’ll probably all 3 talk about. Obie: We will talk about--No you can’t do that. Even though I did my best to explain to the clients that the scope was going to float, so that the scope variable was going to float in the sense that we couldn’t guarantee to you exactly what we were going to be able to launch but it was going to be within the constraint--which may have been explicit, I don’t remember very well, but it was always with the conceit that we would launch something at the end of the 3-2-1, hence 3-2-1 Launch. And there were some other very interesting, unique aspects of it. For instance, Tammer, who’s working here at Engine yard now, at the time he was at Thoughtbot and we brought him down to work on a 3-2-1 Launch as part of our program. Dr. Nic: Yea he had the--how big was Hashrocket at the time? Obie: At the time that was going on, I mean we were, probably half a dozen people. Dr. Nic: So having sort of, novelty people come in. Obie: Having novelty people to expand our brain power and new blood and new ways of thinking and it was quick and easy--it was relatively easy to convince people to come down and do that because it was a very low commitment kind of gig. Dr. Nic: Come work at the beach for a week. Obie: Come work at the beach. I think I was paying 3 grand per person for essentially 4 days of work. So its fly in on Monday morning and work for a solid--so basically get up to speed on Monday, work for a solid 3 days. Those 3 days might be a little bit over hours but not too much and then celebrate on Friday. And then that was the bulk of implementation work for the projects we’re doing BUT the brilliant part about it was not necessarily the execution. It was the splash that it made in the market. A lot of people talked about it and it gave us--it bought us some attention. Dr. Nic: Yup. Alright well, yes. Certainly it seems so from the outside. Obie: We did 8. We did 8 of them over the course of probably 6 months if I remember correctly. Dr. Nic: No doubt. Well, you’re a new business and I’m not sure if people who are not in business recognize that. It quickly becomes a lot than just writing Rails apps. Obie: Oh yea, for sure. Dr. Nic: There’s paperwork, process, controlling/managing clients-- Obie: Collections. Dr. Nic: Collecting money. And the timeliness of collecting the money because typically your staff don’t like to be paid the same time that you get paid from your customers. Obie: Right. Dr. Nic: They tend to--yea definitely. Obie: It wasn’t a cheap enterprise to start Hashrocket. We essentially lost or invested, as you will, ¾ of $1 million to the first year, so that was the initial spend, which, you know-- Dr. Nic: Is there a discussion? Like at the quarter million mark, was somebody supposed to say, “Hey Obie-- ¼ $1million, how’s that going over there.” I mean, where’s that number. Obie: No, about half of that amount was the initial commitment we had discussed and then the rest of that of amount was the amount that we went over and were there discussions? Sure, they weren’t--I don’t remember them as being particularly difficult discussions, it was just something that we needed to do. Dr. Nic: I mean we have going signs, metrics that show that things were actually going well. Obie: Oh, absolutely. I mean things were going very well so, you know, there wasn’t too much of a hesitation I would say. There was certainly thought put into it--there was risk in doing so but it didn’t feel particularly risky. Dr. Nic: I mean, at the time you had--I used to think there was a number of bottle necks to a growing consultancy, 1 was getting staff because you were restricted by how much work hours, because you sort of bill by hours, getting clients, and now I can’t remember what the rest of them are. I used to be very proud of my list at the time. Hashrocket seemed to be able to get staff pretty easily or was that just from the outside or was it--did you get a lot of quality people wanting to come down? You were sort of not really in a major hub. Obie: Yea, you could say that again. The--but we did have the beach. That was our secret weapon so we recruited a bunch of people from where there was no beach. Because people that are not from the beach, myself included--so I was in Atlanta at the time I met Mark and Mary, my partners and I started coming down there to contract for them and just kind of fell in love with the whole living at the beach vibe because I hadn’t lived at the beach before. Loved the ocean and still do. I mean, I have a wonderful place on the beach. You can see the sunrise. I think you’ve probably event stayed there, right? So you know what I’m talking about and there’s certainly a copious amount of pictures out there but there’s this romantic notion of being by the ocean and everything like that and you can use that to get people down and we certainly still do. Now whether you can keep them long term is another story because the extent of the culture at the beach is--are surfers and skateboarders and bleach bimbos and things like that. Dr. Nic: Yea. And those 3 aren’t necessarily the same group of people that become Rails developers. Obie: No, not at all. Nor do they want to date Rails developers so-- Dr. Nic: Aw that hurts Obie. I’m happily married so that’s irrelevant to me but--now, so we finished that conversation. We talked about hiring. So what else? So marketing you did the 3-2-1 which is really cool and its--I know at the time people laughed about it being the largest and--I know ThoughtWorks was running around saying how wonderful Ruby was and it was 40% of their work in some 2007 or something there’s going to be a Ruby-- Obie: Right. Dr. Nic: I mean Hashrocket in those days certainly seemed like the biggest active brand that seemed to be growing. Obie: Right. Dr. Nic: Do you remember what other things you used to be doing back then? Why it was working so well? Obie: We certainly set out to be the best so, we had an internal mission statement to be the best Bleeping web consultancy period. The period was just punctuation, we didn’t actually say period. Dr. Nic: It came later. Someone needed to spell check it. Obie: It felt like we were scaling that mountain pretty effectively and people would come down, particularly in the first year and a half we worked hard and partied very hard. First year, we were working really hard and probably partying every other night. It was very much an environment of drinking and having a lot of fun. So that was good in terms of attracting talent and people that wanted to live, breathe, and eat and drink. Hashrocket worked out really well. I gotta say over the years we matured and some of those folks got married, had kids, and then we hired other family people. Dr. Nic: It changes your life. Obie: It does certainly change--slow you down significantly and so probably now, light beer is the predominant drink instead of Patron or at least beer, I’ll say. Dr. Nic: Now I have an important technical question for you because you’re a technical person--you’re an author. There’s no segway into this--no segway whatsoever except that I just got told that I have 2 minutes left or I was just given the finger. One of the two. Technical question. Do you prefer Rails 1 to Rails 3? Obie: No, why would I? That’s not sensible. Dr. Nic: Ok. Now, actually a few questions from other people, before I get into the important topic of RMM. Ok so, unfortunately there’s just the Twitter tags and not everyone in the world do I remember what Twitter tag matches to their real name. But @RubyBusiness--how do you see large enterprises adopting Rails? Obie: I see it everywhere. We’re doing work for big corporations like Sony Ericsson, Routers, I could probably rattle off another half dozen big companies that we’ve done Ruby with. Dr. Nic: Is that something that as a business--Hashrocket, do they spend any time jsut monitoring outside the scope of your own pipeline, sales pipeline? I mean do you ever spend time pondering how to make Rails grow, just to make sure the-- Obie: No, I stopped kinda caring about that and I stopped the heavy evangelism once--I guess the way I see it now in retrospect, once Hashrocket started going, I kind of saw it as a competitive advantage. I thought it had enough of it to hold in the marketplace that it didn’t really matter whether people thought it was mainstream or not. It like--whether people were saying its mainstream or not, we’re seeing the adoption, therefore, I don’t really care what the perception is. We’re using it to great effect and we’re charging big bill rates and getting a lot of great, fantastic projects with it. Dr. Nic: Has it kept growing? Obie: You know, my mindset is I don’t really care--I mean now, what we’ve-- Dr. Nic: Ok, has the type of customer you get evolved at all? Do you still get the same type of business, the same type of client? Obie: Its changed in the sense that, in the beginning as you would expect a lot--the referrals we were getting, the incoming leads that were coming were due to the book and due to the reputation in the Rails community but now the majority of the business that we get is straight up referrals where the client doesn’t know anything about Rails. Sort of--to give you a better example, we used to get calls in the first year, so this would’ve been 2008, and I kid you not, one guy even told me, “I’d like a Rails app, like with the rounded corners and the AJAX” Dr. Nic: I love the rounded corners and the AJAX. I’ll be honest, that’s one of the reasons I went to--picked Rails because AJAX was harder than .NET and with Visual Studio, I had no idea how to get the rounded corners and they seemed very important in 2005. It was still a bit behind the curve to be asking for that in 2008 but you know, obviously we had rounded corners and we had AJAX. Every-one's got rounded corners now. Obie: There’s not too much of that now. Now its kind of more serious. Dr. Nic: We’re back to normal corners now. Obie: The technology isn’t so much the focus and it should’ve never been the focus. The focus should be on the execution. Dr. Nic: Well a niche is a niche. As a community, you’ve gotta pick--if a community forms out of passion then businesses will take advantage of that passion and in the whole chain of things from do you want a web app to do you want it through Hashrocket, the passion was around Ruby specifically. Obie: Right. I will tell you one thing, there’s huge numbers out there. You and me and kind of, the group of early adopters and loud mouths that are the most visible within the Ruby ecosystem, we’re just the tip of the iceberg. There’s an enormous community of people using Rails who don’t blog-- Dr. Nic: Don’t go to conferences. Don’t blog. Attempt to use it on Windows. Obie: There not mentioning it on Twitter all the time, they probably don’t even use Twitter. Dr. Nic: They have normal jobs, probably go out and play golf on the weekend. I actually have no idea-- Obie: They don’t drive expensive cars. Dr. Nic: No, that’s me. I have a Toyota Sienna. I look awesome in it. Its tremendous. If Toyota ever wanted to sponsor me to say things like that, that’d be awesome. I have a seasonal question. Dr. Nic: You’re on the old Working WIth Rails chart. Obie: You’re stuck just behind me. Dr. Nic: I’m stuck just behind you so you’re currently number 2 but mostly importantly, at one stage you were number 1. In fact, I think you were number 1 and number 3 or something at the same time. What--how did you manage to achieve the feat of having 2 spots? Obie: I think Zed was number 2. So, there’s never been a number 1 other than DHH? Dr. Nic: Really? Zed never got to number 1? I thought Zed got to number 1? Obie: No, I don’t think he got to number 1. Dr. Nic: Because I think he had a blog post that said, Make me number 1. Obie: Oh, make me number 1. That may have happened but i think some of those got disqualified and then he got fed up or bored and wanted to take it up so he changed his name on the site to my name so then I was number 2 and number 3 or number 1 and number 2 or something like that. And then, some people asked me why I had had hacked the site to be on there twice which i just thought was a wonderful indicator of those people’s intellectual capacities. Dr. Nic: Do you think you could ever get Zed back? Obie: No, Absolutely not. Dr. Nic: Is Zed lost forever? Obie: He’s lost forever. Dr. Nic: He’s lost forever so he’s personified us and decided that we’re not lots of different people. That we are one person with one unique ability. Obie: Zed is extremely opinionated. Dr. Nic: I’ve never met Zed. Obie: Really? Dr. Nic: So, I love-- Obie: We should go to drinks tonight. He lives here. Dr. Nic: Oh ok, awesome. Obie: But I know Zed pretty well. We lived together for 6 months. He was involved in that CityClick project before Hashrocket came about> Dr. Nic: Oh, so you were one of the people who didn’t pay him or something? No? Obie: No, I was the one who bailed him out when he was not getting paid. Dr. Nic: No I mean, I’ve been playing with the Mongrel 2 thing too and it looks great. I’d love to know--its annoying that its a project that has an inherent anti-Ruby bend to it. Obie: It’s good to know you guys are still supporting Mongrel. Dr. Nic: Still supporting Mongrel. Yea. Mongrel’s an important piece of technology that we’re glad still exists. Only because--let’s wrap this up. Ok, so the reason we’re laughing is because yesterday we had a deploy day here at Engine Yard--actually before we say Deploy day actually, can you talk about what it was because its as interesting for you to talk about what it was as for me to introduce it. Obie: Really? Deploy Day--we got a chance to deploy to Engine Yard Apploud. It takes some skills, I would say. Dr. Nic: I mean it was interesting. Have you ever seen any of your clients? I mean 80 different clients--do any of those businesses ever gone through the process of using their own app and sort of making an activity of it. Obie: Our clients? No. We are definitely the experts in AppCloud when it comes to our clients. Dr. Nic: That’s right. No, I don’t mean AppCloud. So we-- like I said we did AppCloud and we did a competitive platform as an example but have any of your clients-- Obie: Let’s say SalesForce, for instance, had a platform. Dr. Nic: Right, let’s say SalesForce had a platform. You’ve got the lingo. If its ok, you create apps for your clients. Do any of them as businesses, go through that same process of using their own app, experimenting-- Obie: Oh, well yea, of course they do. Dr. Nic: There’s too many levels of the word client in this conversation, its getting confusing. Obie: Forgot what you asked? Dr. Nic: I can appreciate that. So, CityClick as a customer, does Mark, etc.--do they sit down as a group activity go and use CityClick and say this could be better this could be worse, how do they-- Obie: The folks responsible for the acceptance of features as they’re delivered are all constantly using the app. And in a lot of cases the stakeholder is the same--is the entrepreneur, is the owner, is the client, so yes. The answer is yes they do they do use it all the time. That’s a very good idea--to keep them using it all the time instead of demos and big bang employees. Dr. Nic: Final personal question--personal. Obie: Oh God. Dr. Nic: Did you purpose to your fiance on Twitter? Obie: So I actually used the proposal on Twitter to distract her from the fact that I was getting down on my knee to whip out the ring. Dr. Nic: So if--she was geographically next to you at the time that you tweeted to her? Obie: She was standing next to me at the base of Coit Tower, overlooking downtown San Francisco and I said, “Oh Shit, have you seen Twitter?” which as I was looking at my iPhone, which she took to mean as there was an earthquake somewhere or something. Dr. Nic: That probably Coit Tower was about to fall down. Obie: And so she grabbed my phone to see what it was and as she was looking at the proposal on Twitter, I was getting down on one knee to you know, whip out the ring. Shock and awe. Dr. Nic: Now, I want to follow that up with--there’s a number of other people in the room so I have not prepared this question at all but Coit Tower--that was gifted to San Francisco from a widower or something? Does anyone know the story?............I’m Danish, let me just get on Wikipedia then so I can get my answer. Oh its right here. CoitusTower. I’ve no idea-- Obie: Its not Coitus Tower, its Coit Tower. Dr. Nic: Coit Tower is a 210 foot tower located on Telegraph hill in San Francisco. Blah Blah Blah.....It was bequeathed ⅓ of her estate--so Coit, some person called Coit requested ⅓ of her estate to the city....oh, this is not answering my question. I thought it was some dead person and something unromantic in the context. Obie: No I assure you. It was very, very, romantic. Dr. Nic: It was very romantic. Obie Fernanandez, thank you very much for your interview. http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/11/cloud_out_loud_obie_fernandez.mp3?1297995388 Fri, 18 Feb 2011 02:16:29 +0000 no S01E10: Joe O'Brien Engine Yard S01E10: Joe O'Brien We interview Joe O'Brien and talk to him about ruby koans, jruby and codemash Melissa: So today we have Joe O’Brien from EdgeCase here with us on the Cloud out Loud Podcast. Joe do you want to just take a minute to introduce yourself and tell us a little bit about your background. Joe: So yea, again, Joe O’Brien. I founded a company called EdgeCase about 4 and a half years ago or so. We work out of Columbus Ohio but our client base is international. We’ve got offices in the UK, in the states and we do all forms of Web enabled applications mostly dealing with Ruby on Rails but really any kind of tool that works well for what you’re looking for. We’ve been highly involved in the community as a whole, individually as well--speaking at conferences, running the user groups in various places, and just really trying to spread the word about Ruby and Agile development. Melissa: Awesome. Can you tell us a little bit about, I guess, how you first encountered Ruby and why you’re so passionate about spreading the word? Joe: Yea. So, I can from the Agile community and spent a lot of time there and was spending a lot of time evangelizing it. Was doing some development in Perl of all things and one of my close friends had told me, “You know you really need to check out the pick axe” bought it and never really paid much attention to it at the time because I was trying to become a much better Linux user and of course all Linux users use Perl. So, I was writing a big document processing library and one evening, picked up the Pick Axe, for--I don’t remember why but because of what I was doing at the time, looked at object oriented regular expressions and out of all the weird things to pull me into the language, its something that a lot of languages have for some reason, object oriented regular expressions kind of brought me in. They sucked me in and then I started looking at the language in more detail and just, the more I discovered, the more I was just absolutely amazed and enamored and really have spent my time trying to, at the time--convince the company I was working for to use it and now I’m try to tell everyb--all other kind of individuals what its like to use it, what it offers, the amazing parts about it. Melissa: Cool. Can you tell us a little bit about what those parts are? Joe: The flexibility it brings--one of the things that businesses don’t look at as much as they should is the cost of change. When you’re developing an application, in my mind, the number 1 priority should be cost of change and Ruby gives us that ability. 1-by stripping away a lot of the croft, getting to just the essence of what you’re trying to develop and number 2-the ability to test anything and everything. Yes, we’ve had some trouble lately with over-testing in the community and its a subject we need to talk about but in reality its a good problem to have. Most languages and platforms don’t give you this kind of idea of what you’re looking for--and its amazing what Ruby does give you in that flexibility. So the frameworks here better create the code that you’re able to deliver--you’re able to do things in 20% of the code--basically with 20% of the code than you used to be able to do. Obviously anecdotally but we’ve delivered some incredibly complex applications and we’re delivering a lot less, which means maintenance is lower, which means the ability to change them is lower which means we can focus on the best practices that we’ve been wanting to focus on and spend our time on instead of configurations and things we worked on in the past Melissa: Okay. Cool. Can you tell us, I guess, a little bit more about your software development philosophy? It sounds like you were kind of starting to describe it there. Joe: Yea--it is all centered around cost of change. Melissa: Ok. Joe: My first ever software development project--came into the game very late. I had a sales career for a while and I was trying to run away from my inner-geek. My very first software development project though, I was--I went from intern to project manager in less than 6 months, simply because I could communicate. Here was a company that over the course of 3 years, their entire business model for their industry had shifted from centralized purchasing and decision making and production to completely globally distributed. It was in the garment industry and they had a system written in Foxboro for Dawes, this is not a dig on Foxboro but the way it was written and the way they were approaching software was in such a--was done such that they could not improve. And in 3 years they tried multiple re-writes that failed because they really could not get anywhere with this system and so its all centered around that ability to change. And development philosophies like Agile, pairing, eliminating silos of knowledge, getting feedback from users very quickly, knowing if you mess up you can recover very quickly. Finding the people that can-- Melissa: That flexibility? Joe: Yea. Exactly, flexibility. Finding the people that can help you on a team--on your team. Then, also choosing the tools that help enable that team to do as much and as well as they can. Not, tools that are going to hold them back or make them jump through hoops just for the sake of some perceived--see there’s one of--my brain stops for just a minute--just for some perceived flexibility or some perceived notion of safety that you’re getting from say compiler or something like that. Melissa: Ok. Cool. And then I know--you and I have worked together on a lot of JRuby initiatives like JRubyConf in Columbus, Ohio last October and you guys are--you and EdgeCase are very deeply embedded in the JRuby community. Can you talk a little bit about that--the importance of JRuby and what kind of developments and innovations are taking place in that space now? Joe: I will, yea definitely. I personally became excited about JRuby at RubyConf in Denver so many years back--couple years back now I can’t remember exactly which one that was but when I first got to meet Charlie and hear about it and the work that he and Tom were doing and the rest of the core team, I was really excited about the idea and see it come to fruition is just absolutely amazing. They’ve done some incredible things and the reason JRuby is important is not because of any kind of deep love for Java or anything like that or any kind of nostalgia, its really for the idea that there is a lot of code out there. If every developers was to stop writing Java tomorrow, we would still be dealing with the Java language for the next 10 or 20 years, just like Cobol is still around. Finding a way to allow developers to move forward and work with the systems out there is something we really need to concentrate on. While we’d love it to be tackled from say, an architectural level, which I know is a passion of Tom Morini’s and other people of, you know, arching back to my SOA days, the reality is that its not necessarily going to happen at a lot of companies. So the ability to call into a lot of libraries that are already there to use existing systems but yet move forward in platforms like Ruby on Rails is really going to be critical for corporations. The Java platform is screaming for another option. You’re looking at the Scala, you’re looking at the Closure, your looking at the Groovies, you’re looking at the other things that are out there, they’re screaming for something other than the language they have and I think JRuby’s going to be the perfect complement to that. The guys have worked extremely hard to make a language that is not forked, its not changed, it is a true implementation of a language already sitting out there and it runs on the JVM. They’ve done just amazing work on this. I look at things like Groovy, I look at technologies like that that are out there--they tackle it thinking its purely a syntax issue and its honestly the absolute wrong message you need to be--the wrong direction you need to be going if you’re looking for a change. You need to be looking for something like Ruby that has a lot of mind-share, has proven scalability, has proven productivity gains that come out of it and be able to bring it to your corporation. I think that’s what its giving. And so, we’ve thrown our weight fully behind it because, I’d say probably about 2 years ago, we looked at it again and we been tracking the project for awhile but we finally got to a point where we tried it, used it on a production system and it worked very, very well. We came at it from a Ruby developer stand point of we needed a library--it was in some document processing--that they’re weren’t some good enough libraries that we had whereas Java had a plethora of them, used it, it was brilliant, it worked very, very well and it let us plug away and go. And so not just tackling it from the Java perspective but then looking at the Ruby community, realizing there’s a lot of wheels that have been reinvented. There’s a lot of scalability and server knowledge that’s persisted out of the Java community that we should be taking advantage of and again, kudos to the guys for putting together the project and really taking it forward and so we looked and saw how can we help. They were doing such phenomenal work on the technical side and we’re using it and we wanted to help even more. That’s where it came in. We’ve been pushing enterprise and Ruby for awhile and I think enterprise--I’ve started coming to realize recently that enterprise is the wrong term to be looking at, but established companies, established software areas that could be taking advantage of Ruby in better ways. We put on a conference once a year about it and we thought, “What better way than to help, this past year, than to team up with you guys at Engine Yard and put on this conference” and kudos to you for helping us put it together because it came across incredibly well. For anybody that missed it, if you go to JRubyConf.com, all the videos are up from the conference. We had an incredible amount of talks; you’re going to miss out on the whiskey event--we did not record that but look for this year--we’re going to have another killer conference. We’re going to put it in a more central location, as much as I’m married to Ohio, literally and figuratively, not everybody is, so we’re going to find a better location, put it on again, really show the buzz that’s there in the community and excitement that’s sitting there. Melissa: And for people, who are just as excited about JRuby as you and I are, are there ways that you can suggest that they get involved and contribute? Joe: Yea, I mean definitely. We’ve--we’re always looking for help in different ways. There’s always technical help that can be brought about and as corny as it sounds from bug-fixing, using it is the first thing. Anybody get out there find a different way that we haven’t tried yet and do it. Jump in the JRuby IRC channel, sit there for awhile, help people out. If you come from the Java realm, tell us about some libraries that are out there that are really amazing. The Ruby community--one of the things we’ve done very well is consolidate a lot of the code and the knowledge is there in places like GitHub and at some of our conferences. One of the things that I have not seen from the Java community is the ability to really identify the quote unquote “cool libraries” or the interesting things that you can use. Nick Sieger gave a wonderful talk at JRubyConf on just some ideas for taking Ruby combining it with Java--taking JRuby combining with Java and looking at some interesting things to do from things like reimplementing a document database and different ideas. If you’re in the Java realm, jump in and help us. Let us know what’s there and some of the advantages we can get out of it. And then, if you have any kind of command of the English language, which sometimes geeks struggle with, help us with documentation and I don’t mean, sitting through and documenting code but I mean, write a blog post on your experiences on learning it. Try it from the beginning from installation through to your first program and write about how that works. These are things that as we move forward, sometimes we forget to look at. If you’re on a Windows platform, please God, help us use it. As a community we’re doing a huge Ruby in Windows push, and if you’re anywhere near that kind of platform, help us out. A lot of us are Macs because we like it, we--yes we’ll probably jive back and forth like eMacs and VI are always going to do the same thing but realistically we want you helping us, we want you out there. Come in in those forums and give a talk about it at RubyConf or at a User Group. If you’re looking for ideas, reach out to myself on Twitter, reach out to Charlie, reach out to Tom or Nick, jump on the IRC Channel and just start talking to us. There’s 100 ways you can help. Melissa: Great. I noticed that you guys at EdgeCase are actually sponsoring LARubyConf again this year. Joe: Yea. Melissa: I know there’s a bunch of folks here at Engine Yard who are interested in just I guess, advice for developing their careers and visibility in the community by speaking at conferences and user groups and events like that. Do you have any advice for folks like that who are a little bit newer to that area of I guess, getting up in front of an audience and talking about things that they’re working on. Joe: Indeed. You know, I do it because--well the fact that I’m an extrovert, I get my energy from people. And the fact that there’s enough of a Narcissistic streak that I love getting up in front of people and having them watch me. First of all, realize that that doesn’t have to be the place you go. I know a lot of people I’ve seen get up at user groups who are absolutely terrified and they never quite get over it. Don’t think that speaking--public speaking--is the epitome or top of the game when it comes to development. There are lots of things that you can do in the IT community. However, if you do want to, user groups are the perfect place to start and a wonderful area to go. Find something you’re passionate about. There’s gotta be a reason you’re programming; if there’s not, this is probably not the place for you. You’re finding that its a struggle? Pick up something like The Passion Programmer by Chad Fowler, read it, rediscover your passion--its there, trust me. Then start playing with something. I don’t care if its phone development, I don’t care if its GUI development, playing a game, teaching somebody how to program, whatever it may be, find something that you really like and share it with your local user group. Go up, find the leader, ask him how to speak. I don’t know of a user group that’s turn you down at some point. If you’ve done that and you’re still a little rusty, find local user groups that are within driving distance, find other ones and start trying to get out there and once that’s there, submit an abstract. Watch the conferences you like, they’ll publish when the abstract--when the call for papers is, submit something, put it out there, see if it happens. I wouldn’t make the conference the first place that I would necessarily go and talk. Its a little bit more intimidating, its a lot more critical--people are paying to see you but user groups are a fantastic place to start and a place that a lot of people are coming to see passion and make sure you’re excited about it. Don’t pick something because you want to speak, pick something because you’re really excited about it. Melissa: Yea. Awesome. That’s great advice. Let’s see. Could you talk a little bit more about your experience founding EdgeCase. I know I remember you saying that, when you founded EdgeCase you, I guess, built the company that you always wanted to work at. Can you tell us a little bit more about that? Joe: Yea I have--I have one over-riding principle for having started EdgeCase and I still make sure I question myself all the time which is if I got up tomorrow morning and was unemployed, and I looked around, what company would I want to work for? Would this be the top company I would want to work for? And I have to say, its always near the top and that’s what I strive to do. I have amazing people around me, people that are incredibly brilliant and run circles around me at what they do. They’re people that are extremely passionate about software. We’re not doing Agile because we think its the next buzz word, we’re not using Rails because we think we’re going to make a lot of money off of it, we’re using it because we think its the best tool out there. We’re doing development in this process because we think its the only way to be successful. We got into software development because of a passion and we demonstrate that with everybody around us. I also have a talk coming up at--if you’re going to be in Europe, its Sottish Ruby Conference, formally Scotland on Rails, called “Tales of an Accidental Business Owner.” I basically--we basically got the company together, my business partner Ken Barker and I, 4 and a half years ago, got together and decided there was a lot of demand in the Ruby world. We were both trying to push our companies internally to do it. I was working for a company that I absolutely love and to this day still have a lot of respect for but I was being told to get on a plane every Monday morning and get off every Thursday evening. It was just a lifestyle that I couldn’t sustain and so we looked around and thought, “let’s create something.” Started off as a co-op, we got to 4 people and realized you couldn’t--we couldn’t decide where to buy toilet paper, communist business models are not necessarily around for a reason. So we started taking it a lot more seriously and we’ve gone through some serious--we went through a lot of changes--some great, some unfortunate, some fantastic, all up and down. But we approached business like we did for software development and we iterated on it. The faster we failed the faster we were able to recover the better. And we went about it that way and we’ve got a fantastic company that really passionate about what we do, we love it, I can’t say that enough. And we’ve got some amazing clients. Clients that--its interesting because we enjoyed going to see them. LA is a perfect example. We’ve been working with our friends down in AT&T Interactive for going on our second year I believe at this point and we enjoy going to see them every time we do. All of our clients are this way. We’ve got a testing application we just helped launch in Ohio called Genova. We’ve got really good close contacts there that we enjoy working with them. One of our philosophies with clients and customers is we want to work with you, not for you and it works out very well that way. They respect us, we respect them for what they’re doing and its just a great experience to be doing it. And so we’re really finding why it is we’re doing what we do and EdgeCase has been born out of that. And we’ve taken it overseas to Scotland, we’ve got Paul Wilson on the ground out there to help run the Sottish Ruby Conf and been doing some great work with some amazing people. There’s some awesome talent, there’s a lot of excitement, a lot of belief in Agile development and starting to gain on the Ruby on Rails adoption over there so its been exciting and we’re really looking forward to this year and the years to come. Melissa: Awesome. I just have a couple more questions. So, let’s see. What is the Git Immersion project? Joe: So actually--that was a fantastic launch this weekend. We’re at, I think, 76,000 hits over 3 or 4 days. We--so 3 years ago, we went to do an intro to Ruby class and it starts back with a site called RubyKoans.com. Jim Weirich and myself were asked to do an intro to Ruby and I had always wanted to create a class that was designed in a test-first fashion to learn Ruby. This was based off a--inspired by a person I consider a friend, Mike Clark from the--who leads the Pragmatic Studios who had but a blog entry back circa March of 2005 about learning Ruby through unit testing. It’s baked in the language, its really easy and he--instead of putting a bunch of stuff to system out, had actually written a set of unit tests that walked through different libraries and showed how to use different things. And so we sat down and figured out how to do this with ruby koans and put on a class about this. Eventually our designer who is just phenomenal, Jerry Newmy, put out some great designs for it, absolutely beautiful and we decided to launch a website and just kind of put it out there and see what people thought and it just had rave reviews and it continues to get a lot of hits. And people absolutely love this idea of some people open source code we’re now open sourcing our learning. We think that there’s a lot of value to show and to provide to the community for teaching them the things that are there and enabling them to learn themselves. So we sat back and thought, “this was a lot of great success, what else can we do?” and Jim Weirich put on a class for Git called “Git Immersion” where he had a bunch of labs that he put together and so took us some time to get the design down but again, Jerry Newmy just blew it out of the water and we released git immersion this past week at CodeMash. Again, same idea--its a serious of labs that allow you to learn Git on your own in your own time at your own speed. Starting off very simple and building up from there. And, everybody seems to be loving it, they work it really well so if you’re looking at learning Ruby and really haven’t done it yet, ruby koan’s there and if you haven’t tried Git yet you absolutely have to and gitimmersion.com is definitely going to help lead you there. Melissa: Can you tell us a little bit about how CodeMash went last week in Ohio? Joe: Yea. So beautiful Sandusky Ohio in the middle of January for some reason we decided--not we--a couple community members from the Midwest decided they should really do a conference in up north of the Snow Belt. And there’s this place called the Calahari Resort. I believe its labeled as the worlds largest indoor water park, you never know if the marketing’s believable or not but its absolutely huge. Its this huge conference center and they put on a conference and this was the 5th year running now with it--every year its been growing. And its called CodeMash and the idea--or the name is not just randomly picked out. It literally was this mashing together of communities. First year or two, there was a lot of interest from other communities and its an idea of--they say mash, not bash so you’re getting together and talking about different languages instea of bashing each other. .NET communities sitting there with the Ruby community sitting there with the Python community sitting there with the PHP community. Ok we throw some bars at the PHP community periodically but, we invite everyone to come together and its steadily grown. This year, we took over--they took over the entire convention center, 700 people strong and when they released tickets they sold out in 3 days over a weekend. They released them I believe at a 7pm on a Friday, they were sold out by Monday morning. Melissa: That’s awesome. Joe: Absolutely phenomenal place. It also helps with work-life balance because its an indoor water park--my kids look forward to it as much, if not more than Christmas every year. So you get to bring your family to a resort and go to a conference. It is one of the biggest parties I go to every year. A lot of fun, all self-contained. Takes a little bit to get there through the snow, it takes a little bit to leave through the snow but once you’re there you pretty much move in and stay there for the weekend. Its a great time. Melissa: Very cool. And what was the representation like at CodeMash in terms of--like what different communities folks came from. Joe: I can’t think of a community that wasn’t there--major community. There was a lot of Python development going on. There was a lot of Java development, a lot of .NET representation, Microsoft has a very large presence there--I’d say half or more in the .NET space. Ruby did have some presence although, if you’re listening from the Ruby community, put CodeMash.org on you calender and keep and eye out. We could use some more. We really had all these technologies together in on conference. The interesting thing about it thought, unlike most multi language conferences I’ve been to, it wasn’t the .NET people going to the .NET developers workshops, it wasn’t the Java developers just going to Java--there’s a lot of cross pollination that goes on and its absolutely fantastic. Melissa: That’s really cool. Joe: They do a bang up job of speakers, we had Chad Fowler and Scot Chacon this year as well as others speaking and it--they’re always inspiring. We’ve had VenCat, SuperMedium, speaking in years past. We’ve had Andy Hunt come last year. We had Neil Ford in years past--people still talk about his keynote. Just some really, really good quality content. Melissa: Very cool. Ok, so one last question for you--this should be an easy one since I’ve experienced this firsthand. The rumor on the street is that you’re a whiskey connoisseur.....Can you tell us a little bit about that and what whiskey geeks and the whiskey tour that you mentioned early are? Joe: Yea so there’s a fine line between connoisseur and I have a problem. I’m still not sure where that line is though. Yea so, over a less than lucid conversation between Randall Thomas and myself in Scotland, at the Scottish Ruby Society we met a bartender there that was, who was--we found out--way more than a bartender. We found somebody who was as passionate for whiskey and spirits as we were for software, as if that was possible. And started talking to him and realizing that there’s an interesting similarity in Scotch whiskeys and fine software. You know, this is a spirit that comes down through generations of knowledge, this is a series of craftsman who really care about what they do and they come out with a product that’s absolutely amazing and wonderful to experience. Software is very much the same way when done right. Its something you have to share, its something you want to tell everyone about, its something that you want to share with people. So we decided there was no better way than to get to drink more of it than to actually bring Craig over and so we conspired and we got together with JRubyConf and decided to put on the whiskey--the first version of the whiskey tour. And so we went to JRubyConf and went on to Mountain.rb and we brought the whiskey tour with us. Craig came over from Scotland. He’s--there’s just an unbelievable amount of whiskey knowledge in that man’s head and put on what are some of the best tastings I’ve been to. At JRubyConf, we had almost the entire conference show up, of 150 people to the whiskey tasting--unbelievable amount of people coming from--that didn’t you know, stay back in their hotel room. Put on a show, everyone enjoyed it. He gave them a wonderful introduction to what it was, a lot of ranges of whiskey to try, a lot of different things, which has lead to a group called the Whiskey Geeks who have gotten together and started touring distilleries, getting together and that’s just it--we’re geeked about whiskey. Like the details, like the outcomes, love sharing it with company and people so look out through this year--the whiskey tour will be back and keep an eye on whiskeygeeks.com because we are planning a website for people who want to know more, want to learn more, want to teach other people and just can’t get enough of Craig’s accent. Melissa: Awesome. Ok, well thank you so much Joe for your time. http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/10/cloud_out_loud_joe_obrien.mp3?1297390933 Fri, 11 Feb 2011 02:22:14 +0000 no S01E09: Tom Preston-Werner Engine Yard S01E09: Tom Preston-Werner We interview Tom Preston-Werner of GitHub and talk to him about entrepreneurship and their new conference CodeConf Randall: As it stands, for this edition of Cloud Out Loud, we actually happen to be sitting here in the lovely GitHub offices and we have roped Tom Preston-Werner into discussing all that’s new with GitHub for us. So, thanks for showing up and I hope that the glass of whiskey sitting in front of me didn’t have anything to do with it. Tom: It didn’t have nothing to do with it. I’m not gonna say how much it had to do with it. But I do appreciate you bringing the whiskey by. Its always a pleasant situation when that happens. Randall: Bribery always works. So, tell us what’s new at GitHub. Explain to us what’s going on. What do you guys have on deck. What are the things that are exciting for you at GitHub right now. Tom: We have a bunch of stuff in the works. I am working on redoing all of the search functionality throughout the whole site. So I’ve been spending a lot of time learning solr and the intricacies thereof so that I can go in there, figure out how the indexes need to look, what kinds of things we need to be indexing, get the indexing strategy a little more streamlined so that we’re not missing big chunks of the index and really just rethinking the whole strategy of search. Randall: What targeted--what was the specific thing made you decide that you needed to rework the strategy of search. Tom: It’s just--its been not so great for a long time. I think the catalyst really was over Christmas vacation I was home in Iowa and I was reading through some of the Tweets and someone was like, “Boy, GitHub search sure is bad” and I was like, “You know what, GitHub search is bad” and when that happens then someone on the team takes it upon them-self to do what’s necessary to remedy that situation. In this case, we had been talking about it for along time and we said, “Well, Search is one of those things we want to get better in 2011” and I said, “Well I’m not doing anything right now at home so I’m gonna pick up the solr book that came out not too long ago” and its recent--for the most recent version. And I just sat down and I read it cause I thought, “well, this is kind of interesting”--I mean search--I used to work at Powerset, a search company, so I’m familiar with search stuff so maybe it should be that does it, right, in that I know what some of the terms of search mean and how that stuff works and what not. So I sat down and read the book and I just started working on it and so far so good. Randall: So why did you guys pick solr? I mean considering ok, bout to start the flame war--this is almost like eMacs versus VIM and everything else or TextMate, but ok why did you pick solr as an inverted index in a search solution as opposed to any of the other various, equally valid search options out there. Tom: It wasn’t actually me that chose it, I think Scott initially chose it. We were--I think the main choice was between solr and sphinx at the time. Those were the two--to us--the most prominent choices for open source search solutions. And this was 2 years ago, I guess, that we initially put search out there, very early in the company’s history and we don’t have a lot of money to throw behind fast search or Google search boxes which are like, insanely expensive, etc. so we wanted to use an open source one--we figured we could make that work. And, at the time, sphinx did not do incremental index updates. You had to roll a new index every single time, which for very large document sets like we had, it was just not practical. Now, I’m pretty sure sphinx has incremental index updating now, but at the time it didn’t--if I am informed correctly on what the decision behind that was but I think that’s why we made that decision. Solar was--a lot of people used it--lots of businesses, lots of enterprises use it. Its like, well if it works for these huge companies with billions of documents, we should be able to make it work for our data set which is significantly smaller than that, although not for long. Randall: Nice. Well actually, that brings up one other question. So, are you actually using the raw Java interfaces for solr or are you using something else like JRuby or some other scripting interface. Tom: We use--we run solr, just the regular way through jetty and then we use the solr ruby bindings for Ruby and then that just--you assemble the search query and send it over the wire using solr ruby’s interface and then it comes back as just a set of hashes and we take those hashes and we format them in the proper way for output. Randall: Got it. So do you have any problems with things like memory inset--like essentially the representation of that data set in memory. Can you stream it from the Solar server? Tom: It’s not streamed but the document sizes that are coming back are usually small enough that it doesn’t really matter cuz if you’re searching for the code search, for instance, you’re indexing individual files and we have some cut off which I believe is 50 KB in size that right now code search just won’t index at all. It just says, “This document is over 50K, don’t even bother” now in the future I’d like it to just truncate it at something like 50K or maybe go up to 100K but as long as you don’t have a lot of those documents coming back in the search results then its not really a problem. In fact, we probably don’t even need to send back the full bodies of the files themselves because really all you need is the snippet of what matched--matched highlighting and I just need to figure out how to turn off sending back that whole field on return because it returns that field by default because it’ll return any field that you want it to highlight by default and so I just need to figure that out. So really, it shouldn’t be a problem cuz all you’re getting back is some metadata about the thing that you’re searching on and then the highlighted snippets that it found so the weight of that chunk of data coming over the wire is really very small. Randall: So if you--when you start looking at the other problems with search, specifically what problems in search with code and GitHub like scale, specific types of indexing, different types of files, parsing, lexing, that sort of thing. Have you run into any challenges that definitely sort of fall outside of the regular range. Tom: Yea, well indexing code is a special kind of thing, It’s not like indexing prose because you’ve got all these special symbols and you have to decide well, are we going to index periods, are we going to index curly braces, are we gonna index hash symbols, etc. Normally in the English you’re not gonna do those things; you just throw them out--you don’t tokenize them at all. So we have to decided what is the appropriate way to tokenize those things to make the searching work the way that you expect it to work. Matching on more literal sets of things because if you’re searching for--I don’t know what a good example is but if you want to search for “something dot something” then traditional tokenizing is just gonna take that period and throw it away but it is semantically meaningful in the sense that you want that chuck of those two things together with a period between them. Randall: It could be the difference between a class and a class method. Tom: Right, exactly. And you want that to be a relevant thing. You want it to notice when that happens as opposed to if you throw out that information then its going to match them because they’re close together but its not gonna care that there was actually a period between them. But that is semantically useful information so now its--those are choices that I haven’t really made yet that I’m still going through. Trying to figure out what the best tokenization strategy is for code. And there’s other things like porter stemming which is a common type of stemming so that you match--if you wanna match--if you’re searching English and you type in “run” you would also like to potentially match “running”, “ran”, those types of things. Porter stemming’s not going to match “ran” but it would match “running” and if you type in “running” it’ll match “run.” It basically reduces each word to the most basic component. It would take “running” and it would index the word “run” instead and as long as you do that on the query and what you’re indexing then those two things will match. So another question is, do we do porter stemming on code? And that’s not something that most people think about but in some sense, that makes sense. Like, if you’re going to match something that’s in a comment, then that’s English. Randall: Right. Tom: If you’re going to match something that’s in code probably you don’t want to do stemming but at the same time, maybe you typed it a little off but that it would stem the same and maybe you do want to match that. I’m leaning towards not doing porter stemming. This is probably not something that is that interesting to most people but it is interesting to me right now and going through those kinds of decisions as how do create and craft an index in the right line. Randall: Well no, but that’s kind of important right because now--if you think about it if I’m searching for comments in C code versus C++ code, multi-line comments versus single line comments versus Erlang shell scripts--cuz, actually right now do you have idea what the stats are for like language distributions on GitHub? I know for a while you guys were keeping track of which languages were most accurately represented. Tom: Yea. So JavaScript just recently became the most popular language, followed now by Ruby. Now part of that might come from counting JavaScript code more than it should be because people almost always include the JavaScript libraries in their code bases so you’ll see JQuery included in a lot of things and we do take measures to not count popular known JavaScript libraries in the total code distribution of projects when we count it but that’s not perfect. So JavaScript is generally going to be a little skewed up--but I can look it up and tell you the exact break down--JavaScript 18%, Ruby 18%, Python 9%, Perl 9%, C 7%, PHP 7% and then a handful of other ones. That’s the basic breakdown as far as we’ve automatically detected. Randall: Got it. What’s fastest growing? JavaScript? Tom: I’d say JavaScript is probably fastest growing. Ruby has been number 1 since we started and JavaScript overtook Ruby so I’d have to say that probably JavaScript is fastest although Python is growing very rapidly as well. Randall: Oh interesting. Is that because you guy have been doing a lot more outreach to the Python community? I think--Is Chris just Pycon or-? Tom: No, although he’s been going to the Python conferences and Scott’s talks at a lot of the Python conferences as well. We’ve been doing outreach to Python and JavaScript pretty heavily. We go to those conferences and sponsor those conferences as much as we can. I think its just the general trend of dynamic languages are coming to get--they’re discovering as people go along, a lot of those projects are on GitHub already and they see them and they say, “Oh this seems really cool”--JQuery’s using GitHub. If its good enough for them, its good enough for me. It’s really great to get those big projects. Using GitHub drives a lot of those customers to us. Randall: So you know of the things you guys actually sort of promote as the tenet of GitHub is social coding. So given that you’re actually outside of the Ruby community and I think Ruby was one of the first places where the idea of socially getting together to actually communally write code, sharing code, drink ups, meetups, all that sort of stuff, sort of really took off as an actual value of the community, what would you say are some of the differences or similarities between say, the Python social coding community or JavaScript social coding community compared to what you guys have seen in Ruby or ErlLanger, or other--? Tom: The Ruby community and the way the Ruby community interacts is always kind of my model for how it should be done. It’s my favorite by far of all the conferences and all the events that I’ve been to. The Ruby community to me has always been so open and so interested in bring the language forward and bringing forth new ideas and embracing new people in a really nice way. I can remember very distinctly when I was learning Erlang, it was not that way at all. I would go into the IRC room sometimes--I Just wanted to know how I could write--how I could get the PID of a running process--just get the PID so I could write it out. And I needed to do that because I wanted to monitor it with god and I needed to know the PID file so I could have it under god’s control. And I went into the chatroom and I said, “Hey, how do I this” and the initial first response I was, “Why would you want to do that?” and I’m like, I could sit here and explain it to you but I really shouldn’t have to. I mean, its just like, people need to do things like that--I don’t know it seems like a pretty reasonable thing to me. But that was always kind of like, “Why would you want to do that” and I can sort of understand that in that they want to maybe guide you and understand why you would want to do something specifically which is the question--what are your motivations, although it always came off as aggressive. And some of the people in there were just not nice people. Randall: No no no, actually I remember learning C++ the exact same way. You drop into a C++ room and people would basically post your code knowing that its bad but instead of sitting there telling you why it was bad, mostly you’d get peels of laughter followed by essentially abuse heaped upon your shoulders. Tom: Yea and I think that’s terrible. And Earlang honestly has gotten way better. I go to the conferences and stuff and their community is really nice now. I think it is because they have so many new people coming in and they understand what its like to not know that language and so they generally treat people well whereas things like Erlang and C and these things that require a little more understanding of complex ideas moreso than things like PHP which were kind of built to be understandable and don’t do a lot of the really intense craziness like concurrency and hard core memory management that Erland and C do respectively. If you don’t have new people constantly coming in all the time in droves, then you can fall into that easy place of being-- Randall: It can become a haskel? Tom: Yea, exactly. Its just a natural tendency for those groups to become insulated from new people just because they like the way they are and they like being in that niche and having more knowledge than other people. Having new people come in all the time changes that and that’s what Ruby has basically always had since Rails came about and even before that--everyone was a beginner in Ruby and Matz made Ruby--the favorite saying I always had and people used to use it and they don’t use it so much anymore but there was an acronym MINASWAN which stands for Matz Is Nice And So We Are Nice and that was one of the big things that people would always throw around if someone was being a jackass in a chat room. They would say, “That’s not how we work here because that’s not how Matz works” and that really defined the Ruby community and I always loved it for that. Randall: Nice. So actually, that’s a good point. I mean I think a lot of people have gotten together socially I mean you guys have actually taken the idea of social coding--if anybody has ever been to a GitHub drink up, if you haven’t and you’re listening to this I highly recommend even flying into one if need be--but you guys constantly actually have these social interactions around your code so how does that actually vise what GitHub sort of sees as its philosophy or its place in getting people to be nicer and to interact. Tom: Going forward, that’s what code iss going to be all about right-writing code on your own is becoming less and less of a thing because what hasnt been written yet are becoming more and more increasing complex and so its hard to do on our own. And so getting people to work well together in the coming years and decades is going to be where everything is about. It’s not going to be a solo hacker in his room writing MAKE or something right. It’s just not going to happen that much anymore because those things are already written and they already work really well and its going to be more and more collaboration. Randall: Actually you know what, if I remember correctly, I think last night there was a GitHub drink up. Tom: Indeed there was. Randall: And Josh Susser said that you and the other founders of GitHub actually met at a like an IcanhazRuby ICHR meeting so you guys actually met at a social Ruby gathering. Tom: Yea. That’s actually correct. I mean I knew Chris and PJ through the Ruby community and through the Ruby meetups and the IcanhazRuby was a special, elitist gathering of-- Randall: Oh I remember, if this is your first time at ICHR you must show code. Tom: Yea. It was, I mean--when I say elitist it was really the VC’s weren’t invited was the main thing right. It’s not like it was hard to go to one, it was just that we wanted it a little bit more private because the VC’s had sort of encrouched upon the San Francisco Ruby Meetup and they were no longer tolerable to attend. We were kinda doing a grass roots new one that we could kind of control a little bit better that was much more based on code specifically that it was about VC pitches cuz its really hard to univite a VC once hes there. And its like, VC’s are great—I love VC’s and all but they should be going to those kinds of meetings, that’s not what they’re about. Randall: Interesting. Tom: But, yea that’s how we met. We met through social interactions, not through code specifically. I mean, through code incidentally but ya know—I need a little refresher on that. Randall: A little more whiskey here. Tom: A little more whiskey here. Please. Thank you. Randall: You know what they say—by the time we get to this bottle we get to the bottom of the truth. Tom: But I encourage—in my talks and things—I encourage people to go to meetups and if there isn’t one, to create one because that’s where you’re going to meet the people that you’re compatible with intellectually and those are the people you can code with really well because its hard to know just meeting them online, what they’re like and if you’re going to mesh really well. And I think meeting someone in person and having those outside of the code interactions is really worthwhile for writing the code because eventually you’re going to want to get together in person and if you don’t mesh at all in the real world then that’s kind an unfortunate thing, especially if you’re looking to start a business and meetups are a great place to do that—to find people who have similar ideas to you. That’s what you really looking for—people that have similar visions of the future. Randall: Ok so its interesting right, maybe infamous is possibly not the right work but you certainly have a little bit of notoriety for writing a blog post—I think you recall called “Why I Turned Down a $300,000 Payout from PowerSet.” So you just mentioned the idea of finding co-founders and I think that a lot of people, especially in the community right no--they see themselves as where you, Chris, PJ and Scott were say a couple of years ago right. So given what you’ve learned over the past intervening years, where would you tell them to start, what would you advise them to do and what would you advise them not to do. What’s the sort of gem that you’ve learned? Tom: There’s a few simple things that I identified in thinking about how we were successful early on and this is kind of specific to a bootstrap and I think bootstrapping is really great for a lot of reasons mainly because you don’t have to spend a lot of time raising money to do it. You can just start right away and as long as you have that in mind then you can accomplish really good things but you have to pick the right sorts of things to bootstrap and so if you are in that position and you’re looking to bootstrap something then what I suggest is find an idea that has the elements of virality and community—those things specifically meaning virality being the ability for something to propagate itself without a lot of effort on your part. So, for example, in the case of GitHUb, GitHub is viral in that if you put your open source project on GitHub and you send the link out to all the news feeds and whatever and put it on your blog and Tweet it and stuff, then you’re driving people to GitHub to look at your code. Now when those people get there and look at your code they are also discovering GitHub the service. So in helping you do what you do better, you’re pointing people at our company and in that way its viral. It’s viral because people want you to go to our site because it makes them more awesome by them seeing your code. So the viral component is essential because you don’t have a lot of time when you’re boot strapping or a lot of money to do advertising and to be talking to people constantly. You want your users to do that for you, and that’s virality. And that community is, once you have those people, how do you keep them sticking around. I mean its easy to be viral and short-lived. Randall: Your a meme. Tom: Exactly, exactly. So YouTube has a lot of virality but not a lot of community and while they’re still immensely popular--I think its because people like funny videos, not because its like an amazing service otherwise. Randall: Yea, but actually you know, you’ve got a point because ironically though, its like Funny or Die--that’s kind of how they get their take off because they actually try to go with both virality and community right--in college. Tom: Yea they’re trying to build communities of people that have commonalities and talk to each other and that’s really where the collaboration part of GitHub comes in--its getting people to know each other and work together and follow each other and be interested in what people are doing so that they’ll come back and see what those people are doing tomorrow--that’s community. So virality is getting people there and community is keeping them there and with those 2 things, you can build a huge user base with a very small amount of effort. So I would say think about those things if you’re thinking about building a company or if you’re in a boot strapping situation or thinking about doing it--think about those things because if you’re selling a internal management solution to businesses, you have to be on the street knocking on the proverbial company door everyday forever--there is no virality in that, there is no community in that. It’s not going to sell itself and once the people have it they’re not going to talk to other people and come back right. It’s just a completely different business. And the beauty of the Internet is that if you think about things in the right way and think about how you can build in those elements of virality and community--and you can do it in a lot of situations, you just have to understand that they need to be there. Once you start looking for ways to include virality and community in an idea, a lot of ideas are amenable to them you just have to add them in. Randall: Ok. Then, what was the largest mistake you made after you boot strapped? Like what was the big thing like looking back now--you’ve got that moment, you smack yourself in the forehead you’re like, “Oh my God, I can’t believe I did that”? Tom: I think probably the biggest thing is some of the financial stuff regarding how stocks work--are awarded to new employees and what not. Not coming from a really heavy business background and not having done a start up previously, you don’t really understand how options work versus actually stock grants and stuff like that and if you don’t get those things right in the first place, then it takes a lot of legal manipulation to get them correct again. Randall: Legal manipulation? Ok, that sounds like something where like we’re going to edit that out of the podcast. Tom: Well no, its not like that--its not like we’re doing anything illegal. It’s just that, you then have to go back and, on paper, fix those--you know, we’re not screwing anyone over and we’re not getting screwed over its just that if we would’ve done things a little bit differently to begin with as far as how things were-- Randall: How you structured them? Tom: How things were structured then it would’ve been easier. Like, everyone still ends up at the end of the day with what they should have had, its just cost more money to get there. So I’d say look at the business things and especially know how stocks and stuff--how options and stocks and things work. Randall: So that's interesting. Ok, so I know there are from time to time if you look on HackerNews, you see these things in search of the technical founder, and it seems there’s always a tech guy looking for a business guy and a business guy looking for a tech guy but they never seem to find each other. It’s like they don’t--you know the running blog post right. The technical co-founder doesn’t exist and then the counterpoint, the business co-founder doesn’t exist. So given that this is the case and given that you’re sitting here saying, “hey, I wish I had more business acumen about how to set things up” why do you think there seems to be this cross connector? This--why are these two ships passing in the night, I suppose? Tom: I think, I think its because technical people and business people are generally very different in how they perceive the world and each other so the common thing is that the business guy thinks that his idea’s amazing and all he needs is some code jock to--code jock? Why did I say--code jock? Is that a thing? Some Code Jock. I wish there was such a thing back in high school, right. Randall: Code jock? You could letter in code? Technically if you lettered in code what would you get? A C? Tom: I suppose so? But, the business person perceives what the code person does as like, simplistic and the code person sees what the business person does as simplistic and so neither of them ever sees the other one-- Randall: I was going to say vindictive, but simplistic works. Tom: It’s just--you don’t understand what goes into it and the knowledge that you have to be an expert at that situation. The business guy’s just like, “well aren’t you just opening up front page and typing in PHP” and they don’t even know what those things are, right. But to them its so simple. And to the coder, the business stuff is just like, “don’t you just file a bunch of paperwork” Randall: Right. Tom: But its not really like that. And until those 2 people understand and appreciate the complexities of each other, then they’ll always complain that there’s never a good fit for who they’re looking for. I guess--its the way I see it. Randall: Yea well, that’s what I asked, contextually we’re curious. So what’s next for GitHub. I mean you guys actually have done a great job at engaging with multiple communities. You have the--I think you guys passed SourceForge like a while back right? Tom: In some metrics. We passed them on a number of repositories, like a year ago, at least. Randall: Right. And so, you guys are growing, you’re doing really well. So what’s next? What are the problems you want to tackle? What are the things that you think are going to confront social coding as a concept that you’re going to have to deal with. Tom: In addition to just refining the website itself and the way that people work, making pull requests better and more powerful, making issues better and more powerful, making search better--and you know, there’s all these different things. But for me, what I’ve been thinking about is, we focus a lot on Git users and Git the technology and code writing specifically, and in doing that, are we missing out on a huge chunk of people that could use the site, even if they don’t do some of those things. So an example from when I was at start up school giving a talk there, one of the founders of AirBnB gave a great talk about kind of his journey from creating the concept to where they are now which is very successful. And they started out being very, very niche in that it was all about literally--air mattresses and breakfast in the morning. That was their thing--that was their idea and after a little while, they realized that they were pigeon-holing themselves too much and what people really wanted was the abilities to list properties of any type on their own without having to go through a listing agency. So instead of becoming, literally, air mattresses and breakfast in the morning, it was, “hey I have this rental property I’m not using right now and I can make money off of listing it” or I do have an extra room in my house but its a total room or maybe its even a separate part of like a guest house, whatever, and it has a real bed and no I’m not going to serve you breakfast in the morning--that’s stupid. Cook your own damn breakfast and once they realized that the market was bigger than it had originally pigeon-holed themselves into, they exploded in growth and popularity. And I’m wondering if maybe we are the same somehow in that maybe we are restricting ourselves too much artificially by focusing on people writing code and sharing code. Are there other things that technical people would like to do that we could facilitate. And that’s kind of purposefully vague because I don’t know the answer myself. Randall: Nothing but questions, nothing but questions. So I think one of the things I heard you guys being bandied about is you guys actually have a conference coming up. Are these rumors true? Could this actually be? Tom: The rumor is indeed true--yes. We are organizing a conference and it is going to be the weekend of April 8th and its going to be a 2 day conference. It’s going to be called CodeConf. It’s going to be all about code. We have a great set of speakers that have agreed to come there and I’d like to rattle off a few of their names. We have Wrench--is his handle but he’s the one who wrote Click-to-Flash which we-- Randall: Wait, I’m sorry. Did you just say wrench was his handle? Tom: Yea, wrench is his handle. Randall: Without irony, no pun intended. Not even like a-- Tom: Don’t worry about it Randall. I think on a different plane than you so to me it was obvious. Randall: Oh yes, of course. You think on a different plane--inclined plane, is that it? Tom: I’m very inclined. But Wrench--yea clicktoflash was one of the first really super popular projects that was a native OSX software--before that there wasn’t a lot of Coca on the site at all and he moved that over from Google code and people just started watching and forking it like crazy--adding features and made it way better. That was a crystallizing moment for me in really seeing that what we were doing as far as the collaboration stuff like to really see it viscerally happen at a rate you could perceive. Like you go there and the next day and there would be like 10 forks with 10 new features that Wrench had pulled in and now you have a new version now. And it was all because he made it easy for people to contribute by moving his code to GitHub. So that’s why we invited him and he’s awesome. We have Dr. Nic, who I believe you know. Randall: Yea, I was going to say I’ve never met the man. An angry Australian if I remember correctly. Tom: Indeed. Angry about what though? Randall: I don’t know, maybe the fact that he’s truly Tasmanian? Tom: Is he really? Randall: Yea, actually I think he’s from Tasmania Tom: Oh, awesome. Randall: Yea cuz he got me some whiskey from--Tasmanian whiskey. Tom: I did not know that they made whiskey there. Randall: Trust me, until he brought it to me, neither did I. Tom: Wait, I think we had this discussion actually--about importing Tasmanian liquor. Randall: Yes indeed we did, yes. As I say, not to say that my memory is effected by my drinking at all. Tom: Andy Lester, the author of ACK, only the greatest code searching tool of all time. Randall: So, keep rattling off the names. It’s a long but illustrious list. Tom: Mojodna is his handle. Randall: Jesus-- Tom: Is that really his name? Mojodna? Randall: For all you know, Osama Bin Laden could be appearing at your conference. Tom: You know, half the people I know, I don’t know their real names. They’ll come up to me at drink ups and be like, “hey I’m John Smith--” Randall: John Jacob Jingleheimer? I know him. Tom: Yea-- Randall: The funny part is at one point in time I really thought that was my name too but as it turns out--no, no it isn’t. It was just a dream. Tom: We all have dreams. But he’s going to talk about geo-location. Jacob Kaplan-Moss, one of the main people at Django, Jeremy Ashkenas from CoffeeScript. Randall: O yea. Tom: Which is amazing. Valerie Aurora is going to talk about the Linux Kernal, highly invovled there. Coda Hale, one of my favorite people, is going to talk about something, security I hope. I don’t know--as long as he is himself, that’s all I care about. Ariel Waldman who is an astronomer/technologist working on things like putting satellites into space, like small satellites. Doing really cool stuff with like space and what not so I look forward to seeing what she has to say. Amanda Wixted who works at Zynga, talk about iPhone code. Nicole Sullivan who does OOCSS--object oriented CSS which is an awesome CSS framework that a lot of people use. Ryan Dahl, Node.js--been doing a lot of Node.js recently. Randall: You have? Tom: Yea but a lot of its internal. We have an internal thing called Hubot which sits in our Campfire room and does things for us. Randall: I heard but apparently it doesn’t talk to Arduino yet. Tom: It doesn’t but it will. Randall: Or will it? Tom: Give it--I have it ordered, Arduino. Randall: I was going to say did you get the program-prag book? Tom: I haven’t bought the book yet, no. Randall: There’s and Arduino book that just came out for Prag. Tom: O really? Randall: Yea. I haven’t read it yet but Prag-pragmatic its gotta be good. Ok, cool right so Doll’s there? Tom: Yup, Doll. And Gina Trapani from LifeHacker and Mick Krieger from Instagram, one of my new most favoritist things. Randall: Yea, actually I know. It keeps coming up--trust me. I see your life in like Polaroid style very flashy, strangely attractive pictures. Tom: Yea, I love it maybe too much. But that’s the line up right now, subject to change, obviously, but we hope all those people can make it. Randall: Cool. So what size is the conference going to be? Are you going for like small and intimate, huge and gigantic? Tom: We want to target--we’ve been--the idea is to target more of kind of the business crew so that we can get companies who are going to try to foot the bill for people to come which makes it so that a wider audience of people can make it there and with that in light, then we’re going to target--I think that the number that I’ve heard is 300 which is not tiny but not huge Randall: Yea that will sell out in an hour. Do you have a venue in mind? Tom: Yes. It’s going to be at the Hyatt, right near the ferry building, got it. That will be the hotel where the conference is and where we will have discounted rates. Like, we really want to get people together in the same space. Randall: Have you called Maker’s Mark and asked them whether or not they can fly in enough whiskey for PJ? Tom: No, but that’s a good idea. Randall: You should get them to sponsor the conference. Tom: Sponsored by Makers. Randall: Just saying. Tom: Not a terrible idea. Randall: So yea--actually there is one other question I had, curious as to how you deal it. A lot people--there are those who actually, forgive the pun “Git It’ and they use Git but then a lot of people the first time they come to Git especially if they were on CVS or subversion or something else or God forbid PerForce or something else like that, they seem to have a cognitive block and say that Git’s too difficult to use. So what are you guys seeing in terms of people--because you have so many new people coming into the community, what do you guys see in terms of people who are adopting Git--first time users. Do you get that a lot? Do you have people complaining about user use or burden? Tom: It happens. It happens less, I think, because there are a lot of pretty good resources online now and people realize--they see Git everywhere, like well why am I not using this yet? Guess I better go check it out. They search for Git and they end up at Git-SEM.org which is a site that Scot Chacon has put together which is now the main Git site. and from there you can find the book’s he’s written and download it for free--you can download the PDF for free of Pro-Git by Scot. And I think that alone, him writing and releasing that book with the technical editor being Sean Pierce, probably, almost inarguably the number 2 person in the Git core project itself is the technical maintainer so everything has been vetted by someone who knows everything. And that book alone and being available for free and Scot lobbied really hard to make it available for free because he wanted it to get to a broader audience and he knew it was important for that to happen so his creative common’s license and that event alone I think changed the perceptions of a lot of people. Here’s a book that’s written in the way book should be written that’s approachable and I can go through and I can actually understand this stuff instead of trying to wade through the man pages or the documents that come with Git which are written by the Git developers which I love but are not, you know--their specialty is not writing help documentation and so being approachable in a book format, I think is huge. And so, education is a lot better now and people have that problem less and as GitHub gets better then people have even less complaints because they can understand how things work like pull requests and we give them hints. We say, “here’s a pull request and if you want to merge this, here are the commands to run” and so reducing that friction between getting something and acting upon it, we try to do as much as possible and in doing that, reduce the stress that people have using get because they don’t have to worry about memorizing 17 options to some Git command. But we are constantly working on making that better. Education is gonna be another focus of this year and really getting together some truly excellent resources and putting together all the resources that we have right now that are kind of spread all over the place. Like Scot has like 5 different websites that have videos and tutorials and stuff because Scot likes to produce stuff. Scot is not as good as curating and putting stuff all together. He’s an idea man and an execution man but like getting them coherently together is something that we want to move towards. Randall: So is what you’re telling me is that you’re having problems merging Scot’s-- Tom: No, its just that Scot is just a fountain of awesomeness and we’re just trying to build a system of pipes capable of routing-- Randall: Ok this strained eating scenario fails right here because otherwise-- Tom: You know what I’m getting at. Randall: Yea. So what else? You’ve got a great audience, you’ve got this platform here. People are interested in what you’re doing so what else do you want people to know? What should I have asked you but didn’t --I failed too miserably because I was too focused on that bottle of whiskey. Tom: Just staring at it. We covered a lot of the stuff I like to impart upon people some of the business stuff, some of the company stuff. GitHub FI, we’re going to be doing a big push on FI is the firewall install, the locally installable version. Randall: Yea actually you know what, that actually brings up a very good question which is what do you guys see as the adoption rate of Git inside of enterprises because FI was designed to be used by people who just can’t host their assets outside of their own environment so are you guys seeing a lot of adoption, a little adoption? I mean are the perforce guys running scared yet? Tom: I don’t know that they’re running scared although, I think the landscape is starting to change a little bit in that we are seeing a lot of interest in FI from larger companies. I mean we have AT&T Interactive as using FI, Zappos is using FI, a lot of companies are starting to come to us and say, “hey we’ve heard about this. a lot of our developers thing it would be great to have internally” and some of them you wouldn’t expect and some of them I can’t even say their names because they’re so enterprisey that they don’t even let you do that. I mean there’s a lot of enterprises and we’ve only seen a few of them but in that we’ve seen any of them, I think is really promising and we’re going to see more and more--its inevitable. Randall: There we have it. Git is inevitable. Yea, thanks so much for the time and I will be happy to come by any time and bribe you with another bottle of whiskey so we can chat. Tom: I think that’s a pretty good arrangement. Randall: Works for me. Thanks for tuning into Cloud Out Loud podcast. As always, send any questions to us at Engine Yard or the crew over at GitHub. You know how to find us if you’re actually listening to this. Thanks. http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/9/cloud_out_loud_tom_preston_werner.mp3?1296870696 Sat, 05 Feb 2011 01:51:36 +0000 no S01E08: Laura Fitton Engine Yard S01E08: Laura Fitton This week we interview Laura Fitton and talk to her about the usefulness of twitter and startup life in Boston Kelsey: Welcome to Cloud Out Loud. This is Kelsey Schimmelman. I’m here today with Laura Fitton of 140. She’s fresh off the plane from Boston. She’s traveled a long way to be with us today. Laura: Hey Kelsey. Good to be here. Hi. Kelsey: Good. Nice to have you here as well. So, I’m really interested to hear what you have to say and I’d love it if you could talk a little bit about your background and just introduce yourself. Laura: Sure, sure. So I’m Laura Fitton, CEO and Founder of 140.com and co-author of Twitter for Dummies. I am @pistachio on Twitter and before all that craziness came into my life a couple years ago I was basically a marketing consultant. I helped people suck less at PowerPoint which is not that hard. Kelsey: Wow you’ve come a along way since then. When I was reading your bio I read that a lot of people described your ascent to professional success in social media as a Cinderella story. I’m wondering how you feel about that characterization. Laura: I’m just waiting for the clock to hit 12. No, it really has been insane. I was honest-to-goodness, this random marketing consultant and moved to Boston right after having kids so I had to start my professional network from nada and I started blogging a little bit. I heard about this crazy thing called Twitter. I blogged about how stupid it was cause haven’t we all, right? And that was when it had its breakout at South by Southwest. I was reading about it on blogs over and over and going “This is so stupid.” About May 2007 it started to make sense one day just really out of nowhere and by August 2007 I was blogging an ode to Twitter and I sent a copy of that post to Guy Kawasaki and said, “No man, you’re wrong. Twitter’s great, it can be used for business. Let me show you how” and he listened and he started Twittering and Dave Winer and Laura Fitton convinced me so things just snowballed from there. I started speaking at conferences, I was asked to do a Twitter for Business talk in October 2007 by September 2008 I had relaunched my consultancy to say, “well fine I’ll help businesses understand this Twitter thing”--the book contract came in and frankly I started 140 to solve a problem I had trying to write the book and trying to serve clients which was knowing which app was what, which one should I recommend, how do they compare, how are they different. I couldn’t believe there was no solid list and ratings and reviews so now there is. Kelsey: Wow. That’s really great. What an interesting story. You’re obviously super passionate about Twitter so can you just talk a little bit about the efficacy of Twitter, not just as a business tool but also as a means of overcoming social isolation. Laura: Yea. I think one of the interesting things for me about Twitter has been, “What’s so fascinating? Why am I so caught up? Why are so many other people so caught up? I did a little informal polling and sort of watched all the case studies crews and if you grab Google right now and Google “Twitter: A Love Story” I think is the name of the video. Its like a 10 minute talk I gave at a conference. The thesis of it is “Twitter overcomes human isolation” like we just keeping seeing these events and the reason they break out and they’re significant is cuz the person the event was happening to isn’t alone anymore, right? So way back when the dude in the Egyptian jail, when earthquakes happen....its just this very light weight, very easy way people come together in a flash and share stuff. Elections, sporting events, tragedies, news....its pretty amazing and I think its changes a lot in the future the same way the phone or telegraph changed a lot when they came along. Kelsey: So even despite the lightness as you said, it has a really profound effect on the way that people communicate. Laura: Yea when you think about it, you don’t walk around your town having profound, deep conversations with everybody you pass on the street, right? it’d be crazy; you’d think something was wrong with someone. You do these very trivial, my friend Kevin Marks calls them Phatic, P-H-A-T-I-C, these little trivial interactions with people all the time. That’s where trust comes from to get really out there. That's the fabric of society. That's how we build up trust is minor interactions where instead of getting right in your face and staring at you intensely and freaking you out, I’m just kind of standing next to you and I’m pointing out the window and going, “Wow, cool building” and we just kind of get to know each other that way. So, Twitter mimics that in a trusting way and it can do it only mobile and it can do it so serendipitously that people end up discovering people with really unusual situations or common interests and suddenly you can be in a remote part of the world and have a network of 50 people who have that really unusually thing in common with you and that’s extraordinary when you think about it. Kelsey: That is. That’s really a really fascinating take on Twitter. I’ve actually never heard it characterized that way. So what kind of reception have you encountered to your Twitter-centric business philosophy. Has there been any push back at all or are most of the companies you work with eager to adopt Twitter as a means of branding? Laura: It depends on what calendar date we’re talking about. When I officially said, “Alright fine, I’ll be a social media consultant but I don’t know anything about social media in general really, I just have this kind of one-note wonder thing on Twitter” that was September 2008 and at first there was this huge flurry of interest. I’m in Boston so most of the clients are in New York and then the stock market crashed and everything dried up and there was just nothing. It was a total fetterer. I was 2 years too early. Now there’s serious interest. I think 85% of the Global Fortune 500 has a Twitter account...I might be quoting the wrong stat but there are more businesses on the Global Fortune either 500 or 100 that have Twitter accounts than have Facebook, YouTube, or any other social platform. Kelsey: I did not know that. Laura: And then there’s also some numbers that came in from Exact Target last year showing the act of following a business on Twitter is much stronger intent to buy than liking a business of Facebook. So there’s some evidence that even though its a much smaller platform, it may be more efficacious for the individual companies engaging their....IF you do it right which is key. It takes a long time--that journey I had where it was like oh, “This is so stupid” to like “Oh my God I’m obsessed with it” 3 months later, each business has to kind of cycle through that again and again and make head or tail and see if it works and deal with internal doubt and skepticism. It’s all a pretty normal process. In the grand scheme Twitter’s probably caught on a lot faster than email did in the workplace or telephones did in the workplace. Kelsey: Yea it just exploded. Laura: Yea. Kelsey: That’s really cool. So what’s your development model at 140? Is it Agile or...what kind of development do you guys do? Laura: Yea. So we started out at Pivotal Labs and there its Agile, its XP, its pairs, its everything. We have a modified Agile. We still pair occasionally. We do 2 week sprints. We’re completely dependent on Pivotal tracker still, great tool. I use it for some of our marketing planning as well. We do daily stand ups, occasionally the guys pair--we’re up to 4 engineers. And we do stick to the TDD-Test Driven Development and continuous integration. Also, of course really important to us is being a Lean start up where not only don’t we not know the solution, but we’re not entirely sure of the problem and we’re doing bits and refining and testing and measuring and seeing what catches on. So Lean’s been great at helping you figure out if we’re even asking the right question. Kelsey: Cool. Yea. We have a lot of proponents here at Engine Yard for Test Driven Development and CI so that’s good to hear. What about any plans for a desktop app or is it going to remain strictly web-based? Laura: We really plan to keep it strictly web-based. I think I would probably do and iPhone app or Android app before I did desktop just cuz the usage pattern of consulting a directory is very specific--when do you need it, when are you actually actively researching tools and especially with our business users, we’re just trying to help them get to their answer fast. So i doubt we’ll go in that direction. Kelsey: Ok. Thanks for sharing that with us. So your product was featured in TechCrunch and a lot of people talk about the TechCruch effect where it just drives a ton of traffic to your site. What effect did this have on your business and how did you scale? Laura: Sure, sure. We were super lucky. Well, a couple things. I mentioned that we started at Pivotal Labs-- that’s because we was me for 9 months. I’m solo, I’ve never coded, I’ve never worked at a software company. I really had no idea what I was getting into and being able to have Pivotal sort of teach me how to hire a co-founder and get me up and going on the engineering stuff and then a very nice hand off at the end of my run there to Engine Yard. It was 10 days before my VP of Engineering even started and I’m thinking, if the site goes down, what am I going to do. So, it was worth getting the full service. And then, even with 4 engineers now, they’re really happy with how you guys deal with that stuff. We’ve been on TechCrunch--we’ve been lucky; we’ve been on 8 or 9 times now--and we have never had--we’ve had the site slow down a couple times and it slows down a bit while we deploy but we’ve never had just outright outage because of a spike in traffic and that was impressive to me because before this I was kind of a casual blogger for a couple of years and saw so many people’s blogs just FAIL when they got hit hard with traffic. We were an Inbound Link from Twitter.com, used to have those little definitions off to the side. We got tons of traffic from that all the time; it was kind of like being on TechCrunched everyday in some ways and you guys have performed really well. It’s been outstanding. Kelsey: Well, glad to hear that. So you’ve given us a little glimpse into the path your career’s taken and what I’d like to ask you is what is it like for you to be a first time CEO and what lessons have you learned along the way and what advice would you give to somebody who has similar aspirations? Laura: Don’t do it.....No I tease a lot. I was a Tech Star as well and the Tech Stars came out with a book written by a bunch of Ex-Tech Stars and mentors and stuff like that and my chapter was “Quit Your Start Up.” My basic thesis was, if there is anyway humanly possible you can avoid taking that step of doing that start up you probably should, right. But if its still burning in you and you just can’t shake it and you just can’t sleep, go for it, right. So that was the first thing I really learned, it took me 4 months to recruit myself to the idea. I had just enough experience working at someone else’s start up to know I really didn’t want to go there. The only other sort of quick advice I can give and over arching thing is to look up the poem “If” by Rudyard Kipling and if you think that’s a reasonable threshold of standards to hold yourself to, go for it. Kelsey: Ok. Laura: Again, I’m joking but I honestly have found that poem really helpful. As a CEO, you really have to absorb a lot, as a first time CEO with--I didn’t even manage an employee before. I am a rookie. I’m learning on the fly, I need patience, I need mentoring, I need help, and I need to push myself and really tap into whatever courage and insanity is driving this in the first place. Kelsey: You must be really adaptive. Laura: I think I’m adaptive. I never feel like I’m adapting fast enough. I think that comes with the territory. Kelsey: Sure. Laura: It’s easy to take all the mistakes personally when you’re in the business of going out and making a bunch of mistakes. It’s one of the tough things about a start up also is accepting the fact that you are systematically trying to mess up. To try and--like I said about the test driven and the Agile, sorry the Lean, is you don’t even know if the problem exists. You’re trying to find it and you’ve got to try a bunch of stuff that’s not the right thing before you find the right thing. It’s exciting and fun. I mean, what other job do you get this much chance to reinvent yourself. It’s like a whole other job every 3 months. And again, I joked about that poem but seriously I pull that thing out and read it when I’m getting frustrated because all the answers are in there. Just tap into yourself, listen to your team, accept people....a lot of stuff. Kelsey: We’ll make sure to post it on the site and with the Podcast, seriously. Laura: “If you can trust yourself when all men doubt you, then make allowance for their doubting too”...it just goes on and on its great. Kelsey: Great. Ok. Cool. Ans the final question I’d like to ask is, what is it like for you to work outside the Silicon Valley? What are the culture differences. Laura: Yea. Boston’s really different. We’re--our offices are in Cambridge but just like here we tend to sort of use one word to mean everything and that’s Boston. I did live out here when I was first getting it off the ground. Most of my angels are here, and here being San Francisco of course--I don’t know where you are listening to this. It is different. There are cultural differences. You’re not immersed--I mean when I walk down the street in San Francisco, I run into like 20 different start up people that I know. Less so in Boston. There’s not as many of us, the expectations are a little bit different, the angels are a little less accessible. That said, its not that big a deal. There were people when I was out here saying there’s no way you can run this company from Boston and its actually working ok. I come out here about once a month, I generally stay 2 or 3 days. I probably do 15-30 meetings in those 3 days because its easy to be a priority on some one's schedule when you’re just not here--you’re a scarce resource. So I’d say--it only works because I have a strong foothold out here that I can rely on but other than that it’s great. We’re not all--when you guys had AngelGate and everybody in the start up community was freaking out, we didn’t care. We were coding, we were getting our work done. So a little bit of distance can be healthy too. But no, you can’t do it wholly independent of here because there’s just so much intelligence--or you’d be crazy not to, right, cuz there’s just so much intelligence out here. At least have mentors here, come and go, send your team out for stuff. And the other thing is, Boston sometimes has this, “Oh, we’re number 2” hang up--well maybe number 3 behind New York, right. I’m like, “You guys are crazy.” I did a speaking engagement out in Grand Rapids 2 years ago and they have a start up scene that was all “Yea, we can do it, we can do it here!” and Boston’s too busy going, “Oh, we’re not the best” so it’s like--I’ve definitely been stirring things up. The one other thing I’ve been trying to teach in Boston is go out drinking together a lot. Like all the start ups must drink together. That is such a huge part of why it works out here. Kelsey: it is. Drink ups. Laura: Yea. SF Beta’s tonight, right. Kelsey: Fun. Ok, well its been so great talking to you Laura. Thanks for sharing all of that with us. Laura: Great. Enjoy. http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/8/cloud_out_lout_laura_fitton.mp3?1296781118 Fri, 04 Feb 2011 00:58:39 +0000 no S01E07: Carl Lerche Engine Yard S01E07: Carl Lerche This week we interview Carl Lerche and talk to him about his new gig at Strobe, Bundler and JRuby Danish: All right, today on Cloud Out Loud we have Carl Lerche with us. Carl, can you introduce yourself please? Carl: Hey I’m Carl....Lerche. Just a Ruby Developer, any old Ruby Developer, I guess, coding for fun and profit. There we go. Danish: Alright. Carl: Simple and true. Danish: Sounds good. Alright. So now the next question is, who is Carlhuda? Carl: You’re not supposed to ask that question. Danish: I’m not supposed to ask that question? Carl: No. If I tell you, I’d have to kill you. That joke’s not old. But. So history behind that is, I used to work at Engine Yard. Yehuda as well. We were both working on Ruby on Rails full time. We were actually the only people at Engine Yard that worked on it full time and we paired. So we had a pairing machine that we worked on together and when we committed we just committed from a Carl plus Yehuda at EngineYard.com. Then one of the comments on the GitHub repo, Mislav I think, said “Hey its Carlhuda” and it stuck. So we switched the account to Carlhuda and there we go. Danish: Ok Carl: Still together til this day. Danish: It seems like nicknames run pretty big at Engine Yard from what I’ve noticed. Carl: Yeah. Danish: Alright, so like you said, you were working on Rails at Engine Yard. Now you’ve changed your role. You’re working on SproutCore at Strobe. So I’m just curious how that move has gone for you. Carl: It’s gone great. My favorite thing is actually--I was working on Ruby on Rails, like you mentioned, and it was fun. It was great the entire time I was doing it but in the end I was just working on the framework without really using it. I wasn’t using it for anything serious. A few side projects here and there but nothing that important. In the end I just like to build things. So I moved to Strobe. One of the reasons is I thought, what we’re doing there, there’s a huge opportunity. This is kind of where things are going and that excited me. Also, being able to build something big, hard, and just use Rails for it I guess, and start from zero and use what I’ve been building for the past year and a half I think it what really enticed me. Danish: Ok. Carl: Something new. Danish: Have you enjoyed, I mean, you’re one of the few people that I know I consider lucky, being able to do open source while getting paid to do spen source so one--How did you get to do that so I can learn? Carl: Interestingly enough, when you get paid to work on open source, you get to do everything else nobody else wants to do. So, it was still really fun. I don’t know, I think the way to do it is to contribute to open source for fun. Just lots of it. And I guess eventually, if somehow stars align where there’s a company that wants to do what you’re contributing to, then it all works out. To be honest, also contributing to open source is fun, you don’t need to be paid to do it. Working on closed source problems and applications is also really fun. Danish: Yea definitely. So you’re one of the guys I was involved with building the Bundler Project. So can you just tell us a little bit about that and you know, what are the benefits of Bundler. I know a lot of people ask me, especially what’s the difference between using Bundler and the RVM, I believe its the gem stuff in RVM. Carl: So, Bundler is a great example of getting paid to do something that nobody else wants to do for free. Who in their spare time is like, “I’m going to build a package management solution”? Danish: That’s true. Carl: But it was something that was needed. Alright, I’m sure by now people are starting to forget what it was like before then but managing dependencies back before Bundler was a pretty big nightmare. This was also before RVM which helped in a different way. Actually RVM and Bundler just complement each other pretty well but I’ll get to that. Well some of the benefits of using Bundler is simply that, for the most part you just don’t have to think about dependencies anymore. It just works like magic almost. You have a manifest file that you include with your application that has a list of all your dependencies. Like you can say, “I need this gem and this gem and that gem” and can cherry pick what you need. And then it looks at all the dependencies of the gems you asked for and pulls those in and keeps pulling in til it has everything you need and it looks at the entire thing and figures it all out at once which is something we discovered after we started and the complete problem BUT there are ways to work around that. Which we obviously have something that somewhat works. It embraces you in its warm, warm, warm embrace and hides you from the scary world of dependencies. So....then you asked, how does that work with RVM. So RVM is a project that manages multiple versions of Ruby on your system. It does more than that. It has a feature called gemsets which is--you can create separate profiles of gems. Its similar to Bundler in the sense that you can isolate the gems you want to use at a single time. It differs in the sense that RVM is, for the most part, system wide. Like, its kinda like, “I just want to kind of switch profiles while I’m hacking” or do something different. The whole point of Bundler is, like--you make a Bundle around a certain application and you share that Bundle--the Gemfile and Gemfile.lock with other people that use that application. I guess the key difference is that RVM is mostly just system, global, I just want to change my profile on my single system and Bundler is for working, well you can use it on your own but it helps you when you deploy and working with other developers. Danish: Ok. Carl: I couldn’t imagine not using it anymore. Danish: Ok, interesting. So, I know crazy Dr. Nic likes to ask this about everything cuz he’s just the random Windows lover, but does Bundler work on Windows? Carl: No. For the most part, it works. There were some errors made specifically with Windows, with handling Windows, specific things that if anybody is willing to put the resource and the time to understand the problem and fix it, it’ll get fixed. But personally, like, right now I’m at the point where I’m building applications and I’m going to contribute to open source where I need it. Danish: Yea, definitely. Carl: And I don’t use Windows. Maybe Engine Yard can sponsor somebody to solve the Bundler/Windows issues. I’m sure one of the Bundler dads, like Terrance, Andre, Yehuda or I would help with that. Danish: Alright, well, Dr. Nic there ya go. So you were talking today at the SF Ruby Meetup and you said that for the last 3 months you actually switched to JRuby. You explained to us why but if you can explain to the listeners why you decided to make that decision. Carl: So.....again, for the past year and a half I was mostly just focusing on Rails so I didnt have the luxury to just pick one Ruby or another. Now that I work on just a Rails app I guess, it’s pretty, like--its got its own like specifics and things I do outside of Rails but its mostly a Rails app. I have just the luxury of just choosing the Ruby I want to use. So I came into the problem, I know MRI that’s what I’ve been using, you know, it should be fine. Its--MRI, it works fine for what most people use Rails for. But they’re going to be edge cases where you have concurrency, like a concurrent request--for example, the exampe I gave in the talk today was specifically, I need to upload a 100+ files to S3 before the Rails request ends. I had a very specific need for that. So, I was in a situation where I had to deal with a high level concurrency sending requests out to S3. And then those requests were just blocked for a while and then I had a need for being able to handle a lot of requests that just sat around idle for a while. I had basically JRuby’s perfect sweet spot. The more I use it the more i kind of--well, for server work, if you’re using Ruby on the server, there’s really--I’m sure people will argue with me and I’m sure I’m not necessarily right but I think, for doing Ruby on the server, JRuby is the best option. For a large number of reasons: Java threads, running of JVM....lots of reasons. Danish: Ok, so I know you talked about a few of the projects you’ve been working on with JRuby, so I wonder if you could tell us a few of those as well as maybe ones other people have done that have interested you. Carl: So I’m new to the JRuby and Java world cuz like I just started looking at it recently, but when I first got into it. It was like oh, you should try--like run your Rails app with Trinidad which is a Ruby wrapper around the Apache TomCats Java Server. And you know that worked great for the longest--for the most part. At a certain point, again this is like pretty much my first exposure to using JRuby and Java that at a certain point i needed to go tweak something that happened failry deep down in the internals. Like how JRuby rack handled the requests stream from the Java Server, I needed to tweak something. So, I go in there and see like a bazillion lines of Java, it was like way more than I expected. So I kinda looked into it and was like, “I don’t know what’s going on here” and then I found a Jetty.rb project which is again, a Ruby wrapper but for Jetty this time but it was entirely written in Ruby because JRuby actually has a pretty amazing Java to Ruby bridge. So that was kinda how I got exposed to using Jetty, it was Jetty.rb and again that needed customization but it was all Ruby so I could do it so now I’m starting to get familiar with it. I just started working in a project that I’m calling kirk which is again a Ruby wrapper for Jetty but also supports zero down time deploys. similar to something like Unicorn or Passenger. I’m sure there are a lot of really nice JRuby and Java projects out there that I have yet to discover, but I’m new to it. Danish: Ok, cool. So recently I decided to move to MacVim myself and everybody at Engine Yard told me to go find this MacVim distro called Janus that you and Yehuda created so I’m curious, are you still using Vim or have you switched in the battle between Vim and Emacs? Carl: So I still am using Vim. So actually, I will say, Janus started with me-- like, “I’m gonna try out Vim” and I put out a project with--these are my like .Vim files and these are like--basically it started where I built a Rake file that fetched the Vim extensions from GitHub and installed it. So all I could do is clone it, run Rake, and got the latest. I could run Rake and I could update it and it was like very minimal. Then, I got Yehuda into Vim and then he was like, “I’m gonna turn this Vim project into an amazing Vim starter kit” and I was like, “Alright” I will admit that it was a great project, I just did not contribute that much to it. But I still use it and I still update it and it works great. Anyway, this question has been asked because recently I started looking at Emacs, I just started. Now that I’m on the JVM, let’s look at what other JVM languages are there, ah Closures, maybe--I just want to experiment with Closures. So I talked to a few people who use it and they said--well these people are Vim users--but they use Emacs when they worth with Closure because, well Emacs is really....ok I can’t talk Emacs but its--you use Lisp, its built for Lisp. Closure is Lisp so it makes sense that its optimized for working with Lisp. So its like well, maybe I’ll take this, I’ll start--and I just started doing this. Maybe I should try to use Emacs for bit and see how it sticks and see maybe, maybe in the end I’ll like Emacs better than Vim. I kinda just picked Vim and ran BUT now that I’m familiar with Vim, I won’t lie, its hard. I don’t know if I’ll be able to stick with it. Danish: So we’re not gonna see any Janus version of Emacs coming out anytime soon? Carl: No...but there is a project that’s technomancy GitHub page. It’s Emacs starter kit that’s what I started with and it works pretty well. Although I can’t do anything with Emacs yet. Danish: Yea...I mean I never liked key bindings--I like keeping my hands in one little section and using the J, K, L and all that. Carl: I know, I can’t get away from that. Danish: It’s so much better. I really hate doing Control-Alt, I need to do C, K....why.....I know people are gonna hate me for saying that. Carl: Let’s stay politically correct here. Danish: Alright, so the last question I have is....so today you were saying during the Meetup that the talk was going to be about everything you hate. That’s the jist of where the question is coming from. So I was told to ask you why you’re so emo. Carl: I don’t know. It the source of all my power. There you go--you know, its like, don’t be happy with the status quo, there we go. Always--nothing’s ever perfect. Danish: Do you feel like that’s what drives you to do all these projects on your own and everything? Carl: Definitely I think. There’s always going to be something that bugs me that I’m driven to fix. BUT at the same time, working at a start up, I actually got to move past that too. It’s like....there’s always going to be things that bug you but its knowing when its something that you should do something about or something you should just complain about then forget, Danish: Have someone else try to fix it for you. Carl: There ya go http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/7/cloud_out_loud_carl_lerche.mp3?1296182320 Fri, 28 Jan 2011 02:38:40 +0000 no S01E06: Lewis Cirne Engine Yard S01E06: Lewis Cirne We at Engine Yard could not be more stoked about our partnership with New Relic. Tune in for Tom’s interview with New Relic CEO Lew Cirne—his insights on production visibility and the entrepreneurial spirit are not to be missed. Take note, because we’re sharing the love with Engine Yard customers by offering New Relic RPM Bronze for free! Tom: Our guest today is Lew Cirne, CEO of New Relic. Lew: I really have to thank you personally for giving me a kick in the butt in late 1997 to take this prototype that was a precursor to the New Relic RPM and bring it to market. I think it was your sponsorship of the idea that made me really decide to take a run at this. It’s been a great relationship we’ve had over the years. Tom: I appreciate that. All I remember doing is just being blown away and saying, “Man, you’ve gotta do this thing, because everybody needs it.” It was really impressive when I saw it, and I think it’s ten times more eye-opening now than it was today. So, congrats on all the hard work you’ve done. Can you give our listeners the New Relic “elevator pitch”? Lew: Sure. I guess the easiest way to describe what New Relic does is to say that we’ve got the production tool that developers love. And what I mean by that is we provide production visibility into live web apps that is incredibly deep, and allows development teams to solve the kinds of production and performance problems that usually they can’t solve without trying to recreate the problem in a development environment, or crawl through log files for hours and days to find the clue as to why their app might be slow in production. The way we do that is we provide, through software-as-a-service, we have a web app that collects an enormous amount of performance data from over six thousand customers from our agent. And what our customers do is they install our agent into their app and the agent provides automatic instrumentation that reports on exactly what the app is doing 24/7, including where it’s spending it’s time. Then our customers can log into New Relic RPM to see the performance data and make good judgment calls as to what they need to do to fix performance problems, to fix availability problems and make their app delight their users. Tom: I think that’s one of the key differentiators, as I see it, from the traditional way of doing things. Production is so critical, because you can run things like JMeter, or AB against a staging instance but it’s very synthetic and you don’t get the real-world usage patterns. Lew: That’s absolutely right. It’s not to say that load testing isn’t important, or that profilers aren’t useful—but we believe there’s no substitute for true visibility in terms of what’s going on in production. You can never predict what your users are really going to do to your app, and of course your production database schema will often look different from what you try to create in a staging environment. So there are all sorts of reasons why you need the kind of visibility that we provide from the live production web app. If you’re relying solely on things like load testing or profiling in controlled environments, you’re basically on thin ice when it comes to your ability to deliver consistent performance for your end users. Tom: I know that our support guys at Engine Yard, if they get a customer who has a performance problem, the first question we always ask is: are you using New Relic? It’s the 90% solution to identifying the problem almost every time. Lew: We’re delighted to do that. We love partnering with Engine Yard, and we love providing software that helps your customers be successful and reduce the possibility of finger-pointing when there’s an absence of data as to what’s really going on. People tend to go to their gut feeling and suppositions and that’s where you get tension between various constituencies. It could be development vs. ops, it could be the platform provider vs. the application developer. We find that the ultimate mechanism by which you can get teams on the same page to collaborate and be successful is to provide the data that everyone can agree on. Tom: Can’t we all just get along? In the past, we had a different economic arrangement. I think we purchased services at a discount and the new agreement that we just signed states that our customers get Bronze for free. Let’s talk about free a little bit. Why is that important to New Relic? Lew: We’ve always had a free offering, which is Light—and Light will always be free for anybody who just wants to sign up for New Relic on their own—and to be clear, lots of customers find great value in Light. But Bronze is one level up from Light. And if you want to come directly to New Relic you can purchase RPM Bronze for as many servers as you run your application on. But like every other IT vendor, we believe that the cloud is just this incredible trend in which we want to participate, have mindshare and have ubiquity. We look to partner with the premium players in the cloud space and obviously Engine Yard is one of those companies. So we are willing to work out an arragement to provide something as valuable as RPM Bronze to Engine Yard customers with the belief that due to the higher value that you can get from Silver or Gold, customers who are really serious and that have an exposure to a high-value product like RPM Bronze are likely to become New Relic customers at a higher level. And we’re willing to do that based on the fact that the cloud trend is something we want to ride. Tom: I think it’s a wise choice and I know our customers are going to appreciate it a lot. It’s always fantastic to be able to provide useful tools. Lew: There’s a tendency in companies that people don’t really respect where there’s a little bit of bait-and-switch in their business practices where the claim falls far short of what they deliver. We want to flip that and over-deliver on our claims with the hopes that that turns into long–term business relationships as we grow our customer base. Tom: Since the very first time I heard about Rails, I was also hearing all these questions about scalability. Though you guys have extended far beyond Rails itself, what do you see as the most common performance issues in Rails applications under monitoring? Lew: The most common issues in Rails are also common issues in virtually any common web app that has layers of abstraction in the framework. That is, so long as there’s software development, there’s going to be evolution toward higher layers of abstraction in the development framework, meaning faster time to market. But that, by definition, means less transparency on exactly what your code is doing at run-time. You contrast what assembler code did thirty years ago when you knew what every instruction did and exactly how much it cost, to today when you call an active record “person.find,” and you add one extra param to the cache in that argument and all of a sudden you’re missing an index. And you may not notice that problem when you’re running on your development box when there may be a hundred rows in your table. But when you go into production you’ve got a couple million rows in that table. That’s a big problem. And that’s all sort of abstracted away by the beauty of active record, where you can do person.find. So, I love active record, I love abstraction layers, but what you need to keep in mind when you adapt these accelerants into time-to-market, through development technologies, is that it comes with a cost. That cost is that there is going to be a lack of transparency on what your app does at run time, which is a worthwhile trade-off, because time-to-market is so important and because today’s compute infrastructure allows you to run at very high speeds. But you need to know what the impact of your code is in production and where the hot spots are. So find the five percent of your app that is taking up time and diagnose it. Tom: If we could get a little more specific, is it database queries that we’re talking about here? Lew: Database queries is a great example of it. It could be a poorly formed query. Another great example is just too chatty with any backend system. Even Memcached. Memcached is lightning fast. In most operations it could be sub-milisecond. But it’s not faster than memory lookup in the same process. So you’ve got to be aware of when you’ve got loops of interprocess communications, even to fast systems like Memcached. And if you’re going over the cloud to an external system that could be in a remote datacenter, then you’ve got even higher latency issues. Tom: I hate to speak as the eyes of age, but I tell young developers all the time that one of the problems with modern development is the answer to almost everything is, “Oh, that will be easy to do.” Now that everything’s easy to do, the problem is there’s just so much to do. Everything used to be really hard, but you only had to do one or two things. Now there’s twelve thousand things to do—you’ve got to sort out which ones are really important. So you write the app, and New Relic gives you the ability to quickly get to the hotspots, to where the bottlenecks are. Lew: Performance problems tend to be app-specific. Therefore, app performance management is totally different from infrastructure performance management when you look at six metrics: CPU, Load, IO, etc. Right? In the app, you need to have application-centric metrics which allow someone with some familiarity with the design of the app to find out what the key parts of the app are that you need to pay attention to. So what we tried to do was put together the data in a form that makes it easy to come to that conclusion in your own app. Tom: One thing we talked about the first day we met is, that performance gurus have always said, you cannot optimize until you measure. You measure first. And that’s what New Relic does—it gives you all that measurement, and then you can specifically go out and optimize the critical parts. New Relic is very much a cloud company, Engine Yard is a cloud company. The combination of the two allows a new kind of application development. Where do you see this headed, if you could just kind of put on a futurist hat? Lew: I’m incredibly excited about this moment in time for the technology industry and for entrepreneurs. As a small company, we don’t have any on-premise software. All of our documentation lives in cloud-hosted services. What that means is, it completely lowers the upfront and ongoing cost of doing business at a high level. As someone who founded a company in ’98, that was a classic direct-enterprise sales company, we had to raise an awful lot more money and hire an awful lot more people, to achieve an awful lot less. And much of that was because the delivery of the software was on-premise, it involved a lot more hand-holding in our go-to-market. The fact that we’re in a cloud model now and we deliver our software over the web, we can sell a lot more efficiently and that means a lower cost for our customers. So as a cloud provider I can see a lot of efficiency there, and as a consumer of cloud technologies, our IT spend is far more manageable, predictable and lower than it was in the company I founded in ’98. We’ve got better products that are continually improving over time, because we’re subscribing. Tom: As a serial entrepreneur like you, it’s incredibly cool to me to follow our EY Cloud Twitter account and to see a constant drumbeat of new functionality, bug fixes and whatnot coming out, as soon as they’re ready. It’s a beautiful feeling. It feels much more like the product is alive and is meeting the needs of the users than it used to—it used to be kind of a scheduled thing. Lew: The customer has a problem with it and the vendor has a problem with it, because they’ve got to support back-versions of the software. So nobody wins when you’ve got on-premise software when you’ve got a Cloud alternative. Tom: In the past, I kind of wondered what our customer base was. It was easy to say web developers and that sort of thing because those were the people we spoke to most often, particularly early on. When I was doing a lot of sales myself I was almost always speaking to the business people. I think that both New Relic’s and Engine Yard’s customer bases, and probably most cloud customers in general today are in one very solid group which I’m happy to be a member of, a group which has finally gotten its own national holiday—Entrepreneurs. I believe there was a book written called, Once You’re Lucky, Twice You’re Good, and I believe that qualifies you as good. Congratulations on that. What is it that has allowed you to do this twice? Lew: I guess it may be an affliction rather than a talent. But I feel like there’s unfinished business with this problem that I started solving in ’98. As a bit of context, the company I founded in ’98 was a company called Wiley Technology, which took a bet on a then-fledgling technology: Java. The goal was to put production-visibility into Java web apps to help people diagnose problems and performance issues. We did it with on-premise, heavy-weight Java software which, for it’s time, was innovative and groundbreaking, but which now looks rather dated, like when you watch Seinfeld and you look at the computer on Jerry’s desk and you can tell… Tom: He did have good computers, though. Lew: He did—but I doubt they could load Facebook.com and execute that Javascript. The point is, I’ve been addicted to the application performance problem. New Relic was an opportunity at a do-over using all that we’d learned from Wiley. What Wiley did very well was deliver low-cost production visibility to Java web apps. What I wanted to do better was make it way easier for the end user to install and fall in love with the software on their own, so that we didn’t need to hire a very talented and skilled global sales force to help the customer understand the value of the software. Because that all turned into cost. When Wiley was acquired in 2006, of 260 people, about 70% of the company was in the sales force and maybe 10% of the company was development engineers. Now we’re inverted. We have six thousand customers and 4 sales reps. The vast majority of our customers don’t talk to our sales force, they just try it out. Our litmus test is that if the customer can try it out and fall in love with it and solve the problem without talking to a human, that’s good for everyone. But we do have great sales people available for people who want to learn more or make a larger investment, so that they feel more comfortable understanding what their various options are. So it’s not like we have an aversion to having a sales function, it’s just that we don’t have the same kind of friction in the process and that allows us to have a much less expensive product and a more profitable company. Tom: So at this point, you’re probably well past the ten thousand hours of mastery in the startup phase. Are there any words of wisdom that you have for fledgling customers? Lew: If you don’t love what you’re doing don’t even bother trying it. You’ve got to be so in love with the idea. I think that the most likely chance that your idea is going to resonate with the market is if it really solves a problem that you understand well. Wiley, my previous company, came out of my development experiences with Java and the challenges I had understanding how that Java app ran in production. I kept noodling on that problem to solve it for myself, and when I came up with an idea that I thought was an elegant solution, then I asked whether I thought that other people would be adopting Java in the next five years, and would they have this problem. If you can conceptualize a problem that you don’t have a visceral feeling for, I think that on a shoestring budget you’re less likely to develop a compelling solution for that problem. Look at 37 Signals. They developed Basecamp as a solution for themselves. So that’s the advice I’d give. Let your passion for the problem you solve be a vehicle by which you attract great people. They need to get passionate about the cause. You need to be open to making this a joint effort, not your personal effort, so that you attract a world-class group of people who, as a team, can build something magical. Tom: Did you see the Michael Jackson documentary that was released posthumously? Lew: I did. Tom: I’d never put it this way myself, but I love his line, “For the love.” He really makes a huge issue out of it, and it shows in his work—in kind of a strange, genius, Michael Jackson sort of way. But it’s for the love, which is what you’re saying. So congratulations on loving application performance and thanks for doing so. Lew: Thanks. It’s a strange affliction. I have no idea why I’m so consumed by solving this problem, but it’s what excites me about coming http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/6/cloud_out_loud_lewis_cirne.mp3?1295579442 Fri, 21 Jan 2011 03:10:42 +0000 no S01E04: Tom Mornini Engine Yard S01E04: Tom Mornini This week on Cloud Out Loud, Danish Khan interviews Tom Mornini, co-founder of this fine conglomeration of hardworking people that we call Engine Yard. His profound passion for Ruby on Rails really comes through when he speaks about the evolution of Engine Yard as a necessary reaction to the explosive growth of the community. Danish: Hi, Tom. Could you introduce yourself? Tom: I’m incredibly humbled to be a founder of <a href="http://www.engineyard.com/">Engine Yard</a>, which has grown so quickly beyond our imagination when we started. I’ve been in programming, I have a very technical orientation. I’m the CTO here at Engine Yard, and I’ve been in tech since I was twelve years old, in 1978. I guess I just gave away my tender age. Danish: What is your role at Engine Yard and how has it evolved? Have things changed with the company’s growth? Tom: It’s changed really dramatically, and it’s been kind of a roller-coaster of sorts. It’s had its incredibly exciting parts, and it’s absolutely terrifying parts. When we started, Lance and I were interested in having a product-based business. We had a human talent consulting service called <a href="http://www.qualityhumans.com/">Quality Humans inc</a>. Then we stared into Rails, and what we realized that Rails was really tremendous and was going to have a gigantic impact on IT. The missing piece though, was simplified and really high-quality deployment expertise. That’s how we got started. I think people might find it interesting that one of our primary goals in starting EY was to create a company large enough that we could support ourselves and our families and have group health care. Sometimes the very simplest of thoughts can lead to really exciting times and changes in your life. One of the things my Dad taught me is that when you go into a small business, the person working the hardest is inevitably the owner. As I’ve grown older and gotten more and more curious about such things, I’ve actually made a point to go over and ask the person who’s during the worst job, the guy in the independent gas station spraying down the pavement at 2 in the morning. It’s usually the owner. Especially in a company in a high-growth opportunity like Engine Yard was in, I think a lot of our employees worked incredibly hard behind our real hard work and willingness to roll up our sleeves and get in there and do that front-line work. If you exert yourself that way and provide leadership by example, people will follow. If you work hard, and ceaselessly and tirelessly, everybody will fall into place. All of the employees at Engine Yard show that on a day-to-day basis, and have since the beginning. We have absolutely tireless, dedicated people working here and I love every one of them for the effort they put in. What happens is, you can’t lead effectively that way for very long. You get burned out, and more importantly, you get too involved in day-to-day decisions, and you can’t steer the company if you’re in the boat. It’s been very very difficult for me to transition to more of a guidance and keeper of Engine Yard culture. I think it is important—a lot of what got us here was a few very specific thoughts, and as a company grows big it’s important that it not lose its roots. But it’s also a very, very difficult transition growing from a company of 5 to fifteen employees. There are stages along the way that are very, very tricky and that’s why we’ve brought in management to help us, because frankly, we didn’t know how to run a company with more than thirty employees in it. Danish: I know people say that when you bring in management, that the culture of a company changes. But when I first came to work here and someone pointed you out as the founder, I said, “that guy in the t-shirt and shorts, eating that burrito over there?” How did you maintain the casual, start-up culture around even after bringing in management? Tom: Well, there are people here including early employees who would say that actually I did a pretty crappy job of it. This is something I’ve spent a lot of time thinking about and the answer is pretty complex. The simplified answer is that the culture of a true start-up—an idea alone, creating the first product, getting the first customers—it’s chaos. And it’s managed, focused, crazy, beautiful chaos, but it doesn’t scale well. Things start unwinding pretty quickly until you get systems in place. Lance and I have started a lot of business, and we knew a lot of the things we had done right in the past and a lot of things we had done wrong in the past . With that in mind, we tried to fix some of the things we had done wrong and keep all of the things we had done right. But what we had never done is run a big company where you have to get a hundred people aligned on a common theme, and really greatly increase the pressure at the tip of the sphere. It’s hard for five people to become unfocused. It’s extremely easy for a hundred people to become unfocused. For years I’ve heard big companies with this concept of “focus, focus, focus, focus,” and I’ve never appreciated it as well as I do today. I encourage everyone who’s listening who is running a small company not to slip into something that I certainly slipped into at Engine Yard—Having a long-term vision is good, but you can’t resolve it all at once. One of the things John Dillon, our new CEO, has taught me is that there are a lot of things to do and we need to do them one at a time, until we’re really good at them, at which point we can maybe start doing things two at a time. It seems crazy that with millions of dollars of funding and a hundred people here that we can’t do more than one thing at a time, but it’s the reality. Big, billion-dollar company usually only have three or four things they do at one time. And I think a lot of start-ups, because there’s so much to do, can get disoriented that way and think they have a hundred things that are critical right now. So, lots of things to do, do them fast, do them one at a time, and rinse repeat is really super fundamental. Danish: A lot of people ask me why there is no Engine Yard for other languages, like Java. What’s your take on that? Tom: People have asked me that for years and years now, and I’ve seen it on Twitter. It’s very clear that something kind of special is in the water that the Ruby community drinks from in terms of Cloud adoption and that sort of thing. I’m now kind of paid to think about these kinds of things, and now that I don’t have my head down in the weeds, I can actually spend some calm time contemplating such things. The simplest answer, which is probably the right answer, is that in the past, application development was so torturous and slow that if it took two weeks to requisition a server and configure it to run your application and then run it, that wasn’t a big part of the application development process. I think what David at <a href="http://37signals.com/">37Signals</a>, the creator of Rails—who I pay continuous homage to for giving us this unbelievable gift of Ruby on Rails—I think David and Matz combined will be remembered as the Henry Ford of modern software development. In the past, every application was a bespoke, custom coach, manufactured for the owner. Ruby on Rails is more of an assembly line. It simplifies the enormous complexities of application development with extraordinarily consistent and beautiful, common answers that work better than anything I’ve ever seen individually designed. Now we have a situation where a couple of developers can write an application in a couple of days, and that application doesn’t even need to be trivial. It’s unbelievable what the guys at the <a href="http://railsrumble.com/">48-hour Rails event do</a>. It’s unbelievable the kinds of applications that they’re building in 48 hours with a couple of people. That I think is why Rails is so far ahead in the Cloud space, because if you can build something in 48 hours then you can’t spend a couple of weeks deploying it, right? It was an absolute requirement that we exist. There’s no other way it could have happened—it was purely evolutionary. Danish: What got you and Lance to decide, “we’re going to do it on Rails,” even though Rails was a new language among other game-changing languages. What really got you guys to decide to use it? Tom: At the time, I was working among Fortune 50 companies, as a consultant to an enterprise software development tools company. We were modernizing their software development processes. I was shocked at how far behind open source, modern techniques these enterprise companies were. Working at those environment taught me a couple of things: the world is really quite large. There is a class of customers that has business problems that need solving that aren’t entirely associated with the lowest cost. Fortune 50 companies have stacks of money. They use that money as a tool or weapon to get things done. They are more than happy to spend money to solve problems. And I saw them spending gargantuan sums of money, to put ridiculous products into production, vs what was available in the open source world. So that, to me, immediately screamed “Gigantic Opportunity.” I couldn’t believe how big the market was, I couldn’t believe how easily they wrote really large checks. To people that are into technology, that are into programming, that have an engineer mentality, one of the prime aesthetics in engineering is efficiency: You want something that exactly matches your specs at the lowest possible cost. That almost is the definition of engineering. Because of that, I have noticed that engineers have a crazy kind of cost-benefit analysis: they will spend an enormous amount of their own time to save a penny, because that is the aesthetic. That could be the difference between being the cheapest way, and not the cheapest way. The cost-benefit is way off. So I saw these companies with big problems—billion dollar problems—that were willing to spend a lot of money to solve them, who weren’t really concerned with the efficiency of that. Right about this time, I was kind of burnt out on this gig, and a buddy of mine, Aaron Frye, sent me this very innocuous email that said, “Hey Tom, I’ve heard about this new thing Ruby on Rails, and I’d like your input on it.” I had heard about it as well, as a distant echo, in the newsgroups and stuff I read at the time. I Googled Ruby on Rails and saw the <a href="http://www.youtube.com/watch?v=Gzj723LkRJY">famous fifteen minute video</a>. I was quite impressed. It was something very different. David was a tremendous salesperson on that thing. I went to Amazon, and there was the great book by Pragmatic Programmers Group, Dave Thomas, <a href="http://pragprog.com/titles/rails2/agile-web-development-with-rails">Agile Web Development with Rails</a>. It was available for pre-order, not yet for shipping, so I ordered it and then I totally forgot about it. As soon as I ordered it it left my mind in a way that few things ever have. A few weeks later, I came home and there was an Amazon package on the doorstep. I picked it up and threw it on my wife’s pile, because I knew for a fact that I was waiting for nothing. I had totally forgotten about it. A few hours later, she came in and said, “Did you order this?” and it was the Agile Development with Rails book. I was really excited, because I was bored to tears and tired of traveling, so I was like, “Yeeha, I get to learn something new,” which is one of my favorite things in the world to do. I sat down and started reading this thing, and I could not believe—Ruby on Rails addressed every concern that I was running into on a day-to-day basis and that these companies were writing these gigantic checks to fix. It solved them in a way that was simple, that was unified, that could be repeated across applications forever. So I was enthralled, to say the least. At the time, Lance and I had started another business, which was a horrible failure. We had an application written in Perl, which I’m actually quite a big Perl fan, or was back in the 90s. There’s good Perl and bad Perl and this was the worst of Perl, the worst of a lot of things. I decided that the best way to learn would be to rewrite this application in Ruby on Rails. I was on the way to Washington DC, where we had a consulting gig, and I took the red-eye from Sacramento to Washington DC, and when I got on the airplane I had my laptop all configured to run Rails, and when I got to DC, I had about 85% of the application recreated on a five hour flight. Lance was in DC already. We had a corporate apartment there. It was about 7:30am when I got to the apartment. Lance was up making coffee and breakfast when I walked in the front door—I was completely manic. I said, “Lance, Lance, Lance! This thing is completely unbelievable. Let me show you what I did!” He couldn’t believe it either. I said, “We have to be in the Ruby on Rails business. Buy the keywords, put it on Quality Humans: we are now consulting in Ruby on Rails.” And Lance, being the unbelievably great business partner that he is, and the hardest working guy I know, just made it happen in a few hours. The phone just started ringing. So there was already at that time, about five years ago, this enormous, pent-up demand for Ruby on Rails developers. It wasn’t that there were so many people clamoring for it, it was that there were so few people who knew how to do it and were willing to do it professionally. So, that got us really excited, because there’s nothing like having an idea and having other people agree to pay you money to do it. That’s a very fun feeling. So we started doing that consulting, and what we found was that it completely transformed our consulting business. We had used to have a hard time getting projects done and customers happy with the code. The whole world has suffered this in software development for decades. It’s the problem in software: We can’t get it done fast enough and it never turns out quite the way we want it to. That problem just ceased to exist and the next problem was, “Where are we going to run it?” There were no experts on running your own stack, the stack at the time was extraordinarily complex. It used no technology that anybody else used. The Ruby on Rails community were a bunch of crazy maniacs. They didn’t use Windows, which, at the time, was unheard of; they didn’t use Apache, which at the time was unheard of; they used this crazy language, Ruby, which was developed in Japanese and half the documentation was in Japanese. I mean, it was just a crazy-house compared to the norm, which I am really comfortable with. I don’t like being in that normal group. So I just felt an immediate kinship toward the community, I loved the people who showed up at conventions, the people there were bright and were tired of the status quo. They were tired of the problems they’d had developing software and they’d found a solution. So we decided that we needed to make deployment really easy, and that formed Engine Yard. So, you set the question up like, “you started Engine Yard, what language did you choose to support?” That was totally backward. We were all about Ruby on Rails. We saw pain in Ruby on Rails deployment, and we solved that problem. I didn’t feel like there was even any decision to make. The decisions all appeared to be right in front of us ready to knock down. The hardest parts were getting the right people, getting the message across and all that. It really didn’t feel like we were trying to create something. It felt like a rip had opened in the space-time continuum and we were just sucked into it. Danish: We have some questions from your Twitter followers. The first one is: do you expect to have a two hundred million dollar buy-out from Salesforce anytime soon? Tom: Obviously that’s in reference to the recent <a href="http://www.salesforce.com/">Heroku</a> acquisition. We’re good friends with <a href="http://heroku.com/">Heroku</a>, they’re here in San Francisco as well, we knew them before. I remember the first time I met them, they came into our office in San Francisco before they even had an office, I think. A lot of people have set us up as enemies, but internally we’ve always felt that we would eventually probably have to go after each other—after we both helped take down Java. We really, clearly understood that our product were different, they had different ideals, that each would attract its own customers—the real enemy is not Heroku vs Engine Yard—the real enemy is Java vs Ruby. I think we’re both winners with the Heroku acquisition, because it’s very clear now that that Ruby on Rails is headed deep, deep into the enterprise. Salesforce has announced that, VMware has announced Ruby on Rails support with their OpenPass platform at RubyConf X in New Orleans this year. Nothing could make us happier. The other thing that’s really clear is that everything’s for sale. If someone offered me the right price today, I’d sell you my shoes. That said, when we partnered with Benchmark, Benchmark surprised Lance and I by saying something that was very contrary to what we understood the VC world to be about. They said they believed that there is room in the future for an independent public company in the Ruby on Rails space. That’s what we’re trying to build here. We’ve never been in a race to sell Engine Yard. It’s just that simple. What we’re trying to do here is to build a very big, very cool company that can change the world one developer at a time and take the Java shackles off of their wrists and set them free with Ruby on Rails. Danish: Last question: Any plans for other cloud providers or open-stack technologies? Tom: Yes. <a href="http://www.engineyard.com/products/appcloud">AppCloud</a>, our primary product, takes your apps and deploys them on the AWS infrastructure. We absolutely have rather carefully designed the product so that when the time is right, we will be able to take the customers’ applications and deploy them onto various different back-ends. And perhaps just as importantly, we are eager for customers to be able to push a button and move from one provider to another. I think that is a slightly harder problem than some people make it out to be. The technology of doing it is pretty straightforward, but getting all the pieces right so the application continues to perform properly—what components can be hosted externally as a service, what things must be low-latency connected to the application itself—getting all those pieces right and making that migration smooth and easy is very important. So it’s absolutely part of our planning, certainly no product announcements today. What customers should know is that these decisions will be made based on what cloud platforms they want to deploy their Engine Yard apps stack on top of. We are not going to be trying to pick winners and losers in the cloud space or anything like that. Wherever customers want to go is where we want to be. http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/4/tom_mornini_interview.mp3?1294435106 Fri, 07 Jan 2011 21:18:27 +0000 no S01E03: Sarah Allen Engine Yard S01E03: Sarah Allen Sarah Allen of Blazing Cloud is a true open source insider. In this episode of Cloud Out Loud, she and Matt discuss the Ruby Ecosystem and its effect on programmer happiness. Don’t miss her incisive speculations about why our favorite language and the people who use it are so disruptive. Matt: Sarah, why don’t you introduce yourself? Sarah: I lead a consulting company in San Francisco called <a href="http://blazingcloud.net/">Blazing Cloud</a>, where we create Ruby on Rails web applications and mobile applications and all that fancy front-end Javascript stuff that people like to see on the web these days. I also lead a nonprofit called <a href="http://railsbridge.org/">Rails Bridge</a>, which seeks to broaden the community and diversify it and makes it clear how to go from being an aspiring developer to being an open source contributor. Matt: How does this Ruby on Rails ecosystem differ from other communities that you’ve been a part of in tech? Sarah: The Ruby ecosystem has a few things that I haven’t really seen combined in this way before. There’s open source, which is becoming more and more a part of business. There’s a thriving business climate, there are a lot of hot jobs available, there are a lot of companies starting to use Ruby. There’s a thriving community. When I was developing desktop apps, I don’t think I would ever have said that there was a “C community.” I think that we’ve seen business booms and downturns, and during the last couple booms, I saw a lot of contraction—people got really proprietary about their ideas and their innovations and people felt like, “I’m going to be successful because of my secrets.” We’re seeing something very different now. Matt: You once said to me, “Ruby just makes you happy.” I’m curious—is this a part of why this feels like a more dynamic and active community of developers and engineers? Sarah: That’s part of the driver of it. Ruby makes people want to create stuff that is maybe a little peripheral to the core business value. There’s a new value system that says, “I ought to be happy about my work. I ought to take a little extra time to make toys that I enjoy using, and I ought to share those toys with my friends because I want my friends to be happy.” When people really enjoy working with something and making something and being a part of something, they do it more. I think that people refer a lot to <a href="http://translate.google.com/translate?u=http://www.rubyist.net/~matz/&langpair=ja|en&hl=en&ie=UTF-8&oe=UTF-8&prev=/language_tools">Matz</a> creating Ruby to make programmers happy. He wanted to address the design of the user interface. He wanted to think about how people use it and make them productive, and he had a lot of foresight in stating that. I also think there are some attributes, technically, that make it easy to mix and match components. The way that the language is implemented—as a dynamic language with an object-oriented paradigm that stems from Smalltalk—makes it easier to introduce new components that act seamlessly like old components. The last thing is that because the community is vigilant about testing, and there’s tremendous support for testing, it means that you can just try new things. Matt: there seems to be a velocity in this ecosystem in which things go from zero-to-deployed-everywhere in a matter of months. For example, Unicorn; I never heard of it until summer 2010, and now it’s winter, and most of the apps we see coming onto Engine Yard AppCloud are in Unicorn. Can you talk a little bit about the velocity we’re seeing in this ecosystem? Sarah: A number of things contribute to that velocity. One of them is this emphasis on testing—people are free to experiment because they have a safety net. There is a pride people take in showing off what they do. Reputations in the community are built by producing open-source software, so there’s an evangelism that happens in the community. I have a friend who says that Ruby is a language for extroverts. Matt: Do you think anything is sacrificed by having such high velocity? Our engineers talk a lot about CI and the false notion that a QA team is the be-all-end-all of finding a problem. Could you talk a little bit about that and what the philosophy is like, and how that differs from more traditional engineering groups? Sarah: I think we’re still learning how to do <a href="http://en.wikipedia.org/wiki/Agile_software_development">agile development</a> in such a way that you have the traditional notions of reliability, the five nines, all of that stuff. What a lot of us are noticing is that when we worked in a climate where you had made commitments, and you had run test plans, and you had three— month beta cycles, you still shipped with bugs. And you still had SLAs that stated how quickly you had to respond to customers because stuff happened in the field. What we’re learning is that there are new ways to develop software that can be just as reliable as the old-fashioned ways, but through different processes we can get it out there faster. The reason I say we’re still learning is that there have been new innovations in the last few years around Continuous Deployment. For example, <a href="http://www.startuplessonslearned.com/2009/06/why-continuous-deployment.html">Eric Ries</a> has been very outspoken about what he calls an “immune system” around your deployment, where if anything goes wrong you can roll back immediately, and you have areas around your website that take the brunt of things first. Matt: Is there something in Ruby that makes it a kind of digital antibiotic? Sarah: The attributes of Ruby in terms of it being a dynamic language really play into that. I think that Dynamic languages are really effective in this kind of agile creation and responsiveness. However, I think there are other languages that could probably work this way, for example, Smalltalk proponents would say that that language is ideal in this environment. But what we have with Ruby is not only the language properties themselves, but the thousands and thousands of <a href="http://rubygems.org/">gems</a> that are almost entirely open source. We have a fabulous package system, version control, things like <a href="https://github.com/">Github</a> that by default when you share code you make it public. By default you have read-me’s that are published on the web and are searchable by Google. By default, you have all of these mechanisms that let you publish, collaborate, and make things available. I was teaching a class a couple months ago and talking about the importance of gems, and how to determine if something’s a good gem. These days you can’t rely on something having a staid, well-known name to know it’s reliable; like <a href="http://unicorn.bogomips.org/—how">Unicorn</a> would you know by hearing that name that it’s something you ought to deploy? Or something could be created by a fictitious person, like why the lucky stiff, and still it is great code that you should deploy. Matt: Who is <a href="http://en.wikipedia.org/wiki/Why_the_lucky_stiff">why the lucky stiff</a>? Sarah: He was a very prolific Ruby programmer, who built <a href="https://github.com/whymirror">35 popularly used libraries</a>. He did serious things like <a href="https://github.com/hpricot/hpricot">XML parsers</a>, and whimsical things like creating <a href="http://hackety-hack.com/">environments for kids to learn programming</a>. He wrote songs and comic books about the Ruby language. Then, one day, August 19 2009, he disappeared and took all of his servers with him. Every project that he had created and hosted and maintained disappeared from his repositories. People were stunned—I had created a curriculum from one of his projects. Matt: Perhaps he’s playing chess with Bobby Fisher. Sarah: One of the best jokes I heard about his disappearance was that he had gone underground working on <a href="http://dev.perl.org/perl6/faq.html">Perl 6</a> and had renamed himself “when.” The other thing that’s part of the ecosystem is <a href="http://git-scm.com/">Git</a>. Almost every Ruby programmer uses Git. Git is built for collaboration, and it is a modern source code control system. It makes it so that if your primary contributor disappears, anyone who contributes to the project has a complete repository. So when why disappeared, within 12 hours, there was a “whymirror” up on Github. Within days, there was a volunteer to take over almost every one of his projects. This is the incredible thing about the community: you don’t need to have your chief maintainer be someone who works for a corporation, who has a whole subsystem around them—I think this leads to this philosophy where individuals feel that they can publish stuff, and if it’s good others will contribute, and it will move forward, and you won’t be tied to this thing you built for the rest of your life. Matt: So what are some of the other things, like Github, that you introduce people to? I know you teach classes—where do you point your students? Sarah: I think that Introducing gems is really important, and showing them that it’s really simple to look for gems on rubygems.org, and viewing gems that the documentation for both Ruby and Rails comes from the source—its like Java docs, whenever you look at the documentation it always comes with a source code. Whatever you need to do with Ruby and Rails, for 95 percent of what you need to do, somebody’s done it before—somebody’s written about it, or published a useful script for it, or a gem for it and it’s all searchable. One of the things I tell people is that if you’re writing some code that you think is probably in 85 percent of other web applications, do a quick Google search first. What this does is it liberates you to focus on what’s special about your application and about your code. What’s unique about this moment in history is that we’re building what we’re doing on top of the last 20, 40, 60 years of innovation and computers have gotten fast enough that reusable parts are really practical, and dynamic languages are really practical. Before, it was less practical to use dynamic language as introduction code—now we’re not gated by CPU Power; we’re gated by our ability to solve human problems and take them to market. Which means that we need to focus on communication, on sharing the kinds of things that will become commodity software next month or next year because, who cares? That’s not where the value is. The value is in problem solving. Matt: All of these technologies seem to come out at the speed of light. For someone like an engineer who’s involved in a project day-to-day, who’s engaged with that one project, how do you manage it? Sarah: It’s really hard, I will kid you not. But this problem does not come from Ruby. This problem comes from the world we live in. There’s a lot of stuff happening technically. Some of the perceived churn is kind of imaginary. It’s not like we invented the http status code. All of the stuff that we’re layering on top of hasn’t changed in, what, 15 years? Http is the same, DNS is the same, IP addresses are the same, but we’re mixing and matching them in innovative, exciting ways. Matt: Tell me, what are some things you’re excited about that do seem really revolutionary and innovative? Sarah: I certainly think that the network effects and the size of the data sets we’re dealing with create opportunities for innovation around visualization, around surfacing, and around relationships we used to have to search for. We can ask questions in more powerful ways, but also computers can be smart enough to tell us the obvious things that we really need to know. That’s where the true innovation is happening; how do we leverage these enormous data sets, fast CPUs, and the interconnectedness we have that is truly different. Matt: You use the term “ecosystem” intentionally. Could you tell us what the difference is between an ecosystem and a community? Sarah: When I think about the word “ecosystem” I think about sustainability, I think about growth, interdependence, and a number of organisms coexisting effectively together. Community means either the “we all love each other and we’re trying to bond,” thing or “we’re trying to create a community” a la 1990s: “let me hire a community manager, so I can have my customers fall in love with me,” etc. People were hiring community managers in 1996. This is not a new trend. Having a community manager is about getting your customers to save you money by solving each other’s problems. That is very different from a true community. Community is often achieved by creating boundaries with other communities. With an ecosystem, you often get a balance, where there are edges and terrain changes. But the word “ecosystem” speaks more to natural boundaries rather than to ones that are created to give a feeling of integration. http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/3/sarah_allen_interview.mp3?1293124048 Thu, 23 Dec 2010 17:07:28 +0000 no S01E02: Tammer Saleh Engine Yard S01E02: Tammer Saleh Tammer Saleh, EY’s Director of Engineering, sits down with Customer Systems Analyst Josh Hamilton for a nice long talk about test-driven development, his new book, and the secret to exuding total confidence at conferences (hint: get drunk the night before). Josh: Tell us about your role here at Engine Yard and give us an idea of what you’re currently working on. Tammer: My official title here is Director of Engineering. I’m also the general manager for the AppCloud product, which is our flagship product. I end up wearing a lot of hats here at the office. On any given day, I bounce back and forth from spending a lot of time in meetings, to hallway discussions, to managing the developers, to setting up roadmaps. I also do some development myself. Josh: How did you end up here at Engine Yard? Tammer: Honestly, <a href="http://evilmartini.com/">Randall</a> got me drunk at a bar, and the next day I had a contract in front of me. I started out of college doing systems administration work. I worked for CitySearch and I worked for the University of Illinois doing artificial intelligence stuff. I also worked at Caltech doing the earthquake protection system. That gave me a lot of systems experience and a different point of view, so when I went back to development working at <a href="http://thoughtbot.com—which">Thoughtbot</a> is a great consultancy in the Rails world—it gave me a different perspective on things. So I built up my Rails experience and my development experience working with them, and later independently as a consultant, which gave me more of a business point of view on things. Combined, all of that made me a perfect fit here at Engine Yard. Josh: Besides the time you’ve been spending here at EY doing all those tests, you recently published a new book, called <a href="http://www.informit.com/store/product.aspx?isbn=0321620283">Rails Antipatterns: Best Practice Ruby on Rails Refactoring</a>. Congratulations. How did this book come about? Tammer: Well, I was working at Thoughtbot under <a href="http://chadpytel.com/">Chad Pytel</a>, and we were at Railsconf—this must have been almost two years ago. We were watching <a href="http://obiefernandez.com/">Obie Fernandez</a> speak about the influx of developers who are not totally immersed in the Rails world, and the kinds of challenges that they were going to face. And Obie is pretty opinionated, so he was talking mostly about “rescue missions” and how much money there was to be made doing rescue missions as your sole line of work (he was totally correct, by the way). Afterward, Chad and I, we walked up to Obie and said “As a consultancy, we know exactly what you’re talking about, we see all kinds of terrible practices.” We had already been toying with the idea of making this idea into some kind of publication, and we decided we wanted to work with Obie to make that happen. He jumped on it faster than I could believe. Suddenly I had Debra Cauley, a friend to a lot of people in the Rails world, from Addison-Wesley, talking to us about what the book would look like. Chad had actually co-authored a book on Pro Active Record, so he had some experience in the publishing industry. I had no idea what I was doing. All I did know from reading blogs about it was that I wasn’t expecting to make any money. I just wanted to get the thoughts out on paper and get my name out there. So we went to work on it, and it took almost two years to get it published. We had the book shipped down to Rubyconf down in New Orleans, and that was the first time I held it in my hands. It felt amazing. I should have known how long it was going to take when I talked to Josh Susser at Pivotal, and he said, “that’s great <a href="http://tammersaleh.com">Tammer</a>, but I have lots of friends who have written their first book, and no friends who have written their second book.” And he was absolutely right. It was such a trying experience, having the constant weight of this huge project above me. Any free time that I spent I kind of felt guilty about. Once we actually had it sent to the publishers, Chad and I just felt so much relief. It was great. Josh: Is there a plan for a second book? Tammer: No. Not unless you’re about to offer me something interesting. Josh: Explain a little more about this book. What is an “AntiPattern?” Tammer: There are other books that have the same structure. Basically they describe common worst practices that you see out in the field that are just horrendous. You wonder why people make this mistake, and you realize you’ve seen it ten times, so it’s clearly systemic. The book describes these AntiPatterns in very explicit detail as well as what kind of coding mistakes are happening. It also describes solutions. The reason that I like this type of book is that during my early development career I really got a lot out of the O’Reilly recipe books, because you could focus in on one little aspect. Say you were working on Perl hashes or something like that—you could just jump straight to that chapter, to that little bit. You could immediately get some very applicable advice. We wanted to make sure that this was not a book that you had to read from beginning to end to get information out of it. You can jump to any given point, and get some really good feedback. I went through the table of contents and pulled some of my favorite AntiPatterns. One that I hate is one we call “Spaghetti SQL,” and it’s really common. You see someone who’s new to the Rails framework who doesn’t quite trust the active record stuff, the “magic” that’s in there, all the associations and validations that are in there. So they end up writing these huge chunks of SQL code that span like ten lines. Most of the time when you dissect this string and start refactoring it, you come out with maybe one line with just a couple of chained associations and that’s it—so it’s clearly a bad practice. One of my favorite phrases is “code is a liability.” The less code you can put in your project, the better off you are. There’s another AntiPattern solution that’s proving to be successful is dissecting your monolithic application into services, and how you can do that without increasing your incident of downtime. We called that the “Krakken codebase.” The names of the AntiPattern in the book are supposed to be tongue-in-cheek. Josh: You’ve done some Open Source work in the past. Can you explain to us why Open Source is important to you, or why Open Source should be important to developers? Tammer: Open source is really about passion, to me at least. I’m not so political about open source—it doesn’t really matter to me what license it’s under, or that sort of thing. Open source is really about the fact that the code is written by somebody who’s passionate about code. Otherwise, they’re just writing it for their 9-5 job, and unless you work at a place like Engine Yard that sponsors you to work on open source stuff, it’s just going to be closed source 9-5 code. Open source code is really about those developers who are spending their nights at home hacking something interesting because they’re passionate about it. And the cool thing there is that most of the time, that passionate code is going to be higher quality code, and it’s going to come out with features faster, and bug fixes faster, and it’s going to be code that you can trust. Even when I was a Systems Administrator, I would always trust open source software over closed source software, even from companies like Oracle. It’s also a matter of trust in terms of the political and business issues going on. One of the things that killed me when I was dealing with Cisco software was that they would put these arbitrary limits in place that they wouldn’t tell you about before you purchased it. Open Source gives you the power to do whatever it is you want to do, because they’re not going to put stupid limitations around you. Josh: You created the Shoulda testing framework. Last week we talked to Dr. Nic, who’s really big into CI. Could you explain to us why testing is important to you and why testing is such an important habit for new developers to cultivate? Tammer: I should say right off the bat that the Shoulda testing framework was one of my earlier pieces of code, and I still love it for what it does, but I’m almost 100% positive that there isn’t a single line of code in it written by me anymore. Thoughtbot writes some amazing code and they have been refactoring that thing left and right, so I’m sure that it’s entirely not my baby anymore—but it’s still a great tool for testing. Like most developers who came into Test-Driven Development, I was skeptical at first, because it seemed like a waste of time. But there was this moment when I suddenly just “got” it, and then I kind of freaked out about it. The things that it gives you are a simpler code base and a strong sense of confidence. You no longer have to worry about having done a three-hour coding session, knee-deep in this huge bundle of mess, and having to wonder, “Can I deploy this to production? What’s going to happen?” With TDD you’ve got this great confidence that nothing majorly bad is going to explode on you. And then, of course, there’s the whole rhythm of TDD and behavior-driven development, where you know exactly what it is that you need to do next. When I first started developing, I found myself getting to this point where I didn’t even know where to go next, I didn’t even know where to start. TDD gets you into this rhythm where you’re pumping out little widgets sometimes, and that’s a good thing. Josh: This next question is one that I’m really not sure how to ask, but everyone keeps telling me to make sure I ask it. I guess that last year you were given an honorable mention as one of the top ten sexy geeks of 2010? Tammer: Oh boy. I don’t know how people keep hearing about that (but if you want to tell your friends, please do). I was working as a consultant at the time, and one of my clients was the boyfriend of <a href="http://www.tinynibbles.com/">Violet Blue</a> (NSFW), who I’ve actually been a fan of for a long time. She does sex education stuff in San Francisco, and she’s pretty cool. But I’d never met her. She’d never seen me! I have no idea how this came about, and then all of a sudden I saw that on her blog and I thought, you’ve got to be freaking kidding me, did her boyfriend put her up to this? As it turns out, he didn’t put her up to it— he didn’t know how she saw me, either. So that was a little uncomfortable. Josh: One of the other things you’re known for is speaking at conferences. How did you get into it, and what advice do you have for new developers who might be interested in speaking at conferences in the future? Tammer: The main piece of advice I have is that you should speak on topics that other people aren’t focusing on. The first time that I spoke at any conference was at RubyConf, and I spoke about writing daemons. That was because I had a background in systems administration, and I had never really seen any documentation about how to write daemon in ruby, and the talk actually went over really well because it was something the audience hadn’t seen before, and it was highly technical. A lot of times, the more technical talk gets the better reception, I’ve found. I still get nervous when speaking, and the best piece of advice that I give people is that you should give your talk hungover. That is seriously the best way to deal with that. Not so much that you’re going to throw up—I’m not saying that you should go really whole hog, or anything like that. But the edge will be taken off at that point. So you’re not up there acting all nervous. You seem calm and collected, but really you just want to go home. Also focus on your audience, and all that crap. Josh: How do you juggle all these different projects? Any last piece of advice? Tammer: Well, I used to have more side projects, but to be honest right now I don’t have time for anything interesting. At most I’ll keep one pet project slowly going, to code on, just to have something to relax with. It’s like sitting down and reading a book. That’s how I relax—I work on something where I’m the only decision-maker. In terms of being successful in general, the most important piece of advice I can give you is that you’ll open up a lot more opportunities if you don’t focus only on being a developer. It’s fine to try and make a long-term career out of being the best developer you can be, but that’s a lot harder than having multiple skill-sets. Being business-minded can make you successful. http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/2/tammer_saleh_interview.mp3?1292603984 Fri, 17 Dec 2010 16:39:45 +0000 no S01E01: Dr. Nic Williams Engine Yard S01E01: Dr. Nic Williams Tune in to the very first broadcast of Cloud Out Loud! Engine Yard’s own Dr. Nic Williams joins us for a lively discussion of new developments in JRuby and Rubinius, the supreme importance of Continuous Integration, and why Windows users are people, too. EY: Would you talk a little bit about your role at Engine Yard? Dr. Nic: So, I have the distinguished role of VP of Technology. I am in charge of our open source program, which includes the <a href="http://rubini.us/">Rubinius</a> project, which is the re-implementation of Ruby with all new ideas and technologies on how Ruby can be implemented virtually. I’m in charge of the <a href="http://jruby.org/">JRuby</a> project which is Ruby for the JVM It is a wonderful opportunity for Java developers to be able to use Ruby, and for Ruby developers to be able to work on the JVM. We have another open source project: <a href="https://github.com/geemus/fog">Fog</a> which we sponsor full time through <a href="https://github.com/geemus">Wes Beary</a>, which allows us to provision cloud-resources—that’s storage and compute resources on Amazon, Rackspace—as well as other cloud players that come along. So, I’m responsible for all those, and I’m responsible for lots of other secret things, that I’m not sure I’m ready to talk about. EY: Okay. Despite the secrecy, is there anything you can tell us about what your day-to-day work looks like? Dr. Nic: In my day-to-day, some of the internal secret things, which I subtly alluded to, are the products themselves, AppCloud and xCloud, and the technology that goes into those products. I love writing rails apps. I make rails apps. I deploy them on AppCloud. I’ll have good experiences and I’ll have experiences that could be better. When I have the latter I go and yell at people, I say, “Could this be better, please?” I’m also working on some peripheral projects, which apply to Engine Yard and more specifically to customers: <a href="https://github.com/engineyard/engineyard-hudson">Continuous Integration</a> and <a href="http://docs.engineyard.com/appcloud/tutorials/setup-environment#windows">Rails for Windows</a>. Both of these are high priorities for Engine Yard. EY: Why are you so passionate about Continuous Integration? Dr. Nic: It is entirely unfair for a customer to be the person in charge of testing an app. It’s unfair to the customer and they’re not very good at it. They don’t give very good feedback, and what they’ll do, more often than not, is they just won’t use Your Thing, and they’ll walk off and use Someone Else’s Thing. And it’s great that in the Rails community, one of the things we learned was testing, we had a lot of education in writing tests first—in test-driven-development. And there’s been, to a lesser extent, education around continuously running those tests, so that in a team-scenario, you constantly know the complete codebase, all the tests work, and you have a high level of confidence that you are ready to deploy at any given moment. Whilst we know that we want to do this, a lot of customers don’t have a setup that allows them to do this. Specifically for AppCloud and xCloud customers, it’s highly desirable that they are running their tests in an environment that’s similar to, if not exactly the same as their AppCloud or xCloud environment. So those are some of the things we’ve been working on. There are specific technologies that we care about, but the fundamental idea is: Can we help our customers who are interested in Continuous Integration to do it, and for the ones who aren’t, twisting their arms to make them realize how important it is, so that they have a happier experience owning their application. EY: You also mentioned Rails on Windows. Dr. Nic: Yeah, it turns out there are some people out there using an operating system called Windows. And they are somewhat unloved historically by both the Rails and Ruby communities, and I don’t want to lay blame just on <a href="http://docs.engineyard.com/appcloud/tutorials/setup-environment#windows">David Heinemeier Hansson</a>, who wrote this very cute introduction to using Ruby and Rails which showed this text-editor called <a href="http://macromates.com/">TextMate</a> in 2005, and all of a sudden everyone knew that you needed to own a MAC, obviously, and it sold a lot of Macs. And I know I’m one of those, and I think most developers own a Mac. But the great, vast majority of people who are new to rails don’t know that yet. You, as a Windows developer, think, “I would like to play with this rails thing.” That’s all you know. How do you use it? How do we make that experience work, so that they don’t have to go scour the internet for little scraps and ideas? It’s little things—The Rails 3 Guide, the canonical reference for how to get started in rails, refers to the Instant Rails project as a solution for how to get started in Windows. Well, the project hasn’t been updated in three years, it bundles an old, old version of Ruby— Ruby 1.8.6— that doesn’t work with rails. We love them so little, these Windows people, that there’s no system that’s known to work, there’s no easy, go-to place. But I care about them. I care about them because there are so many of them. I care about them because I used to be one of them. I feel sorry for their experience. And here at Engine Yard, it’s time for us to turn around and help the millions of Windows users who would like to <a href="http://docs.engineyard.com/appcloud/tutorials/setup-environment#windows">start using Rails</a>. EY: What steps are you taking to make it easier for Windows users to get started with Rails? Dr.Nic: We’re restoring the <a href="http://instantrails.rubyforge.org/wiki/wiki.pl?HomePage">Instant Rails</a> project! It’s called Rails 2011. There’s a group of us forming around this problem space. We are going to package it up, and we’re going to run the first ever Rails for Windows conference. These people are new, they need a place where they can talk to each other about what life is like on Windows and help each other fix things. So it’s really a few things. It’s Instant Rails revisited, it’s Rails 2011, and it’s conferences and meet-ups. EY: Could you talk a little bit about Rubinius? Dr. Nic: different people have different ideas about what <a href="http://rubini.us/">Rubinius</a> is, based on when you first heard about it. People aren’t really expecting a lot from Rubinius. I think people were surprised that Rubinius works at all. There’s an assumption that a ruby implementation built in ruby is inherently slow. It’s actually quite the opposite—it’s self-optimizing. The way it’s been written, it can only get faster. It’s very modular. The more apps we begin to see being written on top of Rubinius the more information we can get about how to optimize those. So, the world is our oyster with Rubinius. EY: How about JRuby? Dr. Nic: One of the reasons I came to Engine Yard is do my part to ensure the success of Rubinius and <a href="http://jruby.org/">JRuby</a> as the two future languages. The thing that excites me the most about JRuby is C Extensions: the ability to load up ruby libraries that have C Extensions, into JVM, is not something that the purists would think is desirable, but it just allows so many more rails apps or ruby apps to be loaded into the JVM, without having to have Java-specific extensions. One of the great things about Ruby is the ability to write C Extensions, to be able to map Ruby down into other libraries, and to be able to use them. Because then different things can be written in C, and they can be faster, theoretically. Sometimes, if an application’s used a library that has a C Extension, you aren’t able to use that same thing in JRuby unless it was re-implemented. So in Ruby 1.6, it’s kind of allowed for a large set of C Extensions to be loaded into JRuby. They’re not necessarily going to be fast, but they will basically work, allowing you to at least experiment and play. I personally think that’s wonderfully exciting. Both Rubinius and JRuby are implementing the <a href="http://www.ruby-lang.org/en/">Ruby 1.9</a> syntax and feature-set, now that it’s stabilized, so I believe both will have high compliance with that plug-in. EY: I don’t know if everyone is aware of your thriving comedy career. One of your Twitter subscribers asks, “Did you move to San Francisco because of its proximity to Hollywood in an effort to further your comedy career? Dr. Nic: How approximate is this proximity? Hollywood is 7 hours from here, and that’s a long way to go just to do a <a href="http://drnicwilliams.com/2009/12/03/first-5-minutes-of-stand-up-comedy/">five-minute comedy bit</a>. At best I have five minutes. Now, I haven’t done any since about a year ago. It was a great, wonderful experience. It is hard. Comedy is hard. Being funny is, apparently, very difficult. EY: This Twitter-submitted question is my favorite. When lecturing, does your tee-shirt fetchingly land on top of your belt naturally? Or is that planned? Dr. Nic: I take a lot of pride in my appearance. In fact, if you look—just to show my commitment to consistent appearance—For the last three years I believe I’ve consistently worn a Twitter tee-shirt that I was given by <a href="http://al3x.net/">Alex Payne</a>. On the same day he gave it to me, I decided I should probably create a Twitter account. That was at Rubyconf 2007. I believe I’ve worn that shirt at a lot of conferences. So if anyone has a comment about the way in which my shirt does or does not position itself while caressing my body, why not talk to the people who designed the Twitter tee-shirt from 2007? Obviously it’s not crafted to my physique, and that is not my fault. I did go on a diet at the start of this year, I would hope that that would help, although since Alex left Twitter I’ve decided to retire the tee-shirt from public performances. I’m not sure if I look too good in a suit. But <a href="http://tenderlovemaking.com/">Aaron Patterson</a> presents in a suit, <a href="http://nubyonrails.com/">Geoffrey Grosenbach</a> presents in a suit. So we have a lot of people taking it to the suit level. I’m not sure if I’m ready. I’m going to have to find a clown outfit or something. Other Awesome People that Dr. Nic Mentioned Evan Phoenix (http://blog.fallingsnow.net/) Alex Payne (http://al3x.net/) Luis Lavena (http://blog.mmediasys.com/) Charles Nutter (http://blog.headius.com/) Wesley Beary (https://github.com/geemus) http://s3.amazonaws.com/engineyard.com/podcasts/mp3/mp3s/1/ey_cloud_outloud_interview_drnic.mp3?1291402947 Fri, 03 Dec 2010 19:02:27 +0000 no en-usEngine YardnonadultRuby, Open source and cloud related podcast by Engine Yard