Ruby on Ales notes 2016

roa2016.md

Ruby on Ales 2016

Ted's notes (@thesleepyvegan)

Ruby on Ales schedule. Notes are in order from almost all the sessions. I didn't see Choices by Ernie Miller.

Twitternets: #roa2016

Open source survival guide

Mike Moore (@blowmage) Slides

• model of mastery
• rubocop (or similar) helps resolve disputes about style easily
• the box: experiencing other people or circumstances as having more power over other people than we do
• get good at working remote
• most important point: truthful honest assessment of yourself and your abilities

Including people

André Arkin (@indirect) Code

• inclusivity is more important than diversity
• illusion of a meritocracy
• not a pipeline problem
• if your reason for diversity isn’t to include people, you will never get it. economic arguments for it teeter on exploitation
• including people is an attitude and philosophy of (social) interaction

How to include end users:

• code of conduct — great example is contributor covenant. create a safe space for people
• documentation — write docs aimed at newcomers. use she/they for your pronouns. https://jacobian.org/writing/great-documentation/ tutorials, topic guides, an API reference (useless for newcomers!), troubleshooting docs. links to docs in error messages
• accept issue reports gracefully — huge indicator of how inclusive your project is. start with the idea whatever the reporter says makes sense to that person.
• if you have a support org, be as accepting and open of bugs coming from support to engineers as they are the voice of your users * listen and speak respectfully. anyone representing your project should not harass or be condescending. enforce code of conduct on everyone regardless of how invaluable that jerk is

Including contributors:

• ask people for help in order to include them. contributors do not need to be an expert to help! maintainers especially need newcomer perspectives to understand how to help.
• as a maintainer, be open and honest about what's hard. André mentioned spending first two weeks on Bundler saying "what?! how?! why?!"
• pairing with contributors!
• write developer documentation. TOTALLY DIFFERENT from end user docs. how to get started contributing, how to run tests, criteria for accepting PRs, how to contact people, write a release guide, etc. every project should list things they welcome, eg, typo fixes welcome!
• pull requests are just issues with work done for you. if you need to reject a PR, be gracious: "thank you, i want to understand this and know how to solve your problem in a way that works for everyone"

Apply all of the contributor guidelines to team members. Give positive feedback and ask for help when you need it.

Underlyng principle: respect and empathy. Thinking about how you'd like to be treated is not enough. Think about the context those people are in and what they're struggling with.

Tech is a biased field and only the people in tech can change it!

Object Oriented Orbits: a primer on newtonian physics

Tobi Lehman (@habitmelon)

• Lots of physics, math and geometry stuff I don’t understand 😳
• Vectors, real numbers 🔢
• Distance between vectors represents points in space
• Given a model of objects in space, we can write some ruby code as below:

class Vector
  att_reader :components

  def initialize(components)
    @components = components
  end

  def +(vector)
    sums = components.zip(vecotr.components.map{||vi, wi| vi+wi })
    Vector.new(sums)
  end

  def *(scalar)
    Vector.new(components.map{|c| scalar*c})
  end

  def ==(vector)
    components == vector.components
  end

  def dot(vector)
    # some science
  end
end

class Body
  def force_from(body)
    rvec = body.position - position
    # .. more code that looked pretty straightforward -- yay readable :ruby: :smiley_cat:
  end
end

def Universe
  def evolve(dt)
    # about 10 lines of readable :ruby: with some physics math :memo:
  end
end

General physics:

• Summations? -- at least some math sigma stuff
• Newton's law of universal gravitation -- a vector from a body at position j to body at position i
• In gravity, all that matters is the total mass and the center of that mass -- not radius or shape. Even if the sun were a black hole or a singular point of mass, all planetary orbits would remain the same. It could even be a hot dog or a meatball (THANKS JONAN FOR THE MEAT THEME).
• Centripetal acceleration between bodies

UI for seeing this:

• Ruby with websockets pushing physics states to browser with window.requestAnimationFrame to render.
• Super cool animation!
• Newtonian::DimensionError that we 200+-pair programmed through!
• Highly symmetrical examples that are cool to study -- rarely occuring in nature
• Three-body example of planets juggling each other! Super cool!

