HN user
Freelance Go developer.
Additions to that list:
https://thehonestsorcerer.substack.com/p/running-on-empty-co... - the hidden world of copper supply
https://www.orcasciences.com/articles/there-has-to-be-a-bett... - thoughts on improving the current titanium production process
Really appreciate the graphics, in-between summary elements and the progress bar widget. A bit too much colorful font variants my taste as it leans towards distracting, but hey everybody is different. That was a swell read, thanks for sharing!
As far as "app which helps create overview, reduce overwhelm and taks small steps" - I wonder how many of those are out there? I have written about 3 of those already for various use cases and in different flavors. Using them over a longer period of time, once the chaos subsides or the novelty wears off seems to be hard for me personally.
What would be an easier niche in your opinion?
I'm also curious about ways to provide value with a technical project.
The challenge when exploring this topic: the incentive to stay under the radar. Those succeeding don't have much to gain from sharing details here. Worst case: it could invite competitors into their space.
Communities that thrive on growth (e.g., open-source) tend to share freely, but API businesses, especially ones which are easy to execute, often guard their edge.
A recent finding I had, while not necessarily an API: services which help you 24/7 stream a lenghty video file. YouTube live streams seem to work well for those lofi-types of channels, and there are services which are built to enable autopilot live streams.
Good stuff. Thanks! Any chance this has to do with the generous grants which get bestowed on movies and tv productions in Canada?
Thanks for the reply! Never would have thought.
According to a HN post from 2015, Buenos Aires is the bookstore capital of the world. https://news.ycombinator.com/item?id=9747230
Thanks for the suggestion!
That's the reason why I chose to focus on Go instead of Rust after immersing myself in it for a while.
Rust invites you to aim for brevity and crafting smart solutions whenever you can. Don't get me wrong, sometimes this leads to beautiful code. It can be super satisfying to write. But there is only so much fun in reading yet another 10-step iterator method chain which works due some arcane edge case in the middle of it.
I vastly prefer reading dumb and obvious Go code. It's just easier to understand and to work with.
Thanks for the kind words! I'm currently revising some old articles and getting back into writing more often, this is a nice reminder to keep at it.
Thanks a lot for sharing! I ended up watching the referenced "It's Time for Operating Systems to Rediscover Hardware" talk as well. Fascinating stuff.
Way out of my depth! However, the stuff I saw the folks from Oxide [1] talk about comes to mind. Hardware stuff with Rust. If you want to look at a specific project, Hubris [2] is a kernel for "deeply-embedded" systems.
[1] https://oxide.computer/blog/building-big-systems-with-remote...
I wondered about an adjacent topic recently ("what IS the kernel actually") and found out that a great way to understand it, would be to start with the boot process. Once I felt less lost, I tried to capture my learnings [1]
The text is not edited yet, but as I had the benefit of learning about it with fresh eyes, it should be very approachable (and hopefully accurate enough)
The site was built with Next.js and TailwindCSS in about a day. The size is quite big, because data is baked-in, for that sweet sweet quick interactivity.
"Liked", "watched" and similar annotations are only saved on your local device. "Look, no server ma!"
Hope this helps some of y'all to find one or two interesting JRE episodes you haven't stumbled over yet.
Interesting! Reminds me of James Clear and the way he used blog posts as raw material for his book.
PKM geek-out time: Edw519 has been using HN as a tool for thought. Producing intermediate packets in the form of comments. If those comments were more interlinked, it would be closer to a Zettelkasten.
Hi HN! First time I see one of my articles on here. What a nice surprise.
If the above link caught your attention, you might also enjoy the following ones:
* For the quickest ROI: https://vsupalov.com/improve-your-docker-images/
* Stuff I WISH I knew: https://vsupalov.com/12-docker-facts/
* If your image builds are slow: https://vsupalov.com/5-tips-to-speed-up-docker-build/
Looking forward to join the discussion later!
At long last, winter is coming.
Whoops, sloppy generalization on my part. You're completely right of course, thanks! I've been focusing on deep learning a lot lately, to the point where AI has become an alias for those exciting new GPU-heavy techniques.
The results are really impressive. At the moment I'm considering spending a low 3-figure amount for a professionally spoken intro for a new podcast. Some of the lines I generated are in my top 5 easily, human speakers don't have a lot of edge for short generic blurbs of text anymore it seems.
Yeah, running anything related to AI involves GPU instances. An alternative is to point people to using Google Colab where you can get access to a GPU for free, but that's not a smooth end user experience for most folks.
Shameless plug: if you want to learn more about building better Docker images (beyond using hadolint, which is an excellent quick win) I put together a comprehensive free email course about that topic over at https://vsupalov.com/courses/
+1 for hadolint. There's also https://github.com/goodwithtech/dockle and https://github.com/aquasecurity/trivy if you want more security emphasis.
For those who want to like Hugo, but can't stand the templating language: there's also Zola (https://github.com/getzola/zola), a superb static site generator, with built-in Sass compilation, written in Rust.
To me it reads more like Nebula is a VPN solution, with end-to-end encryption and security groups baked in.
To my understanding, a service mesh does not establish a common VPN-like network, but assumes it's there already. Nebula and service meshes both provide authentication, end-to-end encryption and role-based access control. A service mesh can do more than Nebula: it makes it possible to shift traffic between services for example apart from a "security group"-like filtering.
However, I might be mistaken. Any corrections are more than welcome.
Good point. But that's not limited to automation. As with data engineering, or software development, you're likely to overdo it and build something which does not agree with reality if you "try to build the whole thing" at once. Building the smallest possible deployment pipeline (a skeleton pipeline, as it's called in the continuous delivery book (from 2010 but still the best thing on the topic out there) [1]).
You start covering the most essential needs just so they become useful and usable. Then you go ahead and iterate from there, building something which suits your team, company & product. Learning and adapting in the process.
[1] https://www.amazon.de/Continuous-Delivery-Deployment-Automat...
Great article! A tiny nitpick: the distinction between continuous delivery and continuous deployment, is that in the first case you could deploy anytime your want, but the triggering is still up to a human. With continuous deployment, everything is shipped to prod automatically, given that all conditions are met.
If you want to learn more quickly - I did a talk on the topic last week, and did my best to provide a concise overview of the most essential terms. Check out the slides for a high-level view on ci/cd [1] and deployment pipelines in general [2] if you want to learn more.
[1] https://www.slideshare.net/VladislavSupalov/automated-testin...
[2] https://www.slideshare.net/VladislavSupalov/automated-testin...
That really depends on your project and tech stack. If you're into Python and are going to deal with relatively static HTML, then the Python modules Scrapy [1], BeautifulSoup [2] and the whole Python data crunching ecosystem are at your disposal. There's lots of great posts about getting such a stack off the ground and using it in the wild [3]. It can get you pretty darn far, the architecture is solid and there are lots of services and plugins which probably do everything you need.
Here's where I hit the limit with that setup: dynamic websites. If you're looking at something like discourse-powered communities or similar, and don't feel a bit too lazy to dig into all the ways requests are expected to look, it's no fun anymore. Luckily, there's lots of js-goodness which can handle dynamic website, inject your javascript for convenience and more [4].
The recently published Headless Chrome [5] and puppeteer [6] (a Node API for it), are really promising for many kinds of tasks - scraping among them. You can get a first impression in this article [7]. The ecosystem does not seem to be as mature yet, but I think this will be foundation of the next go-to scraping tech stack.
If you want to try it yourself, I've written a brief intro [8] and published a simple dockerized development environment [9], so you can give it a go without cluttering your machine or find out what dependencies you need and how the libraries are called.
[2] https://www.crummy.com/software/BeautifulSoup/bs4/doc/
[3] http://sangaline.com/post/advanced-web-scraping-tutorial/
[4] https://franciskim.co/dont-need-no-stinking-api-web-scraping...
[5] https://developers.google.com/web/updates/2017/04/headless-c...
[6] https://github.com/GoogleChrome/puppeteer
[7] https://blog.phantombuster.com/web-scraping-in-2017-headless...