What a trip! By day three I was struggling after traveling, meeting tons of people and listening to more lectures than I’ve been in since college. Here are the notes from the final day.
Keynote: Livable Code
Speaker: Sarah Mei
This was one of my favorite talks of the whole conference! A great perspective on programming with actionable takeaways. I ended up making it it’s own blog post here: Livable Code.
Takeaways
- Think of code as a house, keep it clean and organized but you live in it, so make sure you can live and be happy.
Putting Rails in a Corner: Understanding Database Isolation
Speaker: Emil Ong
Notes
Database commits have four isolation levels:
- Read Uncommited: no guarantees on reading data that won’t be rolled back.
- Read Committed: read may change during a transaction and will throw a “this changed” warning.
- Repeatable Read: if an update came through while reading then rolls back.
- Serializable: Transactions are completely isolated.
Translating these isolation levels to be useful in Rails:
- ActiveRecord allows setting the isolation level.
- Read the data you are updating inside a transaction so that the db can throw the changed warnings.
- Keep assumptions and transactions small.
- AR Statement Invalid error has a cause field that can be inspected.
Up and Down Again: A Migration’s Tale
Speaker: Derek Prior
Notes
Walked through how migrations work under the hood. Rails 5 introduces compatibility migrations to ensure running migrations with a new version does not produce different results. Even with compatability layer not all migrations are reversible or will create the same results. This is best effort and there can be migration rot: when migrations that previously worked are no longer runnable because they are no longer valid.
Active Record migrations use the adapter pattern to handle the differing
connections to different databases. Each conecttor knows how to translate
commands like add_column into the SQL statements the database understands.
When rolling back a migration ActiveRecord will record the steps a migration
did and reverse them, ie create_table -> drop_table
Takeaways
- Migrations that worked at the time might not be re-runnable.
- With versioned migrations Rails make migrations easier to run after an upgrade.
The Intelligence of Instinct
Speaker: Emily Freeman
Notes
Talk was based around the System 1 and System 2 thinking that is described well in the book Thinking Fast and Slow. Fear is a natural instinct that is system 1 saying “something is wrong!”. It’s up to us to listen to it. As developers we don’t face life or death fear but instincts can still be useful. Something not sitting right in code or in the system? Check it out. You might be on to something. But remember that anxiety and fear are not the same thing.
Takeaways
- Learn to listen to your instincts a little, they are honed for quick pattern recognition. Why not dig and find if they are right?
Don’t Settle for Poor Names (or for Poor Design)
Speaker: Alistair McKinnell
Notes
Strive for ubiquitous language. Ubiquitous language is used by everyone on the team from product to designers to users to developers. If people can’t write, speak and program with the same language than communication issues are going to happen.
Introduced the Simple Design Dynamo which is basically the diagram from here: A Model for Improving Names and comes from extreme programming practices. There are three stages:
- Have passing tests for code.
- See structure and improve the names.
- Abstract and remove duplication
It’s a iterative cycle that can start in any stage but naming and code improves as the process is repeated. The complete working process looks like this:
Takeaways
- Don’t settle for poor naming.
- Use ubiquitous language to prevent confusion.
- Iterate naming and code on structuring, naming, and cleaning duplication.
Tenderlove
Speaker: Aaron Patterson aka Tenderlove
Notes
What a ridiculous talk. The topics covered many git puns, Twitter musings, cat poop tracking, toilet lid left up strobe lights, and Ruby performance, memory managemnt and profiling. Tenderlove doesn’t take himself too seriously but stilled ended up giving some insight between puns and jokes.
Performance profiling is tricky. Aaron talked about when to use a sampling profiler and when to use an exact profiler. What you are trying to figure out determines the profiler to use. When it’s general performance and you need to know where time is being spent use a sampling profiler. This gives you statistical data without slowing down code. When the question is “how many” then you will need an exact profiler.
Takeaways
- Need to profile?
- When asking “how many?” use Exact Profiler
- When asking “how much?” use Sampling Profiler
- Incredibly smart people are working hard to make other developers lives easier.