3,857 karma · joined December 16, 2012
Former Django core developer.
josh.smeaton@kraken.tech
Having http targets means you get things like rate limiting, middleware, and observability that your regular application uses, and you aren’t tied to whatever backend the task system supports.
Set up a separate scaling group and away you go.
Fun fact (and a bit of a brag, apologies), I was the contributor that added the “new” Expressions API with the intent of building a reporting platform on top of it. That platform never eventuated but I’ve still got lots of use out of those APIs.
It creates a moat around monetising the tool, not using it. I certainly see the argument around free loaders.
Their team wants it, and is offering hours to help get it done. Is this not what everyone wants from businesses using OSS?
To his credit he came straight to me and told me he got all of the items “for free”.
After a huge muck around I finally got a refund (dealing with a combination of Nintendo and Epic) but the outcome was that I could no longer use a credit card to make purchase on my account ever again.
They’ve known for a long long time that accidental purchases happen and avoided having a decent path to refund (up until somewhat recently according to TFA) so I’m glad they’re being slapped with regulations.
Instead I use mackup[0] which automatically manages symlinks to your Dropbox/Drive/Share and has support for a huge amount of software by default. You can also manually add “extra” files you wish to track if you like.
Wishing is indeed a terrible plan. Teams that treat estimates as commitments are dysfunctional. Estimates are a tool for budgeting in an agile-like world, and need to be refined as progress is made.
I’ve only seen this work in one company I’ve worked for and will carry those lessons with me.
You’re on the money about time and/or scope needing to be flexible. Estimates improve as you gather more information and complete parts of a project. Providing early feedback that relates to the original estimate is key!
“This is more complex because of X, and will likely add Y time. Do we want to proceed?”
Nothing worse than getting to the end of an original estimate and only then letting a project owner know it’s going to be twice as long.
Python 3.1 could then have introduced some of the other minor changes, perhaps behind a future import.
I had a hand in moving from 2.7 to 3.6 for a 1M LOC repo and it was not pleasant. So many backward compatible changes that that all had to be accounted for rather than being able to focus on the major breaking change of a particular version. We couldn’t have done it without six.
It seems that a bunch of changes were made all at once because it was already going to be incompatible so let’s take the opportunity to clean up as much as possible. I think that was the big mistake.
It’s fun to know what the actual difference is though. I had always just assumed that if I select credit when using a debit card the transaction would just fail “silly customer we know, you told us to check the wrong vault”.
And if they are not, then maintainers can pull, run black over the diff, and commit.
CI prevents poorly formatted code from entering main.
The actual changes between black versions of late have been minor at best. You’re making a mountain out of a molehill.
Having a tool that dictates formatting is a lot less oppressive to new developers than 100 comments nitpicking style choices.
Simon Willison has a bunch of examples of scraping sites with GHA and storing the results in a repo. But you can use the same technique without the storing part if need be.