Struggles of a Rust Novice - Annoyances and Stumbling Blocks

Over the past few weekends, I've been spending time investigating more of the Rust language. Along with the web trifecta (HTML, CSS, JS) and OpenFrameworks, this is one of the things I've been meaning to spend some time learning/playing with this year.

It's a funny kind of language, as I've previous noted during my very brief foray into some simple things from last year) - On one hand, a lot of the concepts seem nice/vaguely familiar to stuff I've played with in other languages, making it sometimes feel deceptively easy to use. But then, you go to compile the code, and proceed to spend the next 30-60 minutes trying to find a way to convert various things into the right types that the compiler insists you need. Admittedly, it's quite frustrating work at times (see notes on String handling below), but, it pales in comparison to the blackhole and deranged hell that is web-based dev (i.e. CSS-based Layouts in particular - aaaaaaargh!!! Despite now having "CSS Flow" and "CSS Grid", it seems that CSS Layouts and I still don't get along very much at all). Faced with a choice between the two (and having just done experienced both back-to-back recently), I'd much rather face the Rust compiler anyday.

Anyway, to actually get a proper feel for the language this time, I decided to use this opportunity to bash together a little processing tool that I was going to need for another one of the many projects I'm working on atm:

That is, a tool to take XSPF playlists generated by VLC (and containing a carefully sequenced list of music I've composed/recorded over the past year), extract the filenames (and process them to unpack/extract-out the important identifying bits of metadata I was embedding in the filenames), and then spit all this info out into a more easily consumable format (e.g. JSON).  

Sure, I could've done this all in Python (though it lacks a XML library that just gives me the DOM element tree with no "namespace" tag mangling, etc.), or a mix of VLC + Python (i.e. saving out a m3u list - 1 line per track - then processing that in Python), but this way was going to be more fun (and a good way to throw something a bit meatier/realistic at Rust than the toy-examples I'd been playing with) :)


Hopefully the following post will be enlightening to some people out there - both other newbies stuck and struggling to get their heads around certain things they keep running into, but also for the Rust dev team in their self-professed "ergonomics drive" to lessen the humps that new devs face when learning Rust.

Happy Chinese New Year 2018 - Year of the Dog

Wishing everyone a productive and joyous Year of the Dog!

Silvereye vs Berry - Slowmo & Regular Speed

Yesterday evening, I caught a plump little silvereye blissfully feasting away on a tasty little yellow berry out the back of the house. Amazingly, I managed to stand there for a few minutes snapping away and recording footage through the gap between the window and the windowframe; it may have helped that the toilet was gurgling away nearby to drown out the clap-clap-clap-clap-clap of the shutter XD (hence why I've replaced the original audio with some more snippets of music from my thesis writing collections).

Here is the footage of the birdie in action. First up is the slowed down version (from 25 fps down to 5 fps):

It's comical watching the birdy chomping, twisting, and tugging away like this.

It's also surprising just how relaxed/serene it all looks when slowed down like this (something I've noticed when stepping through the footage of some earlier clips too) - it's almost like we're finally seeing the world at the speed that the birds actually live/experience it! And to think that I only really noticed this after watching the full-speed clip render out at about this speed and realising just how much more interesting it was to watch when played back this slowly... :D


Now, if you're wondering what it actually looks like at full speed, here's the full-speed version:

