The Ruby Rogues

Panel Steven! Ragnarok (blog/site twitter github) Avdi Grimm (twitter github blog book) Charles Max Wood (twitter github Teach Me To Code) James Edward Gray (blog twitter github) Josh Susser (twitter github blog) Discussed in this Episode Exceptional Ruby (from exceptionalruby.com or pragprog.com) Avdi wrote the book because he felt like he sucked at exceptions Avdi's Ruby on Ales talk The method method Array() Hash#fetch raise rescue warn redefining warn to raise an exception for access to the backtrace Matching an exception based on the error message Custom exception matchers Make an error module and rescues the exceptions and tag them with that module. Nested Exceptions Bundling all exceptions raised during an import or unreliable process. Avdi asked about raising multiple exceptions. The checklist for raising an exception. "Are you ready to end the program?" rescue $! nil isn't very informative Special case object - something benign that represents the actual state of things begin is probably a code smell Putting bulkheads in your code This book should be required reading for gem authors. James pointed out that the book missed Thread#abort_on_exception Avdi outlines the process for writing the book Emacs org mode LaTeX Picks IO programming language (Steven) The original wiki c2.com (Josh) tvtropes.org (Josh) How to record Skype conversations (James) Audio Hijack Pro (James) Levelator (James) Amadeus Pro (James) OOPSLA paper on mocking (Avdi) Binkies Google Maps for Android

Panel Charles Max Wood (twitter github Teach Me To Code) David Brady (blog twitter github ADDcasts) James Edward Gray (blog twitter github) Josh Susser (twitter github blog) Ryan Bates (twitter github RailsCasts) Discussed in this Episode When not to test: In a new startup trying to get funding It’s too hard to write the test It’ll take too long What is a test? Verifies code functionality Automated testing Manual tests Only run the tests you need to run. Guard Autotest Timecop Redis Testing myths: It’s too hard to test this. This is usually a design flaw. Forked processes are hard to test. Complicated User Interface stuff. It’s better/easier to fix it first. You can’t test code in Rake Tasks. Testing is hard or Writing code and tests is harder than writing code. Is this code for “Testing requires discipline?” Don’t test “One shot code.” - You’re only going to run it once, until you need to run it again. You don’t have to test migrations. TDD gives you a regression test suite and better design. Do you not test because of ROI: Routine tasks are diminished ROI in design. Duplicate code Low Risk code Testing Javascript from Rails: Jasmine Vows Jasmine Headless Webkit Zombie The clock is a global variable. Code coverage: Ryan likes to have 100% code confidence. Coverage means exercise, not correct functionality. Rails’ migration code didn’t get covered and then got crufty. Code that is difficult to test is difficult to refactor, reuse, extract, and modularize. It’s a “meta-code smell.” Picks Moleskine notebooks (David) A notebook (David) Pry (on Railscasts)(Josh) Showing appreciation for your friends (Josh) Ruby Weekly (James) RailsCasts (James) Harvest (Chuck) Netflix App (Chuck) Audible.com (Chuck) Go board game (Ryan) Foreman (Ryan)

Panelists Brian Ford (Shirai) (blog twitter github) James Edward Gray (blog twitter github) Josh Susser (twitter github blog) Charles Max Wood (twitter github Teach Me To Code) Discussed in this Episode Rubinius RubySpec Testing Test::Unit RSpec Cucumber Levels or Ruby Language Implementation Community/Culture Ecosystem Assignment to something that could be a local variable or a setter method Having more than one way to do things map vs collect and vs && aliases alias method chain copy on alias when you alias a method, then alias its aliases for consistency in some cases ruby is white space sensitive ruby’s complex grammar documentation How much documentation do we need if we can open the source of our projects? speed Generally takes an architecture change to get better. the Ruby Application Archive (RAA) narray rbtree Picks standup meetings post (Josh) officeplayground.com (Josh) www.thinkgeek.com/geektoys (Josh) Rails 3.0 (James) Snow Leopard (James) Actors Blog Post (Brian) Mirrors Post (Brian) Netflix for iPad (Chuck) Skype (Chuck)

