Aaron Gunderson

Rails Conf 2018 Day 1 April 17, 2018

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.

Keynote: Fixme

Speaker: DHH

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.

Notes

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.

Embrace Leaky Abstraction

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.

Rails is Inclusive

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.

Takeaways

Continuous Deployments and Data Sovereignty: A Case Study

Speaker: Mike Calhoun

Notes

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.

Takeaways

Scaling the Software Artisan

Speaker: Coraline Ada Ehmke

Notes

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:

  1. Innovate:
    • Should we solve this with code?
    • Can we fix this with better communication?
    • Is this something we should build ourselves?
    • Should we extract this into a library?
  2. Standardize:
    • How do we want to do things?
    • How do we build consensus? Be inclusive and allow dissent
    • How do we spread best practices?
  3. Mutlitply
    • Do we have a good mix of people?
    • Are we pairing people effectively?
    • What can I do to level the team up?
  4. Be Ethical:
    • What are the consequences and reprocussions of this code?
    • Remember that bias, selling data and algorithms aren’t neutral.

Takeaways

Down The Rabbit Hole: An Adventure in Legacy Code

Speaker: Loren Crawford

Notes

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

Takeaways

The Life and Death of a Rails App

Speaker: Olivier Lacan

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.

Notes

Sucess for them came from (timing + content) * audience.

Stages of a company/software project:

  1. Growth: As the company grew they added dependencies: both human(customers) and software.
  2. Butterfly: When they started growing they got to a stage where they started to think they were special and justifying why they needed to do something different. Spoilers you aren’t different.
  3. Adulthood: They recognized that the decisions they made were not the only solution.

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.

Takeaways

Post-Mortem:

Knobs, Levers and Buttons Tools for failing gracefully

Speaker: Amy Unger

Amy is a software engineer at Heroku and talked about managing failure in the software like pilots in a cockpit.

Notes

Lots of types of knobs, levers and buttons to help manage failure.

  1. Maintenance Mode: big on/off lever to put your site offline if there are issues
  2. Read Only Mode: requires splitting writes and reads but can be useful for some applications. For example you can disable posting/comments but enable browsing.
  3. Feature Flags: Disable failing features behind a switch.
    • User: per user feature flags, less useful when tons of users.
    • Global: disable a feature for everyone
    • Group: disable a feature for groups, i.e. admins, partners, enterprise customers
  4. Rate Limiting: Load shedding. Best implemented with a default value and have ratio modifiers on the individual level to allow graceful scaling of load.
  5. Stop Work: Being able to turn off non-critical work is important in error situations.
  6. Known Unknowns: When you want to roll something out but are unsure of the consequences, github/scientist or similar can help.
  7. Circuit Breakers: Responsive shut offs and hard shutoffs can help manage failure.

Takeaways

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.

Turbo Boosting Real-world Applications

Speaker: Akira Matsuda

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.

Takeaways

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 }.value

Keynote: Rails Doesn’t Scale

Speaker: Mark Imbriaco

Clickbait talk title that was less focused on scaling code and more on scaling teams.

Notes

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.

Takeaways

Do you have thoughtful comments or corrections on "Rails Conf 2018 Day 1"? Email me. Relevant replies may be included inline.