NickTelford.net

There is an interesting discussion on the use of the term “login” as a verb, part of a much wider discussion on colloquial terms often misunderstood to be verbs, that got me thinking about the proper terms for such actions.

“Login” is just one of many offenders (many of which originated on the Internet) that could easily be replaced with verbs that make much more sense.

Readability

Of course, there’s a strong argument that words such as “login” and “checkout” have well-defined, verb-like connotations that readers’s are familiar with. So it’s often wise to sacrifice absolute grammatical correctness in order to communicate better with your readers. After all, the purpose of a language is as a well defined, but constantly evolving communication protocol.

However, there are ways in which you can ensure grammatical correctness without misleading your readers.

Grammatically Correct Software

In the context of software development, “readers” are the users of your software. Understanding how users perceive actions within your software (and optimising it) is a crucial aspect of development that is often overlooked. Using correct grammar can help a lot by providing users with a language that is familiar and un-obtuse. Users should never find themselves thinking “what does that mean?”.

So we need to be both grammatically correct, but colloquial enough that users don’t have to think too hard about what they’re doing. Lets see if we can apply this to a couple of common “anti-verbs”.

“login”

As the notaverb.com reference for “login” points out; “login”, while not a verb, can be a noun. This is useful as it allows us to use terminology that user’s are already familiar with in order to prevent them from getting lost.

So if “login” is not a verb, what is? It’s suggested that “log in” is appropriate, but since this is a verb/adverb combination this doesn’t really fit the bill as it implies that you are “logging” in an “in” way. Even if this is grammatically correct, it’s quite vague: what or where is “in”?

I’d propose that, in the context of software, an appropriate verb would be to authenticate. Authentication implies that you are being recognised (or rejected) by an authority – in the case of software, the application itself.

Note: There are often two software processes involved in “logging in” – “authentication”: checking the authenticity of a user and; “authorization”: ensuring a user has authority to do something.

It’s good practice to disambiguate these terms internally (in the software code and audit logs etc.) but wise to make the latter transparent to users; a user should only be concerned with authentication.

The problem with “authentication” as a verb is simply one of complexity. Big words scare people.

We can use the noun form of “login” to provide user’s with a grammatical cue that they’re familiar with, but what is a “login” if it’s a noun? Simple, the “username”.

“username” is a word I’m strongly opposed to as it’s (in my opinion) not really a noun; it is two nouns squashed together: a “compound noun” if you prefer. More specifically, it is the “name” of the “user”, although the actual name of the user is often quite different – so how do we disambiguate the two?

The solution is simple: ditch the term “username” in favour of the proper noun “login”.

Using these ideas, here’s how an authentication process may appear to a user in a way that’s both accessible and grammatically more accurate:

Authentication
Please enter your login and password:
Login: __________
Password: __________

It seems to have become part of modern internet culture to define new words, often that defy traditional language conventions, in order to describe something new and exciting. This is not only unnecessary, it makes technology obtuse and less accessible – particularly to the older generations.

At the end of the day, technology is meant to innovate, liberate and empower users – not confuse them with unfamiliar words.

I’ve been doing a lot of multi-process and signal programming PHP lately, and I found myself wondering which signals it’s possible to intercept and handle in userland PHP. Of my findings, the most interesting was that you can trap SIGSEGV (“segmentation fault”) and handle it yourself.

By default, when the kernel raises a SIGSEGV on a PHP process, PHP intercepts the signal and handles it by simply printing “Segmentation Fault” to stderr (standard error) and the process immediately exits. This is understandable behaviour, but in most applications, especially large ones, it’s useful to know what it was that caused the segfault to be raised so you can address the problem.

So I found myself wondering if it was possible to trap SIGSEGV and gather some debug information about it before exiting, and discovered that it’s much simpler than it sounds:

<?php
/**
* Demonstrates signal handling to trap Segmentation Fault using userland PHP.
*
* Useful for debugging larger applications that occasionally generate
* segfaults.
*
* You are free to modify and redistribute this code without attribution.
*
* @author Nick Telford <nick.telford@gmail.com>
* @copyright Nick Telford (c) 2010
*/

// you need this towards the start of your application in order for signal
// handlers to be executed
declare(ticks = 1);

/**
* Signal handler for segmentation faults.
*
* Since a segfault indicates a memory problem, it's wise to keep this separate
* from other signal handlers and to have it do as little as possible.
*
* Also, since there's a memory problem, this should call exit(1), otherwise
* you could end up with unpredictable behaviour. Only avoid exit(1) if you
* *really* know what you're doing.
*
* @param integer $sig The UNIX signal, will be SIGSEGV for a segfault.
*/
function handleSegfault($sig)
{
    // note: unless you're running the CLI SAPI, this will be sent to the
    // browser, fwrite() it to STDERR instead or better yet, log the info
    // somewhere (a file or syslog) for later analysis
    echo "Segmentation fault, printing backtrace:\n";
    debug_print_backtrace();
    exit(139);
}

// attach the segfault handler
pcntl_signal(SIGSEGV, 'handleSegfault');

// tests the segfault handling by generating one
posix_kill(getmypid(), SIGSEGV);

Update: I’ve changed the exit code to 139, as processes terminated by a UNIX signal should use an exit code that is the signal number + 128. The exit code for processes that terminate due to SIGSEGV is 139.

As my notes in the code suggest, you shouldn’t merely echo the information out, as by default it is sent to stdout (standard output), which any SAPI handling web requests will send to the browser. Something strongly inadvisable.

Instead, you’ll most likely either want to output the information to stderr (using fwrite()) or log the data using your application’s logging layer. It’s important that you execute as little code as possible, especially memory operations, as a segmentation fault indicates memory corruption that could have unpredictable effects on your application.

In PHP 5.3.0 PHP’s handling of signals was changed from implicit, using declare(ticks = n) to instruct the interpreter to automatically dispatch pending signals after n lines of code are executed; to explicit, by calling pcntl_signal_dispatch() yourself. Whilst the new explicit process is more flexible and provides for better performance, it does have the potential to decrease the durability of your application, especially if you’re trapping SIGSEGV, because the application will continue to run until you call pcntl_signal_dispatch(), even though memory corruption has occurred.

Finally a note about performance in PHP < 5.3.0: using declare(ticks = 1) tells PHP to check for pending signals after it executes every line of code. Obviously this adds an overhead (albeit a small one) to your application. For that reason, it's probably wise to have this disabled in production environments.