August 12, 2015

Pro tip: Use CDPATH in Your Shell

This is a tip I first picked up about thirty years ago (my God!) when I worked at Sun Microsystems and used the C shell fairly extensively. Fortunately there's no need to do so any more, as many of its more desirable features have been incorporated into bash.

There's nothing worse, even with tab-completion, than having to stab through a sequence of directories to find the location you want. If you're anything like me there are typically three or four main directories that I use for about 80% of the work that I do.

The CDPATH environment variable works pretty much like your PATH setting, except that instead of being used to locate executables it's used to locate directories. It comes into play when you issue a cd or pushd command. So, for example, on my personal machine my .bash_profile contains the following line:

export CDPATH=.:~/Projects:~/Projects/Python/

So when I try to change to a new directory the shell first looks in the current directory (it can cause real confusion if you don't look there first), then in my Projects directory, then in its Python sub-directory. So the command

pushd PytDj

takes me to my ~/Projects/Python/PytDj project directory with no need to specify the path. I estimate this saves me at least a minute a day, so over thirty years it's saved me a substantial amount of time. Try it, and see what you think.

June 14, 2015

A Short Musical(?) Introduction to Infinity

Wondering how best to convey the bigness of infinity, I came upon the idea of using a musical exposition. Please forgive the inadequate nature of the performance - like present-giving it's the thought that counts. It's a monologue on the nature of the smallest infinite cardinal. Enjoy. Or not ...

May 20, 2015

What Kind of Geek am I? (1)

I've been pondering about why sometimes progress seems hard to make when I am learning a new piece of technology, which other people apparently just pick up and start using with no trouble at all. I now wonder whether it's a combination of personality and knowledge.

In common with many developers I like to understand things thoroughly. For me this means being able to construct satisfactorily self-consistent mental models that I can, effectively, "unit test" by applying what-if techniques. Unfortunately my history as a developer means that I have a detailed knowledge of system architecture. Without claiming to be fully up-to-date (for example the last time I built logic was in 1987, from Schottky TTL clocked at 12 MHz), when I use the term "full-stack" I include a reasonably detailed knowledge of all aspects of system architecture, including the hardware, operating system, language support libraries and application.

In other words, I am (often subconsciously, thanks to many more than 10,000 hours of practice at this computer game) aware of lots of things that can go wrong at many different levels.

I suspect this causes me, without specific motivation, to choose test cases that go “near the edge of the envelope”. It's frustrating when I'm learning because it often reveals deficiencies (most often in the documentation) of the “system under test” that can block progress; but I also believe it helps to integrate my newly-learned knowledge, and leaves me with valuable knowledge that you just can't pick up in the middle of the road.

February 14, 2015

Carl Trachte: Mining Engineer Turned Geek

Another #LABHR post.

I first met Carl when he came to a training session for new PyCon speakers. He was very nervous, and concerned that his topic would not be of sufficient interest to his audience. I made a point of attending the beginning of his talk, and by the time I left there was no doubt in my mind that Carl would do well in the Python community.

Over the years he has done invaluable work for the PSF, both in policing potential abuses of the Foundation's trademark for the Python programming language, and also in collecting sample descriptions of Python in many languages and alphabets to try and make Python's web presence more welcoming to those from diverse linguistic communities.

He has been a PyCon volunteer for a while now, helping others to find what they need and demonstrating by example the helping spirit of Python and open source generally.

Carl has done all this with no thought of return, and in doing them has helped uncountable numbers of Python users. Well done, Carl, and thanks!

Brian Curtin: A Solid Record of Community Involvement

As a personal #LABHR contribution (having already thanked recipients of PSF awards) I should like to bring to your attention a person by the name of Brian Curtin.

If you are part of the Django world you may know Brian from his work with his then-local Chicago group, though he latterly moved to San Antonio. He has been featured as a Python core developer in the Python Insider blog, and more recently in Mike Driscoll's Pydev of the Week column.

Brian also contributes by serving as a Director of the Python Software Foundation, that worthy body charged with responsibility for the intellectual property in the Python programming language and in growing the international Python community. He is in essence its voice, having for a long time been the Foundation's Communications Officer. Though many others contribute from time to time, they do so under Brian's editorship, and I know from personal experience he is a great editor to work with.

Brian has also spoken and volunteered at PyCon on a long-term basis. I can't think of a single area he's touched without making a contribution of some kind.

So thanks, Brian, for making a difference, and good luck in your most recent role with Rackspace in San Antonio.