Panel Avdi Grimm (twitter github blog book) Charles Max Wood (twitter github Teach Me To Code) David Brady (blog twitter github ADDcasts) James Edward Gray (blog twitter github) Josh Susser (twitter github blog) Discussed in this Episode How do you score developers? Salary When you run out of ideas How wide is the angle of your re-approach Debugging does not stop when you run out of answers, it stops when you run out of questions Josh brought up this article. A few points brought up regarding getting better were: Practice Measuring achievements Learn the Fundamentals Start a hard project Practice builds skills and habits Habit vs instinct Dunning Kruger effect Non-code related qualities that make you a better coder: Empathy Communication Skills Panel suggestions for being better James: Become a better communicator Learn from other fields (brain physiology as an example) Avdi: Practice Read Code Complete The Pragmatic Programmer Work with other people and read their code David: Never stop playing Never stop learning Never stop failing Never stop until you succeed Josh: Pair program Care about something Tackle hard problems Chuck: Be confident in your skills Tackle hard problems Get to know advanced programmers Problems you can tackle: Language Interpreter Picks Pragmatic Programmers (James) Avdi Grimm in every form (James) Exceptional Ruby (James) James’ blog (Avdi) jasmine-jquery (Avdi) sinon.js (Avdi) jasmine-sinon (Avdi) Travis CI (Josh) Yoga (Josh) Standing Desk (David) Extreme Programming Explained (David) Business Model Generation (David) Ruby Quiz (Chuck) Project Euler (Chuck) ActiveModel (Chuck)

Book Club: Exceptional Ruby by Avdi Grimm

This episode was recorded live at Lone Star Ruby Conference by Opus Video Productions Show notes are on their way.

Panel Avdi Grimm (twitter github blog book) Charles Max Wood (twitter github Teach Me To Code) David Brady (blog twitter github ADDcasts) James Edward Gray (blog twitter github) Josh Susser (twitter github blog)   Discussed in this podcast: Definition of Queuing and Background Processes: Queuing is about messaging. Typically first in first out (FIFO) Background Processes are processes that pull messages off the queue and do things later. Systems that people have used Beanstalk Resque cron RabbitMQ bunny ZeroMQ BackgroundRB AMQP Delayed Job Queue Classic   Poor man’s queue or database backed queue What do you look for in your queue technology? How it takes failure Introspection It depends on what you’re doing Regular tasks vs. Immediate tasks One worker vs several workers on several servers Dave’s beanstalk utilities Beanstalk RailsCast Hybrid approaches Google’s Geocoding API - Rate-limiting with cron Amazon’s FPS - polling amazon to get updates on payments Best Practices Structure jobs so they are simple input/output Isolate your jobs as much as possible from the database Decouple your application from your queue - Message Passing Distributed == Not Dependent - If the job dies and you are broken, you’re designed wrong Idempotence on the job Messaging Queue == State Machine Logging/Emailing when something is unprocessed for too long What do you send to the background? Payment Processing Emails PDF Generation Billing reconciliation Geocoding External Web Services Collate events into an aggregate event Farming out multiple jobs to multiple queues Separate unusual resources onto other servers Picks Service-Oriented Design with Ruby and Rails (Addison-Wesley Professional Ruby Series) (Dave) Enchantment: The Art of Changing Hearts, Minds, and Actions (Dave) If you gaze into nil, nil gazes also into you (Avdi) hacker monthly (Avdi) rubythere.com (Josh) code for america (Josh) Philosophy Gym (James) Philosophy Bites (James) Ask a Ninja (Chuck) Ruby 1.9 (Chuck) RVM (Chuck)

Panel: Aaron Patterson (twitter github blog) Charles Max Wood (twitter github Teach Me To Code Rails Summer Camp) James Edward Gray II (blog twitter github) Josh Susser (twitter github blog) Discussed in this episode: Deliberate technical debt - deferring development to when you can later afford the time Inadvertent technical debt - adding technical debt without realizing it or because libraries/frameworks go out of date. When would you deliberately accrue technical debt? Time crunches Everything pretty much devolves down to time Deferring for lack of expertise Shorten time to market by trading time. Lean Startup What’s the right solution? Fix your code? or rewrite your code? Quantify the cost of your technical debt - Josh gave an example. Sources of Technical Debt: Upgrade costs Test coverage Application features Non-core features Compatibility costs Coupled code Dependencies Early adoption Solutions: Versioning Upgrading Do the work Bypassing the problem - Solving it a different way How do you know you’re adding technical debt? When you start to feel the pain. When you make the initial payment. Technical debt is a deficiency in your code or process. It’s costing you time. Counter-examples: Code you don’t need to maintain Code you can avoid without incurring immediate or eventual cost How do you avoid technical debt? Good abstractions Good refactoring Refactoring (by Martin Fowler) Declaring Bankruptcy - Folding up the project? Restarting/rewriting? Picks Working Effectively with Legacy Code by Michael Feathers (Aaron) SGU - Skeptic’s Guide to the Universe Podcast (James) SGU - Stargate Universe (amazon.com) (James) Coda Hale - Metrics, Metrics, everywhere (video) (Josh) Wunderlist (Chuck)

