Git security mistakes; addressing tech debt; & writing fast code in Ruby on Rails

My TL;DR style notes from articles I read today.

Top 5 Git security mistakes

How to avoid common mistakes most of us make (or have made):

• Never hardcode sensitive data. Use a secure key management solution.
• Use .gitignore to prevent sensitive data from reaching the repository.
• Use PGP/GPP to sign your commits.
• Assign access rights to each repository & give access only to the developers who need it.
• Always patch your software. Know what systems integrate with your Git installation and patch them too.

Full post here, 5 mins read

---

How to get buy-in for addressing technical debt

• Get the first & unequivocal buy-in from engineers on the team.
• Tell other stakeholders how the business benefits by addressing tech debt.
• Try to understand the pressures on & the problems at hand for other stakeholders and develop genuine empathy.
• Show how addressing tech debt will have ripple benefits across the organization.
• Give it some other name that people care about- self-care, continuous product health, etc.

Full post here, 6 mins read

---

How to write fast code in Ruby on Rails

1. In Rails
   • Cache all the things.
   • Throttle any operation that can’t be cached. rack-attack and rack-throttle can help throttle unwanted requests. 
   • Consciously minimize dependencies. They will turn into liabilities as projects grow.
2. In Ruby
   • Use metaprogramming sparingly to prevent unnecessary slowness.
   • Think about how your code will scale with more data. Know the difference between O(n) and O(1).
   • Avoid mutating global state while leveraging mutation on the local state.
3. In Active Record (Rails’ default ORM)
   • Know when queries get executed and what causes them to get evaluated.
   • Index the columns you need to query.
   • Use select and pluck to select only what you need. By default, Active Record selects all columns in SQL with SELECT *

Full post here, 8 mins read

---

I share these TL;DR versions of articles on software engineering that I read every weekday through my newsletter - in.snippets(). Sign up here if you liked what you just read.

Comments

[Andrew Brown 🇨🇦]

⭐⭐⭐⭐⭐

Dependencies

The number one thing the hurts my ears when people say "There's a gem for that". If you haven't maintained an app for 5+ years then you may not know the pains of having too many dependencies or how things you never would think to break or would become serious obstacles down the road.

Objects

I honestly never think in Big O terms but it's easy to fix bottlenecks when you know the number of objects ActiveRecord makes. So I use raw queries and not use ActiveRecord models for reads in most cases.

[Arpit Mohan]

While I agree with some of the inefficiencies caused by ORMs like ActiveRecord, I think they have a place in this world. Most ORMs get a bad rap from people misusing them (because it's so easy to use) and not bothering to understand the underlying queries being made by the ORM.

Although, executing raw queries is great because you have a lot of control, you would lose out on syntactical sugar and ease of programming. It's a trade-off but I'd still use an ORM and try to optimize it's usage unless I need to eke out a LOT of performance from the webapp.

[Andrew Brown 🇨🇦]

True, except I wrote my own gem called monster-queries which gives you syntactical sugar and ease of programming for writing raw queries. 😉