A side quest about RSpec's aggregate_failures. There is some (IMO bad) rspec guidance that says one assertion per test. There are many ways to achieve that, but here is one:

gist.github.com/davetron5000/a…

1/

https://twitter.com/davetron5000/status/1588204254342299654

In theory the advantage is that you can see ALL of the assertions pass or fail at once as well as descriptions of each specific assertion. But, this does not serve my second guiding principle of Rpsec:

⭐️Tests should assert all behavior intended⭐️

2/

I am a sucker for RSpec test organization and have opinions on it after using it for many years, so this post caught my eye:

blog.arkency.com/test-which-rem…

It's a quick read where the author re-organizes an rspec test do be better. 1/ The original test IS bad. It's hard to follow what is being tested and, despite the fact that it uses RSpec's API, it fails miserably at doing what RSpec tries to do:

⭐️Treat tests as examples of how the code under test should be used.⭐️

This is my north star 2/

github.com/tierrun is a way to describe your pricing model and outsource it all to Stripe. I will never understand why you would outsource the gears of collecting money to Stripe or anyone else. Payment processing, yes, but the logic around deciding who to charge what (1/2) when—I can’t think of a business where that is not a core competency that must owned. Outsourcing to Stripe in particular puts your business at extreme risk—they can and will shut you down with no recourse or notice. #xp (2/2)

The first real chapter in sustainable-rails.com talks about creating and maintaining scripts like bin/setup, bin/run, etc. We sorta did this at Stitch Fix, but I have really done this at current job and it's just so nice. Docker somehow corrupted my local DB… 1/ I nuked the image to force it to redownload. I'm running everything in Docker for local dev. Of course, now I have no local DB, just postgres running. bin/setup + 1 minute of churning and I'm 100% back where I was.

Creating a solid & reliable bin/setup is kinda tricky tho… 2/

I RARELY experience type errors in prod with Ruby outside of nil issues, which are prevalent in pretty much every popular compiled language, too. I DO get type errors in tests, but in tests are of functionality, not type-checking, so this argument has never resonated with me I think it's a fantasy that developers without a lot of experience operating apps written in dynamically typed languages tell themselves for some reason.

I will give this to statically typed languages - the "lean on the compiler" refactoring technique is awesome

Here's a better—IMO—way to think about this. It does not matter that you are or are not "refactoring", outside of perhaps when communicating with others about what the definition of 'refactoring' is.

What matters is that when changing code, do your tests still pass? 1/

https://twitter.com/tottinge/status/1501644287108427782

If you change code and your tests pass, one of these is true:

• your code still does what it is supposed to do
• you are missing test coverage

the difference here is more important than what is or is not "refactoring".

Further, if you change code and your tests fail: 2/

Dear Salesforce: thank you for setting the Heroku login timeout to 42 seconds so that if there is a problem with their API that I could work around by being logged in, I cannot work around it. Reminder that Heroku has so much untapped potential that is just being burned every day at Salesforce: naildrivin5.com/swot/heroku.ht…

I love Heroku and want them to continue existing and being awesome. So, let's SWOT Heroku!

SWOT is "Strengths", "Weaknesses", "Opportunities", and "Threats"

Here is Jared Dunn explaining what a SWOT analysis is:

Strength: Maturity of Features and Offerings.

If you think the value Heroku provides is git-based deploys, you are very, very wrong. "A web app with a database and some caching" is super common and when you run the three commands needed to set that up, you have something

I just finally released Sustainable Web Development with Ruby on Rails after a year of writing and editing. sustainable-rails.com Here are all the hot takes it contains: 1/59 Sustainability is like scalability, but harder to straw man. Sustainable development is literally development that can be sustained. Thus, your entire goal is to manage carrying costs. 2/59

I disagree that internal platforms are a bad thing. Teams often benefit from consistently using the underlying platforms (e.g. AWS, Heroku) they are using. There are a million ways to Heroku, but likely you don't want all your engineers using a different one 1/

https://twitter.com/QuinnyPig/status/1327105051815333888

Heroku cannot enforce a naming convention, a way of managing config vars, the choice of or type of add-ons to use,etc. But your team may very well want to standardize those things. e.g. you may not see a reason to have MySQL and Postgres in production, at least by default. 2/

My favorite Twitter right now is Agile Thought Leaders telling us how the vague and unsubstantiated tenets of agile are being misinterpreted by literally every practitioner and it’s somehow our fault they can’t clearly communicate. When they said “no big design up front” and we stopped doing design at all, why were they surprised? When they say to use story points and velocity and we start converting those to hours/days and measuring productivity, why are they surprised?

Can’t see the article, but these rules are all largely bullshit. If you follow only one, it’s to be on time, because being on time is one of the best life skills there is.

Let’s break these down, but first some background on me and where I’m coming from… 1/?

https://twitter.com/drbarryrubin/status/1282324871960244224

I’ve worked remote for 7+ years, at a startup that went public and expanded internationally. I was an individual contributor, line manager, program manager, an executive leader during that time, all remote. I’ve been in a lot of video calls. Here we go: 2/?

This, among others of Aaron's tweets around this one is something other engineers should pay attention to. OKRs, sprints, quarterly goals are very common and they involve pretty large tradeoffs when running a team in this way. A big tradeoff is… 1/

https://twitter.com/tenderlove/status/1182910835179454464

that you cannot accomplish anything that can't be described in this way (i.e. satisfies an OKR or can be thought of as completable in a quarter). Many engineers DO need structure like this to get things done, but not all do, leading to another tradeoff… 2/