Note: This post is an un-contexualized, un-edited, & un-proofed bunch of notes taken during Cascadia Ruby 2013.

Josh Adams and Robby Clements Ruby Robotics

Where to start

Sphero - $130.00

  • Bluetooth enabled ball.
  • Drives itself around.
  • Best dog toy ever.
  • Waterproof.

Parrot AR Droid - $150.00

  • Acts as its own wifi AP.
  • Connect over wifi.
  • UDP packers.
  • Stream video from 2 cameras.

Rolling your own

  • Beaglebone Black.
  • PCDuino.
  • Arduino.
  • Raspberry Pi.
  • Microncontroller is a small computer.

Pi Setup

  • Install rvm.
  • Ruby.
  • 1.9.3 works better.
  • Expect changes.

Pi Tips

  • Be caeful with the PI. Get transistors to protect it.
  • Limited hardwar PWM out.
  • At least 1amp power supply.
  • Pi Cobbler.
  • Cirago wifi $11.00.
  • Case so the PI does not short out.
  • Class 10 SD card. DD is slow on a bad card.
  • Camera module $24.00.
  • Ruby gem: Pi-Piper.
  • Ruboto project for jruby & android.
  • jRuby put the stdlib in the laod path.
  • Pulse Width Modulation.

Nick Cox We All Make Mistakes: Learning from Gaffes in the Ruby Community

We all make mistakes.

Thesis

  • Perfection is a goal.
  • Mistakes in software are inevitable.
  • Openly admit mistake.
  • Ecourage openness.
  • Learn from mistakes.

Shame spiral

When mistakes are made you can fall into a shame spiral. Definitiation: When you feel bad about something then you feel bad about feeling bad.

Software isn’t life or death.

Software ability != intelligence

Think about your own mistake

  • Does it bring you anxiety.
  • How did you handle it?
  • Did you cover it up with tech jargon so know one knew it happened.
  • Did you bring it up with someone?

Blameless Postmortems

  • What actions did they took at what time?
  • What effects did you observe during the time of crisis? (How was it handeled?)
  • Expectations they had?
  • Assumptions they made?

Encourage team communication

  • Dev days or half days.
  • Teamwide postmortems.
  • Lunch & Learn.
  • Consultancy? Write a post about it.

Conslusion

  • Mistakes are inevitable.
  • Change the conversation: Mistakes shoud teach lessons.
  • What are we doing as a culture to encourage transparency?

Nick also published a software confessional http://softwareconfessional.com/ if you wanted to make a confession about a major bug you created.

Jeremy Hinegardner Taking Ruby to the Movies

Act 1

  • Amazon Import - Shipping your HD to amazon.
  • Create Manifest.
  • Prpare your device.
  • Send a CreateJob.
  • Put extra stuff on shipping boxes. FedEx records all of those things.

Act 2

  • S3 torrent file. Add “.torrent” to any url. Only torrents smaller then 5GB in size.
  • S3 multipart

Act 3

  • Use FFmpeg.

Act 4

  • Firstboot.
  • Init script.
  • rc.local.
  • Amazon User Data. (curl any instance url).
  • :shutdown_behavior => ‘terminate’.

Starr Horne The hackers guide to usability testing

  • Design can have bugs.
  • Programmers are not your users.
  • Designes are not your users.
  • You clients may not be your users.
  • Form make them feel dumb due to terminology.

“Usability testing: you don’t need microphones and video cameras and two-way mirrors and guys in lab coats.”

  • You don’t need a lab or a team. Just sit someone infront of a computer and have a clip board ready.

Two tests:

  • What is it test?

    • Have them look at something and just ask them what it is?

  • Please do this:

    • Give someone a particular task.

Read: Steve Krug - Rocket Surgery Made Easy

Aja Hammerly (slide deck) We’re sorry but something went wrong

Debugging

Step 0: Known State

  • Not nessecarley a good state but be able to always get back to it.

Step 1: Identify A Problem

  • Write down steps.
  • Write a test.
  • Failing Integration test is usually to big debug.

