I've used DO's quite a bit. I'm a big fan... however I find the database latency pretty hard to deal with. In the past 6 months I've seen upwards of 30s for little side projects running tiny (100's of kb) databases. Sometimes it's lightning fast... sometimes it's a disaster.
As a consequence I've had to build quite defensively - adopting a PWA approach - heavy caching and background sync. My hope is that latency improves over time because the platform is nice to work with.
A hobby project I started putting together late last year; a little spot on the internet for prayer and reflection. I've just shipped a small feature where you get a Bible reading (KJ only for now) in response to a prayer.
A pro bono tech consultancy for local (Stavanger, Norway) non profits. The idea is to help them use tech to better deliver on their mission. Last week I built a little bookmarklet for a non-profit to surface some of their data buried in a SaaS tool ... which will make their apple pressing operation easier.
A pro bono tech consultancy for local non profits. The idea is to help them use tech to better deliver on their mission.
Just today I finished off building a little PWA to help a couple of non-profits offload the admin of volunteer scheduling (mostly done through whatsapp, messenger, etc).
I'd recommend others try the same pro bono consulting in their local area, it's quite rewarding!
I actually quite like the system. They tend to only install speed cameras at high hazard areas e.g. where fatal accidents have occurred. Also the camera's are mostly super visible - bright high-vis yellow, and there are often warning signs as you approach them.
It's quite a different story in other countries at least in terms of visibility!
Their chat about the limitations of optical memory made me think of Magneto-Optic (MO) memory cells [0] that I read about earlier this year. From what I understood (not an expert - so I'm open to correction) we move away from Von Neumann, to something where memory is a "filter" that light passes through rather than a bucket of data that needs to be moved around.
Overall it’s interesting to me that we can trade a bigger size to get more speed.
For anyone looking for an in-vehicle EDC to solve this problem I'd recommend a Keetch tool. I used them in the fire service with great success on the laminated glass of a windscreen. I assume it'd work equally well on a laminated side window glass - though I've not tried. Nice thing is that the sharp spike on it would work quite well on tempered glass too (though we had proper glass breakers for that).
I think the general premise of AI in war is pretty scary. But this in particular stood out to me as an important challenge:
> There are also fears that automated systems will violate the rules of war. How will they avoid harming civilians, or distinguish soldiers who want to surrender?
As it stands we see guerrilla fighters already ignore these rules (ISIS for example). It's a little frightening to consider such groups acquiring and deploying automated machine guns. We need to regulate these kinds of weapons systems much like we do with CBRN weapons.
The poor regulation around this is pretty bad for startups. Personally I've taken to only buying rechargeable battery powered devices from big brands. Anything else and I look for a power cord, single-use batteries, or mechanical operation.
It's not an ideal solution and not just because of examples like the Samsung Galaxy Note7. It's because I love rooting for the startups, the disruptors, the innovators. But in the world of battery powered products I'm inclined to think (or hope!) that the bigger players have more to lose by cheaping out on cheap batteries.
If you want more context on PFAS, I recommend this Veritasium video [0]. It expanded on my usual thought of "PFAS = bad," explaining why non-stick cookware is probably fine while other forms of PFAS are problematic. The video also covers the environmental damage caused by PFAS manufacturing.
After seeing warnings about rustwasm not being maintained [1], I'm glad that wasm-bindgen is still actively supported [2]. That said, it's concerning that many previously recommended practices (e.g. like relying on wasm-pack) are now in question [3]. This makes it harder for devs to adopt Rust for building WASM apps.
There's an interesting planet money podcast[0] about SawStop and why it's not a bigger thing in the world. TLDR: the big power tool companies didn't want to pay to licence the tech, so evidently came to some mutual agreement to ignore it as a feature to save customer fingers.
As a consequence I've had to build quite defensively - adopting a PWA approach - heavy caching and background sync. My hope is that latency improves over time because the platform is nice to work with.