Summary of physics after Newton -- moving to general relativity and quantum mechanics

Making a Test Framework from Scratch

Ryan Davis (@the_zenspider) Code

• Never compare floats for equality -- use a constant for 'close enough' and compare within that (assert_in_delta)
• Avoid leaky tests that infect results -- variables mutated within testing
• Use local variables within tests to avoid sharing state between tests
• Use classes to make writing tests easier
• When a test fails, in a naive test runner, the runner quits, so you only see the first problem that occurs; rescue and print what happened.
• Don't show the whole backtrace
• Make sure run returns self. Also, an explicit return is needed from a begin/ensure block to ensure you get the right value.
• shuffle tests for nice randomization and to ensure there aren't test ordering issues
• Done > Good.
• 70 ~LOC.
• A book about this may be forthcoming! :D
• Dr Seuss font!
• Lots of goddamn meat pictures of stuff he cooked
• Better reporting -- next feature he would implement. Abstract reporter for multiple reporters and CI integration, then plugins afterward. More assertions too.

Sharpening The Axe: Self-Teaching For Developers

Aja Hammerly (@thagomizer_rb)

Lots of dinosaurs! And kitten pictures!

Why do self-teach and how?

• The ferret point: getting bored.
• Whatever we learned is insufficient. We need to learn new things. This makes it fun!
• "Lifelong Learning" -- tech and elementary school slogan
• Learning a little bit about C so you can say "Yes I understand pointers and I still don't care" was one of the most important things in her career
• Learn the "Thinky stuff" -- programming paradigms (OO, FP, declarative, logic) and database types (relational, object, document)
• Build a scaffold from paradigms and abstract principles

How to do it!

• MOOCs (udemy, coursera, universities, etc) provide structure and lots of free help. Big MOOCs tend to have higher quality. Downsides: sometimes $$, feels like school. Read the syllabus first! Avoid being a guinea pig in a first run of a MOOC
• Set aside a time for learning.
• Study groups: in person accountability and friends. If you don't have friends this is hard. Meet every week. More details from Ryan Davis' Nerd Party 3.1 talk. People who didn't do their homework had to cook for the people in the group ("penance work"). Keep it small -- six-ish people.
• Games and puzzles: Rosalind, Project Euler, Exercism. Rosalind is bioinformtics problems and they build on each other so time for refactoring. Easy to schedule this in, satisfaction from finishing work. Similar to interview questions -- helps training for interviews! Big tech company interviews are like this Consider a local competition to encourage puzzle participation with prizes
• Books: exercises and short chapters are nice. Aja's favorite books in this picture

Giving a talk is a great way to learn a topic! Aja give a talk about Prolog at Cascadia Ruby Conf.

• Standing on a stage forces you to finish
• Provides more opportunities from demonstrated competency -- jobs, consulting, more talks
• Bad thing: deadlines and pressure. Give yourself a couple months to write it and have a plan.
• Pick a topic you are willing to learn about.
• Do NOT propose a talk you do not want to give!
• Keep your proposal and abstract simple -- 101/102 level of advanced beginner level has highest reach. Audiences want to hear 80% of material they know.

Not finishing != failure. You still learned a lot! Do not feel bad if it does not see if your work light of day

Learning things at work

• Hackathon thing at work. Inspiration time. FedEx day. Inspovation.
• Prototyping. Timebox so managers will say yes. Do not say "I want time to learn xyz." Say "I want z time to prototype solving x problem"
• Internal apps give you freedom to try new things. This helped Aja a lot in her career.
• Testing at a higher level than unit. Content generation? Integration? Load testing? Code is often throwaway.
• Own your time doing this by saying "this is why it helps me be better and more productive." Don't make excuses to your boss because the time learning is worth it.

Find an accountabilibuddy! Accept setbacks!

Baby-driven development

Allison McMillan (@allie_p) Slides

Having a kid is overwhelming like learning to code. There are many parallels:

