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
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
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. 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.
The hardest challenge as developers IMO is understanding and selecting the best technology that suits the current era, your use case / goal, and your current situation.
Most people that I know made technology stack's decision making based on hype.
I used Slite (YC W18) for keeping my personal knowledge base. The reasons I use Slite other than Google Keep or Google Drive are because it's simple to use, it's like Slack so very easy to rearrange and organize like the structure that I want (this is the most important part of knowledge base IMO), and it supports markdown better than google docs (most of my knowledge base are software development related, so I'm a big fan of markdown).
Last but not least, for business presentation, I'll link the Google Slides on the Slite so every information will be centralized and organized from Slite.
> What kind and required by whom? Most of such things are "if you have all, good, if half an hour is missing, we'll do without those", not something akin to transaction data in relational database where you cannot lose even a single byte.
So we will do log analysis from the data (counting, sum of the amount from the data, etc). So ideally need 100% precision and we will do the analysis in daily basis
> What is "not to lose logs"? Is losing a single record OK? Is losing 1% of logs OK? How long network problems should be tolerated? What to do if such network problems are longer than anticipated and disk buffer is running out of space?
In my case, losing single record is significant enough because we will do calculation for those logs. For the network tolerance, I think that's very good question, I'll take that as my consideration too. But the network problems that I mean before is the intermittent one like < 1 minutes and with assumption the data buffered is not until making the server running out of space
Also, In terms of reliability, which one is better between logstash and fluentd?
I saw logstash and fluentd is really similar, The difference that I found is just fluentd has buffering into disk mechanism, but logstash not (logstash only has the in memory queue buffering)
1. For my case (yea, they are kind of required audit data), I need the log to be able to not loss when sending to logstash or kafka, probably this should be handled in client side by buffering the data before sending to logstash?
2. For volume "at scale", my point is just for clarify whether this logstash could be good to be used for production for big volumes. Maybe can be like 100GB per day