Panelists Avdi Grimm (twitter github blog book) Charles Max Wood (twitter github Teach Me To Code) David Brady (blog twitter github ADDcasts) Gregory Brown (blog twitter github Ruby Mendicant University) James Edward Gray (blog twitter github) Discussed in this episode What is metaprogramming AST Ripper method_missing send super defined?(super) alias method chain rdoc rspec Guidelines Aliasing/Redifining methods (generally wrong) Dynamic Module generation (Generally right) understand Ruby’s method call lookup understand modules (extend and include) Calling super is usually a good idea If you’re going to monkey patch, make sure that the method isn’t already there Make your changes easy to find class_eval def vs define_method Convenience constructors - In a medium sized project, you should not do this more than 3 times. Picks vagrant (Avdi) Best of Ruby Quiz (Avdi) anti-pick: TeamViewer (David) Let Dave know if you have a great tool for sharing screens and collaborating over the web. gnu screen (Greg) irssi (Greg) square foot gardening(Greg) find/be a mentor (James) George R. R. Martin's A Song of Ice and Fire (James) #rmu channel on freenode for mentoring (Greg/James) Rails 3.1 hackfest (Josh) escapepod.org (Josh) Cassandra: The Definitive Guide jQuery-UI

Panelists Charles Max Wood (twitter github Teach Me To Code Rails Summer Camp) James Edward Gray II (blog twitter github) Josh Susser (twitter github blog) Dr. Nic Williams (twitter github blog EngineYard) Peter Cooper (site twitter github The Ruby Show Ruby Inside) Items discussed in this episode Ruby distributions Why haven’t companies sponsored core Ruby AT&T Interactive sponsoring Aaron Patterson’s work on Ruby & Rails Engine Yard sponsors or sponsored Rubinius & JRuby & Rails Company Benefits Expertise of OSS developers Attracting awesome employees Developer Benefits Work on their passions Higher level of engagement Possible Problems Community can become dependent on corporate support Can damage reputation Can cause problems moving forward Heroku hiring Matz SQLite has several Sponsors SQLite forces all code into the public domain Corporate fork (Twitter forking Ruby Enterprise Edition) Ruby Enterprise Edition forked from Ruby by Phusion Matz Interview on Heroku Better process Corporate vs Community Kerfuffles What should Ruby do with its new resources? Web based VM performance features? Ruby-spec Picks Cassandra (Chuck) Stargate SG1 (netflix)(Chuck) Anti-pick TK (Peter) The Ruby Programming Language (Peter) Code Brawl (Peter) Ruby Patches by Michael Edgar (Peter) HATEOAS (Josh) Steve Klabnik’s write up on HATEOAS (Josh) Blendtec blender (Josh) iterm2 (James) Netflix (James) Star Trek: The Next Generation (netflix) (James) PostgreSQL (Nic) In Plain Sight (netflix) (Nic) .rvmrc (Nic) Living in America (Nic)

Panelists Avdi Grimm (twitter github blog book) Charles Max Wood (twitter github Teach Me To Code) David Brady (blog twitter github ADDcasts) James Edward Gray (blog twitter github) Josh Susser (twitter github blog) Topics Discussed in this Episode Premature optimization is the root of all evil. Choosing the right tool. Be top-down (premature implementation). Don’t do big upfront design. Why are you doing this? Who is going to use it and why do they want it? How high up is the “top”? James starts with the URL. Be open to design rules not applying. Be open to being wrong. “Simple things should be simple, complex things should be possible.” ~Alan Kay Implement the functions that natural come out of the function you’re building. Simplicity is Complicated - Avdi’s blog post YAGNI - You aren’t going to need it. “There is no rules.” ~James There is always a tradeoff. Use the appropriate amount of paranoia for a particular problem. ~James “Just because you’re paranoid doesn’t mean someone isn’t trying to kill you” ~Woody Allen “It’s more important to know how to get the cows back into the barn than knowing how to keep the cows in the barn.” ~David “If you don’t have a mediation plan for something, don’t bother checking.” “Listen to your tests.” ~Avdi Picks Smalltalk Best Practice Patterns by Kent Beck (David) Practices of an Agile Developer (Avdi) Restful Web Services (Josh) Dissertation on REST by Roy Fielding (Josh) Cisco-Linksys E4200 (James) Pivotal Tracker (Chuck) Jelly (Chuck) The Pragmatic Programmer (Chuck)

