Weekly Head Voices #133: Onder in my Whiskeyglas.

The legendary Koos Kombuis (aka André Letoit) performing with Schalk Joubert on bass and Vernon Swart on percussion in the Helderberg Nature reserve, eponymous mountain visible through the trees on the right. This was a surprisingly amazing end to the week.

What a week.

It was beautiful to see the whole team step up to the plate and engineer at about 110% throughput (software gets complicated quickly, and there’s always one more thing you need to get done before the deliverable is ready), all the while remaining calm and, most importantly, kind.

Pro-tip Special

I was of course the lucky winner of the manual-writing sub-project. I love writing code, but there’s also something quite satisfying about writing documentation for a technical product. Anyways, there are five tiny but hopefully useful lessons I extracted from this exercise which I would like to present here:

  1. I’ve lamented the sorry state of the Windows console before (in 2011 to be exact). In a surprise twist, the Windows console still sucks almost 7 years later. At least it’s reliable. Anyways, cmder is a great console replacement which makes some of the stupid go away, somewhat.
  2. The Windows 10 built-in screenshot facility … wait for it… sucks. When you’re writing documentation you need a tool that fits into your workflow. Keyboard shortcut – window or region – image ends up in a directory of your choice. Greenshot is an open source screenshotting tool that does this with aplomb.
  3. You need to show a CHM (Windows Help) file to the user of your wxPython application when they hit F1. How hard could it be? Well, you could spend a number of hours trying to come up with a wx-y cross-platform solution, or you could use that time for something else worth your while and just use the Python win32 package to call into the official Windows help API. (cross-platform does work, it’s just really ugly)
  4. Sphinx is a much better tool to write technical manuals than is Markdown and related tools. I briefly considered Markdown because I always have to look up reStructuredText syntax, but fortunately ran into enough other places warning against using Markdown for documentation. For the record, I prefer orgmode over all of these puny formats in most other cases, but the documentation story of Sphinx with reStructuredText is admittedly much better.
  5. Start writing the manual as early as possible. It was amazing to see how this helped me to see the software we are designing at a more integrated (user) level. This knowledge was useful in driving more valuable improvements. If you can’t explain the flow of some procedure in a manual, that’s a good sign the procedure might need some refinement.

Humble Book Bundle and Rust

I bought the Humble Bundle of (O’Reilly) Functional Programming Books for a super affordable $15. I was primarily interested in the Programming Rust book by Blandy and Orendorff, but the other titles on Scala, Clojure, Erlang, Elixir, Haskell, Javascript and general functional programming are welcome additions to my library. Speaking of which, I emailed O’Reilly to ask if the books in the bundle could be added to my member library, which they promptly did!

I have avoided Rust up to now due to natural hype suppression circuitry, and because I grew up with C++, but its zero-overhead memory safety and trustworthy concurrency story makes it hard to ignore any longer. Even although Andrei Alexandrescu once called Rust the language that skips leg day, it’s certainly interesting seeing the constructs the language designers have come up to build a really fast compiled language with the lowest number of foot-guns per line of code.

Anyways, when this blog gets published, you should still have about 22 hours to make use of the Humble Bundle deal if you too see something that you like.

Life is continuous practice

I wanted to conclude with something that I’ve been thinking about recently. It has to do with explicitly treating one’s life as continuous practice. As I’ve mentioned before on this blog and people much smarter than me have been pointing out since forever, goals are no good and (lasting) happiness is probably not attainable.

Discarding as many as possible of these sorts of fetters is liberating (you Buddhist), but can seem to leave holes in one’s  life narrative. However, treating your life as a super long practice session is an interesting perspective.

There is also no end point, and no real life goal.

The only point of the whole exercise (yes, I see what I did there) is to try to improve continuously. Every day, we try to become a little better at our jobs, or at running, or at being a good human, or a partner, or a parent.

Practice means that you have good days and bad days. It means that you sometimes look back and think that you were a better person then than you are now. Practice means that when you pick one activity, another will temporarily languish until you can make time for it again.

All of this is ok, because tomorrow you have a whole new day to try again.

Python 2.6 enabled VTK 5.4 Windows binaries

You can always check my Latest VTK Windows binaries page to make sure you have the latest blog posting and hence the latest binaries.  It also links to the “old” Python 2.5 VTK 5.4.1 binaries.

I’ve made available my home-baked VTK 5.4.2 Windows binaries.  These have the new-and-improved version of my python-exception-patches integrated (more about this in a future post; a serious dead-lock has been fixed and as a side-effect, you can now run multiple VTK pipelines in different threads!) and have been built with Visual Studio 2008 (9.0) SP1 on Windows XP SP3 with full Python 2.6 support.  Get the binaries (or my patched source) from the two links below.  You want the binaries if you want to use VTK from Python.

