Should everyone learn to code?

January 31, 2013 | 6 comments

I posted this the other day, blissfully unaware of how contentious it would be:

“Learning to code is non-optional in the 21st century.”

It’s a piece of hyperbole, of course; learning to code is perfectly optional. Nobody’s pointing a gun at your head and forcing you to do it. But here’s what many of my friends and contacts read into it:

  • People who can’t code are less valuable in the 21st century.
  • Coding is as important as, or more important than, learning to read, write, do math, or cook.

Of course, I didn’t say any of those things. It’s interesting that they were inferred, and that the idea that everyone should code was seen, generally, as being self-important and enthocentric from the perspective of the tech community.

Here’s why I said it:

  • Software technology is an integral part of all of our lives. It’s part of our environment, and will only become more so.
  • Coding gives us an increased level of control over our environment.
  • Without being able to make or alter software, you are relegated solely to being a consumer of it.
  • Learning to code is virtually free (if you already have a computer), and it’s not hard to get started.
  • The web in particular is a medium that has the potential of allowing anyone to contribute to it. I feel strongly, ideologically, that it should not be yet another medium where a few large companies dictate the form.

It’s also true that, in today’s economy, technology is one of the few growth industries, and having technology skills means you’re much more likely to be able to get a well-paying job. It’s also, generally speaking, not an elitist industry: most tech companies care much more about what you can do, rather than where you went to school (or even if you did). There are also no required professional qualifications to obtain. It’s a pretty good deal. All you need to do is know how to make things well, and you get to teach yourself. (Codeacademy and Mozilla Thimble: both fantastic.)

Far more importantly, technology isn’t going away. It’s not a fad; it’s ingrained in everything we do. There’s no reason at all why you should have to do it for a living – and obviously, there’s a universe of fulfilling career options out there – but understanding how technology works is empowering. It’s a 21st century literacy that will differentiate – as Douglas Rushkoff says – between the programmers and the programmed. And guess what: I do think that the people who understand how it works will ultimately be more valuable. They’ll make better technology decisions, which – as technology becomes more and more ingrained – will mean that they’ll make better decisions overall.

But hey, what do I know. What do you think? Was I out of line? Or is code as important a skill as I think it is?

Serializing PHP objects into JSON with JsonSerializable

August 29, 2012 | 3 comments

JSON (JavaScript Object Notation) is a handy data interchange format that’s overtaken XML in a very short time for a lot of API use cases – and rightly so. It’s easy to use, bandwidth efficient, and widely supported across platforms and languages.

PHP is still one of the most widely-used web scripting languages. It’s perhaps not as cool as Python or Ruby on Rails, but it’s got its adherents. I’m still a fan, although there are some things – like long-polling real-time sites – that are much harder to do on the platform. And when it comes to JSON, it doesn’t get any easier than $json_string = json_encode($php_data); and $php_data = json_decode($json_string);. (Assuming you have the PHP JSON module compiled and enabled – but if you’re using PHP 5.2 or above, you probably do.)

Unfortunately, if you’re using object orientated code and your data to encode includes an object, json_encode() has traditionally not been as friendly as it might have been. Sometimes, for example, you want to define exactly how your objects translate to JSON, to avoid lost data (or too much data). This is particularly true if you’re using magic methods to get and set properties, as I often do.

PHP 5.4 contains a new interface, JsonSerializable, that gives you this control. Once you add the interface to your class:

class myClass implements JsonSerializable {
    // ...
}

You can add a new function, jsonSerialize, that will be triggered whenever json_encode() is run on the object, and returns the PHP data of your choice:

class myClass implements JsonSerializable {
    // ...
    
    function jsonSerialize() {
        $data = array();
        // Represent your object using a nested array or stdClass,
        // in the way you want it arranged in your API
        return $data;
    }
}

Now, when you run json_encode() over a data structure that includes your objects, you’ll know that they’re being saved in a way that can easily be interpreted by your API consumers. Again, the function should return PHP data that can be serialized by json_encode(), rather than encoded JSON data. I recommend using nested arrays, or a stdClass object, for simplicity.

Note that unlike, say, serialize() (which serializes data in a PHP-specific format), this isn’t a two-way translation. In other words, json_decode() won’t automatically reconstitute your object with class from your data.

We can illustrate that by taking the following test class (which I’ll expand first and then print the var_export() output for):

class TestClass {
    public $foo = 'bar';
    public $dev = 'null';
}
 
TestClass::__set_state(array( 'foo' => 'bar', 'dev' => 'null', ))

Which json_encode() encodes as:

{"foo":"bar","dev":"null"}

(Because that was a simple object, there was no need to employ jsonSerialize() in its construction.)

In turn, the JSON string is decoded back into PHP as:

stdClass::__set_state(array( 'foo' => 'bar', 'dev' => 'null', ))

Note that the classname has vanished and the class is reduced to being a stdClass. As a result, you need to take care when consuming JSON data and turning it back into your internal data structures – which is a very good idea anyway. It’s perhaps worth creating your own validator function that can take in a stdClass object and, following sanity checking and sanitization, turn it back into one of your own classes.

And that’s it. I don’t normally write about code here, so please let me know if you found this useful.

