Notes from Madison Ruby 2013. Day 0: Rapid Prototyping workshop, Days 1 and 2 were the conference itself.

madruby13-day0.markdown

Madison Ruby 2013 - Rapid Prototyping

Bermon Painter, Charlotte NC @bermonpainter

TOC - Morning

• Why's of rapid prototyping
• Using preprocessors (Slim, Sass)
• (Afternoon) Pair up and do some rapid prototyping

Typical design process

• discover -> design -> develop -> deploy
• waterfall
• wireframes (rarely useful)
  • not suited for dynamic interactions
    • open to interpretations
    • creates silos ("lob it over the fence")
• mockups (also rarely useful)
  • may or may not be possible to build
  • time-consuming
  • same drawbacks as wireframes
  • sets unrealistic aesthetic expectations for stakeholders

Better process

• (design, dev, discovery together) -> iterate, test -> deploy
• living styleguide in HTML
• rapid prototype and dev backend can proceed concurrently, then merge the two together as they proceed
• many rapid prototyping toolchains available
  • we'll be using Middleman today
    • built in Sinatra
    • Uses Sass/Compass by default

What's great about rapid prototyping?

• code reuse
• generate docs and comments and style guides
• efficiency over hand-coded samples
• working with web tools & browsers
• cross-discipline collaboration
• rapid prototyping is a good time to pair!

Creation is a shared activity.

Goal

• Create a consistent framework to use for your rapid prototypes
• Using middleman today with Sass/Compass and Slim
  • Or use HAML or Less or some other preprocessor
  • Using node.js? Check out Yeoman/jasmine/stylus

Intro to Sass

• http://github.com/bpainter/sass-workshop
  • Follow Codepen URL in the README
• Went through each chunk showing the basics of Sass

Tweak Middleman

• Create templates in ~/.middleman/NAME_OF_TEMPLATE
• http://github.com/bpainter/middleman-boilerplate
  • Good defaults, partway to Bermon's preferred setup
• http://github.com/bpainter/middleman-frankenstein
  • Berman's preferred setup.
  • Incorporates parts of Frankenstein and HTML Boilerplate
• Make your own and post to GitHub!

Frankenstein Walkthrough

• assets/stylesheets/
  • base/
    • _normalize: make consistent browser defaults
    • _emphasis, _tables, _paragraphs, etc: placeholders for different base styles
    • _variables: Single place to place variables used in other stylesheets
    • _functions: Single place to place functions used in other stylesheets
  • scaffold/
    • Layout stuff
    • "major selectors", one per page
      • _header
      • _footer
      • so on
  • modules/
    • structural styling
    • "minor selectors", reusable
    • SMACCS-style modules. One file per module.
    • _navigation
    • _badgest
    • _progress-bar
    • _tabs
    • so on
  • themes/
    • Pure decoration
• Try not to be overly specific with selectors
  • 3 levels of nested selector is a good max
  • "Why ul.class when you could instead .class?
• Use classes for state
  • .is-hidden, .is-active
  • Add and remove these states with JS, rather than applying local styles with jQuery.
  • Easier to test, can be more complex and reusable
• Include a "style guide" page that includes every piece of markup so you can quickly tweak styles and be happy with them.

madruby13-day1.markdown

Madison Ruby - Day 1

Interview With Your Application

Bryan Liles, Thunderbolt Labs, @bryanl

I don't hate it. I just don't like it at all.

I'm not a mathemetician. I'm a developer.

• We (developers) have an opportunity to create our own futures
• A lot of the problems we face aren't exact, with a single right answer

I think I'm a better developer than most people in this room. I'm NOT smarter than anyone here; I work on my craft and my tools.

• "Drunken Boxing"
  • Use your strengths to compensate for your weaknesses
• "What are you trying to do?" vs "What are you doing?" when helping somebody.
  • Refocus from how they are solving the problem and back onto exactly what problem they're trying to resolve?
• Trust that you will have the right answer.
  • Ignore anyone who says that you can't.
• Do not practice "coding"
  • Waste of time
  • "general practice" isn't useful. Focused practice is better.
  • Practice solving problems
• Optimize your dev environment
  • Alfred!
    • Workflows for things you do frequently
  • Learn your editor of choice
• Short-term vs long-term goals
  • "Short-term" meaning in the next year
  • Focusing beyond short-term probably isn't very useful
    • Things change so fast in this industry
    • Opportunities arise
• Hate that code school, rails bridge, rails girls are necessary
  • We have made a lot of progress as a society towards equality
  • We still have so much room to improve

Rethinking the View

@bryanp http://notmagic.org

• State is moving from the backend to the client
  • Tons of frameworks to do this (Backbone, Knockout, Ember, Angular, and the list goes on and on)
  • This adds complexity
• "The crux of complexity in modern web is the view"
  • It's possible to unlock this in a traditional server/client system
• View is structure (markup) combined with logic (data)
• Compilation is destructive
  • We end up with static markup
• Workarounds?
  • Force separation between logic and structure
  • Build in knowledge about what view with represent

<div data-scope="post">
  <h1 data-prop="title"></h1>
  <p data-prop="body"></p>
</div>

• Let logic act on this view
  • view.scope(:post).apply(data)