IMPORTANT: you might have to install the MS VS2008 SP1 vcredist_x86 package (free!) if you want to use these DLLs (thanks Jelle for pointing this out).  This might not be necessary if you already have one or more of the MS development environments installed.

Please leave a comment on this blog posting if you use these or just hate them. It’s almost like postcard-ware, but with blog comments. Please also link to this page and not directly to the download location, thanks!

To use this from Python, you need to add the following to your PATH:

  • d:\opt\VTK\bin

You also need to add all of the above to PYTHONPATH, as well as the following:

  • d:\opt\VTK\lib\site-packages

… where d:\opt is the drive and directory where you unpacked the ZIP file.

Once you’ve done this and logged out and in again, “import vtk” should work at the Python prompt. Shameless plug: you can use my free envedit software to do the environment editing. It beats the default XP editing thingy.

Python 2.5 enabled VTK 5.4 Windows binaries

You can always check my Latest VTK Windows binaries page to make sure you have the latest blog posting and hence the latest binaries.

I’ve made available my home-baked VTK 5.4 (actually build from a CVS VTK-5-4-1 tag checkout) Windows binaries.  These have the new-and-improved version of my python-exception-patches integrated (more about this in a future post; a serious dead-lock has been fixed and as a side-effect, you can now run multiple VTK pipelines in different threads!) and have been built with Visual Studio 2005 (8.0) SP1 on Windows XP2 with full Python 2.5 support.  Get the binaries (or my patched source) by going here.  You want the binaries if you want to use VTK from Python.

IMPORTANT: you might have to install the MS VS2005 vcredist_x86 package (free!) if you want to use these DLLs (thanks Jelle for pointing this out).  This might not be necessary if you already have one or more of the MS development environments installed.

Please leave a comment on this blog posting if you use these or just hate them. It’s almost like postcard-ware, but with blog comments. Please also link to this page and not directly to the download location, thanks!

To use this from Python, you need to add the following to your PATH:

  • d:\opt\VTK\bin

You also need to add all of the above to PYTHONPATH, as well as the following:

  • d:\opt\VTK\lib\site-packages

… where d:\opt is the drive and directory where you unpacked the ZIP file.

Once you’ve done this and logged out and in again, “import vtk” should work at the Python prompt. Shameless plug: you can use my free envedit software to do the environment editing. It beats the default XP editing thingy.

What I did this, err, summer

Taking a hint from Joe, aka Swimgeek, here’s a summary of my life since the previous time we spoke:

  • The VCBM 2008 workshop, my first attempt at playing the organising conference chair, went swimmingly.  Two days of solid presentations, a lovely dinner at Van der Dussen (no Ronald McDonald in sight!) and meeting up with many old friends.  I stopped stressing during the conference dinner.
  • I joined the ranks of the intelligentsia (As opposed to the millions of plebs with iPhones – oh stop whining and look at the stats.  Can’t find the stats?  Go figure out how to copy and paste, then get back to me. :) ) and acquired a Nokia E71.  Best. Gadget. EVAR.
  • Had a fan-tas-tic holiday in South Africa.  Had profound conversations and the most raucous get-togethers with best friends and family.  Realised again how extremely lucky I am with people I’m this close with, on two different continents.  Linked up with my dad for the first time in too many years, which was cool.
  • Migrated my extremely complex todo system (I’m a foaming-at-the-mouth GTD follower) from todoist to a local installation of the open-source RoR-based Tracks software.  Todoist is really cool, but it’s very much deadline-oriented, whilst in the GTD world deadlines are just so passé.  DAMN I’m with it.
  • My laptop was sort of stolen and then returned 5 minutes later.  Besides the acute trauma that this caused, it got me wondering about the security of the Windows XP Encrypted File System thingy that I use to encrypt some of the more sensitive, err, documents on my laptop.  On Windows 2000, the fact that on a local install the administrator was the default data recovery agent (DRA), made it possible to decrypt a user’s files without having to crack that user’s password.  On a local install of XP, this is fortunately NOT the case.  I repeat, on a local install of XP there is no default recovery policy.  In other words, a laptop thief needs to crack your password to decrypt your EFS encryption.  You can double check this by downloading efsinfo and running it on your files with “efsinfo /u /r your_files”.  It should confirm that there’s no recovery agent.  You should also check the strength of your Windows passwords with ophcrack.  Your EFS is only as strong as the user password protecting it.  After my little episode, I’ve deleted most of those sensitive, err, documents from my laptop (they’re duplicated on a server at home) and encrypted even larger parts of my laptop hard drive, just in case.

Now I’m supposed to conclude this blow-by-blow with something profound.  I know, I’ll end with a quote attributed to Plato that I first saw in the PhD thesis of a friendly colleague.  At the time it made quite an impression on me:

Be kind, for everyone you meet is fighting a hard battle.

Heck, it still does.