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)
- 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)
- Property-based testing with hypothesis.
- 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.
- Build a good product.
- Build people: spread competence, knowledge of the code base.
- 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:
- Provide a prose overview
- Give long commit messages
- Keep the commits small and logical
- Make the code easy to read (comments, docstrings, naming)
- FileMerge and this gist.
- 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.
A Gentle Introduction to Deep Learning with TensorFlow (by @michelleful)
- 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)
- 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
Stay tuned for days 2 and 3!