Day two notes from RedDot Ruby Conf

reddot_ruby_conf_day_two_notes.md

#Red Dot Ruby Conf 2012

##Day 2 Summary of Reddot Ruby Conf 2012

###Due Props: Obie Fernandez - Redis on Ruby

• When to consider using Redis?
  • SQL is overkill
  • update-only data
  • non-transactional needs
  • no relations w/ other tables
• Why redis?
  • Redis is blazing fast
  • Redis can snapshot at a certain time/number of operations etc
    • snapshots can't be corrupted
  • Redis AOF (Append Only File)
  • debugging w/ redis:
    • redis-cli -p 9999 then type monitor
  • Nest (OO Keys for redis)
  • RedisProps (easy annotation of AR objects)
  • RedisObjects (maps ruby to redis-objects)
  • Testing tipes
    • Dont bother mocking it out
    • | Select a diff database number Redis.current = Redis.new(db: 13)
    • Redis.current.flushdb is your friend

===========

###Github: Zach Holman - Due Props

• Git.io url shortener
  • gitio url name
• microgems, gem in a gist
  • add a gemspec and file, then you can create a gem already
  • example: git.io/mini
• shortcuts:
  • t = file selector
  • w = branch selector
  • ? = all shortcuts

===========

###Heroku: Terence Lee - bundle install

• git gems:

  gem 'mygem',
    :git => "http://github.com/blah"
  
  gem 'mygem',
    :github => "blah"
  

• bundle outdated

• bundle show --paths (returns all gem locations in your bundle)

• self loading bundles: bundle install --standalone

  • needs ./bundle/bundler/setup.rb

• AIM: no need for bundle exec

===========

###New Context: Carl Coryell-Martin - CS, Developer, Engineer?

• professionals
  • take responsibility
  • work on interesting problems
  • make things that work
  • grow complex systems from simple systems
  • write for humans, not for machines

===========

###Fundexplorer: Sebastian Burkhard - Complex Calculations in a Web Request

• PORO: plain old ruby object(much faster than AR)
• uses Marshal class
• Use Rails.cache
• config.threadsafe!
• Don't be lazy
• avoid methd missing chains

===========

###Tutoring Australasia: Gabe Hollombe - CoffeeScript

• Less syntax means low cognitive load
• no global scope pollution
• JS type coercion
• Coffee has a switch notation(compiles to if-then in JS)
• Cofee has better checking for variable existence ? if myvar?
• null references in method chaining
• Post-fix conditionals eat sushi if()
• debugging coffee:
  • debugger keyword in coffee
  • Source Maps (coming really soon)
  • guard, guard-coffeescript gems
• browser tools
  • coffeeconsole (chroe plugin)
  • js2coffee.org

===========

###Filter Squad: Darcy Laycock - API-Driven Development

• HTTP
  • Cache-Control
  • Expires
  • ETag
  • Vary
• Efficient Validation
• Varnish + Rack-Cache
• Be consistent especially in responses
• API should be simple to learn and explore
• Public API vs Mobile Apps vs Web Apps
• Header vs URI versioning
• Building APIS
  • github/intridea/grape (REST-like API microframework)
    • Standardised Error Handling
    • Simple Resource Conversion
    • Minimal Dependencies
  • Rails::API (github/spastorino/rails-api)
    • no view layer
    • has controllers/models
    • gem install rails-api
  • rocket pants
    • built on Rails (like Rails::API)
    • URI-based versioning
    • Automatic Header Metadata (X-Api-*)
    • HTTP Link Headers
    • opinionated responses
    • smart error handling/mapping

===========

###Southgate Labs: Michael Koziarski - Contributing to Open Source

• Listen to Users
  • only those who really USE, not just trolls
• Make users the best contributors
  • solves a problem they already had
  • help your users
  • As a contributor:
    • Focus on small digestible fixes
    • Focus on minor annoyances
• Contributors are like Super Users
  • need persuading sometimes
    • When creating bug reports, use concrete examples
      • "This breaks when..", "This doesn't let me..."
      • NOT "This is more elegant...", "This breaks RC1231...""
    • Don't start with a rant and not actually say what the bug is
  • Don't take maintainers' mistakes personally
• Applying patches is really hard work
  • WHY does the change fix it?
  • Is this the right fix?
• Contributions should be a by-product
  • Don't go looking for problems to solve
  • Solve the problems that you find as you work