Mostly just has my (tech-focused) blog, although there are aspirational placeholders for the important things in life, like coffee and homemade pizza.
It has been hard to make time to write personal blog posts since my second kid was born, but I have a couple of drafts in progress that I aim to work up soon, at least when I take time off work.
I will! cleaning up now and going to publish it later on github. The main idea was a least privilege approach to running simple desktop applications independent from the host OS and being able to control filesystem/network access on a per app basis. (spotify on fedora without flatpak or rpm-fusion repo's, not even sudo needed to install)
No real need for full Flatpak, Bubblewrap (bwrap) is intended to be a lightweight sandbox providing this out of the box, with Flatpak (and other stuff besides) building upon it. The Arch wiki has a nice introductory page: https://wiki.archlinux.org/title/Bubblewrap
Oh didn't know about bwrap yet! If i understand the wiki page correctly, you still need to get those binaries to your pc. So thats why i went with plain and simple dockerfiles.
We did consider sharding PostgreSQL and opted for something that would be fully managed for us to minimize our management overhead. Managing sharded databases can be complicated business and that wasn't something we wanted to take on if we could avoid it.
I dug back through our design docs from when we designed this, and we largely chose not to use Cloud Spanner due to unknowns. We were more confident we could predict the read and write performance in BigTable (especially due to the constraints you get when you drop relational features).
I mean, it depends on criticality. If something is critical, pushing further along the formal methods spectrum makes sense (see also: why AWS has done a lot with TLA+). Sure, we probably won’t verify all of Instagram, but super critical portions of the platform underlying it are likely worth it and would save money in the long run by reducing outages, bugs, etc.
I'm fond of formal methods, but I'll offer the usual counter-example:
Formal methods struggle to scale up to real-world problems. There is no formally verified TCP/IP stack. There is no formally verified TLS or SSH implementation. That's despite how immensely useful and reusable such implementations could be (that is to say, high demand, and yet no supply).
As I understand it we're not even close to being able to develop a formally verified TLS implementation, but if we were, it would likely take the form of an internationally acclaimed PhD thesis, akin to CompCert. It still wouldn't mean formal methods are cheap and easy.
It's astounding that core security infrastructure isn't formally designed and certified, and isn't available as standardised - certified - drop-in elements.
A top decile PhD thesis is not a high bar in engineering. It's how most disciplines evolve. "Not invented here" is not a credible explanation for why CS feels a need to be different.
There’s a spectrum of formal methods and with the push toward static types in Python coming directly out of industry I would argue that industry is definitely deeming it important in some degree; the question is to what degree. Right now a lot of the time it’s only worth it for the most critical systems (S3, for example, but not my side project webapp) but if tooling improved, it would be worth it for more cases.
> When all the software companies went full remote, they just took a break from hiring juniors (!).
This isn’t true at all. Where I work, we hired more junior engineers than ever before during the pandemic. We were hybrid colocated/remote (mostly colocated, plus me!) in the before times. We had certainly hired juniors before, but we hired a lot more and we’re able to source them from all across the country. It’s been fantastic, and onboarding and training junior engineers remote isn’t the impossible task people make it out to be.
And I'd say it was common, at least before the pandemic. Our remote-first company rarely hired very junior engineers, partially after a little trial and error, including finding that hiring someone who already had remote experience would typically have a higher chance of succeeding. Not that it was required, but it was a better guarantee that things would generally go pretty well.
On the flip side: we've also had one experience with an absolutely fantastic junior contributor, who we got as an intern. Unfortunately, this person wanted an on-site experience, and we couldn't give it since we are fully distributed.
Having better techniques and approaches to help get junior developers more engaged, trained, and leveling up is good, but there are a lot of intangibles - including the social aspect - that simply don't work great for many young people fresh out of college or other training.
If you've been watching the stats then you should have a citation on hand to show some of those statistics, otherwise your comment sounds dismissive and condescending to the person you are replying to.
In addition, since you made it sound like your hobby is compiling these statistics but didn't bother sharing them, it makes me think you haven't actually been following anything and are full of it
I'm not dismissing ntietz. I'm only remarking on general trends. It is a hobby of mine to watch programmer job trends and I'm in the process of compiling my new report for 2021 right now.
This is often a requirement of grocery stores where they intend to sell it, who don’t want to have stock that isn’t salable after two weeks (it can take the big groceries longer than that to just distribute it to their stores).
Mostly just has my (tech-focused) blog, although there are aspirational placeholders for the important things in life, like coffee and homemade pizza.
It has been hard to make time to write personal blog posts since my second kid was born, but I have a couple of drafts in progress that I aim to work up soon, at least when I take time off work.