• Googling stuff when you don't understand. Learning to skim through results.
• There is no stack overflow for being a parent
• Earned dogmatism when people feel like they are experts. For example: "Don't let your child cry it out" "Practice TDD" "Anything other than breastfeeding is terrible."
• Debugging
• Tempermental
• Pairing is encouraged

Struggles in both:

• "How do you keep doing it while learning, being a great mom, great employee and at least an adequate wife?"
• Parents struggle to keep up in an industry that values a GitHub resume, keeping up on latest developments, etc
• Such a busy schedule for parents that there isn't time to build the things you need for a new job
• Not having an impressive GitHub, side projects or code from your job you can show is hard
• Without the things above, in an interview, you have to rely on your code challenge. This takes time away from your family and is very difficult for parents.
• Single parents have it even harder
• Attending community events is very hard for parents to make the time -- and possible cost for babysitting
• The lack of sleep from parenting can make it hard to focus on code during the day
• Mothers often run into scheduling issues with hard stops/starts due to child care
• In a survey, no fathers said it had hurt their career -- only helped or neutral effect. One father said it built empathy and helped with client relationships
• In the same survey, one third of mothers said having a child hurt their career.
• Parents took significant time off work. From a survey, little concern about difficulty among senior technologists reentering the work force. This is a huge privilege we should recognize.

Hugely insufficient parental leave:

• No mandatory leave in US.
• Maternity: four weeks can be common but it's still super difficult, evne for an uneventful birth.
• Paternity: two weeks is common. This places an even larger burden on mothers.
• When making policies, think about whether you want parents back who aren't ready to be there
• Pumping can take 32-34 minutes including cleaning, travel time to room for pumping
• If there are women pumping in the bathroom, seriously consider how you prioritize women in the workforce.
• WFH and partial transition (part time) can help a lot. Partial transition makes an enormous difference. Same for schedule flexibility.

Solutions (many targeted at employers):

• Parental leave (paragraph above)
• Parenting slack channel can help and is super easy
• Parent groups at work to connect new parents with those who've taken leave and returned -- safe space for discussion
• Train managers on what to expect when new parents come back to work -- for many managers, it's the first time they've had to help. Lots of quotes about bosses being a big part of success when returning to work.
• Realistic expectations. Recognize KPIs/goals need to be revisited when parents return. New goals need to be realistic and will likely be less ambitious.
• Nice mother's room with comfy chair, fridge, power, fridge
• For new parents: get rid of parent guilt. Don't feel bad when you do something you love. Not everything can be perfect.
• Emoji for being away for pumping (🍼💪) so people know when/why you're gone
• Lightning talk about what it's like to be a new parent built empathy and helped colleagues understand
• If you need to leave your company, leave your company. If companies treat parents well, employees won't leave. All survey respondents who said companies cared about work/life balance said they wouldn't leave soon. Most who reported issues had already left the job where they had children. (Admittedly, most survey respondents were senior engineers who have more flexibility.)

Struggles are not unique. People need to face that and admit it.

Parents: high fives ✋

Advice for people who work from home:

• Separate space with a door for working
• Child care

Anyone who wants to take the survey should tweet at Allison @allie_p -- it's just five questions

How to Stop Hating Your Test Suite

Justin Searls

Why the hate?

• You write tests because you need stuff to work and trust.
• Tests get slow and become a burden. Teams become slaves to their builds and tests.
• An ounce of prevention is worth a pound of cure.
• Work Harder Comrade isn't the right approach
• Testing is always job #2. Shipping is #1. This impedence mismatch is an issue.
• Move your crappy tests to an old folder and create a new awesome tests folder

Important parts of testing:

• Structure
• Isolation - communicates concepts of what you're doing
• Feedback - are tests happy or sad, fast or slow?

Big objects: Lots of branches. Lots of depenencies. Lots of complexity

Rule of product. A method like valid(a,b,c,d) means we have abc*d number of combinations, so if it's boolean, 16 test cases.

Testing makes writing big objects harder to deal with. Stop adding on to big objects. Justin's approach: Limit every object to 1 public method and at most 3 dependencies. Lots of small objects.

