killcoder

The plugins system has been extremely valuable to us, and the hoisting / peer dependency behavior has been consistently correct, where other package managers have caused bugs.

It's used in the aho-corasick and regex crates. It now supports SIMD acceleration on aarch64 (including Apple's M1 and M2). There are some nice benchmarks included in the PR demonstrating 2-10x speedups for some searches!

I'm searching for songs like Anotherclock by Parcels.

The first one is this ambient electronic song, the next is some reggae, which don't feel very similar to Anotherclock to me.

How does it determine acoustic similarity?

https://news.ycombinator.com/item?id=37545040

Thank you for your kind words!

> I don't comprehend how you made no mistakes on the journey after drafting the PCBs and writing drivers.

As jacoblambda said below, it's about making mistakes recoverable, and failure modes graceful. Scott put a hell of a lot of effort into planning and design, making sure in the end we could get what we needed out of the hardware. During the process, there's a constant stream of problems that are fixed or worked around in pursuit of the end goal. One nice thing about this kind of project is the scope is fixed and known, and scope creep won't happen. We can build safe guards for attaining the known scope instead of predicting future scope creep. Originally we wanted a turbidity sensor in there as well, but we just didn't have the time to get it working.

On one of the boards we reflowed, something happened with the solder paste (it was probably a bit old) and it started exploding (in a small way), sending components flying across the board. Scott had to jump in with tweezers and put stuff back in real time on the hot plate. Unfortunately I had the macro shot set up for the other side of the board so I didn't get to capture it.

Shooting the top down macro shots, it would take literally 6+ minutes for the rig to stop wobbling visually in the footage, so every top down shot is 6+ minutes of swaying footage before the action. It took so long we only did a couple of these shots.

We thought it would be very dark underwater, and brought a camera that could do 12800 ISO base, but it turned out it was actually surprisingly bright on the day, and we ended up way down at ISO 640 for the shoot.

We couldn't get the camera to focus underwater when zoomed to a focal length of 70mm, so there's a whole setup of footage that just didn't work. But since everything had already been shot at 35mm, it wasn't a big deal in the scheme of things.

The camera rig was incredibly buoyant underwater, I had to steal weights from our other divers just so I could get neutrally buoyant.

> Why not make "the perfect espresso machine" or "the perfect bike" or whatever? Why not, with your skills, make a thing and fucking sell it?

I think I can sum up my personal drive as "I like making things", essentially no matter what the thing is, be it hardware or software. I saw that "inventor" character in the movies, and that's who I wanted to be growing up. In most engineering jobs you'd probably be happy to spend 20% of your time making stuff, with the other 80% spent in paperwork. We're trying our best to flip those percentages for ourselves.

We've worked on several projects with hardware together over the years. From multicopters, to camera gimbals, to an entire space ship set for a short film. Time and time again, we found ourselves building user interfaces from scratch, and that was amongst the hardest parts. So we figured maybe there's a business here, and we started Electric UI - tooling for engineers to build user interfaces for their products, both during development and for production. Selling software must be easier than hardware, right?

It turns out it's unfathomably difficult to market products effectively to the right audience, especially if you don't have millions of dollars to blow on targeted advertising. We're constantly seeing the success stories of good marketing and we intrinsically don't see the thousands of shots that didn't work out. There's just a lot of luck involved, hitting the right people at the right times, even assuming you have perfect product-market fit.

We figured our best chance is to go back to our roots and just build stuff that we find interesting, and document the process. Hopefully people will come along for the ride, and other engineers out there will see our user interface software and the next time they're building something that could use a UI, they'll think of us.

sirrandalot on YouTube used the Cycles path tracing renderer in Blender to create a virtual camera setup that acts like a film camera. Light rays pass through modelled lenses, individual colour film layers are simulated in shaders.

https://github.com/orlp/glidesort

Originally this post was much longer, but I've split it into two, and I'll release the second part once it's finished soon (hopefully in a couple of days).

This was sparked by Preact Signals monkey patching the renderer in their React package. I thought that such a high maintenance cost decision surely conferred huge performance benefits, when in fact it does not! Though I don't show it in this specific benchmark (it's in the next post), it's more performant to subscribe to the signal and update a regular useState hook in the component, no monkey patching required.

I think it's helpful to see that these text updates are taking on the order of <20 microseconds on 10 year old hardware, so upending your entire state management solution in pursuit of better performance might not be a sound compromise.