Didn't have much time to work on WebTurtle after my holidays and so it got parked for now (work is pretty busy and any spare time went into the AnyKey project, sorry if someone was waiting for that interpreted version, its not happening as soon as I thought. Codewise it was getting close and doable, but timewise I've got other things planned for the rest of this year). I'm certain I'll need to finish the gui part of firmware upgrading in the configurator and push some updates once all backers received their anykeys and find some good feature to add, so that's something that will take time in the near future. And once the whole anykey kickstarter is done (which was made especially hard due to covid-19) I've got a full plate in restorating our newly bought home.

We finalized stable enough firmware on the AnyKey hardware but our supplier refused to flash them at the factory (or rather they kept on insisting it didn't work because they wouldn't use an ICSP to flash our firmware and only wanted to try it over usb which ofcourse doesn't work as we have a custom secured bootloader).

Long story short, getting ready to ship for our backers meant manually opening and flashing each AnyKey by hand. I've spent quite a few of my weekends and holidays either flashing microcontrollers (literally hundreds of them) and writing manuals and installers to make it all user friendly to a point where you can call it an actual product. This week however we're putting them on the mail so the hard part is finally over. I'm glad we didn't wait longer before getting all items shipped from china to belgium and decided to go the 'were doing it all ourselves route'. If we had waited one or 2 weeks longer most likely the whole deadline would have been blown when belgium went in lockdown. Instead we met our goals and deadlines.

We switched to full color logos by doing a webpoll which luckily went ok. However for our next iteration of the AnyKey hardware I'm looking at better and cheaper alternatives like the stm micro's. Somehow the 8 bit microcontrollers stagnated in price and all the 32bit ones are getting bigger, faster and cheaper than their 8 bit counterparts.

A good example of this phenomena is this stm32 bluepill ducky clone ofcourse we want something more portable in size and we'd need another whole round of weekends programming in c++ to get all the features ported. But it should be easier as we're not constrainted by the low flash and memory of the atmega32u4 anymore. Actually the only real thing that puts me off is the bootloader on those things (yes there are some to be found but most are either binary/proprietary or a big ball of c to untangle again in order to make something clean and secure). We will need to find sources for a good usb bootloader that works on all systems without driver issues before we can replace our current hardware.

Ow another interesting project I played around with recently was this minimal c++ build system for android apps from cnlohr Raw Android. I patched it so it worked on my aging One Plus One on api level 23. And it looks promising indeed solely for the small filesize and fast building (less than 60k for an entire app that does full screen drawing, and has multitouch+gyros and some perlin noise rotating in 3d).

Apart from that, my regular office work was really busy and I've been polishing my python and react.js skills a lot this year which means doing overtime and less time for 'hobby' projects. By now, doing stuff in python seems about as easy as it was in ruby a few years ago albeit on some occasions I still fringe at the utf-8 vs bytestr errors that sometimes pop up when you weren't expecting them. It happens way less than in the python 2.x days but ruby had those bumps sorted more than a decade ago. By just resolving everything to utf-8 and allowing you to choose a different decoding whenever you want to do something special (manually add an encode or force_encoding call in that case) all other normal usecases are covered and you don't run into those. In python now and then you still need to add the occasional .decode('utf-8') to make some cryptic 5 page long errortrace go away.

A recent example of this happened to me last week. When you wan't to use popen to run some process and pipe the results into a dictionary that later gets returned as a json response. Whamo you got a .decode that's absolutely needed because otherwise you might accidentally get the wrong decoding. Honestly, my guess is by the time python 4 is released it won't be needed anymore just like in ruby today, because ruby also had that kind of stuff happening in the early days and after enough developers lost their precious time on those errors. Someone steps up and figures out that just defaulting to utf-8 works better for the majority and issues a pull request to python-lang to make it happen and then a few months after that the pythonics move on and find something else to opiniate on ;).

Another one is the infamous res = "v={}".format(var) vs res = f"v={var}" vs res = "v="+var ;). Imho all 3 ways have their place and are equally useful/clean in certain situations. However, indeed the older versions of python interpreter didn't have f"{var}" so format was the only way to properly do it. And string additions are still not seen as 'clean' due to some python versions having issues with string addition and releasing memory allocated. However, give it some time and probably all 3 versions get their place again just like it happened in other languages. Having said that the nice trick of using .format instead of the other 2 versions is that you can omit asigning it to a placeholder variable and just inline the expression, but again that depends on each case. Incidentally nowadays the f-strings are now the fastest and if you want performance then you should use f-strings. But be wary that inlining a lot can result in an unreadable unacceptable long codeline vs the .format way which might be easier to read in that case.

My react.js skills are getting closer to what I could pull off in angular & vue around 2018 (but I've had about 5 years of experience in AngularJS so that's a big win for ReactJS in my book).

Back to archive