683 karma · joined January 29, 2017
Since I shared the AudioCraft cool project with my family, they were keen to try it but there does not seem to be any live version from it, I decided to host my own for a while and detailed my steps in this guide.
There is a live MusicGen demo app for hn users to try, I don't know how long it will last online because the server doesn't seem to be capable of handling many concurrent requests: https://audiocraft.wiringbits.net/
In a preview hn discussion about AudioCraft I saw a few people that weren't sure how to execute it, this guide can hopefully help the community (https://news.ycombinator.com/item?id=36972347).
The way to deploy this version is the old-school way, similar to a previous hn discussion (https://blog.wesleyac.com/posts/how-i-run-my-servers) that generated some interest.
Overall, this piece of technology is pretty interesting and fun, I hope the guide helps.
Thanks.
Thanks.
- Github-actions over circleci/travisci/etc, while I miss features from time to time, github-actions adoption allows to easily find most workflows you can need, having it with github itself is also handy.
- Integration tests with a real database mounted by docker, some people complain that this is slow but its worth it given the confidence it provides, in-memory databases or fake databases could be appealing due to the speed but they are annoying to maintain and never behave like production.
- DigitalOcean over AWS/GCP/Azure, for most projects, DO is enough, its simple to use and predictable pricing is something I could never get from other clouds.
Location: C-Corp from Chicago
Remote: Yes
Willing to relocate: No
Technologies: Scala/Scala.js, Java, Rust, Postgres, Pulumi, Ansible, JavaScript/TypeScript, React, Ruby, Blockchain.
Résumé/CV: linkedin.com/in/alexis-hernandez or github.com/AlexITC
Email: hn at alexitc dot com
> Alexis consistently proposed solutions that were both practical and innovative, illustrating his commitment to our project's success above his own billable hoursI grabbed a piece shared by one of my customers, there are more comments at https://wiringbits.net (you can ring my phone from there).
I'm generalist that commonly deals with tricky problems, broken projects, flaky infrastructure, etc.
My goal with projects is that they work smoothly without much maintenance.
I'm looking for part-time work to fund my own product, I can increase my commitment temporary to deliver important milestones.
I have worked in anything from tiny companies to even enterprises where we delivered projects to FAANG.
> Alexis consistently proposed solutions that were both practical and innovative, illustrating his commitment to our project's success above his own billable hours
I grabbed a piece shared by one of my customers, there are more comments at https://wiringbits.net (you can ring my phone from there).
I'm generalist that commonly deals with tricky problems, broken projects, flaky infrastructure, etc.
My goal with projects is that they work smoothly without much maintenance.
I'm looking for work to fund my own product, my time-commitment would increase/decrease based on your needs, we can work together for a few weeks or a few years.
I have worked in anything from tiny companies to even enterprises where we delivered projects to FAANG.
These are the tools I commonly work with, I'm happy picking new ones: Scala/Scala.js, Java, Rust, Postgres, Pulumi, Ansible, JavaScript/TypeScript, React, Ruby, Blockchain.
There are many code samples at https://github.com/AlexITC
Darknet dairies has an interesting episode about this: https://darknetdiaries.com/episode/133/
It's a real problem which makes it harder for people like me that are legitimately working remotely. This has existed for a long time but it wasn't as popular because remote working was unpopular before the pandemic.
> Really frustrating because it's making us have to do silly things like require photo ID verification over video on the first screening call
Unfortunately, this wouldn't solve it, a person can join the calls and get someone else to do the work.
Our situation is a bit particular because we sell software development services while using the funds to create our own product.
I'd suggest you to think again about being fully distributed, getting it right is hard and you may want to invest such a effort in the product itself.
I'd suggest you to consider an alternative, hire someone for a retainer covering up to X hours/month, there is a high chance that this person will be able to put more time when necessary and you will pay the difference.
The best way to find someone to handle this would be by devs you already know/trust or referrals.
Upwork/Fiverr could work, still, some luck is necessary to find a reliable dev on those platforms. If you want to take this route, I'd also suggest Codementor, try many people with small tasks until you find someone you are comfortable with.
I support others about posting on the monthly `Who's hiring` thread.
At last, we have this kind of engagement with a few of our customers, I don't know if we can support you but a call could be worth it (you can find a phone widget in my website that rings my phone). We are working on our own product which is funded by working on these kind of tasks.
Good luck.
Not really, there are many kinds of apps that don't need such redundancy.
> Also, none of the solutions discussed here gracefully handle new connections on the new service while waiting for all connections to terminate before shutting down the old service. Maybe some of the more esoteric Ansible do idk.
I have dealt with this in the code with shutdown hooks on the server, waiting for existing requests to finish its processing and reject new requests, clients will just end up retrying, not all apps can accept this but many can.
I have been running a similar setup for many years with some differences:
1. Use `EnvironmentFile` on systemd to load environment variables instead of bundling secrets into the binary.
2. Set `LimitNOFILE=65535` on the service to avoid reaching the file open limit on the app.
3. Set `StandardError=journal` and `StandardOutput=journal` so that `journalctl` can display the app logs.
4. Use postgres instead of sqlite, DO is taking regular backups for me and postgres maintenance is almost null for simple apps.
5. Nginx can have password-protected endpoints, which are useful to expose the app logs without requiring to ssh into the VM.
6. Nginx can also do pretty good caching for static assets + API responses that barely change, this is very helpful for scaling the app.
At last, I use ansible but I'm considering if its worth it, replacing it seems simple and I'd be able to keep a single deploy file that runs faster than ansible.
My take from the post is that author's goal is simplicity, AWS isn't simple, also AWS load balancers are expensive.
I have used cargo-dist and the process is quite smooth, it could be worth giving it a try.
I do use ansible but I'm reconsidering whether it is worth it, while my scripts have barely changed in the last 7 years, they tend to be slow and require me keeping multiple files around.
Related to debugging, you can expose the app logs through a password-protected endpoint by nginx.
Unnecessary overhead gets introduced with docker, for example, now you need to depend on a container-registry + the authentication to pull those images from the server + other stuff.
One advantage from DO is the regular backups.
Like you said, you can go for executing docker compose on the server if you want to do it fast.
For a simple setup, postgres maintenance is practically null.
I'd guess that the author's idea is that if someone gains access to the server, the secrets would be either dumped from the binary or the environment file, if so, why to bother with another file?
Good luck.