Learn to program the Codecademy away

August 18, 2011 | 1 comment

I’m really taken with Codecademy, a series of free tutorials on learning to code. It’s incredibly simple, and you can take the first exercise without signing in.

I know quite a few people whose portfolio of skills could be enhanced with a little bit of coding; this is a great start for them. I’m not sure it really gets over the initial “eeurgh” factor many people have when they think about programming – but maybe it’s just not for those people. It’s certainly the friendliest coding tutorial I’ve ever seen.

httpID: adding identity to standard HTTP requests

April 19, 2011 | 17 comments

This is a more technical post than I’ve been writing lately. I’m considering splitting out into two blog channels; let me know if you’d prefer this.

This is a request for comments and ideas. Please let me know what you think in the comments. Thanks!

One of the advantages of the decentralized social web, as opposed to a social network (federated or otherwise), is that identity can, theoretically, be shared with any web page, anywhere. That page doesn’t have to be running any particular software or provide any particular function; it should optionally be able to support identity-related features. That could then be used to tailor the page to the viewing user. (Of course, sharing identity should never be required, for security reasons.) This is part of three broad activities that I see as being part of the social web:

  • Publishing web content in an identity-aware way
  • Consuming web content in an identity-aware way
  • Sharing socially

Much of the decentralized social web development activity to date has been focused on the third point, and on reading and writing as part of a social web application like StatusNet or Diaspora. However, I’d like to look at the first two points with a view to make them web infrastructure, rather than features of a web application.

To achieve this, I’d like to be able to report, as an option, the identity of the person making an HTTP request, as part of the headers to that request. This might come from the browser itself, eg via an identity plugin, or it might come from a web-based identity proxy.

HTTP supports basic authentication, which involves sending a username and password, potentially in the clear. Out of necessity, we’ve moved beyond this, eg for things like API authentication. Often tokens, hashes and encrypted requests are included as extra header values to authenticate a request.

I’d like to use the same general principle for identifying a user. Here’s how it might work:

  1. The user visits a site for the first time. The browser sends a standard HTTP request. (Or, alternately, a HEAD request, if the site content isn’t required.)
  2. The site responds as normal, but with an extra HTTP header indicating that it’s identity-aware, including the URL of a handshaking endpoint. This will be ignored by clients that aren’t looking for it.
  3. If this is a standard browsing scenario, the user’s browser asks if he or she would like to share identity information with the site. For the purposes of this example, the user clicks “yes”. (This step can be left out if this isn’t a standard browsing scenario.)
  4. Via the handshaking endpoint from step 2, the user’s browser gives the site a public and private key, and a URL, through which it can access the user’s identity information as an XRD file (as in Webfinger). This is exactly the same as the public and private key system used to retrieve social information in points 5 and 6, using the same method. The site simply makes a signed request to the user’s identity URL, which can be anywhere.
  5. The browser receives public & private keys for use with this server only. These might be stored in the browser, or in some central identity store that all the user’s browsers access.
  6. Whenever the browser makes a request to the server, it adds extra headers using these keys (and HMAC-SHA-1), signing each request with the user’s identity until he or she says otherwise. It also sends a header to indicate when the user’s identity information was last changed, in order to prompt the site into obtaining new information if it needs to.
  7. If the site in point 4 is associated with a specific person (for example benwerd.com would be associated with Ben Werdmuller), he or she can use the public and private key generated in step 4 to browse the user’s site.

The publisher would get a list of users who have identified with the site, and, depending on their server or content management system, might add some of them to special access control groups that would allow access to different content. The next time the user visited the site, they’d see more privileged content. A notification would probably be sent to them to let them know this had happened, but this is out of scope for what I’m discussing here. (Perhaps notification methods could be shared as part of a user’s identity information?)

Conversely, the user’s XRD file containing their identity information can also change depending on who’s accessing it (as the requesting site always makes a signed request).

This system has a number of advantages:

  • It’s server and system agnostic. It simply uses the building blocks of the web.
  • It’s very easy to build for. Checking and setting HTTP headers are easy to do, and don’t require any front-end work like HTML parsing or JavaScript libraries. This makes it usable for APIs and feeds as well as web pages, and for clients that use web APIs as well as web browsers.
  • The web isn’t just a platform for people to read these days. This method doesn’t depend on anything visual.
  • You don’t need to control the root of a domain to make it work. If you install a script at http://yourdomain/~foobar/banana/hockeystick.php, the system will be happy there too.
  • It’s passive. There are no blockers if you don’t supply identity information – you just see something different.
  • It’s based on similar assumptions to WebID, but doesn’t require SSL certificates in the browser, and it’s as easy for a web app to implement as it is for browser software.

It incorporates the following assumptions:

  • Relationships are assymetrical. (Here, there’s a set of keys for each side of a relationship. If one side stops participating, perhaps by removing the other from an access control group, the other side is still valid.)
  • Privacy isn’t binary. (Everyone gets a different view on a given page or piece of data.)

Let’s call it httpID. I’m looking for feedback on the idea and process. Does it make sense? Have I missed something obvious? Let me know. If there are no major blockers, I’ll firm up the spec and create some libraries.

Next Page »