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.

That limit is going to be pretty high. Adaptive capacity (or on-demand) gives you up to 3000 read capacity units / second and 1000 write capacity units / second per partition.

The general solution if you think you are going to get to volume where that is not sufficient is to do something like add an additional integer (or other known symbol) to the end of the key. Ex: `key.1`, `key.2`, `key.3`. When doing operations you would have to run N operations across the key + symbol space. Not as elegant and you'll pay the additional computation for those queries, but since they can all be run in parallel it's not too bad in terms of latency.

Now, if all you are doing is hammering away at a few rows, you are stuck for sure. DAX [1] or some other caching layer may be your only way out of that problem.

[1] https://aws.amazon.com/dynamodb/dax/

To be clear, the auto-scaling with provisioned capacity still lags behind demand quite a bit. The new on-demand pricing makes this a non-issue but you pay for it at much higher cost at any sort of sustained load. https://serverless.com/blog/dynamodb-on-demand-serverless/ has a good breakdown of when to use on-demand vs provisioned capacity.

Especially with the new(ish) DynamoDB features mentioned in this article (ex: adaptive scaling), the backup and restore capabilities including Point in Time Recovery, and on-demand pricing model, makes it a really effective database when going with the single table design.

Wrapping your head around this takes some pretty serious time along with trial and error. Work and rework your data model multiple times. Turning to spreadsheets actually tremendously helps with being able to define and move data around to play that game of Tetris mentioned in the article.

In addition, you'll probably want to avoid any of the common ORM type clients that exist for DynamoDB, they tend to have made decisions that make using a single table design an uphill battle. Write your own little wrapper for the native AWS DynamoDB client in your language of choice and you'll be much happier long term.

Entirely untested and just spitballing... use Firehose to concat a bunch of small files and store based on size or time passage as a larger file to s3.

Then use Lambda transform in firehose to index the byte ranges for each record (file)? (Biggest q in the process would be here... you might have to index after it hits s3)

S3 also allows the Range request header out of the box as well.

Interesting problem, and I can totally related with s3 put costs be astronomical.

I’ve been working on and off for a few years to solve the time tracking problem for myself. I do a lot of things in a given day, and tracking granularly is quite hard. I’ve found I would rather just work, track it all somehow, then just bill / aggregate at the end of the week.

I’ve tried rescuetime and all sorts of solutions. One of the most interesting lately is https://timelyapp.com/memory-ai.

That all said, I recently stumbled on a really elegant solution in http://arbtt.nomeata.de/#what. Automatic Rule Based Time Tracking. Based on what apps are open, and the title of the windows (which can expose your file paths, url, etc) I can tag times. The great part is that it’s a store everything, classify later. So I can switch classification of times if I need to slice and dice a different way for a different report. All automatic. Need to add a new project? Git clone into my tracked directory and it just starts tracking a new project based on the directory name. Pretty slick.

There's an interesting side effect I've seen that a serverless approach enables, which is that it is now much easier to logically separate your various routes and logic to "route handlers" or "services".

However, if you naturally extend your system with these logically separated handlers in a vacuum, which is easy to do, and you have not thought through your packaging and dependency management, you can quickly fall into a pattern of producing a lot of duplicate boilerplate and utility functionality that a monolith would have avoided. Basically, take all the pain points and downsides of SOA and make it really easy to make all the mistakes.

That said, when approached with foresight, it's a perfectly manageable problem and I wouldn't agree that it is linear.

Beautiful, this hits a need for me. A decent changelog is something that has been on our backlog for weeks but was never quite important enough to invest the engineering time ourselves. Not only that, it's better than our specs and cheaper than doing it in house.

It absolutely depends on how burst driven your utilization pattern is, but don't forget the cost to actually manage the test cluster, and the engineering cycles that go into optimizing and sharding those tests across the cluster.