Unopiniated variable binding

I'm a bit crazy. I like vanilla front-end work. I just like it when you do not need a compile step and what you've written is what is executed. I've always been like that, even when it made a lot less sense than it does right now, like in the times of Internet Explorer and browsers having lots of incompatibilities and some not supporting standards well at all.

In the light of using vanilla javascript, seeing the technology making progress is really nice. Sometimes, that means that you get shiny new tools built into the browser. Other times it means that you no longer need a library to do what you were already doing. I loved learning about document.querySelector(), as it covered one of the two things I used jquery for. The other thing I used it for was later covered by the fetch api. Learning about css variables was far more exciting to me than learning about the css preprocessors of the time.

When I do use a framework (for personal projects), I like using something that isn't very opinionated. The big front-end frameworks generally tell you how to set up your whole project. I prefer something that I can introduce in that one place if I want. And if the project grows big enough, I will refactor it to have a better structure. I probably end up with something similar to what the frameworks prescribe. Or I might end up with something slightly better or a lot worse. In any case, it'll probably be more tailored to my project.

In the past few years, my goto front-end framework has been Knockout.js. When I was first introduced to it at a previous job, I thought it was just another AngularJS with a slightly different syntax, but in the years after that I started appreciating it for how unopinionated it was. There was one major part of its usage that I didn't like, but adding knockout-es5 solved that. The es5 library doesn't work well with knockout's component functionality, though, which is essential once you start refactoring. So I wrote a script that worked around that. The script was a quintessential hack: it does some pretty ugly manipulation and leaves things in a state where it usually works. Together, all of these basically gave me what I wanted: unopinionated variable binding.

The time to let go of knockout has been steadily approaching for a while, though. There really hasn't been much development of the project for years. The project's website has had trouble several times recently. There is tko.js which aims to be the next version of knockout, but development seems stalled in an alpha state and it doesn't actually address most of what I want to see changed. I just don't really see a path towards not needing the knockout-es5 or my own script on top of it, and both of those feel more like temporary fixes than true solutions. For projects that I expect to live for a long time, it just doesn't seem to be sustainable enough to keep using it.

Recently, I have been working on a very old project. This project is built around the google maps API. Because of that, it doesn't actually do a lot of html manipulation. So, even when redoing most of the project six years ago or so, I just did that little bit of manipulation in vanilla javascript. But now I'm adding features, and some of those do require a lot more manipulation.

That sent me into a bit of a panic. Not using a framework was starting to weigh down the project. Using knockout doesn't feel like a sustainable option, but other frameworks are much more opinionated than I like. Even the ones that are minimal and/or proclaim not to be opinionated require you to work in components and thus don't just drop right into your project to do that one task you need from them. I felt like I was at a crossroad with none of the paths leading where I wanted to go.

I think I have a solution, though. I started looking at WebComponents recently. It's a collection of three javascript APIs that are mostly used by frameworks. That's because using them without one is complicated and doesn't really manage to compete with using a framework. I have been using two of those APIs to prototype what is basically my own framework. It provides the unopinionated variable binding that I was looking for and not much more than that.

It's only some three hundred lines of code, but it's able to bind variables to text, attributes and events, and it's able to repeat parts of your html or remove them. About a third of the code is dedicated to a solution for tables, as the default looping solution clashed with the way those are special in html. And because it is built on top of WebComponents, the system to upgrade to when refactoring is built right in.

There's definitely more to be done. When you use the prototype incorrectly, it doesn't tell you what you need to change. There will probably also end up being more things that the library needs to do to. But I do believe this pretty small prototype already covers most of what I want.

I compared total byte size of my prototype to Alpine.js (just because it came up in a search for small frameworks) and the byte sizes are about the same. That's more impressive than it sounds, because we're comparing a minified and gzipped version of Alpine with the plain sources of my prototype. While size comparisons aren't actually that useful, size does matter. It matters in how sustainable maintaining the code base is. It's also a part of how close it is to vanilla javascript, which is a part of how it stays unopinionated and how it can interoperate with existing codebases and other frameworks. For neither of those it's the whole story, but it is an important part of it.

I think I'll be using this for the time being. And I'm starting to think that a version of this may end up being my tool of choice for a long time to come...

Christmas Tree Project Step 4: Improving the Mapping

Last time, I got the first 3D mapping of the LED coordinates. I wasn't entirely happy with the results, though, so it was time to improve them. So, I started by working on code that I could use to verify the results of the scan. The idea was to turn a few LEDs on at a time, so you can visually verify that those LEDs are in the right order on one of the axes. However, while the y axis is completely obvious, the x and z axes aren't visible in the real world, so that was the first thing I did: create a gradient from red to blue on one of the axes so you could identify the axis.

The x axis

