I have a GitHub action that uses an OAuth token to provision a new key and store it in our secrets manager as part of the workflow that provisions systems - the new systems then pull the ephemeral key to onboard themselves as they come up
It can get especially interesting when you do things like have your GitHub runners onboard themselves to Tailscale - at that point you can pretty much fully-provision isolated systems directly from GitHub Actions if you want
I just wanted to share that the latest release of Encore automatically captures a trace of every test, providing much more visibility into what's happening and making it easier to understand why a test failed.
The test traces automatically include everything you expect: API calls (including mocked calls with Encore's new mocking support!), Database queries, Pub/Sub messages, HTTP requests, etc.
And it does all of this without the user having to change or add any code outside what they would normally write for a Go test.
I agree; there are entirely different ways to achieve this same goal without generics. I mentioned using a struct and including the data from the struct in the post. However, what I wanted to show within the post is how generics can make this problem easier for us.
> As boilerplate goes, if you look at it, it isn't even that much more. Interfaces can still be used to ensure that the correct methods are guaranteed to be implemented.
Yeap, we implemented many different interfaces on our ID types, and the resource type also implements a couple of interfaces (such as methods to get the Postgres type information). Unfortunately, this means we still need to create receiver methods for each of these interfaces so we can use the ID types with those underlying libraries (such as `JSON` or the `SQL` scanners) which ends up being 14 methods per resource type (and we have quite a number of resource types). We would have ended up code generating these, and generics just saved us that work.
> Underscores are too common in identifiers.
We picked underscores, as they are not included in the base32 encoding of XID. They're also safe to put in URLs without needing to perform any encoding. Our static analysis tools during CI check that all code generation has been completed and prevent the prefixes from having underscores. That means we don't need to worry about escaping as we can always unambiguously split it. However, even if your prefixes allowed underscores, you can always just split the string at the last underscore; as the XID portion of the string cannot contain it.
I'd be interested to know how you were bitten by it in the past?
For context, like I said, your solution is good and I probably would use something like it, perhaps I even will in the future. Where my comments come from is that as I read people's comments around using Go generics now that they are here now, I'm beginning to wonder if a great deal of the mismatch between the Go community's attitudes towards them and the external community's attitudes towards them is that a lot of people bounced off of X thinking "it just can't be done", when in fact it could, perhaps just not as well, but not necessarily "not as well" as people thought, either.
I don't have 14 instances, but I do have a few places where I have 6 or 7, and they mostly ended up copy&pasted blocks, and I sweat about that a lot less than I used to because in the end the question isn't whether you end up with repeated code at scale but how. Your mileage may legitimately vary. My larger concern is more trying to figure out how to help people understand how to do things in general, because even if the technique isn't useful enough here it's still the answer to a lot of Go problems. (And, for that matter, a lot of FP problems. They use a lot of "just functions" over there.)
"I'd be interested to know how you were bitten by it in the past?"
I mean it as a general warning, because your specific case is fine.
But I've been bitten multiple times by people thinking this is a great encoding scheme to use in key/value stores where they also use underscores in the values being encoded. Bear in mind the person writing the "%s_%s" may not be the person choosing the other values being used as keys, and may have simply been using the key/value store as a magic box that stored things for years.
So if someone writes some code and the key "msg_value_by_author"... where exactly does it break down? Even as a human, stripped of context, you don't really know. The real fun is when multiple bits of the code decide "oh, it's just a string, I can parse this myself, we don't need library code" and then of course the bit of the system that sent in "msg_value" writes a workaround for their own parsing, that other bits of the system don't get.
Is it a mess? Heck yes. Should you not write that mess in the first place? Of course. Has it at times been a persistent thorn in my side anyhow? Oh yes.
As you have it written now, no, you really shouldn't have a problem, and even if you do, it'll be brief. But it's still good to know you've got code that is, shall we say, "problem adjacent" and it doesn't take much for an intern to come in, see that, and make a "small tweak" that turns out to be a long-term problem. And also, I'd like to put that idea out there for other people so they can also keep an eye on it.
If you instead consider the format string as an encoding scheme into which you must encode the two values in an unambiguous representation, and it so happens that the XIDs are always unambiguously encoded by performing the null transform on them, you're better off then thinking about them as strings that can always be separated by a random other string safely. Done correctly, this is quite safe and you can jam quite a few strings into something like a Redis key without having to worry about what they may contain.
> Always build your architecture in a way that will avoid becoming trapped into a specific service. Amazon’s AWS Lambda sitting between any services and your app is a strongly recommended path!
Isn't using AWS Lamba as your gateway, trapping you into using a specific service, just as much as firebase was?
This times and again.
If you're hitting an API hosted on a domain you don't control, you're bound to get screwed.
Otherwise they would just be able to deploy a simple Firebase API proxy (for the single call that they use) that uses TLS tickets and keep alive, change the DNS records and call it a day.
You wouldn't have clients talk to AWS Lambda directly. You'd put it behind API Gateway, which would allow you to use your own domain in front. Your clients would just know to send requests to https://myapi.mycorp.com.
Since you control the domain, you could then stop something like this more quickly.
Solution here is to make sure all api endpoints and URLs used in your code (eg into services such as lambda) get mapped through a domain that you can control / change via DNS. Then you can always cut off a service or redirect all requests to a different endpoint of your choosing (eg another serverless system or your own backend). This is better than hardcoding an unalterable endpoint / url / domain in your code that is beyond your own control, and it is doubly important if updating code on your product is difficult or impossible.
We spent a good hour or two when Chrome 56 came out trying to work out why our .eu domain didn't work but the .com did. Even though it was the same startssl cert on the same IP. Turned out our .eu wasn't popular enough to remain allowed even though it was our primary domain up until last year.
I had read the original blog post but my original understanding was that existing certificates would remain trusted and simply newer ones would not be. Hidden in the paragraph was the parts out then staring to distrust existing certificates. Very poor communication from Google
Two others in my office read the front page, but quite none of us have yet found invites (not that we've looked hard), but the idea of an invite only community sites feels counter productive
I'm interested in what you're looking at which says that. Against the dollar 2.5-3 years ago GBP was never below 1.47, since the referendum, the highest it has been is 1.34 and that was the lowest we got in the 2008/2009 crash.
Usual caveats apply: U.S. sales tax is still to be added to that £204 figure, so it's not actually £204 for an American buying it.
Adding vat to your £204 figure takes us to about £245, so even if we assume that an American does pay just £204 for it, it's only a £25 difference (~10%). It's not ideal, but it's actually not bad either --- I've seen that difference being much, much bigger in the past.
In California, you were, in theory, required to pay a "use tax" on any goods purchased from out-of state, that just happened to be equal to sales tax. The reality is that most consumers didn't do this, since the only way to get caught would be if they audited your return.
On top of that, if you maintained a commercial presence in the state you are shipping to, sales tax was required. So, any national retailer that also sells online had to charge sales tax.
Amazon was in a gray area where they had shipping warehouses, but not commercial offices in California. They ended up making some deal a couple of years ago where they would charge sales tax online. I'm not sure what Amazon got out of it though.
So you used to be able to illegally get away with buying online without sales tax in some circumstances, but it is no longer the case for Amazon.
Specifically, by default, mail order stores are not required to collect sales tax unless the have a physical presence in the state (retail store, sales office, distribution center, etc.) Quill Corp. v. North Dakota from 1992 is the major SCOTUS case law.
In theory--at least in most states with sales tax--residents are supposed to pay a use tax on out-of-state purchases bought to be used in their state of residence.
A number of states have put pressure on online retailers like Amazon to collect. One of their levers has been to argue that Amazon Associates constitute a physical presence. And Amazon has agreed to collect sales tax (although not for affiliate sales) in several states. Massachusetts for one.
Online shops aren't required to collect sales tax unless they do business in the state that they're delivering to. If a company only exists in California, then only California residents have to pay sales tax. Amazon has warehouses or offices in most states.
At that price Amazon are going to sell - oh... - five or ten. At least.
I really can't imagine who's going to buy this. There may be a mythical subset of hyper-rich hyper-readers who are bored with their existing Kindle collection and want something newer and shinier, because.
But the average reader is already happy with their average reader. This offers nothing of value to them.
At half the price there might be serious interest, but £270 is completely unrealistic.
