jbergknoff

This appears pretty superficial and it gets many things wrong.

> Choose between [DynamoDB] on-demand option (no capacity management) or provisioned option (cheaper).

It's very, very easy for provisioned capacity to be more expensive than on-demand. You need to overprovision because, if you exceed the provisioned throughput, you will get throttled and your application will suffer. Scaling up and down is a slow, opaque process, and you're only allowed to do it something like 5 times per day. If your workload has any idle periods, you're just burning money.

> Avoid using S3 for static web hosting (No HTTPS)

I won't argue that S3 is ideal for static web hosting, but "avoid" is pretty strong and IMO not warranted.

> Do not use AWS Lambda as a general EC2 host

What does this mean? As general compute? This is too simplistic a judgment. Lambda is a versatile service and can be useful in many situations.

> Kinesis: unlimited consumers

No, Kinesis is an extremely limited service. 5 reads per second per shard. In my experience, if you put even two consumers on a stream, you will start to see throttling. The official solution is to fan out to multiple streams. Hacky and super expensive.

> Kinesis 30x cheaper than SQS

This is hilarious. Maybe it's true for some workloads. In my experience, Kinesis is incredibly expensive and SQS is not.

As far as I know, SSH over SSM doesn't do anything regarding user management. It just establishes an SSH connection. Management of users on the host, authorized SSH keys, etc. is totally out of scope for SSM.

So if you already have access control setup on your host, then SSM doesn't do anything to undermine it. If you don't have it, you'll still need to add it.

We've been using SSH over SSM at work, and it's been great for tying access to IAM credentials.

Using the SSM tool as a ProxyCommand for OpenSSH is brilliant. I can SSH to an instance (turning on agent forwarding, etc.) or SCP files back and forth, all the same way that I'd do it with a regular host. But that host doesn't need to be exposed to inbound SSH traffic!

I was also able to get the ProxyCommand working in a Docker container, so I don't have to install the AWS CLI or the SSM plugin on my (Linux) host system, with an .ssh/config entry like this:

  Host i-*
    ProxyCommand docker run -i --rm -v $PWD:$PWD -w $PWD -u 1000:1000 -v ~/.aws:/tmp/.aws -e HOME=/tmp -e AWS_PROFILE <docker image ref> ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'

A few problems in practice:

* We often use our bastions to do port forwarding, e.g. to connect to an RDS instance inside VPC. As far as I know, we can't accomplish this with just SSH over SSM, so we still keep our bastions.

* User management: SSH over SSM doesn't do any user or key management for you (which makes sense). It establishes the SSH connection and you're on your own from there. We use Keymaker [1] to dynamically create user accounts on the EC2 instances, and populate SSH keys according to the user's IAM profile. This works fine, but maybe there's room for simplification.

* Connecting based on instance ids (`ssh i-...`) can be awkward. It would be amazing if we could alias these somehow, like set up a CNAME that points to `i-...`. I wasn't able to get OpenSSH to follow a CNAME and then use the ProxyCommand. Maybe it's possible, though.

[1] https://github.com/kislyuk/keymaker

There are dozens of us! I've tried to get comfortable with touchpads, but I always find them frustrating (yes, even MBP touchpads). For instance, selecting text with them is a disaster. Trackpoint or external mouse for me.

It's interesting to see the complaint about containers starting too slowly. I haven't seen much discussion about it before this article and this comment thread, but it's one of my biggest pain points with Docker. I know we can save some time by skipping some namespaces (e.g. `--net host`) but I've still never been able to get satisfyingly fast container execution in that way. (e.g. `time echo` -> 0.000s, `time docker run --rm alpine echo` -> 1.3s; come to think of it, this is even slower than it used to be)

Still, Docker is the best method that I've seen for distributing software, especially cross-platform. Not just for shipping a containerized web app to production, but also running dev tools (e.g. linters, compilers) and other desktop and CLI applications. I know some people run lots of stuff in containers (https://github.com/jessfraz/dockerfiles, probably the most prolific), but I think this is a largely underappreciated facet of Docker.

