2018-04-17
I visited Rails Conf and Pittsburgh this week and I wanted to post my notes from the talks I went to. Here are the notes and takeaways from day one.
We wouldn't have Rails without the focus and work of DHH and this talk was a great start to the conference. The talk focused on learning and making Rails easy and accessible to everyone through conceptual compression.
Technology is constantly changing but at the same time it is staying the same. Some technologies change but others change the same. Rails attempts to reduce the mindspace needed develop for the web.. DHH gave the example of ActiveRecord allowing people to build websites without needing to understand SQL. This lowers the barrier to entry. We no longer need a DBA's specialized knowledge and can just use the developers. We can now get a lot more done without worrying about details that our predecessors had to. All of this is enabled by conceptual compression, taking complicated problems, solving them and then abstracted them so day to day development doe not rely on the specialized knowledge.
Rails has tons of leaky abstractions, and DHH is proud of this. It's an important tool for getting basic functionality out. Day one doesn't have a perfect solution but you can help manage away some complexity. Where complexity leaks through users can dive deeper when they need. Defined this as JIT(Just in Time) learning.
The internet has been colonized by large companies. Rails attempts to keep the bar of entry low to encourage growth and new opportunities. Low barriers to entry and more businesses is benificial for everyone.
Different countries have different data laws. Working in a place like Australia means users Private Identifying Information can not leave the country. This complicates the deployment and development structure. Originally they tried doing separate branches per region it wasn't practical. Ended up just doing completely separate deployments per region, with little interoperability.
If cross region support is required One solution is to have separate regional deployments and then a service that has a (region_id, user_id) pair but none of the identifying information.
Coraline argued developers are software artisans not software engineers. Creating custom solutions is being commoditized away. More and more software is generic and composed of smaller open source or closed source subsystems, this is like manufacturing standardizing on parts. "The job of the future is not your job today" As a software artisans career progresses it's less about the code, instead you are asking four questions:
Legacy code: system of working software written by many.
When deciding whether to change or not change, if no one is reading it then don't change it.
"The hurrior I go, the more behinder I get" ~ Lewis Carrol
Most of the material covered in this talk I already summarized here: Working Effectively with Legacy Code
Olivier Lacan worked at Code School and he walked through the stages of birth through death of their startup and team. I really enjoyed this talk.
Sucess for them came from (timing + content) * audience.
Stages of a company/software project:
Faced team instability and lack of ownership. Making diverse hire's helped with to counteract this and other problems. Introduced the concept of immunity for new team members, with permission to question and criticize decisions. I think this immunity should be indefinite.
You need to distrust the process. What is right for the company changes and process makes things comfortable but not necessarily efficient. Continue to question choices.
Some warnings:
"Sunset" and "Acquihire" are euphemisms and hide the truth that an application is dying or being killed.
Post-Mortem:
Amy is a software engineer at Heroku and talked about managing failure in the software like pilots in a cockpit.
Lots of types of knobs, levers and buttons to help manage failure.
There are a lot of different ways to manage failure to use depending on requirements. Using ratios for load shedding was something I had never considered and sounds valuable and easy.
This talk was a dive into some slow parts of Rails and hacks to make things faster. Most of this was around adding parallelization to database queries and view rendering.
There are some ways to parallize sending database queries to speed up responses but you have to be careful of database connections. The futures pattern is easy to use in Ruby and can enable async work
Thread.new { do_something }.valueClickbait talk title that was less focused on scaling code and more on scaling teams.
The social side of scaling an application isn't as interesting as scaling the team. If you can scale a team effectively than they can scale your application. Hero culture doesn't scale; teaching scales as you add people. So scale up your team with good teaching practices.