The Perl programming language turns 25 today. Little did I know when I was 12 years old that I would learn a language being birthed at that moment, and pursue a career in speaking it.

Here is a tribute to / history of Perl’s first 25 years.

Long live!

Not that it matters, but while reading through the sort(1) man page, I noticed a new (to me) option:

-R, –random-sort
sort by random hash of keys

Yes, newer versions of sort will actually shuffle your input data.I’m not sure if that’s a cool thing for a command named sort to do, but I like it anyway.

A quick test (on Red Hat 6) shows that it really is random: you don’t get the same shuffle each time.

Good replacement for the Perl one-liner:

perl -MList::Util -e ‘print List::Util::shuffle <>’

(Added later: many versions of Linux include the “shuf” command.)

Consider this oddly redundant sounding UNIX command:

$: man man

This gives you the manual page for… well, for the program that you read manual pages with.

$: man man | head -50
man(1)                                                                  man(1)

NAME
       man - format and display the on-line manual pages

SYNOPSIS
       man  [-acdfFhkKtwW]  [--path]  [-m system] [-p string] [-C config_file]
       [-M pathlist] [-P pager] [-B browser] [-H htmlpager] [-S  section_list]
       [section] name ...

DESCRIPTION
       man formats and displays the on-line manual pages.  If you specify sec-
       tion, man only looks in that section of the manual.  name  is  normally
       the  name of the manual page, which is typically the name of a command,
       function, or file.  However, if name contains  a  slash  (/)  then  man
       interprets  it  as a file specification, so that you can do man ./foo.5
       or even man /cd/foo/bar.1.gz.

       See below for a description of where man  looks  for  the  manual  page
       files.

OPTIONS
       -C  config_file
              Specify  the  configuration  file  to  use; the default is /pri-
              vate/etc/man.conf.  (See man.conf(5).)

       -M  path
              Specify the list of directories to search for man pages.   Sepa-
              rate  the directories with colons.  An empty list is the same as
              not specifying -M at all.  See SEARCH PATH FOR MANUAL PAGES.

       -P  pager
              Specify which pager to use.  This option overrides the  MANPAGER
              environment  variable,  which  in turn overrides the PAGER vari-
              able.  By default, man uses /usr/bin/less -is.

       -B     Specify which browser to use on HTML files.  This  option  over-
              rides  the  BROWSER  environment  variable. By default, man uses
              /usr/bin/less-is,

       -H     Specify a command that renders HTML files as text.  This  option
              overrides  the  HTMLPAGER  environment variable. By default, man
              uses /bin/cat,

       -S  section_list
              List is a colon separated list of  manual  sections  to  search.

I’m tired already.

The UNIX world is one thing. We *have* to read this stuff. But my users don’t have time to read manuals, and I don’t have time to write them. Not for the number of applications we support at UNH.

Tim Clark and I were talking about software manuals today, and I remarked that any user interface confusing enough to require a manual is by definition not intuitive enough. That might have sounded good at the time, but I realize that information concepts can be quite difficult to communicate in a lot of circumstances.

I realize this every time the phone rings, and one of my users is lost in a UI that I had designed.

Why hadn’t my UI been good enough to lead the user to water? Reasons vary. Perhaps I had been making silent assumptions that my user couldn’t be expected to make. Maybe the concept I needed to represent didn’t really have a visual metaphor to use among the UI elements at my disposal, and I had had to ‘jerry rig’ something to work… which it did… but confused the user as a result. And maybe the UI was a quick and dirty first draft, that plain needed attention.

Whatever the case, designing an intuitive and usable UI is like every other aspect of development: challenging and iterative. I wish I had an easy answer, a single law of UI physics which made it all right and immediately understandable, but if I did, I wouldn’t have (or get) to think about this stuff anymore. And that wouldn’t be any fun.

All I can offer is a few non-silver bullets to keep in mind while developing (some of these are web-specific):

• listen to your users
• use the basic UI elements such as dropdowns, checkboxes, radio buttons and text fields in their intended manner. Do what would be expected.
• don’t demand anyone to find CONTROL or FUNCTION keys on their keyboard.
• use layout devices such as tabs to free up real estate on the screen, and organize functionality in a logical way.
• with that extra real estate, sparingly instruct the user on the more complex concepts they may need to know.
• full page loads cause the screen to ‘flash’. That’s ok if you’re changing contexts and people are quite accustomed to web pages loading. If you’re not making a major context change though, consider using AJAX calls to re-render only the part of the screen that the user is affecting with the current action.
• listen to your users!

That’s all I’ve got for now.

So you are Linux Demigod? Have you seen OpenSolaris. What other OS can you plop on a lowly PC and scale it to more than 128 processors running multiple cores. It can run Linux code, virtualize itself or other OS’s, removes the painful init.d and it’s start/stop scripts, has a kernel tracing system called Dtrace that plops exception probes right in a running kernel, has a far superior kernel thread mechanism than anything out there, and it enjoys the benefits of ZFS: Zettabyte File System — a file system that can handle double bit parity RAID 10 or V, create backup snapshots, implement pools of cheap storage into aggregates of simple virtulized storage (why even go HW Raid?). And the finale: It is openSource!