• With a small JS shim, can update the front-end view with back-end calls to .apply.
• gain
  • Simplicity
    • Understanding: data all the way down
    • Development: separating layers of development. data v. structure
    • Maintenance: Independent refactor back- or front-end
• http://pakyow.com
  • Framework that puts this into place
  • They will be working on porting the view logic to Sinatra and Rails

Yak Shaving is Best Shaving

aaron patterson @tenderlove

Following his path through fixing one bug and shaving several yaks for better performance and cleaner code.

https://speakerdeck.com/tenderlove/yak-shaving-is-best-shaving

The 15 minutes of comedy in the front aren't done justice by the slides. But the code examples are worth reading.

Schemas for the Real World

Carina C Zona @cczona

• Do not conflate CS "normalization" with sociological normalization
• Not everything can be easily categorized
  • gender dropdown
  • length of name column
• 2 kinds of schemas
  • mental
  • database
• Data doesn't need to be for analysis
  • Textarea instead of foreign key
  • You can perform analysis on non-normalized data, if you find that useful. Don't force people into narrowly defined buckets to do it.
• "People aren't edge cases."
  • Don't exclude people by saying that they are "invalid" or "Other"

Improv-e Your Organization

Jessie Shternshus

• Improv removes barriers
• What to look for in a good improv group or work team
  • understand what is good for the group as a whole
  • diversity of talent and experience
  • able to be vulnerable and try new things
  • know when to lead and when to follow
• improve your culture
  • create a non-judgemental environment
  • be self-aware and actively listen
  • think from multiple perspectives
  • blocking gets you nowhere
    • Reminds me of a rule my wife and I have. You can't just say "No." You have to have an alternative. "Let's eat at X." "I don't want to eat there today. How about Y?"

A mistake is a gift.

Closure: This Time is Well Spent

steve klabnik @steveklabnik

A personal story about _why and his magnum opus: "Closure".

• http://words.steveklabnik.com/closure
• http://words.steveklabnik.com/the-closure-companion

madruby13-day2.markdown

Madison Ruby - Day 2

Eight-Fingered Chef

Jason Garber

• Infrastrucutre Automation
  • Infrastructure as code
  • Chef!
• Chef server to orchestrate
• But Chef Solo is simpler if your needs aren't incredibly complex
  • knife-solo plugin to use knife with Chef Solo
• Helpful vagrant plugins
  • vagrant-vbguest: Keep guest software up-to-date when building servers
  • vagrant-box-snapshot: Snapshot Virtual Box VMs
• vagrant ssh-config --host HOSTNAME outputs configuration to drop into ~/.ssh/config to be able to ssh directly without vagrant ssh.
  • Biggest deal of this: interacts with knife-solo now
• knife-solo init --berkshelf . to set up a new project with a Berksfile
• Some live coding of working with Vagrant and Chef
  • spinning up a new Jenkins server
  • deploying a Rails app locally
  • Deploying this same setup to production with a couple commands

The Beautiful Myth of Psyche and Eros

Leon Gersing @rubybuddha

• You need a full breadth of emotion to experience joy
  • sorry gives depth to love
• combine love and purpose
  • one without the other is less than
  • without purpose you "have no barometer" to judge your actions
  • without love, you're just going through the motions mechanically

These rules you perceive to be made of bricks and stone aren't.

• Invent reality
• Get out of your comfort zone as soon as you begin to feel complacant

Open Sourcing Mental Illness

Ed Finkler @funkatron http://funkatron.com

An incredibly personal story of his jouney with mental illness (depression, general anxiety disorder, ADD)

https://www.youtube.com/watch?v=o-z1lY6BEZU

Rapid Game Prototyping with Rubty

Michael Fairley @michaelfairley

• Game loop

setup
while game_running?
  update
  draw
end

• gosu is an excellent library for game development
• Gosu::Window has a couple of methods you overwrite
  • #initialize to set up the game
  • #update to make whatever changes are necessary to progress the game
  • #draw to display the effects of these changes
• Provides useful methods for games
  • draw_quad to draw quadralaterals
  • inspect keyboard and mouse interaction
  • sound
  • math
• hasu presenter's wrapper around gosu
  • hot code reloading
  • exception catching
• live demo of recreating pong
• "Game Programming Patterns" is an excellent book on the subject

Office Politics for the Thin-Skinned

Justin Searls @searls

• "Politics"
  • many perceive as zero-sum
  • Simply not true
• 4 virtues
  • character traits to get started
  • not to "manipulate"

Awareness

• most imporant
• you can aomplish a lot by paying attention
• many believe that the nail that sticks out is at risk
  • simply not true
• local optimization v global optimization
  • being too "good" or disruptive threatens success by making enemies
  • help others succeed

Empathy

• powerful
• useful to be helpful
• but normalizes emotion
  • can wear you down if group is down
• devs must advocate for the user

Programmers are the last line of devense for bad ideas. We're the ones with the keyboard.

Unity

• Critical that everyone works to the same goal
• we assume (naively?) that everyone is always on the same side
• usually true
• sometimes not, though
  • not always clear why
  • pay attention to everyone's incentives

Patience

• allow bad eggs to fail
  • or else it won't change
• painful to accept failure (we want so badly to help)
  • but you reduce overall failure by letting lethal people to implode, even at great cost, so that they are eliminated