If you are interested in time in programs go read falsehoods programmers believe about time. If you are interested in historical times make sure you’re aware of travesties like Sydney’s pre-standard time offset of 10:04:52.

Future times can’t, in general, be specified in UTC timestamp and offset: the definitions of timezones can and do change and can change with little notice. For dates this doesn’t make too much of a difference (a date, of course, denotes the whole 23, 24, or 25 hour period and not some particular instant within the day) but values with higher precision it’s possible (though in Australian fairly unlikely) to convert a future date/time to UTC with a time zone definition which is not the one which actually applies when the time occurs.

There’s no particular reason to expect any polity to not change it’s time zone over any particular period (New South Wales did it for the Olympic and Commonwealth Games; Fiji changed it’s DST start/end dates in 2011, 2012, 2013, and 2014; Israel negotiated the dates in parliament in every year but now has a regular schedule - except where it conflicts Jewish new year).

You need to represent a local date and time in the target time zone and, at some point, commit to using the time zone definitions you happen to have to interpret the local time into UTC. Ideally this would be safe for instants in the upcoming 12 months , say, but who knows? For some polities it might make sense to commit with the time zone definitions we have now (DST in Australia’s eastern states has settled down in the last few years and there are still a few more years before they can attempt another referendum to introduce it to Western Australia) but not in others.

PS: As a person who lives in the world and interacts with people and organisations around me, I’m using “time” to mean “the numbers which are supposed to correspond to the the numbers on my clock” and not “absolute time”, “UTC”, etc. I generally try to use words like “instant” and “timestamp” (respectively) to refer to those latter things.

Update On Monday, July 4 2016 a meeting of Egypt’s cabinet cancelled daylight savings time which was due to start on Thursday, July 7. Three day’s notice is enough to upgrade the TZ database on all your computer systems, right?

Attributes

Attributes are “extra” bits embedded in source code that doesn’t necessarily mean anything in the language. Common examples include the documentation annotations in many comment systems (such as the tags used in Javadoc comments), JVM annotations, and .Net attributes.

A testing framework, for example, might use a TestFunction attribute to identify which methods should be called.

@TestFunction
public function testValidation() {...}

[TestFunction]
public function testValidation() {...}

Use cases

In Java EE you have “beans” which encapsulate business logic. Each bean requires a bunch of wrappers for remote access, “home” access (whatever that means), XML files, etc. Keeping all this relatively “boiler-plate” code in synch is painful. Annotating the bean classes and methods with attributes makes it possible to generate most of this automatically. No more manual synching XML files.

Java, though, (as of Java 5) has built in support for annotations and is a compiled language. This makes it relatively simple to do this analysis and generation at build time. PHP, on the other hand, doesn’t have an annotation mechanism and doesn’t have a built time.

Instead, Peter’s approach is to use PHP comments to add the attributes. At load time, these comments are processed using the reflection API and this is used to build a data structure to use for access control. See the permissions example.

A more complex case

To take this a little further, Peter wrote a Zend extension that makes it possible to [sort of] do aspect oriented programming (on function points) in PHP. The add_function_hook() function allows you to register an attribute and a callback and the extension will call your callback before a function with that attribute is executed:

<?php
class RequiresLogging
{

	/**
	 * @log notice "Secret action performed by user [user]
	 */
	public function secretAction()
	{
		// perform secret action...
	}

}

// 
// The callback function
//
function performLog( $message )
{
	$parts = split( " ", $message, 2 );
	$level = $parts[0];
	$message = $parts[1];
	Logger::log( $level, $message );
}

// 
// Register the callback
// 
add_function_hook( "log", "performLog" );

// Now code like this will result in a log message being recorded
$object = new RequiresLogging();
$object->secretAction();

This type approach is flexible and extremely powerful. You can inject permission checking code and raise an exception before the real function is even called.

There are a bunch of memory leaks and possible bugs in the Zend extension, but it is working and in production use!

After a bit of background on the mainframe, mini, server, desktop progression, Guiseppe introduced the space that Gearman operates in: distributed heterogenous system (like the web). Amongst Gearman’s peers in the space (not to say that they fill the same role 2at all) is memcached.

Gearman is a client/server system for distributing jobs from clients to a number of workers. Guiseppe drew an analogy to a manager in a company: the manager gets a request from a customer, delegates it to one or more employees, and hands the result back to the client (monitoring progress along the way and assigning the job to new employee/s if the current ones are, e.g., hit by a bus).

The Gearman server fills the role of the manager: it accepts connections from clients and one or more workers (which can be local to the server or on other hosts). The Gearman server is responsible for then farming the jobs submitted by the clients out to appropriate worker/s for execution.

There are a numerous ways that this can be useful. It can help to decouple applications and features from each other. Rather than re-writing existing components for use in projects in another language or on a different platform, you can use Gearman to mediate the invocation of the existing code from the new system. Similarly, you can use it to offload computationally intensive tasks to more capable systems.

Using Gearman is reasonably simple: the gearmand server is written in C and there are client libraries available for, according to Guiseppe, “everything that counts”: C/C++, PHP, Python, etc. You just start a server, start one or more workers, and then use one (or more) of the available client libraries to submit jobs.

# Start a server
PORT=1234
gearmand -d -v -p $PORT

# Start a worker
gearman -p $PORT -f count_lines -- wc -l

# Submit a job
gearman -p $PORT -h localhost -f count_lines < /etc/passwd

The above code starts a Gearman server, starts a worker that can compute the count_lines function (by running wc -l on its input), and submits a job.

There are some rather more complex uses. One of those that Guiseppe mentioned is using the client in user defined functions in a relational database server (he used MySQL, but PostgreSQL is also supported). With appropriate jobs and workers this can be used to retrieve status information from, e.g., MySQL slave servers and store it in a database on the master (which will then be replicated to the slaves giving all nodes knowledge of the health of the whole cluster).

To help avoid introducing a single point of failure, you can deploy multiple servers and use all of them: if one fails, then clients and workers will try the next. It wasn’t clear, though, if the client libraries do this sensibly (re-submitting jobs, etc.)

For more information, your first stop should probably be the official Gearman web-site. There are also a number of posts on Guiseppe’s blog.

The talk, aimed at newcomers, covered a lot of ground. It started with a characterisation of Haskell as a pure, functional, non-strict, strongly, statically typed, programming language and gave all the usual reasons that those are nice properties for a programming language to have.

After a few examples of the syntax, Stephen talked about recursion and mentioned that idiomatic Haskell tends to use a higher-order function implementing a particular recursions scheme, but didn’t really point any out (other than using map in example).

Next was a brief discussion of the type system: it’s strong and static, but it also features type inference so you don’t need to supply signatures for everything. It’s probably important to note though, that it’s still a good idea for top level definitions for documentation purposes, if for no other reason. Next was a mention of QuickCheck and automatic testing.

Finally, there was a bit about Haskell’s non-strict semantics and the usual points about concurrency (being hard in imperative languages and rather easier in Haskell). Laziness is useful as it makes it possible to represent [potentially] infinite data structures and looping data structures without destructive updates, alas it can make it hard (or, at least, harder) to reason about and predict the time and space behaviour of a program.

It was a pretty good talk, but I though Stephen missed a few opportunities to make some important points that the audience might have appreciated. In particular, I’d have mentioned the various higher-order recursion operators and opportunity they provide for automatic application-specific optimisations through fusion. This is the sort of thing that is difficult or impossible in a lot of languages but are seriously cool!