Ruby On Ales Day 2

Baby Driven Development: BDD

• Slides
• @allie_p - ongoing study and survey on dev+parenting
  • more single, non senior, adopted children

similarities

• Know how to Google (filtering, right searches)
• Earned Dogmatism (close ears to opinions beacuse think you are expert)
• Debugging (common issues, inspecting logs (haha), reintroducing single features)
• build new features
• don’t forget about happiness
• pairing is encouraged
• learning new things
• nobody really knows what they’re doing

challenges

• being good mom,developer,employee,wife
• parents struggle to keep up
• time for projects, code challenges, for new jobs
• flexible hours
• help with empathy and patience
• small percent say hurt, but say slowed or changed (actually hurt?)
• no time to waste

solutions

• parental leave
• work from home, creative working options
• support systems,
• train managers of parents
• realistic expectations
• normalize

Thoughts

• good things to think about for managers, teammembers and parents
• also some just for anyone with interesting/dependent situations

---

How to stop hating your tests

• Justin Searls @searls
• Video from RubyConf
• why the hate?
  • experimentation -> production, some tests. slow -> slaves to tests
• prevention
• structure, isolation, feedback
• structure
  • test files too big to fail
    • tests make big objects even harder to deal with
    • rule of product
    • one more argument? double the tests
  • too many small things!?
  • tests that go off script
    • can do 3 things - setup, invoke, verify, Given, When, Then (and)
    • call out 3 phases in tests
    • make tests clear
    • rspec-given
    • easy to read
    • calls out code smells
  • hard to read
    • test code is untested. shouldn’t have logic
    • rspec context vs describe
  • framework
    • balance between terse and expressive
  • accidental creativity
    • subject, result
    • consistency
    • point out unimportant stuff, important stuff
    • test data should be minimal, also minimally meaningful
• isolation
  • clear focus
    • define types of tests
    • create suites
    • separate out levels of abstraction
      • unit (mock) vs integration (dont mock)
      • clear rules for each level
    • too realistic
      • realistic are slower, take more time, more complex
      • increase focus on tested vs controlled
      • cant predict unknowns. Might be able to write targeted test after
    • redundant coverage
      • thourough, but redundant
      • how detect? coverage tools - avg hits per line
      • can combine/eliminate test layers?
      • outside-in tdd
    • careless mocking
      • thoughtful isolation
      • can treat test pain as symptom not cause
    • app frameworks
  • test feedback
    • useless error msgs
    • long runs
      • throw out tests? (at least skip)
    • false negatives
      • erode confidence in tests
      • redundant coverage
      • poor mocking
      • slow tests
      • track failures, how long to fix, use to improve suites

Thoughts

• very quick preso with lots of slides and points
• but a lot of tips and tricks, things to keep in mind to make tests better
• work on speed because less likely to skip things when it takes too long

---

a machine state of mind

• @vaidehijoshi
• Code
• dont know what you’re doing, but thats ok
• state machine
  • state, data, changes
• what looks like state machine?
  • state or status column
  • timestamps with null value
  • start_date and end_date
• directed graph
• acts as state machine
  • states
  • callbacks
  • block passed to state transition, only fires if succeed
  • guards

Thoughts

• aasm vs workflow
• with start/end how to use state machine?
• tracking state transitions

---

In the Name of Whiskey

• @juliaferraioli
• can i hug that?
  • image -> can hug?
• whiskey
  • managable, objective data
• feature vector
  • numeric values
  • matrix math
  • tensor = n dimensional array
• tensorflow
  • deferred execution
  • define compute graph
  • tensor object -> matrices , but eval
• k-means clustering
  • k = number of groupings
  • iterative to converge centers
  • choosing k important
  • initialization of centers is important
• tensorflow
  • fortran? just use docker image
• whiskey k-means
  • flavors grouping doesnt quite look like regional grouping
• neural network
  • input -> ??? -> output
  • hidden layer - guides for choosing, lots of math
  • each input to each neuron, to output
  • init each layer (again, initial state important)
  • how to optimize (each iter)
  • training, testing
  • accuracy
• lessons, goals
  • pronouncing scotch incorrectly
  • data collection is hard
  • 86 points not much
  • wrong data is still wrong
  • thinking in n-dimensions is brain-bending
  • bit.ly - k-means-scotch tensorflow-oss ff-nn learn-tensorflow gentle-intro-ml

Thoughts