My team at work is heavily Mac while I'm on Linux. The dev workflows are identical on my machine, on their machines, and in Jenkins. Nobody has to have a snowflake setup, installing this or that version of Python, we're all just `docker run`ning the same image. It's great.

Unfortunately, Docker for Mac's IO performance is abysmal. If past performance is any indication of future results, that's never going to change. I'm constantly on the lookout for other ways to share tools cross-platform that don't involve Docker. Things like podman and binctr are exciting, and I've played with them, but I don't see them filling this niche.

I came across https://www.thingiverse.com/thing:2588513 in some Reddit thread about this, got it printed on my public library's 3d printer, and it's been pretty nice. (Had to etch some grooves in the sides of the Yubikey so there's something to grab it to pull it out of the sheath, but that wasn't a big deal)

I like a lot of these suggestions. For instance, it's true that I never get anything out of the commit messages in the file browser (though "how recently has this file been updated?" is often useful).

One other thing I've never understood about the GitHub UI is why the issues search defaults to open issues. I have literally never wanted to restrict my search in that way. Maybe it's just geared towards maintainers? As a user of a project, I would rather land on a closed issue with a solution to the problem I'm seeing.

I wonder if this could be used to get Docker running on a Mac without painful file system performance (a la Docker for Mac, running Linux in a VM). Could something like this project work for that? Are there Darwin equivalents for container stuff like namespaces?

Rival | Multiple roles | Los Angeles | Remote | Full-time | https://rival.co

Rival is building the operating system for the world's biggest venues. Ticketing is just one aspect of our platform, and by managing the inventory and truly digitizing the ticket by linking access to biometrics, we will be able to drive commerce, intelligence about fans, and enhanced security.

We have extraordinary engineers, PMs, and designers from the best technology companies in the world, who are working together to solve the many challenges of bringing millions of fans together for the music and sports events that they love. With investment from Andreessen, Upfront, sports teams from every major league in the US, and the leaders of Instagram, Twitter, Slack, and Stripe, we have the financial runway to build this platform the right way, from the ground up. We have revenue on the horizon and our first clients will be going live next year.

Our stack is mostly Python 3 and ES6+/TypeScript/React Native backed by AWS Lambda, Fargate, Kinesis, SQS, Aurora, and Dynamo. We're heavy AWS users with all infrastructure managed by Terraform. Local development and CI use Docker extensively. We're interested in engineers with expertise in these or similar technologies, or with background in distributed systems in general. We're especially interested if you're also passionate about building things, enjoy continuing to learn and grow, value open communication, and strong collaboration.

This is the opportunity you have been waiting for - hard engineering problems to solve; the conditions to move quickly and do your best work; to push yourself while having impact; to work with other exceptional people; and the chance to be a part of the early team that is building the technology platform that will change an industry.

Read more and apply via https://rival.co, or fast-track your application by completing the short CTF starting at https://hacker.rival.rocks.

Rival | Multiple roles | Los Angeles | Remote | Full-time | https://rival.co

Rival is building the operating system for the world's biggest venues. Ticketing is just one aspect of our platform, and by managing the inventory and truly digitizing the ticket by linking access to biometrics, we will be able to drive commerce, intelligence about fans, and enhanced security.

We have extraordinary engineers, PMs, and designers from the best technology companies in the world, who are working together to solve the many challenges of bringing millions of fans together for the music and sports events that they love. With investment from Andreessen, Upfront, sports teams from every major league in the US, and the leaders of Instagram, Twitter, Slack, and Stripe, we have the financial runway to build this platform the right way, from the ground up. We have revenue on the horizon and our first clients will be going live next year.

Our stack is mostly Python 3 and ES6+/TypeScript/React Native backed by AWS Lambda, Fargate, Kinesis, SQS, Aurora, and Dynamo. We're heavy AWS users with all infrastructure managed by Terraform. Local development and CI use Docker extensively. We're interested in engineers with expertise in these or similar technologies, or with background in distributed systems in general. We're especially interested if you're also passionate about building things, enjoy continuing to learn and grow, value open communication, and strong collaboration.

