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
- Conceptual Compression: software is improving and becoming easier; advanced topics can be reduced to simpler extractions that can be learned later.s
- JIT Learning allows developers to go far without knowing everything, learn more when you need it.
- Embrace leaky abstractions to help enable just in time learning.
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
- Think hard about the audience before building and structuring your app if you will be multi-region.
- Consult lawyers.
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:
- 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?
- Standardize:
- How do we want to do things?
- How do we build consensus? Be inclusive and allow dissent
- How do we spread best practices?
- Mutlitply
- Do we have a good mix of people?
- Are we pairing people effectively?
- What can I do to level the team up?
- Be Ethical:
- What are the consequences and reprocussions of this code?
- Remember that bias, selling data and algorithms aren’t neutral.
Takeaways
- Software is changing and being commoditized and our jobs will change.
- Stay on top of the change by innovating, standardizing, multiplying and being ethical
- We are accountable for the software we create
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
- Watch: A Common Taxonomy of Bugs and How to Catch Them
- Read books: “Refactoring”, “Working Effectively with Legacy Code”, “Ruby Object Oriented Design”
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:
- Growth: As the company grew they added dependencies: both human(customers) and software.
- 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.
- 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:
- Beware of not invented here syndrome, there are a lot of great tools out there. Remember you aren’t special.
- Devalue code and overvalue your people.
- Security is important and bug bounty programs are a good start.
- Not listening to security issues isn’t a security strategy.
“Sunset” and “Acquihire” are euphemisms and hide the truth that an application is dying or being killed.
Takeaways
Post-Mortem:
- The legacy is the people the team and customers that you built and reached.
- Ditch toxic people ASAP.
- Nurture good people.
- Share ownership and allow mistakes.
- Involve yourself in the ecosystem you live in, i.e. open source, community etc.
- Accept mortality (never enough money, time, talent, etc).
- Share healthy habits and ideas.
- Focus on joy.
- Learn by doing.
- Just In Time learning is okay, learn and discover as you grow.
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.
- Maintenance Mode: big on/off lever to put your site offline if there are issues
- 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.
- 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
- Rate Limiting: Load shedding. Best implemented with a default value and have ratio modifiers on the individual level to allow graceful scaling of load.
- Stop Work: Being able to turn off non-critical work is important in error situations.
- Known Unknowns: When you want to roll something out but are unsure of the consequences, github/scientist or similar can help.
- 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
- Just because you learn a lesson once doesn’t mean you won’t repeat it.
- People are what scale technology, so scale your people.