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.

I'm currently doing something similar to build a photographic film scanner. I will say that I've found that moving the optics is generally much more error and vibration prone than moving the target. I'm actually using a 2 axis microscope stage as the basis for my scanner, ironically enough, and CNC spindle z-axis for focus.

In NYC I can tell you that the metropolitan area lost about 500,000 people since 2020, added ~20-30k housing units per year in that same time. The vacancy rate somehow dropped dramatically despite this and rents also rose dramatically. I've yet to see any good explanation for this, yet you'll still see people advocate for building more housing as the solution.

Simply using the rental vacancy rate as a proxy for supply and demand does not work, since there are lots of factors that can affect vacancies. One of then, as outlined in the article, is landlords keep units off the market to drive up prices.

yeah because now that we've all been asking about it, that answer is in its training data. the trick with LLMs is always "is the answer in the training data".

Because I don't want to pay monthly for a bunch of content I probably won't read. I want to pay a small amount of money, with as little friction as possible, for the specific content I want to read now.

Yes, there's actually a very good test for a properly inverted color negative. You need a negative of a greyscale step scale from light to dark. If the color channels are properly linear relative to one another in the scanned image, you should be able to white balance any one of the patches and have all of the others remain neutral: by which I mean each patch should have equal amounts of red blue and green. In practice the characteristic curves of film often mean the darkest and lightest patches are often slightly more green or red, but its very close.

So the process would be, using the RAW scan of the image (the orange mask intact):

1) Invert the image.

2) White balance on any patch.

3) Sample the color balance of every other patch. They should have equal amounts of all colors.

Yes, you do actually need to do this. You basically need to calibrate every sensor to ensure that the correct wavelength of light ends up in the right channel.

Technically, yes. I know a few people have done it. In a practical sense it is very difficult and you are unlikely to get it working without a lot of trial and error. The tricky part is that the IR image needs to be perfectly aligned with the rest of the image data, which introduces a number of difficulties.

• You can modify a sensor for IR, though this is often a costly and difficult modification. But even if you do so, the IR focal distance is different from the visible light focal distance. So for every shot you need to refocus for IR, but also ensure that the refocussed IR image is exactly the same size as the visible image.

• You can use another sensor that is sensitive to IR, but its probably not going to have the same resolution, you're going to struggle to somehow have both cameras see the target image, and then once you get both exposures, alignment becomes a problem.

So yeah, doable but non-trivial.

RGB scanning doesn't actually expand the color gamut, but removes erroneous color information. If you use white light you end up recording color information from the dyes in wavelengths outside of those that RA-4 paper is sensitive to, and which the color engineers who designed the film never intended it to be used with.

So I wrote an article about this a few years back and also developed a custom RGB light for my own scanning:

https://medium.com/@alexi.maschas/color-negative-film-color-...

There's also some proper academic research into this subject going on currently: https://www.researchgate.net/publication/352553983_A_multisp...

One thing that's important to note about this process is that the idea is not to _image_ the film, but rather to measure the density of each film layer and reconstruct the color image from that information. This is a critical realization, because one of the most important things to know about color negative film is that the "color" information in the negative actually only exists relative to the RA-4 printing system. Negatives themselves don't have an inherent color space.

Cool to see someone else working on this though. I actually considered those drivers for my build, but I ended up building a very high frequency, high resolution PWM (30khz/10bit) dimming solution with TI LM3409 drivers. It's very hard to get uniform light as well so I ended up getting some custom single chip RGB LEDs.

https://i.imgur.com/BVM9p6Q.jpeg

https://i.imgur.com/5oozHnN.jpeg

I've been working on this for a few years, and what I will say is that there's actually another level of complexity beyond just implementing the light. There's a lot of testing to ensure that you're getting proper linearization of each channel, and there's still a color crosstalk problem arising from the misalignment between the color sensitivity of most modern digital cameras and the bands that are used to scan color negatives. It requires some additional tweaking to get all of the color information in the correct channel. You can also very easily end up saturating a channel without realizing it as well. Oversaturated reds are a common occurrence in RGB scanning.

I'd also note that the wavelengths you should shoot for are more along the lines of 440nm 535nm 660nm, which correspond to the Status M densitometry standard. This standard was designed specifically for color negative film.

This is how I mostly do interviews. Get the candidate talking about their previous roles and see how they talk about the problems they've solved and what that reveals about how they see the job.

I'm going to give you all a bit of very real advice from a very senior engineer. The premise of this discussion is based on a fundamental misapprehension of what the job of a software engineer is about. The amount of time you get to spend finding fun optimal solutions to optimize individual operations is like, 0.001% of your career. Most senior engineers, even those without a background in advanced math, have an intuition for optimization patterns over years of solving problems, and often the reason something has not been optimized for speed is not because nobody knew how to do it, but because speed was not a requirement.

The sort of engineer who can define the requirements of a project and execute based on those requirements is much more valuable to me than a algorithmic prodigy. Seniority is not defined by the mathematical complexity of the problems you solve. Focus instead on design patterns and best practices, scalability and maintainability concerns, mentoring of more junior teammates and the buildout of tooling that helps ease the overhead of working with the codebases under your purview and the development, deployment and testing of that code.

It's not super surprising that LLMs perform well on standardized tests, given that they have a lot of standardized test related text in their training data. There are a lot of claims out there about the zero-shot ability of LLMs, and very little specific research to back it up. Until now that is.

This was very funny to read because as someone who is actually familiar with these JS builds I immediately guessed that a dependency had changed. That's literally the first thing I'd check if an app is behaving differently in a remote environment than it is locally. I'd recommend the OP learn some JS best practices and apply them rather than complaining that JS isn't C.

Congratulations you have just invented yet another query language with the special fun addition that the result is non-deterministic.

5 years to get a wrap_comments feature stable? I sometime wonder if people read the things they write?