Step 2: Make Hypothese

  • Avoid Conjunction.

Step 3: Test Hypothese

  • 5 minutes. You should have an understanding in 5 minutes.
  • One thing at a time.
  • Stop refactoring while debugging (Red/Green/Refactor).

Step 4: Is it fixed?

  • Use guard.

Step 5: Refactor

  • Only once it is fixed can you begin refactoring.

Step 6a: Next Failure

  • Re-run your tests and find out if it is still broken.

Tools

  • Git Bisect.
  • People.
  • Rubber ducking (Talk it out even if it is an inanimite object).
  • Labradoing (Rubber Ducking).
  • Ask for help.
  • Read the Docs.
  • Issue & Bug trackers.
  • Mailing Lists.
  • Set a time Limit. (30min)

Bug writing:

  • What I did
  • What happened
  • What I expected
  • Notes

Be nice

  • No generalizations.
  • Don’t write bugs with words: always/never/everyone. It comes off as condesending.
  • Be Objective.
  • “If it was obvious it would be there.”

Provide a patch

Just do it. People may not accept your patch but do not take it personally.

Do not Panic

  • Recognize the real problem.
  • Come to a consensus (including non-tech folk.)
  • Triage. The “loudest” problem may not be the most important.

Stop the bleeding

  • Rollback.
  • Does it stil work?
  • Feature Switch. To turn features off.

Fix the issue

  • Coordinate with your team.
  • Write a test.
  • Set expectations with everyone.
  • Be pridictable.

Reflect

  • Solo (by yourself).
  • With your team. Ask the 5 W.
  • Fact based (no blame).
  • Future focused.
  • Do not add a process. Process usually means bad communication.

Matt Kirk Sentiment Analysis

Big Data Languages

  • Java
  • Python
  • R
  • Julia
  • Clojure
Ruby is not complex math Photo by: [Sara Blackthorne](http://twitter.com/sarablackthorne)

Step 1: Collect Data

Linear regression has a curse: The curse of dimensionality

Play with it sentiment-analyzer.heroku.com

Features of Text

  • Character count.
  • Frequency of words.
  • Words.
  • Stems.
Portland Hippies make Good Donuts

Mando Escamilla Tell Us Another Story, Grandpa: Lessons Learned Over 16 Years as a Developer

“A bosses job is to protect and insulate employees.”

“Do what you like as much as you can.”

“Good employees are like gold.”

“Find a mentor.”

“Apply engineering principals to family and every day life.”

“The worst reason to do something today is because you did it yesterday.”

“Work towards your priority.”

PJ Hagerty Coding and The Mozart Effect

8-10 iq points higher when listening to Mozart over ocean sounds or similar “calming music.”

Measuring cognitive ability.

The Mozart effect: A set of research results indicating that listening to Mozart’s music may induce a short-term improvement on the performance of certain kinds of mental tasks known as “spatial-temporal reasoning;” Popularized versions of the hypothesis, which suggest that “listening to Mozart makes you smarter”, or that early childhood exposure to classical music has a beneficial effect on mental development;

Most studies used the exact same peice of Mozart. They decided to test how far away from that song and receive the same effect. They tested with Justin Bieber and found a benefeit was still present but barely. The further away you get from the sound of Mozart the smaller the effect will be. Find something that is similar and within the same genre but must be a little different. You must be finding new music. Jazz/Old Blues.

It’s all Ephemeral. If you listen to the same thing too often it will become less effective.

Ryan Davis Real craftsmen (can) create their own tools

90% software engineering is a lie.
Websites/devops is not engineering.
We write software but it is not close to engineering.

We are craftsman. We craft software.

Use the right tool for the job. Custom tools. Do not always write custom tools.

Algol-based languages are no grood. It is static & opaque, not introspective and can not reason about its own code.

Tool-Making is for the elite.

Do you write tools to help you code? Why not?

Language Tools

Flog and Flay

Flog analyzes complexity on methods.

Flay reports structually similar code. Fuzzily Similar code.

Tools need to know how to build and walk a language.