This is the opportunity you have been waiting for - hard engineering problems to solve; the conditions to move quickly and do your best work; to push yourself while having impact; to work with other exceptional people; and the chance to be a part of the early team that is building the technology platform that will change an industry.

Read more and apply via https://rival.co, or fast-track your application by completing the short CTF starting at https://hacker.rival.rocks.

Rival | Multiple roles | Los Angeles | Remote | Full-time | https://rival.co (https://rival.co/)

Rival is building the operating system for the world's biggest venues. Ticketing is just one aspect of our platform, and by managing the inventory and truly digitizing the ticket by linking access to biometrics, we will be able to drive commerce, intelligence about fans, and enhanced security.

We have extraordinary engineers, PMs, and designers from the best technology companies in the world, who are working together to solve the many challenges of bringing millions of fans together for the music and sports events that they love. With investment from Andreessen, Upfront, sports teams from every major league in the US, and the leaders of Instagram, Twitter, Slack, and Stripe, we have the financial runway to build this platform the right way, from the ground up. We have revenue on the horizon and our first clients will be going live next year.

Our stack is mostly Python 3 and ES6+/TypeScript/React Native backed by AWS Lambda, Fargate, Kinesis, SQS, Aurora, and Dynamo. We're heavy AWS users with all infrastructure managed by Terraform. Local development and CI use Docker extensively. We're interested in engineers with expertise in these or similar technologies, or with background in distributed systems in general. We're especially interested if you're also passionate about building things, enjoy continuing to learn and grow, value open communication, and strong collaboration.

This is the opportunity you have been waiting for - hard engineering problems to solve; the conditions to move quickly and do your best work; to push yourself while having impact; to work with other exceptional people; and the chance to be a part of the early team that is building the technology platform that will change an industry.

Read more and apply via https://rival.co, or fast-track your application by completing the short CTF starting at https://hacker.rival.rocks.

Similar experience with Dynamo here: it's very easy to get into a situation where it's unusable (rejecting requests) unless you pre-provision enough capacity. The act of scaling up capacity often takes 5-20 minutes, and then there are the limits on how often you can scale. The backup/restore options are very poor. There's no good way to clear a table besides deleting and recreating it, which can be a problem when there are stream listeners. The tooling around Dynamo, both first party and third party, is also pretty shabby.

Maybe I'm just using it wrong. I wish Dynamo came close to its apparent potential.

This infrastructure/configuration distinction is very hazy when it comes to services like Lambda or Fargate, where you just specify your code artifact and there's essentially nothing more to do. It's not clear that it's a net benefit to introduce additional tooling beyond CloudFormation/Terraform for deploying to these services. It's certainly not strictly necessary.

Rival | Multiple roles | Los Angeles | Remote | Full-time | https://rival.co (https://rival.co/)

Rival is building the operating system for the world's biggest venues. Ticketing is just one aspect of our platform, and by managing the inventory and truly digitizing the ticket by linking access to biometrics, we will be able to drive commerce, intelligence about fans, and enhanced security.

We have extraordinary engineers, PMs, and designers from the best technology companies in the world, who are working together to solve the many challenges of bringing millions of fans together for the music and sports events that they love. With investment from Andreessen, Upfront, sports teams from every major league in the US, and the leaders of Instagram, Twitter, Slack, and Stripe, we have the financial runway to build this platform the right way, from the ground up. We have revenue on the horizon and our first clients will be going live next year.

Our stack is mostly Python 3 and ES6+/TypeScript/React Native backed by AWS Lambda, Fargate, Kinesis, SQS, Aurora, and Dynamo. We're heavy AWS users with all infrastructure managed by Terraform. Local development and CI use Docker extensively. We're interested in engineers with expertise in these or similar technologies, or with background in distributed systems in general. We're especially interested if you're also passionate about building things, enjoy continuing to learn and grow, value open communication, and strong collaboration.