• no ruby interface for tensorflow (sound familliar), but yes python
• try TF for recommendation boost, offer ‘rating’, think about what tf would mean for ocr
• maybe a talk on something fun like playing a video game via NN learning?

---

fold, paper, scisors - origami cut and fold problem

• @sailorhg - bubblesort zines
• Slides
• tech and art
• paper folding algorithms - provable
• any polygonal shape with just one cut - proved
• fold so all cuts are all aligned on the same line
• angle bisector
  • if intersect - straight skeleton
  • shrink original shape along bisectors
  • stop when shrnk to point
  • two edges merge to line as its own
  • separate into two disjoint shapes, continue algorithm
• shoes + ruby geometry
• computational folding theory
• not all sets of edges fold flat
• extend inner skeleton to edges
• how to generalize
  • must meet shape edge at 90 degrees
  • every internal vertex - wont need them all
• mountain valley foldability
  • can detect in vs out folds
• can generate too many folds
• can be used for
  • folding solar panels
  • 3d modeling?

Thoughts

• fun application of algorithm theory
• could be a fun project to turn into 3d app showing folds

---

Crystal Programming Lang

• @leinweber

• Citus Data - sharding automated

• Code
• crystal play - online browser for live workbook
• ruby inspired
• built on llvm
• fully self-hosted
• static method dispatch
• easy to link c
• classes are still open
• modules + mixins

• common idioms (?, trailing conditionals,

  =, parens, spec framework)

• tooling
• can chain things in to_procs
• union type (compiletime). methods downstream need to be defined (typewise) downstream.
• nil can be checked at compiletime
• explicit casting
• method overloading
• abstract classes, abstract methods
• touples
• Generics (parameterize types)
• macros
  • method template language, looks a lot like liquid
  • can shell out at compile time
• no orm yet…
• Linking against c code
  • since llvm, quite simple. just define interface
• regex pcre
• profiling c code - instruments on osx
• misc
  • structs (stack alloc), io (evented!), code formatter (built in), concurrency (channels + coroutines like go)
• crystal-lang.org/docs

Thoughts

• seems like lang has been around for a while and is still very young
• compare to rust
• but, way of solving type problems pretty interesting

---

when good software goes bad

• @reinh
• sotware fails alot
• culture - behavior, beliefs, values, symbols and meanings we share as a group of people
• quality - software that is valuable to someone
• failure - difference between expectation and observation
• process patterns
  1. oblivious - dont even know theres a process, not following any process. capable of solving own problem, and you are using it
  2. variable - we do whatever we feel like in the moment. poor adherence to process, depend on individuals. separates developer from user. blaming appears.
     • require great relation with customer, competant professionals, not solving a problem too big for team
     • myth - rockstar programmer - completely dependent on performance
     • only follow process when convenient
  3. routine - we follow routines (except when we dont). plan to solve all problems
     • depend on plans, managers to implement. exceptional cases are problem
     • problem cant be bigger than small team handle
     • myth - rockstar manager - repeatable, but not repeated. blindly follow process.
     • name magic - ‘agile’, ‘tdd’, ‘lean’ - imbue with powers just saying
  4. steering pattern - choose among routines by the results they produce
     • usually management training (not individual contrib)
     • processes not super well defined, but goals well defined. recover if process doesnt work
     • problem hard enough for simple routine to not work
     • some control/negotiate with externaliies. can reject arbritrary schedule/constraint
  5. (+1more?) - 85% at variable, 1% at level 3, 0 at 4 or 5
• Cybernetic Control
  • feedback to make good choices, iteratively
  • inputs - resources, requirements, randomness
  • outputs - software, outputs
  • variable - no controller between inputs and outputs - software somehow comes out
  • controller - manages requirements - needs feedback from outputs
• nonlinear system
  • inputs dont correlate to outputs
  • humans really hard at predicting
• deal with nonlinear
  • governing actions - prioritizing.
  • act early, small, often.
  • if you can’t see it, it doesnt exist - get visibility
  • if you cant understand it, you cant fix it
• models
  • Mythical Man Month - failure for lack of calendar time - make model explicit
  • make model explicit and share them
  • implicit - developers will do what i tell them. i can add people to make it go faster. bugs occur at random. the more pressure, the faster they work. I know how to identify best developers
    • characteristic of variable orgs
• feedback/control systems needed at all models
  • control nonlinear effects
• better software - spend time thinking about people

Thoughts

• great talk on process, types of process, etc.
• obvious that levels are a bit fluid