It looks a whole lot more frantic eh? (And, just to be clear, I didn't speed up the video... they really do move that quickly in real life!)


As always, these were edited in the Blender Sequencer - I still have the same complaints about ugly quirks in the workflow though :(

(Note to self: I must really get cracking on either adding per-strip blendin/out + better font/text support to the sequencer, OR just bite the bullet and put together my own FFMPEG-based "VIM x Node-Tree" video/audio editor project. If it wasn't for the overhead of setting up a new app structure from scratch and then maintaining it, I get the feeling that the latter would almost invariably end up being a better solution in the long run for my particular needs/workflow)

The Battle Against Compartmentalisation - Curiculum Design Challenges

Recently there has been a lot of discussion about the need for ethics courses as part of Computer Science / Software Engineering (or really, any form of engineering) degrees for obvious reasons. While I don't dispute the need for such courses (and indeed, I firmly applaud and welcome the introduction of these as integral parts of the curriculum) experience suggests that we do need to think about how we're presenting such material to students.

Specifically, I have doubts about whether the standard model of "let's just include a course in there to tick that requirement off" is actually the most effective way of doing it. Examples of such courses include "Programming in Matlab", "Ethics", "Security", and to a lesser degree, parts of HCI/Usability/UX. Many of these also carry a bit of added baggage in that they are often designated as "required" courses for a particular degree (more on this later).

From personal experience (and from observing students over many years), topics like this cannot be easily "compartmentalised" into a "tidy little thing that you think about separately from other things". That is, you can't really say, "Here is the body of knowledge you need to know. Memorise it, and pull it out of a hat when you need it". Instead, true understanding and mastery of such material is actually only achieved by adopting the "fundamental mindset" involved. For example, a few crude examples of fundamental mindsets for the aforementioned fields are:
     * Security - Trust no inputs - Treat everything that the "user" inputted as being potentially compromised, and a potential attempted attack.
      - Alternative mindset: How can I hack/crack this?

     * Ethics - How could this go wrong in the worst case? Who could get hurt/harmed, how bad would that be, and are there better alternatives that won't cause anyone that sort of trouble?
      -  Alternative Summary 1: Don't be a jerk
      -  Alternative Summary 2: Would you subject yourself and your loved ones to this? Your mother? Your children/future-children/grandkids/great-grandkids?

     * Usability - Humans are clumsy and stupid creatures of habit (with limited memories, limited attention spans, limited physical capabilities, and a whole bunch of other handicaps).   The problem therefore becomes - how do we try to reduce confusion and/or the potential for things to go wrong so that the bumbling apes can still get their jobs done.
       - Alternative Summary: Could I still use this thing when drunk, sick, injured, all of the above, and I couldn't look up the code/docs to check what's going on?

     * Programming -  Computers are idiots - They can perform complex operations, lots of them, very very fast. But, you have to precisely tell that what to do, when to do it, and how to do it first.

However, you can only adopt/absorb a fundamental mindset if you spend time developing a new a set of skills and/or adopt new ways of thinking about problems.

"Hex to RGBA" and other Colour Conversion Tools for Sublime Text 2/3

Today I'm announcing the first release of a new plugin for Sublime Text 3 (ST2 untested, but may well be supported too, *fingers crossed*) that makes it easier to work with various colour representations in code. As anyone who spends any time working with various colour pickers and colour-related API's on different platforms knows, at some point you're going to have to convert your colours from one representation to another for some reason, and then you suddenly have to waste heaps of time converting and transcribing colour values between different representations. Clearly this can be optimised (we're using modern text editors for goodness sakes!)  So, without further ado, the plugin can be found at the following Github repo:

https://github.com/Aligorith/Hex-to-RGBA

Key Features:
* Convert Hex (i.e. #RRGGBB) color representation to a RGBA tuple (i.e. rgba(0-255, 0-255, 0-255, 0-1))
* Convert RGB(A) tuple (i.e. rgba(0-255, 0-255, 0-255, 0-1)  OR rgb(0-255, 0-255, 0-255)) to Hex (i.e. #RRGGBB)
* Convert individual colour values from 0-255 (unsigned byte) values to/from float (0.0-1.0) values
* Accessible from menus (shown in screenshot), using hotkeys (shown in screenshot too: Ctrl-Shift-R for "Convert to rgba", and Ctrl-Shift-H for "Convert to hex"), and from the command palette (Ctrl-Shift-P - I recommend searching for "hex" or "ub")

EDIT (20180215):  I've just tested it in Sublime Text 2, and it also works there. So, it's safe to say that it works on both now :)