Panelists Avdi Grimm (twitter github blog book) Charles Max Wood (twitter github Teach Me To Code Rails Summer Camp) James Edward Gray II (blog twitter github) Josh Susser (twitter github blog) Peter Cooper (site twitter github The Ruby Show Ruby Inside) David Brady (blog twitter github ADDcasts) Mentioned in this Episode Ruby-Chan Why Beautiful Code? You know your code is written correctly by looking at it. Knots metaphor - If it’s shaped right, you know it’ll hold. The shape in your mind matches the shape on the page Evaluating code: Eric Hodel - Audio evaluator of code rubygems-sing Reveals the intention to someone Practices: 80 character limit 1 statement per line Comments are code smells Red-green-refactor Engage more senses-use more parts of the brain Short functions/methods Morph the language into the language of the problem domain (DSL’s) Dave’s post on Dishonest code Picks Laser (Peter) Laser Thesis (Peter) Minitest (Dave) Minitest/spec (Dave) Simplecov (Dave) hasmanythrough.com (James) virtuouscode.com (James) The Psychopath Test (James) Dropbox (Chuck) metric_fu (Chuck) metrical (Dave) fixture_builder (Josh) cast of characters pattern (Josh) vivo barefoot shoes (Josh) guard (Avdi) Object-Oriented Programming: An Objective Sense of Style (Avdi)

Panelists Aaron Patterson (twitter github blog) Charles Max Wood (twitter github Teach Me To Code Rails Summer Camp) James Edward Gray II (blog twitter github) Peter Cooper (site twitter github The Ruby Show Ruby Inside) David Brady (blog twitter github ADDcasts) Mentioned in this Podcast Reading: http://blog.stevecoast.com/what-the-hell-is-happening-to-rails http://yehudakatz.com/2011/06/14/what-the-hell-is-happening-to-rails/ Thoughts on Rails 3.x: Resource routing changed - Good and Bad Performance problems - Explained Code is more accessible - Reading the source is easier Rails Wishlist: Background processing Better multi-database support Fixture loaded database caching The long fixtures tangent: Fixtures Foxy Fixtures Factories Considerations for Rails’ Future Mobile Web Javascript front end Persistent sockets/connections realtime rails API versioning Panel Picks Amazon Prime (Aaron) libsyn.com (Chuck) iMic (Chuck) Roland R-05 (I have the Edirol R-09HR) (Chuck) Resounder (Chuck) Behringer XENYX 802 Mixer Mixer (Chuck) first world medicine (Dave) amoxycillin (Dave) Acorn (James) Graphic Converter (James) Coffeescript (Peter) Foreman (Peter) James has spent about $40 of Chuck’s money so far.

Panelists Charles Max Wood (twitter github Teach Me To Code) Peter Cooper (site twitter github The Ruby Show Ruby Inside) James Edward Gray II (blog twitter github) Gregory Brown (blog twitter github Ruby Mendicant University) Mike Moore (blog twitter github Rubiverse Podcast) Items discussed in today's episode Debuggers and Tools Ruby Debug pry Ruby in Steel other IDE's Formatting Debug Output YAML's y method Object#inspect awesome_print Outputting debug information puts p raise pp Other debugging tricks abort_on_exception = true The Ruby executable's -d switch and the $DEBUG constant Using a logger to output data from a specific piece of code The debug method in Rails helpers and views Using Object#freeze on to find what is modifying the object Passing a dummy object that uses method_missing to output method calls and arguments Do not debug alone Spike the debugging, git stash the changes, write the test, unstash the changes and verify the result Panel Picks Gaming side events at conferences Lost Cities Board Game (Affiliate Link) Jambo (Affiliate Link) Pandemic (Affiliate Link) Agricola (Affiliate Link) Race For The Galaxy (Affiliate Link) Ticket To Ride (Affiliate Link) The Settlers of Catan (Affiliate Link) Scrabble Crossword Game (Affiliate Link) awesome_print rails footnotes go The Go Programming Language, or: Why all C-like languages except one suck. Mobile Magic (Disneyland Android App) Elantris (Affiliate Link) iPad Kindle App Couch to 5k Rubyflow.com open_gem

This week the rogues discuss the importance of conferences and user groups to the Ruby community. Panelists David Brady (blog twitter github ADDcasts) Peter Cooper (site twitter github The Ruby Show Ruby Inside) James Edward Gray II (blog twitter github) Marty Haught (site twitter github) Mike Moore (blog twitter github Rubiverse Podcast) Items discussed in today's episode User Groups: OK.rb Boulder Ruby Utah Ruby User Group (URUG) Conferences: Red Dirt RubyConf mountain.rb Rocky Mountain Ruby MountainWest RubyConf (MWRC) Ruby Web Conference Should speakers pay admission? PyCon: Everybody Pays Conference organizing and speakers What makes a great conference? Try something different Melted brains Single track Social interaction Dual tracks Managing repeated talks Panel Picks Ruby There Ruby speedup patches Pharo Pharo by example Ruby on Rails HighLine Lanyrd padrino