From there, I turned the lights green one by one according to their order on that axis. My original idea was to turn just the light after it and the light before it on, or perhaps a few, but I ended up just turning everything on, with the ones that were before the green LED being red, and the ones after it blue. Then, you could press either space if the LED appeared to have the right coordinate when it came to that axis, or x if it didn't. The software would then remember the incorrect coordinates and write them to a file when done.

Verifying the green LED

A modified version of the mapper can now also be used to scan only the incorrect coordinates. In that case, it will read which LEDs need to be rescanned from the file. It then scans every such LED from all four directions, but only updates the coordinate components of the axes marked as incorrect. With those changes made, I got back to the physical tree and got working on my new coordinates.

I decided not to use my previous mapping results, but start over instead. I had marked the position and orientation of the tree and the camera stand hadn't moved, but the camera wasn't in it in the exact same way. The way the webcam was mounted on the stand was a bit improvised and the webcam was borrowed from my work setup, so it hadn't stayed in the stand and the result was that I didn't put it back in the exact same way.

Improvised does not mean bad!

So, I took a few pictures with the new setup to get the tree properly in frame again and then started scanning. I alternated between judging the coordinates and rescanning them several times until I ended up with something that I was happy with.

Deciding what LED was wrong and what wasn't always obvious. When two LEDs are in the incorrect order, this method just isn't great for determining if the first one or the second one was wrong. When there are more LEDs involved, it gets even more complicated. I did develop a bit of a feeling for it, I just chose for rescanning more than necessary in a number of cases and I restarted the verifying process without saving the results a number of times. I could probably improve things by allowing you to go back in the LED order as well, so I will probably do that if I end up mapping another tree.

I was also important to learn that the result just wasn't going to be perfect. Slight changes in perspective can have big results, and we're already combining several perspectives into one coordinate. Whenever two LEDs were a close call, it was best to just go with whatever result the scan had. The mapping wouldn't be perfect, but it was never going to be perfect and as long as it's close enough, it'll look good, especially considering that the viewer won't have a fixed perspective either.

Finally, there was one LED left that just didn't get a good scan for its Z coordinate. I checked the photos and saw that it was indeed on, but just wasn't visible from either of the two opposite sides. I decided to just set the coordinate manually, so I lit it up as well as some LEDs around it. I identified which were its closest neighbors and gave it a coordinate between them, which I manually put into the output file.

With the new mapping, the next thing to do was of course to run the test effect again. I think the actual changes were relatively small, but the whole effect looks a lot more smooth to me...

(Well, I promise it does in person, at least.)

As before, all the code I wrote for this project can be found on GitHub.

Is the this the end of this project, then? Not just yet. The basic setup is done now, but I do still need to run effects on the thing. I am planning to both write some of my own and run the ones submitted to project that serves as inspiration for this one...

Christmas Tree Project Step 3: Mapping

Spoilers of what I pulled off

With the hardware gathered and the lights working, the next step was to put the lights in the tree. I took a bag of zip ties that I think I bought with the intention of using the for cable management in my computer (I bought way too many, though). For the most part, this was pretty uneventful, but there were a few things that I would do different if I'd do this again. The first is that I would plan it more carefully and use more zip ties and attach in more places. The second is that I dislike the colored wires between the lights, so I think I would sleeve them in something green to make them stand out less.

The colored wires do stand out...

I also wanted wifi on my raspberry pi, so I wouldn't have to run a network cable to it. As I realized last time, the device itself doesn't have wifi hardware, so I went looking for wifi adapters. I found two. Both are old and were probably cheap, but they were worth a shot. The first adapter didn't get recognized by the Raspberry Pi, but the second one worked well and after some messing with the configuration, I was able to freely move the device anywhere I had power.

Getting wifi running

The next part was the real challenge: mapping the LEDs to three dimensional coordinates. I did actually send an email to Matt Parker to see if he could share the code he used for this, but unfortunately, he didn't have it in a usable form. Not wanting to wait, I started working on my own.

Getting the camera to take a picture was both easy and hard at the same time. Basically, copying some code from the internet and saving an image wasn't that hard. However, there were basically three libraries to choose from, and none of them was exactly what I wanted and I definitely didn't like that you have to install non-python dependencies for each of them. In the end, I went with pygame, which uses sdl2 under the hood.

My complete mapping setup

There were also several issues with the camera that I had to solve once I started using it more extensively. The first was that the first photo would often have different brightness at the top than at the bottom, with a clear dividing line about a fifth from the top. However, this didn't show up at first, as it starts happening when you run the program more than once. I solved this by taking an image from the camera on startup, discarding that and then working only with the images taken later on.

The next problem was something I started noticing when I was working on the mapping: the photos taken were often from well before I gave the command, sometimes by ten or more seconds. I got around this by re-initializing the camera every time I wanted to take a picture, as then the picture would always end up being current. To prevent the previous brightness issue, though, I had to discard an image each time I did this.

