lipanski
Joined 13 years ago
Karma
291
Submissions
51
Member since
Jan 24
https://lipanski.com
View on Hacker NewsRecent submissions
Comment · 1 year ago
Berlin - Die Sinfonie der Großstadt (Berlin - Symphony of Metropolis) is by far my favourite.
Comment · 2 years ago
If this is the nano version then let me share the pico alternatives with you:
* BusyBox httpd [1]
* thttpd [2]
* Lwan Web Server [3]
* gatling [4]
I built and maintain a super tiny Docker image (~158KB) for serving static files [5]. My current implementation is based on Busybox httpd and scratch but I also tried out thttpd in the past, which worked well but came with a high memory footprint in some cases. thttpd was used to serve big projects back in the day but it doesn't seem maintained any more. The other two projects were on my list of things to try out. All these projects should compile to binaries <500KB.
By comparison nano-web builds a 18.5MB image on my machine. In my experience you can't go below 5-6MB with Alpine (scratch is the way to go if you can compile statically) and you can't go below ~500KB with Golang or Rust, at least not for serving http requests (C or ASM is probably the way to go).
Note that I'm not saying that small is always better, it probably depends on your use case and there are reasons for using nginx for a static website as well.
[1] https://www.busybox.net/ [2] https://www.acme.com/software/thttpd/ [3] https://lwan.ws/ [4] https://www.fefe.de/gatling/ [5] https://github.com/lipanski/docker-static-website
Comment · 5 years ago
My YT recommendation on the topic is the hilarious but very well docummented BBC series "Supersizers Eat" [1]
Comment · 5 years ago
My favourite is thttpd [1] which is super tiny, battle-tested and actually meant for the job (and only this job). It's available as a package on most Linux distros.
Serving a static folder `/static` on port `3000` as user `static-user` and with cache headers set to 60 seconds would go like this:
thttpd -D -h 0.0.0.0 -p 3000 -d /static -u static-user -l - -M 60
Comment · 5 years ago
They require you to use a business email address in order to enter the hackathon (gmail is blocked).
Comment · 5 years ago
Same here, I basically learned how to write POSIX-compliant Shell with the help of ShellCheck. Shell is not a difficult language to learn but it definitely has its oddities and the different flavours (Bash etc.) only add to the confusion.
What people don't always expect is the immense portability that POSIX-compliant Shell offers you. This thing runs on pretty much everything.
Comment · 5 years ago
I recently installed ClickHouse (part of my self-hosted Plausible setup) and had to modify a record inside the database. At this point my only knowledge of ClickHouse was that it comes with an SQL interface. So I opened up a client and typed "SHOW DATABASES" and guess what - it showed me a list of all databases. Then I typed "USE mydatabase" and I was connected to my database. I typed "SHOW TABLES" and got a list of tables, followed by "DESCRIBE TABLE users" and "UPDATE users SET email_verified = true" (FYI I was trying to avoid having to set up SMTP credentials for Plausible). I was able to use ClickHouse without any prior knowledge because the authors decided to based it on a well-known and fairly simple standard instead of inventing their own.
It felt as good as building Ikea furniture without checking the manual and it's what user/developer experience should be about.
Comment · 5 years ago
I second this - it sounds like a massive waste to spin up a Github Actions job in order to trigger a basic request every 5 minutes, 300 times a day.
Why not just use a dedicated uptime service with a free tier? I've been using UptimeRobot [1] in the past - they give you 50 free checks at the same refresh rate of 5 minutes.
Comment · 5 years ago
On the same note, I'd recommend the very well documented and funny BBC series Supersizers Go: https://youtube.com/playlist?list=PL0815CC4054AB8D12
Comment · 5 years ago
Airbnb enabled a great range of people to see places they might have never afforded to see before. It managed to commoditize travelling in a similar way low-cost airlines did. On top of that, it enabled regions with no previous tourism revenue to have a slice of the cake. Sure, the company made a good profit while there was a profit to make, but their service benefited consumers as well and I think it did leave a positive impact not only on the travellers but also on some of the communities that understood how to balance its pros and cons.
Comment · 6 years ago
In my experience, automatic eager loading is the most elegant solution to this problem. For ActiveRecord, I'd recommend Goliloader [1] (which is a gem similar to ar_lazy_preload but with emphasis on doing that automatically) while for Sequel, you can enable the TacticalEagerLoading plugin [2].
These tools don't require explicit `includes`or `preload` calls. They can infer the tables that need to be eager loaded through usage (e.g. if you iterate through users and every iteration requests the user's posts, the first iteration will eager load all posts for all those users). This fits really well with GraphQL because different clients might trigger requests for different associations. Automatic eager loading allows you to optimize for all those different cases without writing a single line of code.
The other solutions are either way too explicit or might be eager loading too much. Things like graphql-batch don't even feel like ActiveRecord any more (and for a good reason - it's a different kind of abstraction, meant to batch all sorts of things, including HTTP requests).
There are more caveats when it comes to eager loading, mainly there are many things that can break eager loading. I recently wrote a blog post [3] about dealing with those issues.
[1] https://github.com/salsify/goldiloader
[2] https://sequel.jeremyevans.net/rdoc-plugins/classes/Sequel/P...
Comment · 6 years ago
> Give me all users whose phone number starts with 555
There's no magic there, it's left up to you whether you expose such functionality and you are in full control of all fields that make up your API. Most of the time your APIs will reflect your database associations `{ users { posts { comments } } }` which should be indexed anyway. Custom queries on top of that, like a search filter, can be indexed/optimized individually. Resources can be paginated quite easily and you can also enforce a maximum depth when requesting associations, so that you don't end up with requests too large to deliver.
The main problem with GraphQL comes from the many different ways you can use it, which makes caching or eager loading difficult.