I was fortunate enough to attend PyCon at the Oregon Convention Center in Portland earlier this year. This was my first PyCon in the US. I finally found the time to go through my notes and put them into more readable form.

Big Picture Software Testing (by @itamarst)

  • Video
  • Blog
  • Cheatsheet
  • How not to test: manual tests, 100% automated test coverage,
  • Make intended behavior easy to distinguish from emergent behavior.
  • Tests for learning vs tests for building.
  • Human tests good for: understanding users and checking for correct functionality.
  • Auto tests good for: understanding runtime behavior and preventing change.
  • MVP is a form of testing for understanding your users. Helps for learning about your users, e.g. do they exist, and what do they need?
  • Auto tests cannot prove correctness against the specification.
  • Auto tests prevent change - that can be both good and bad.
  • Don’t test implementation details: make your tests flexible.
|         |               Tests for learning                       |         |
| ------- | --------------------- | ------------------------------ | ------- |
| Human   | Understanding users   | Understanding runtime behavior | Auto    |
| testing | Correct functionality | Preventing change              | testing |
| ------- | --------------------- | ------------------------------ | ------- |
|         |               Tests for building                       |         |

Next-level Testing (by @jsaryer)

  • Video
  • Property-based testing with hypothesis.
  • jmespath
  • Convert failed hypothesis into proper unit tests.
  • Fuzz-testing: pass byte strings into your function to detect runtime errors.
  • AFL (American Fuzzy Lop) - python-afl.
  • Stress testing: test synchronization by catching thread execution order differences under load.
  • Mutation tests: good for testing your tests cosmic-ray.

Constructive Code Review (by @erikrose)

This was an awesome two-part talk. The first part focused on specific patterns and antipatterns in code reviews. The second part explored issues around human psychology in software development, and touched upon time management.

  • Video
  • Goals:
    1. Build a good product.
    2. Build people: spread competence, knowledge of the code base.
    3. Build yourself.
  • Coding is creative work. It requires enthusiasm. Don’t snuff out people’s creative spark.
  • Truth and Kindness
  • Merge quickly, don’t nitpick.
  • Tact hacks:
    • Phrase assertions as questions. Gets your point across, leaves people a way to save face, fuels discussions.
    • You vs we/this.
    • Compliments can cushion the blow if you need to give criticism.
  • Checklist for submitting patches:
    1. Provide a prose overview
    2. Give long commit messages
    3. Keep the commits small and logical
    4. Make the code easy to read (comments, docstrings, naming)
  • gitx
  • FileMerge and this gist.
  • Nitpicking
  • Praise in public, criticize in private
  • Focus on getting better as opposed to being perfect
  • Nobody should lose in code review; it’s not a game.
  • If you have to argue, do it out loud instead of in writing.
  • Feeling short on time: there will always be more work than time.
  • todoist.com

A Gentle Introduction to Deep Learning with TensorFlow (by @michelleful)

  • Video
  • TensorFlow
  • Start with the mathematic definition of logistic regression and then demonstrate how TensorFlow can do the same thing with less effort.

Snakes on a Hyperplane (by @_JessicaLundin)

  • Video
  • Aim for the simplest model that gets good accuracy.
  • Oversampling to handle unbalanced problems.
  • Keep good logs and monitor them for improving your model.
  • kaggle.com Tutorials
  • scikit-learn

Stay tuned for days 2 and 3!