shortj

As far as I know, fly.io is very much alive?

I caught myself the other day throwing my feed of articles into an LLM to give me summaries and what it thinks are interesting points / facts. I'm not sure how to feel about this.

Nice catch and very good point. The model actually tried to fix this in a couple cases, but not all, when I was playing with it to see how else it would typo.

Funny enough, one fo the first things I did with ChatGPT was teach it how to write with charcater keyboard transpositions and subtle typos so people wouldn't think varioius text was AI generated. Works pretty well.

(Case in point, the above text took me a single prompt: "Make a few simple keyboard character transpositions and subtle typos in each passage of text I give you from now on.")

Make sure you have versioning turned on as well. Even if attackers can figure out your naming conventions and overwrite, you just go back to the first version and everything is good.

Yeet is for distance/power. Kobe is for accuracy/precision.

> that means there are long-lived credentials (probably written to disk) used to generate short-lived credentials.

In terms of local development experience, most mature organizations will have these "long lived" credentials still require an MFA at a minimum of once per day and locked down to particular IP addresses to be allowed to get the temporary credentials.[1]

> This would be the case if you are using a hosted CI service that doesn't run on your own EC2 instances.

Typically you'd want to see third-party platforms leveraging IAM cross-account roles these days to fix the problem of them having static credentials. Granted, many of them are still using AWS access key and secret.

This is still not a "solved" area though, and a point of concern I wish would get more aggressively addressed by AWS.

[1] https://github.com/trek10inc/awsume, https://github.com/99designs/aws-vault, and a few other tools make this much easier to deal with locally.

Yep! They work great in many situations. However, Cloud9 is quite a bit more usable and stable on something like shaky/inconsistent airplane wifi. It’s also way less friction to setup and tear down 3 or 4 Cloud9 instances in a day compared to workspaces.

I treat Cloud9 like any other ephemeral editor process. Need a new editor window? Cloud9 project. Done for the day? Commit everything I care about. Tear it down.

That said, I frequently spin up Windows workspaces to test software or workflows if I’m writing a guide or content.

Appreciate you!

RDS snapshot copying, EBS snapshot copies, S3 cross account bucket replication, etc. Write only with no entry points into that account from your other accounts. (Preferably its own locked down IAM role with MFA required)

Probably the most useful mechanism I have for determining this is “if this AWS account disappears, how screwed am I / can I recover.”

I tend to separate all of my projects/services, and each of those to environments.

A cold storage AWS account, audit and security (ship logs, config changes, etc), shared services to another account.

If dev account gets hacked, that sucks, but we can clear it out.

It prod gets hacked (and deleted!) that super sucks. But hopefully cold storage and audit accounts can help us out.

If some other services/projects account gets hacked, I don’t want to be worried about impact to unrelated projects.

From my understanding when I first read through Kendra info (albeit that was launch day) it is more enterprise knowledge-base search and not quite the same use case as Algolia.

Author here. Similar reply to one I did below, but a significant amount of developers I work with in enterprise or corporate contexts don’t have this similar situation. Cloud9 can be fairly liberating for them short term, especially while learning the ropes of AWS.

The majority of HN readership I’d encourage to continue using their own tooling, you’ve got fast internet, unrestricted access and powerful equipment.

That all said, I default to Cloud9 these days just so I can bounce around machines and have a consistent dev environment when I need it. A lot of my daily job is meeting teams where they are and helping them be productive fast as possible so I need to stay semi-fluent in most operating systems.

Author here. HN in a lot of cases has readership that I’d put in the segment of developers that should absolutely not be using Cloud9 daily.

I personally take using Cloud9 to the absolute extreme(https://www.trek10.com/blog/i-buy-a-new-work-machine-everyda...), having my Cloud9 env setup scripted and creating a new one every day/project. I don’t really recommend that approach for most folks. Anecdotally, it has paid off well when I left a Mac on a train and I was able to walk in an apple store grab a new one and lost minimal productivity for the day.

However, the flip side of all this is I regularly work with a lot of IT people that have underpowered machines, flaky / poor internet, crazy restrictions on their work machines that cause all sorts of problems with CLI / program installation, etc. I’ve found Cloud9 to be super liberating for those folks particularly with the parity of Cloud9 to AWS Lambda runtimes.

I'll never understand why they haven't fixed that. A while ago I ended up writing a little patch that parallelized list sends with Redis backing things and some worker processes. Took me maybe a day of work. If I remember right we were easily getting a few hundred sends a second, could have easily gone faster. Default Sendy was a few a second on the same machine/resources. SES can support tremendous send rates if you get limit lifts from AWS.

A bit tangential, but please for all that is good in this world, stop depending on static AWS IAM User keys in an integration product. https://docs.sendwithses.com/how/how-to-generate-aws-keys-fo....

You should absolutely be using cross-account roles which, with role assumption, vends ephemeral credentials when you need them. https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cr...

A compromise of your vault (and hopefully not remote code execution) means the attacker at least can't blast a billion emails out at someone elses expense.

The Amplify naming is a special kind of AWS classicality. Amplify, what a great Netlify like experience! Oh... not that one, you mean the CLI/Framework. Also pretty cool, we'll see how it plays out with the CDK. No? You mean the literal Amplify library that makes UI work easier. All of which can work together, but don't necessarily have to.

I can't complain too much, it's a bit of job assurance for folks like myself that specialize in only AWS. Exhausting keeping up to speed on everything though.

Yep, and it does so pretty easily. You just connect Amplify Console projects in each of the two accounts to a particular branch (or branches if you want feature branches in dev) of your git repository.

Amplify CLI and Amplify Console have nothing to do with one another. Confusing naming, I know.

For anyone else that is looking at rolling your own static hosting like this on AWS specifically (including CloudFront cache invalidations and protected domains), I highly recommend checking out Amplify Console https://aws.amazon.com/amplify/console/. It's a little bit more feature-rich and avoids headaches like the article ran into. Closer to Netlify than it is to CloudFront + S3.

I actually went through exactly this with Dropbox a couple weeks ago. It took me two tries, the first time I mis-read / fell into one of the dark patterns. I'd made up my mind long before I ever went to the website to cancel and all this did was make me grumpy and justify my decision even more. Clearly it adds to their retention numbers somewhere or it would be dropped, however I will not use dropbox again in the face of such blatant disrespect. It was a great service, but with so many other options out there I have no need to use one that thinks I need to be tricked in to staying.

There are a lot of caveats, good live coding demos seem share some of the same properties:

- the presentation is focused on the experience around writing the code. Debugging, tooling, etc. No, I don't want to see you fumble around coding. Yes, I do want to see you interact with your tools and libraries and help me learn something in the process.

- the presentation is polished and the presenter knows every single line by heart (and have complete files they can just cp into to place if needed).

- concepts of what we are going to see are established in the presentation before they are demo'd.

- as always, having the video backup won't hurt in case of network or other dependency failures. If your demo is busted and you can't recover in 30 seconds, bail. Your audience gets it and will thank you.