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