How will we deal with all of these well-organized, comprehensible small things?!?! It's okay to program in easy mode.

Always use given/when/then or similar stanzas so it's easy to skim tests to see structure. rspec-given by Jim Weirich. It's been ported to minitest, jasmine, mocha and lots of places. Very easy to read and point out superfluous code. Too many givens mean too many dependencies. Too many whens mean your API could be simpler. Too many then means your code is doing too much or you're breaking the command separation idea.

Logic in tests is bad. if/when/etc have issues. Who tests the tests?

Sometimes tests that need to be DRYed up point to non-test code that also needs to be DRYed up.

Sandi Metz qquint test: How are things organized? Can I tell what's under test? Lexically are things organized in the same order as the non-test code?

Tradeoffs of a big test library like rspec vs simple test suite with your own helpers.

Naming conventions: always name the thing under test subject and the expected thing results. When there's no consistency, it makes it easier to see what parts of the code deserve more attention and are special snowflakes.

Test data should be minimal and meaningful.

Create separate tests suites for all of the different kinds of things we have in our system. Whole talk about this Justin gave, Breaking up with your Test Suite: https://www.youtube.com/watch?v=vkAfGHd7sZY

Isolation:

• What level to test? suggestion: test at highest level with real data and test at lowest level with all collaborator interactions stubbed
• Too realistic
• Outside in and mocking http://is.gd/discovery_testing
• Careless mocking can be terrible. Don't go too far because it confuses tests and makes things very hard.
• Deciding when to test within the framework and not is a hard choice

Test feedback:

• "Assertion failed" is a terrible piece of feedback. You have to read test and debug to figure it out. Use better assertions. Ideally you can figure out the problem just by looking at the test failure output.
• Slow feedback loops are difficult. Every second you spend waiting for tests or deciding what to do means you have less you can get done in that day. Non-code and distraction time multiplies when tests are slowest, so the effect compounds.
• Data setup is often the biggest obstacle. You can have different test data strategies to get better feedback.
• Test times and builds can fly off the rails easily and turn into a geometric curve. This happens a ton 📈

A Machine State of Mind

Vaidehi Joshi (@vaidehijoshi) Slides

We solve tough problems. Things are never what they seem. This is endless learning.

Application state and state with an object is awful

State machines have four parts:

1. call functions
2. reasons to call functions (events)
3. some data to keep track of these functions (states)
4. do some work before an event or state change

Even something like a simple order status field deserves a state machine as complexity is added.

How to start?

1. functions, eg, user entering credit card number
2. events, eg, submit event that updates database and finalizes an order
3. states, eg, where is the actual order in its life. encapsulates
4. validation

Great gem acts_as_state_machine -- aasm. There are others too. Statesman, state_machine and transitions. aasm has great docs.

To use acts_as_state_machine (aasm):

• Include it in your model
• Provide initial state, eg state :unplaced, initial: true
• Provide transitions event :ship { transitions from: :something to: :another }
• Lots of methods provided now, like shipped? and may_ship?
• Callbacks let you hook into these state transitions
• Guards that return a truthy value to determine if a transition can happen
• whiny_transitions for booleans instead of exceptions

Learning new things can be scary, intimidating and seem impossible.

In the name of Whiskey (machine learning)

Julia Ferraioli (@juliaferraioli)

Machine learning

Used an AI to determine if you can hug something. It worked for barbed wire!

Feature vector (x,y,z,?,?,?,?,?,?) is a descriptor for a thing in a number of dimensions. For example, take a scotch with its notes, body and lat/long and you get a matrix like [5,3,4,0,etc,lat,long] to describe a whiskey

Tensor Flow. Deferred execution. Python, C, C++ interfaces. No Ruby.

k-means clustering. k is # of clusters

Fortran. But in a Docker container so 😷 ?

Neural networks. All based on passing numbers through a series of coefficients. Hidden layer(s) make them more useful and accurate.

Gradient descent optimization

Split data into training and testing

Lessons

• Data collection is the hard part. If it's wrong, that's bad. (Scotch from Germany?)
• The whiskey example needed twice as much data to be useful

