Skip to content

Instantly share code, notes, and snippets.

@corroded
Created May 19, 2012 19:57
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save corroded/2732227 to your computer and use it in GitHub Desktop.
Save corroded/2732227 to your computer and use it in GitHub Desktop.
Day two notes from RedDot Ruby Conf

#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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment