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)
Managing and iterating on payment models IS a pain, and startups SHOULD do it. Where I’m at, we did it a lot and it creates a lot of cruft. But: we have ultimate control to manage how we like and adapt it how we need too. We don’t need to fit it into some generic leaky (1/2)
abstraction that we cannot control or debug. #xp (2/2)
• • •
Missing some Tweet in this thread? You can try to
force a refresh
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:
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/
Another downside to this approach is you run all of your set up for each assertion and this can add up to slow tests. aggregate_failures can solve this, sorta, as it will execute each expectation and aggregate (thus the name) the results:
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/
The author's revision is better, but still isn't quite right for how i like to write and read RSpec tests:
• use the code as it would be in regular use as much as possible
• duplication to increase immediate context on a per-test basis
• Use literals for meaningful values
3/
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
Otherwise, I feel like I'm growing old waiting for the Go or Scala compiler (the FASTEST COMPILERS THEY HAVE OMG SO FAST). They are slower than running tests on a Rails app. And they don't catch everything and they produce shit error messages.
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/
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…
This post from the orange site tracks with what little insider info I have. Basically that SF wants to spin down Heroku and merge into its offering. I don't think it will work and something I consider to be a core part of the internet, like SO or Wikipedia, will be dead :(
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
mature, scalable, secure, and reliable. All without having to know how the underlying infrastructure is managed.