flimsypremise

Been interviewing for over a decade. Tests like this do not really tell you whether someone is a good programmer, they tell you whether a person has spent a lot of time practicing problems like this. The only way to tell if someone is good at the job is to have a conversation with them and pay attention to how they answer your questions. Ask your candidate their opinions on API interface design or whether they favor mono-repos. A good candidate will be able to speak legibly and at length about these things. The problem is that in order to judge those responses you also have to be very knowledgeable. So instead we have stupid little tests designed to let interviewers of varying ability screen candidates.

I've been doing something similar. I started with a 3D printer approach, then two cheap aliexpress C-beam linear actuators and finally managed to acquire a 2-axis microscope stage for cheap. The key I have found is that any issues with alignment can actually be solved with focus-stitching.

The real problem with most scanning setups is actually getting accurate color out of color negatives. The common wisdom these days is to use high-CRI light, but I believe that approach is flawed. Film scanning is not an imaging challenge, but a rather a densitometric one. You don't actually want to take a photo of the negative in a broad spectrum because the dyes in photo negatives were never intended to be used in a broad-spectrum context. You actually need to sample the density of the dye layers at very specific wavelengths determined by a densitometric standard (status M) that was designed specifically for color negative film. Doing this with a standard digital camera with a bayer sensor is... non trivial and requires characterizing the sensor response in a variety of ways.

Basically the hardware is easy, the software is hard.

As someone who has built multiple custom macro film scanner setups, owns basically very consumer film scanner of note (including the Coolscan 9000 and the Minolta Scan Multi Pro), and is intimately familiar with the workings of various film scanners and science of digitizing film, I don't think this article provides particularly good advice.

Just for instance, the LS-2000 features in the post has an advertised optical resolution of 2700DPI, which means the absolute maximum megapixel resolution you can get out of that thing is a little over 10MP. Film scanners are notorious for overstating their optical resolution, which has nothing to do with the resolution of sensor used to digitize the image data and everything to do with the lens in the scanner. You can have a 200MP sensor scanning your film but if your lens can only resolve 1000DPI you will have a very high resolution image of a low resolution lens projection. It's maybe a little better than a flatbed and it features dust removal, but in the year of our lord 2024 the LS-2000 is not a good choice for scanning film.

As for his macro scanning setup, he appears to be using the digitaliza for film holding, which is a notoriously bad product with many known flaws. Negative supply makes a line of lower cost version of their very good film holders, and Valoi also offers an affordable system of components that I highly recommend. There is a ton of good information out there about macro scanning, and had the OP sought it out he could avoided his little adventure in retro computing.

If you really want to, you can have a react app that is just static templates with no interactivity with a simple Node server that just called renderToString and all of a sudden react is just a backend templating framework. If you want to get really fancy you can then re-render specific components on the client side without re-rendering the entire page. You don't need NextJS to do this either, its very simple and straightforward and lets you use an entirely frontend toolchain to do everything.

Very funny that you think a build with an entire CMS involved is somehow "simpler". You apparently have a lot of patience for Django's static asset management pipeline, but I do not.

Modern CSS has _some_ of the features of SCSS/SASS. It does not have all of them. But most importantly, many of dependencies one might want to use also make use of SCSS/SASS downstream. If you're happy to build everything from scratch and eschew any dependencies that require a build system, then have fun explaining to your product person why it took so much time to build a thing that they know very well is a pre-built component in some frontend library somewhere.

What does "most sites" even mean? I do this professionally, and I assume that most of the people replying here do as well. The article we're discussing is written by a professional for an audience of professionals. The number of sites I've had to build that were entirely static with no interactivity I can count on one hand.

What's rendering the pages on the server? Because if its not javascript, and you still have a frontend build, you have a repository with two separate builds, and builds are expensive to maintain. If your containerizing, you need two different containers, each with a dependency management system, a runtime, probably a separate workflow for development and production.

There are many ways to render pages on the server using a single JS builds, most template rendering engines have a node implementation, and most javascript frontend frameworks have a mechanism to render components statically to a string. If we're talking about a simple, mostly-static website, the content is going to be cached so the performance of the backend isn't a huge factor. So just use JS for the whole thing, and save yourself a build.

In web application terms, the "build" is everything that needs to happen to get your application running into production. That means a runtime and dependencies. Speaking of dependencies, does your perfect frontend simply not have any of them? Is every tool you will need to use perfectly packaged with vanilla CSS and ES6 modules? Browser support for import maps is around, but its nothing I would build a production application on. And god help if you if you work in a context that requires support for older browsers.

Maybe in 5 years this will be a practical approach, but there's a reason that old ways of doing thing hang around: they're well-documented and reliable.

Building a web application with a UI in a professional context without a frontend build is borderline malpractice. Even a "thin" layer of JS on top requires some degree of dependency management, and I personally have no desire to go back to the days of vanilla CSS, so you need a SASS/SCSS transpiler. Then there's a lot of handy things that frontend builds do, like normalizing SVG icon formats, automatic organization of static assets etc. The fact is the "islands of interactivity" model still requires two builds.

I don't think the author of this article actually understands the pressures that increasingly drive all frontend development into javascript frameworks, but those pressures are actually very straightforward:

• A large portion of the cost of maintaining a code repository goes toward maintaining the build.

• Multiple builds per repo create significant costs.

• Any web application with a UI _requires_ a frontend build for CSS/JS. Anyone around from the JQuery/pre-SASS days will recall the mess that lack of things like dependency management and ability to control import order caused.

• If the frontend build is already baked into the process, you can save costs by _only_ using a frontend build.

• SPA patterns are the easiest to use with a frontend build, have the most examples/comprehensive documentation.

I have several 2-axis microscope stages from the 80s/90s that are driven by brushed motors with position feedback, and they are all capable of higher accuracy than any stepper motor I have. The capability was there, it was just pricey.

Hell, CNC machines existed back then too.

If the microservice has dependencies on other services it is not a microservice.

what company have you ever worked for that was happy with the current rate of progress in software development?

I'm shooting to do 35mm and medium format. 4x5 is a stretch goal. Even illumination is definitely a challenge, though I use the same technique you do, which is generally refered to as flat field calibration, where we capture the field of light without any target and use it to calculate the offset to apply an even field. One of the trickier aspects is finding affordable lenses with appropriate magnifications that can focus evenly out to the edges of the frame. There are various lenses pulling from scanners or that were specifically used for copying that are useful if you can find them.