Welcome

I’m a (mostly) Python developer and DevOps engineer, though I’ve also got frontend development and full stack on my record.

I write about thoughts and challenges I deem worth sharing. In my free time I’m currently focused on my N-th attempt to learn guitar.

In order to contact me, mail me at contact@<domain name from the address bar>. Alternatively, base64 -d <<<"Y29udGFjdEBrYXJvbGluZXBhdWxzLmNvbQo=".

Table of contents

• Let’s get exceptions right
  • Know your error boundaries
  • Error handling strategies are domain-specific
  • except Exception is not a good coping strategy for dealing with uncertainty
  • Distinguish between error- and non-error exceptions
  • One exceptional condition, one exception type
  • Exception hierarchies are fine
  • Be super careful when catching commonly raised exceptions
  • Don’t reuse exceptions that belong to other projects
  • Documenting exceptions
• Why your team will procrastinate reviewing your PR
  • Because we don’t know where to start
  • Because you copy-pasted the same 150 lines of test code 4 times
  • Because it combines refactoring with functionality changes
  • Because the code is obscure for no reason
  • Because the implementation is a show-off
  • Because it’s just too big
  • Because we are tired and you will be defensive
• dbrewind - am I onto something?
  • Design
  • Usage
  • Limitations
  • Failed approaches
  • Talk is cheap. Show me the code
• Python 3 porting - pickles
  • The debatability of text-friendliness
  • Unicode-bytes confusion bites for the last time
  • A word of consolation
  • Conclusion
• My Pdb++ config and extensions
  • My Pdb++ config - annotated
  • An anecdote
• Set up your test database from migrations
  • What do we mean by create_all?
  • What’s the problem with create_all?
  • Suffer early, suffer less
  • Problems remaining unsolved
  • When is it OK to use create_all?
  • Conclusion

All content of this website is licenced under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International licence.