With the camera working, the next step was to start identifying the LEDs and their location. The idea was simple: turn on a LED, take a picture, identify the brightest pixel in the picture and repeat this for the next LED. I also added a step of drawing some lines on the picture, so I could see the result.

Pretty orange lines

The first result wasn't bad for some of the LEDs, but just going with the brightest pixel didn't quite work for others. So, I changed my code to take the average of several bright pixels. My first implementation was quite bad and allowed a gradual increase in brightness to shift the average towards the top of the image. But even after fixing that, the results weren't to my satisfaction at all. So, I decided to take a different approach. Instead of looking for the brightest pixels, I just look with pixels that are above a hardcoded brightness.

For the most part, that gave pretty good results. However, when a lot of light was being reflected, the reflection of the LED would sometimes throw off the calculation. The way I solved this was by lowering the brightness of the LEDs. Originally, I had assumed that full brightness was a good idea, but in the end about 20% brightness gave better results because there were far fewer reflections that were bright enough to be taken into account.

Next, it was time to do multiple scans and combine the results. Doing multiple scans was straight forward: just put the code in a function and all that function four times, with a bit in between where tell the user to rotate the tree. For combining, I gave each mapping result a score, based on the brightness and on how many pixels were involved. Then, I took the y coordinate from the highest score on any of the four scans, the x coordinate from the best among the front and back scans and the z coordinate from the best of among the left and right scans. And those results I printed to a file.

In order to check the results, I quickly threw together some code that read the file (this was basically a copy-paste job from Matt's code) and then changed the color of each LED in order of either the x, y or z portion of the coordinate. And I must say, I'm not at all displeased with the result. It's not perfect, but it's quite good, especially if you consider this was based on the first time I did a full scan of the tree.

There are still LEDs that pretty clearly have inaccurate coordinates. So, that's what I'll have to do for next time: build the tools to see what LEDs are wrong and correct those...

Oh, also: my code is now on GitHub.

Christmas Tree Project Step 2: The Lights

Last time, we left off with all supplies gathered. Now, it was time to wire things up and get the lights lit up in some pretty colors. First, though, I had to solder headers onto one of the breakout boards. Soldering isn't something I'm great at, but this seemed like a manageable task.

Headers

With that behind me, I could start wiring things up. My first try was to just connect the power wires to the lights. But the result was nothing. However, I didn't know if this was because I had made a mistake, or that they just wouldn't light up until there was a data signal telling them to do so. So, I took out a Raspberry Pi that wasn't doing anything at the moment. After spending way too much time on things that should have been simple (like trying to configure wifi on a device that doesn't have wifi), I managed to get things up and running.

Here, I used a little bit of a trick. In order to make it work. In order to make two power supplies work together nicely, you need to wire up the Grounds. However, the Dupont cables I was using didn't have an easy way to go from the breakout board to the lights and to the Pi. However, the Pi has multiple Ground pins, which are wired up internally, so I connected the Lights to one of them and breakout board to another, basically letting the power flow right through the Pi. Unfortunately, nothing happened yet again.

Nope

Still nope

Now, it was time to do some debugging. I wasn't even sure if I had gotten the right one of the two connectors, so I messed around with that for a bit, but to no avail. Then, I realized that I could just get rid of the power adapter and breakout board for a bit. As long as the power draw wasn't too high, powering the lights from the Pi's 5V rail shouldn't be a problem. And indeed, I got things to light up!

My one LED program works

This meant that the Pi, the code and the wiring were all good. The problem had to be in the adapter or the breakout board. I should probably have gotten out a multimeter and started measuring. I decided to try something else: powering the Pi from the breakout board. This could definitely potentially damage to Pi, I went with it anyway. And I did see that the Pi's power LED only powered up when I was touching the ground pin on the breakout board. Apparently, I had done poor job soldering and there wasn't a good contact there...

Green across the board!

After making sure the soldering job was done properly this time, I hooked things up again. And I got the lights to turn on this time. It seemed that the hardware part of it was done now. And because programming is what I feel comfortable doing, I was quickly writing several effects. These weren't actually getting me closer to my Christmas tree goals, but I liked doing it nonetheless.

The effect that I liked the most was one that picked a random color for the first LED, and another color for the last LED without changing the last LED just yet.  Then, it gradually moved through the lights in the order of the wire to turn them a color that was slightly closer to the color for the other end each time. Once done, it would pick a new color for the first LED, and do the same thing on the way back. I wanted to include a video of that happening, but the effect didn't show too well on video and there were also some interference patterns causing lines of darkness. So, instead, a picture of each LED in a different random color will have to do.

A poor substitute, I know...

Next time, I suppose I'll have to start involving the actual tree.