I put together a list of open-source voice-first AI tools to help devs and makers get more done without touching a keyboard. Curious what the HN community thinks — anything I missed?

"Torvalds: I really never wanted to do source control management at all and felt that it was just about the least interesting thing in the computing world."

I love how this story underlines the 'just do it' attitude. Git wasn't born from a grand plan but from an immediate need and a pragmatic approach. Sometimes, that's all it takes to start something revolutionary.

I believe that's working but it's kind of pain because we need to passing context across function call. So I wonder whether there is better way to do that.

I believe node.js has async_hook feature that can capture context without passing function call, but it's still in experimental phase and won't work for tracing

Like I said I've never worked with Node but being explicit seems like a better pattern than having some background async process do it.

When developing new things, I always used Terraform and Jenkins.

The reason is because:

1. Terraform You can abstract the deployment logic and requirements into single unit because developers ideally should spend more time building products rather than dealing with the deployment and cloud stuff. Furthermore, this will be one source of truth for any deployment configuration and documentation, that will be super worthed in onboading as well especially when you're working with big engineering team (> 50 engineers)

2. Jenkins We actually can run terraform from our local computer, but with Jenkins we can standardize the way people update and create the resource in consistent way. Also, by using Jenkins we can track all deployment that happened

My future plan is for combining this workflow with management configuration tools like Ansible since Terraform is not only for creating cloud resource, not for manage configuration. Currently, I'm ussing bash command which obviously won't be easily scalable and understandable by engineers.

But maybe will be good if you can provide the difference between envkey and vault or some similar stuff like AWS Parameter Store? Especially in reliability side

Cool, thanks! I guess I'll go asking into your intercom website directly.

Interesting, thanks! How is your experience using that in production?

Thanks! How is your experience using that in production?

Unfortunately I haven't gotten a chance to use them in Prod. We used a homegrown process at my last company and we use Vault at my current company (which I haven't even used directly yet).

I mostly like credstash because I independently arrived at the same design for securing secrets before I knew it existed. And many of my security minded friends are excited to try out the AWS service.

Interesting. Thanks for the sharing, Sevii!

1. For your AWS deployment, could I know why you didn't use docker image for your deployment?

Because essentially you can use docker for building the image instead of packer. Furthermore, Docker also has caching mechanism which make the build much faster. I'm not sure packer also has capabilities for caching.

Any reason you choose packer over docker?

except with docker youre managing two userlands, the underlying host and the container, instead of one.

I've used packer a bunch of times, generally for things that dont change frequently. For instance, for creating the image the docker containers run on. Or for one-off utility servers that are just running third party code that doesnt support docker. For the thing that id work on and deploy every day, id want something else on top whether thats docker/puppet/codedeploy/etc - probably docker today.

Some of the most business critical code ive worked with was built with packer, because the extra complication of docker added no value, we wanted as little software on the server as possible since each added thing could fail, and we wanted fast bootup times and minimal launch scripts for autoscaling.

Well, this deployment was using aws ecs, we created custom AMIs via packer and then ran application containers on them via ecs.

Not OP, but we dont use docker because legacy. We developed our infrastructure before containerization was popularized.

Gotcha.

Ah also one thing that I wonder in Packer is versioning. Since in docker we can tag every release of the image, we can somehow do versioning on that.

1. How is the versioning in Packer?

2. Also, do you have plan to adopt docker image/ other containerization pattern even if you already used packer for 3+ years? Maybe you have different use cases for adopting docker?

1. We just commit packerfile to repo and version through git 2. We've talked about it. The problem is we have some stateful processes we can't trust to container- like database stuff/etc. So its really a matter of separating what is safe to containerize or not.

But from what I understand, even if you're using github https://about.gitlab.com/features/github/, you can have the CI/CD of gitlab feature.

Also, I wonder what's the benefit of in house installation in your case?