News for hackers. Stuff that matters.

bayjorix

I recently set up Immich as a backup to Apple Photos, but the mobile app had trouble with my library (120,000 images and 4,000 videos, about 1.6 TB).

I've stumbled on Immibridge which solved my exact problem perfectly, and uploaded the images overnight

https://github.com/emerysilb/immibridge

Re:The contagious visual blandness of Netflix on Sunday January 22, 2023 @02:02PM (#34481022)
This trend started when the first video-capable full-frame DSLRs appeared on the scene about a decade ago, and they led to a mixing of the visual language of photography and filmmaking. Combined with the fact that camera lens developers are working hard to remove flaws from their products, making their picture more and more perfect, but also removing any character a lens can have.

The classic Super35 frame size is more akin to APS-C in digital photography, whereas the new top tier cameras use full frame sensors, which are 1.5x larger in diameter.

The larger the sensor, the more bokeh you get, with a shallower depth of field.

Modern tech for focus pulling allows for extra shallow depth of field even if the actors and the camera are moving. Something that would have been mostly out of focus footage 30 years ago can be easily shot with a small crew.

Large aperture photography lenses and large sensor also means much better low-light capabilities. Which means you can shoot with less studio lights, in a much lighter setup with less crew, less planning etc.

Blurry backgrounds also allow for cheaper sets.

Which means the cheaper the production budget is, the more likely they'll go with shallow depth-of-field shots.

And we the viewers will inevitably connect the cheapness of production with these visual cues.

In contrast, when an older movie had shallow depth of field scenes, those were expensive shots that had to be carefully planned, and painstakingly executed with "flawed" optics which gave them a lot of character.

Right. We gave a lot of thought (and iterations...) to why those tools felt like they are holding developers back instead of making them faster, and why were they ultimately abandoned.

We believe the answer is that one-way code generation is a trap: if you export code from a tool which cannot be edited by a human and then read back into the tool, it is going to end up being edited by a human anyways, but the tool will be abandoned for that file / project.

So we made it our number one priority that Utopia must work with any valid javascript/React code. There is a happy path where we can understand a lot of that code and populate the inspector and enable editing on the Canvas, but even if you veer off the happy path, Utopia is still going to be able to parse/preserve all of your code, and render it on the Canvas as well.

This means that if an application gets complex and a team of people start working on it, making refactors to the code, write complex components, add any kind of state management, etc, people on the team who use Utopia will still be able to open the code and make changes to the design.

One thing hugely working in our favor is React and its functional reactive component paradigm. If you look at an individual component, the JSX part is just about parseable enough for us to be able to reason about it and update it while preserving the javascript code that surrounds it. This means we can avoid printing ugly machine-generated code around them to be able to track the changes. ( for example we don't need to litter the code with markers like <!-- 53170a63-315f-4bb0-9f32 --> ) Plus, as React applications grow in size and complexity, most of the individual components remain small and simple. This means that if you open a real produciton React app in Utopia, there is a good chance you will find leaf components that are used for the actual content rendering, and you will be able to make changes to those without creating a mess.

Thank you! I'm one of the developers working on Utopia.

> I saw some visual builders for React , downloaded/tried a couple but they had pretty big learning curves of their own so I didn't bother taking it any further.

This was our experience with existing low code or code generating design tools as well – you actually have to put a lot of time into learning how to use them, time you could spend on learning actual React.

One of our guiding principles was that people who use Utopia should not need to learn anything that is proprietary to our platform.

The important difference is that those cars were designed for you to steer and brake it without assistance. Different gear ratios and such.

I had to drive a modern car home once with the power brakes malfunctioning and I couldn't exert enough force (grabbing the steering wheel to give me leverage) to have safe braking power. I ended up going very slow in the emergency lane of the highway in second speed so that motor braking could help me stop. It was not fun.