Gentle intro to ML: http://bit.ly/gentle-intro-ml

Question: A human can classify 50 whiskeys but an ML algorithm can't do it from such a small data set-- why? Humans have many years of training data.

Online algorithms train with new data all the time. This contrasts by batch data.

How many nodes in your hidden layer? Math. Lots of papers trying to answer this.

fold, paper, scissors—an exploration of origiami's cut and fold problem

Amy Wibowo (@sailorhg)

Mathematics of origami!

Fold & cut theorem: you can generate any polygonal shape from a single piece of paper just by one cut. Proven academically. Long history for this problem going back to 1700s in Japan.

Fold the paper a lot before cutting. We want to outline the whole thing along the line.

A straight skeleton is the calculation of a set of paths that looks like it could be a skeletal structure for that shape.

Super cool Amy wrote a solver UI with shoes and the ruby geometry library.

Straight skeleton isn't totally sufficient. Not all edges can be folded flat. This is a whole computational field. Helper lines can help with this! All helper lines need to be perpendicular.

Another complication: determine if folds go in or out (valley or mountain folds)

Introducing the Crystal Programming Language

Will Leinweber (@leinweber)

dad jokes++

Crystal is unabashedly Ruby-inspired. Completely compiled. Built on top of LLVM, a super great VM from Apple. Crystal is really just a front-end to LLVM.

Method dispatch is all static. No dynamic dispatch. It knows exactly what methods will be called once compiled.

Statically typed. Highly intelligent inferred typing.

Easy linking against C libraries

Fast.

Self hosted -- all of the language of Crystal is written in Crystal.

all of the classes are open to extension (eg, adding a mysize method on String)

Question marks for boolean methods (thing?) Conditionals at the end of lines (do_work if valid?) Optional parenthesis

fancier to_proc with chaining (a.map(&.upcase.reverse))

typeof keyword in language for compile-time type, .class as runtime type

automatic union types. if a method returns a string or number, type is (String | Int32). compile time inference based on method AST.

abstract classes and abstract methods like Java.

no empty arrays supported -- types required

shell out during compile time, eg, macro buildtime "{{\date`}} end` has compile time burned in

Linking to C code is super easy

PCRE for Regex

C debugging tools work great for Crystal.

misc things

• structs: immutable once allocated. highly performant
• io: all evented.
• formatter: built in to the language
• concurrency: channels and coroutines. no parallelism. concurrent code, but only on one core

crystal-lang.org/docs

Why good software goes bad

Rein Henrichs (@reinh)

Culture, Quality, Failure

Process patterns. Excellent reference How software is built by Gerald Weinberg

Oblivious pattern. We don't know that we're performing a process. Writing a thing and being done with it -- no SCM or issue tracking. Good for some things. You need to be capable of solving your own problem.

Rockstar programmers. Bad.

Variable Pattern

Routine Pattern. Force everyone to have a plan and follow it. Exceptional circumstances make this hard. The myth of the rockstar manager. Name magic -- "agile" fixes it, just by saying the word.

Steering Pattern. Depend on understanding. We choose among our routines by the results they produce. Managers often have training in these orgs. These orgs can take on harder things. For problems that are too hard for a simple process. Need control over some externalities and can reject artificial constraints and arbitrary deadlines.

Two more patterns that apparently nobody falls into! DOD study found this, based on maturity models (CMU maturity models?)

Cybernetic control

The ability to act on the system to bring actual closer to the desired

Non-linear systems. Easy things found first, then only hard things remain.

Act early, act often

Models. Make them explicit. Share them. Everyone gains understanding and becomes open to criticism and improvement then. Everyone operates with these models. Keep in mind unconscious bias is a model, too.

Feedback control systems are needed at all levels.

Thank you organizers!

• Coby Randquist (@kobier)
• Colton Fent (@fettyfent)
• Mark Turner (@amerine)
• Josh Sullivan (@jsullivandigs)
• Adrienne Sullivan (@ansokami)
• and to the MC Jonan Scheffler (@1337807)

Thanks for posting these notes Ted!