It sounds like they’re trying to emulate Disney/Universal to some extent. I can imagine them having themed restaurants, gift shops, etc. similar to what you see in theme parks.
Technically that’s always been the case. It’s just that now you can tell the computer what to do in a “natural language” like English instead of a “programming language”.
We have reached a point where the computer no longer does exactly that we tell it to do :P I always though of computers being stupid, but very fast. With AI they are slow, and make human errors :P
It is true that this is somewhat influenced by how Heroku works, but ConfigMaps and GitOps do not meet the same security and usability requirements as Heroku config/env vars.
If you want secure config storage on Kubernetes, you end up using Secrets, which ends up being key-value like env vars anyway. If you want similar security with Git you need a layer of encryption, which breaks diffs and requires additional tooling. This all leads back to why high-level deployment tools like Heroku were created.
> If you want secure config storage on Kubernetes, you end up using Secrets, which ends up being key-value like env vars anyway.
You can load the secret file directly into the app, no need to load it as env vars or keep it strictly as key-value pairs.
> If you want similar security with Git you need a layer of encryption, which breaks diffs and requires additional tooling. This all leads back to why high-level deployment tools like Heroku were created.
You can use tools like ejson[1] or sops[2] to get encrypted files checked into Git that have key level granularity on diffs.
There is definitely a place for higher level abstractions than Kubernetes. Mostly it gives operators a standard platform to build from when teams outgrow the PaaS sandbox.
> You can load the secret file directly into the app
Now you're getting away from the spirit of 12factor and hard-coupling them again. The intent is for the app to consume the secrets but have no knowledge or care where they came from.
Edit: misread as "load the secrets directly into the app." Yeah, this is just env vars but different.
My trick for this with k8s Secrets, when there's some sort of config file that absolutely must be consumed from disk, is to
1. create a Secret that defines the file as a key
2. mount that Secret into the container (.secret.secretName in the volume definition) under an arbitrary conventional path, e.g. /secrets
3. define an env-var that gives the full path to the file; where the fallback when this env-var isn't defined is to find the file in the working directory with a conventional filename.
If your own code uses the file, it can read the path from this env-var; while if the core of your container is some opaque tool that doesn't know about the env-var but does take the file's path on the command-line, then you can wrap the tool in an entrypoint script that reads the env-var and passes it as a command-line arg to the tool.
IMHO, this approach is flexible but principle-of-least-surprise obeying for both development and production deployment.
A .env file allows you to go from knowing/assuming where a particular file is, to having environment variables.
What I'm describing is that you can go from being passed environment variables directly, to knowing where certain files are; which therefore allows those files to be mounted into a container-image in arbitrary places, rather than encoding brittle assumptions about config-file locations into the binary within the container-image — assumptions that usually get in the way during development, when you're not running the binary inside a container.
You still didn't understand my point. The thing that I'm talking about is using env-vars to point at config files that do not themselves contain env-vars, but rather are opaque app-specific config files, in formats like YAML or whatever-else.
I don't use kubernates. We have JVM servers running on AWS. We load secrets from Secrets Manager. Configs are mostly HOCON files stored in S3. The knowledge of where to find them is configured via env vars.
We use a custom setup in which the config values are loaded from multiple sources actually, so we could put everything into secrets manager, or load them all from env vars or HOCON files.
If we had to set every config value in ECS / lambda using env vars, it would be a major pain in the ass, and error prone.
Not OP but an IAM role with scoped access to secrets. Better again, using secretsFrom in the task definition which injects the secret as an environment variable for you.
> Now you're getting away from the spirit of 12factor
The entire point here is that 12-factor isn't the be-all, end-all, so this is irrelevant.
> The intent is for the app to consume the secrets but have no knowledge or care where they came from.
This doesn't really make sense, and is an impossible requirement. The app will always have to know where configuration or secrets come from. Environment variables is just one option of "knowing where they come from". Choosing file storage is just as valid.
The Twelve-Factor App is marketing content produced by the former Founder & CTO of Heroku. It's a great piece of content no doubt, but it should be viewed with that lens.
If it's marketing content then it's not doing a very good job. I have known about the 12factor app principles for a long time, and only found out today that it has ties to Heroku.
ExternalSecrets with K8s. Put them into SOPS, Vault, your cloud’s secrets handler etc. - then reference them in the app as though they exist. They get loaded at deployment.
I wonder why there hasn’t been more effort behind replacing single use plastics for food/beverages. People get all up in arms about plastic straws, but then stick their paper straw in a big plastic single-use cup.
I also find it sad that some companies like Snapple are regressing, changing from glass to plastic bottles.
Seems ironic that you’d use rust to “build fast”. My impression is that Rust is more about building things safe/correct and efficient, with developer productivity being lower relative to other modern languages.
That said, the “infrastructure-from-code” idea is interesting. I’m not a big fan of coupling your code to your infra, but I’m intrigued by the idea of inferring infra dependencies from existing application code.
> Seems ironic that you’d use rust to “build fast”. My impression is that Rust is more about building things safe/correct and efficient, with developer productivity being lower relative to other modern languages.
I have to admit that I have limited experience working deeply with Rust, but I've found thus far that my relative productivity is inversely proportional to the size of the project. That is, for large projects, Rust is much more productive than other languages. For small ones, less productive.
You got that right. What Shuttle is trying to do, among other things, is to extract the difficulties of getting started, especially in a language like Rust, so that you can focus on writing good code and moving fast (when moving fast is a requirement).
I’ve actually run into this more with debit/cash accounts than with credit cards. I’ve had checking accounts frozen, but I’ve never had a credit card entirely suspended for “unusual activity”. At worst they’ve declined individual charges until I called, or I just switched to a different card, since it’s easy to have many redundant credit cards.
For travel, etc. it's absolutely a good idea to have multiple redundant cards (that aren't issued by the same bank). I haven't had issues for years, but I have had issues in the past and it's a lot easier to just pull out a different card than deal with international calls trying to get a problem resolved on the spot.
I have CCs suspended all the time, requiring verification (often steam purchases..). In this case I'm talking about the entire account, and linked CCs, suspended for activity - all incoming payments, card payments and direct debits suspended.
Anecdotally, I’ve noticed most cafes in NYC with more than a handful of seats have a bathroom (even if they hide it) and WiFi. Outlets are pretty much everywhere, it’s more a matter of whether you can get a seat next to one.
To be fair, public transport often has similar issues. If a subway/train car is stuck, nothing else can get by on the same track and thousands of people could be delayed. It happens in NYC all the time. At least with the road system there are typically ways to get around stopped cars.
As a user this seems like a nice way of connecting with people online.
As an engineer I wonder if/how you would open this up to a wider audience (behind “lonely” users). Moderation is the first issue that comes to mind, but I’m guessing that’s already a concern with the current audience.
Definitely, opening up to a wider audience is the plan :)
We first wanted to attack the 'hair on fire' problem as Paul Graham states it, creating solutions for people who really need this connection platform that is different from others because they would tolerate it even if our platform is sucky!
Moderation is easier on this platform I think, and so far we did not have to moderate any content. I think it is self-policing by nature because people need to speak what they want to share and also share their approximate location.
Do you have a sense for what motivates "support" users?
Already in listening through what is on there, a few people were clearly depressed, and lending support to those people is awesome, but also difficult to sustain (for any given individual).
I am not sure, but I was actually very surprised by how many supporters actually consistently came on the platform to leave supporting messages to lonely people. At one point, there were more supporters wanting to support than lonely people needing support haha
And a couple of very interesting occasions were when the people who initially reported 'lonely' decided to become 'supporters' because they wanted to give back to the community for the support they got, and wanted to help others who are in need more than themselves. I found that very touching :')
We do not have private voice messages yet. All voice messages are public, as in, everyone can listen to them.
This way, people who are hesitant to speak can still listen to other people's conversations, and also learn from them.
In the near future, we plan to implement private messaging functions, which will be end-to-end encrypted. Upcoming feature! :)
Having recently shopped for an EV, I did find that there are a lot more options in the US if you’re looking for larger vehicles. It’s a shame because many smaller models exist abroad, they just don’t want to bring them here (e.g. the VW ID.3).
What’s also funny is in many parts of Europe, their idea of a “small” car seems to be very different from ours. I’ve heard people there classify cars like the Honda CRV or the VW ID.4 as “big”.
I own an ID.4 and live in the US. In my opinion, the ID.4 is enormous and handles like a barge. For perspective, I used to drive a Corolla as my commuting car.
In hindsight, I kinda wish I would’ve just waited for a current-year Nissan Leaf to be in stock. But, I had burned out on looking for Leafs between dealerships blatantly lying to me and trying to sell me 5+ year old Leafs for roughly the MSRP of a brand new one.