This is the opportunity you have been waiting for - hard engineering problems to solve; the conditions to move quickly and do your best work; to push yourself while having impact; to work with other exceptional people; and the chance to be a part of the early team that is building the technology platform that will change an industry.

Read more and apply via https://rival.co, or fast-track your application by completing the short CTF starting at https://hacker.rival.rocks.

You can also set a PYTHONUSERBASE environment variable (and `pip install --user`) to scope the installed packages to the project's directory. This is effectively the same as a virtualenv, but doesn't have the requirement on bash or "activation", and it's less magical than virtualenv because these choices are explicit on each command. The tradeoff is that it can be tedious to be explicit, remembering to use `--user` and specify the PYTHONUSERBASE. If you're scripting everything via make, though, then that's not such a burden.

This has the added benefit of letting you encode the system dependencies (OS packages) for library build time and for run time.

Docker images are also a great way to distribute Python CLI tools, certainly far better than installing via pip which either pollutes global state or is confined to a certain project's virtualenv.

How does CI work with a monorepo? Do you always have to run all the tests and build all the artifacts? Or are there nice ways to say "just build this part of the repo"?

What are best practices for sharing build artifacts (e.g. images in ECR, files in S3) among AWS accounts? Cross-account IAM policies, explicit promotion process to move artifacts between accounts, or something else?

Anybody know why logical replication isn't supported in Aurora Postgres, or if it's on the roadmap?

Finally, a semantic use for the marquee tag.

Who really clicks on https://news.ycombinator.com/shownew, which isn't in the top nav? A new "Show HN" doesn't get exposure on /show, as far as I know.

Great post. It's always good to see more examples of people putting these tools to work.

With that said, I consider getting the AMI id dynamically to be an anti-pattern which undermines the principles of infrastructure-as-code. Specifically, it introduces an implicit build variable "time of `terraform apply`", which is not tracked in version control. Happily, because of Terraform's design, this sort of thing mostly won't cause your infrastructure to drift into unexpected states (e.g. production instance 1 running AMI X and production instance 2 running AMI Y). Within an environment, things should be consistent, but your staging environment may run AMI X while production is running AMI Y, and you wouldn't know from looking at your Terraform definitions.

I previously wrote about similar ideas in the context of pinning dependency versions, where wildcards can and often do get you into bad states. https://jonathan.bergknoff.com/journal/always-pin-your-versi...

You might find this useful: https://jbergknoff.github.io/mathjax-sandbox (example: https://jbergknoff.github.io/mathjax-sandbox/#JGVee2lccGl9PS...)

Why is the default issue filter "is:open"? When I have an issue with a project, I never want to restrict focus to open issues. In fact, I'd much rather land on a closed issue where it turns out the issue was recently fixed, or there is a workaround, a better approach, etc.

You're exactly right. Arguably worse than ugly, unnecessary and difficult to parse are that many of these things are difficult to research with a search engine. For example, `const { user, post } = this.props;` there is nothing to plug in to a search engine (and the meaning is not obvious, even to somebody with plenty of experience in ES5). Same thing with `arr1.push(...arr2);`.

Sounds like you're looking for many of the same things as I am. I tried all the usual suspects (including Trello, per the article), and none did what I wanted. I have actually been using Jira for personal task management for the past 6 months or so. It's pretty good, but it's Jira: slow, too many features, etc. It's still better than anything else I've tried.

Relevant discussion on the nesdev forum: http://forums.nesdev.com/viewtopic.php?f=3&t=13552

Yes, the npm "request" module is extremely bloated and badly written, to boot. https://www.npmjs.com/package/needle is a good alternative.

Nice. I have a 30 year old garage opener but I don't have a remote. I know the combination because I set the DIP switches, and I think I even dug up the trasmission frequency when I looked into it a few months ago. I don't know what sort of transmission the opener wants to receive, though. Any resources you can point me to on that topic?

"less usable than before" -- this is completely the opposite of my experience. Kudos to cloudflare for ditching the dysfunctional infinite scroll.