Beach ArtÉibhear, 2015-08-20 23:08:00 CEST I was at the beach today, and drew this in the sand: It took about 30-40 minutes to complete. It was cute watching how people would walk towards it and then veer around it. Parking in ClontarfÉibhear, 2015-08-02 23:24:00 CEST If you've ever attempted to drive up or down the southern end of Vernon Avenue, you have probably been blocked by traffic caused by cars parked illegally. Here is how it works. Documentation and versioning, Part 3 of 2Éibhear, 2015-07-31 12:34:00 CEST In part 1 of this series of 2 – now 3 – posts, I highlighted some of the worst examples of when document versioning can go wrong. In part 2, I lay out some guidelines that will help keep document versioning under control such that it's understandable and predictable. In this part, part 3 of 2, I close off that list and make a recommendation at the end that would greatly help putting my guidelines into practice. As outlined in part 2, the following is a summary of my recommendations. Use only one versioning system for all your project's artefacts. Use a document properties to record version information Maintain documents in a networked location, and use URLs. No embedded documents Remove older versions out of the way. No version information in file-names. Use a project librarian Make documents easy to get by making them easy to produce properly. I outlined my reasons for the first five in the last post, and here are the last three. Don't put version information into file-names. If you agree that documents should be passed around as an address or link – rather than as an attachment – and that older versions should not be in the same directory as the current version, then this recommendation becomes logical: Don't permit the names of the files that contain document to express any kind of version information. If, say, you pass around a link to the document BusinessRequirements_v0.2.odt, then as soon as v0.3 is announced, that link will either be pointing to the wrong document, or to an address that no longer exists. The latter can be annoying for the person trying to review the document, but the former could cause more serious problems, as the wrong version will be accessed. Similarly, if you operate the rule of keeping only one version of a document in the directory it is to be found, then putting version information in the file name doesn't make a great deal of sense, and may cause confusion. If, however, you mandate that document file names1 should not make reference to the document's version, then you derive the following 3 benefits: All e-mails and other resources that provide the document's address will link to the correct version of the document at all times. Visitors to the document's official directory will be without doubt that the only document with BusinessRequirements in its file name is the current version of the business requirements document, especially as it's called BusinessRequirements.odt. The maintainer of the document has now one location fewer in which to update the document's version number, reducing yet more the risk of internal inconsistency. Use a project librarian A project should appoint one member to be a librarian. This person would set up the document repository and be a document reviewer, looking for compliance to the project-specific rules on document versioning. If this person has early visibility of the documents-in-draft, then compliance advice can be given early, which will help keeping things in line. This wouldn't be a full-time role, of course, but it should be filled by someone on the project. That way, you have someone who's close to the work, and its goals, rather than someone who's sole job is to declare rules for others to follow. Make documents easy to get by making them easy to produce properly. One of the hardest things to do for someone working in the earliest stages of a project is to start preparing a mandatory document. "Is there a template?", "Can I use a previous version?", "Where will I put it?", "Who will review and approve?", "What's the correct way of passing this around?", "How long will this take to prepare, and how much of that time will be spent on document compliance?" A project office worth its name should have all these answers available for you in an easy-to-read and easy-to-follow format. The goal around a document maintenance frameworks should be two-fold: It should be easy to do things right; and it should be hard to do things wrong. Using a revision control system As I said in part 1, traditionally I have required the same revisioning regime for our documents as for our code files. Consequently, I have always maintained technical documents in the project's revision control system, and I have required my teams to do the same. The primary reason for this is straight-forward: as we create project labels or tags declaring that our development has reached specific milestones, it's a good idea to make available to a reviewer the documentation that is associated with that specific version of the deliverable. For example, if the label implements the requirements as they were agreed in March, the delivery should be assessed against that version of the requirements document, and not the version that was agreed at the end of May and not yet sent to the development team. If the correct version of the requirements document forms part of the label, then there is less difficulty in validating the delivery. As well as the above, excellent, reason, consider how maintaining your project documents alongside your technical files – in a dedicated revision control system like, for example, subversion, git, TFS (if you insist!) – can help with my guidelines. By using a revision control system, you can rely on its scheme for incrementing revisions. You don't have to devise one yourself. Also, you could go further and using tagging or labeling to mark files as DRAFT, FOR APPROVAL and COMPLETE. Many revision control systems have a feature called keyword expansion. This will allow the revision control system to update files with specific information, including the document's revision within the system. If your document has a field that uses the relevant keyword, the revision control system will update it automatically, removing the need for the document's author to do this. Now, the document's author or maintainer doesn't have to update the revision number anywhere in the document. The only problem with this is that files that use compression as part of its format (e.g. modern Microsoft Word XML files or ODF) aren't accessible to this feature. Nor are encrypted files. It works great, though, with the older Microsoft Word *.doc formats2. All modern revision control systems are network-capable, and allow files maintained within them to be referred to by a simple URL (TFS excepted; those URLs are a nightmare. Even worse than SharePoint!). If you are liberal with your document-access policies (e.g. everyone has read-only access), then everyone will become used to seeing documents being passed as links that all look the same as links to tags and other resources in the revision control system. A revision control system doesn't help with the embedding of documents. However, it will make accessing those documents easier if you use links. The revision control system will automatically hide older versions of documents. These older versions will always be available, though, through the revision control system's interface. The value of a revision control system would be lost if you changed the name of a file every time you updated it. In fact, /keeping the file's name the same for as long as its relevant will allow you to derive the full benefits of using a proper revision control system/. The job of a project librarian is made easier as there are fewer locations to keep an eye on. Also, as some tasks can be performed automatically by the revision control system, the librarian's reviews will consequently be shorter. A revision control system will help greatly in making it easy to do things right and hard to do things wrong, but will give little help in developing a framework that you might want to use for that. And, that's it. Thank you for reading. If you think any of my guidelines is flawed, please let me know. My contact details are at the bottom of this page. Also, if you want me to clarify anything, let me know. At some time in the future, I might address some of the other problems with project files and artefacts, like… Spaces and other special characters in file names. Formatting and how stylesheets help impart the information. Addressing the "I just don't see the value of doing this," and other misconceptions around documentation. Why the name of a file doesn't necessarily indicate what's in the file, and the wider consideration that we shouldn't confuse a document and the computer file that contains that document. Footnotes: 1 In my head, a file is a container, and the document is the information within it. For this reason, you'll read sillinesses like "a document's file name" in my writings. 2 I would like to be wrong: if you know of a way that keyword expansion will work in ODF files, especially, please let me know. My contact details are at the end of this page. Documentation and versioning, Part 2 of 2Éibhear, 2015-07-31 08:21:00 CEST In part 1 of this formerly two-part, now three-part1, series of posts, I explored what can happen with document versioning if there's little or no discipline. In this part I set out to offer some simple suggestions to make versioning of documents predictable and understandable, which will make the documents themselves more accessible. The following small set of rules on versioning can greatly improve the quality and traceability of your documents. In summary, these are: Use only one versioning system for all your project's artefacts. Use a document properties to record version information Maintain documents in a networked location, and use URLs. No embedded documents Remove older versions out of the way. No version information in file-names. Use a project librarian Make documents easy to get by making them easy to produce properly. The first 5 of these is covered in detail below, and then in part 3 I will discuss the last 3 and how to make things even easier by using a dedicated revisioning tool – i.e. the one your software developers use – for your documents too. Use only one versioning system for all your project's artefacts. This might sound obvious, but it's not always the case in practice. Different contributors to your project will have different understandings of what each designation. Version 0.9 to some is just a version number on a draft document, but to others it's reserved for the version that's to be sent out for approval. FINAL means a completely finished document to me, but some colleagues have used it to say this version is the last one to be published to get the very last approvals _v0.5_JDComments is version 0.5 marked up with comments by John Doe. To me, this is not a new version, though I've seen others regard it as one (i.e. send it around as a version to be reviewed, rather than incorporating the comments into _v0.6). The versioning system you use should be simple, so that all interested people don't have to try to remember loads of different rules. One recommendation is to separate the mechanism you use to distinguish one version of a document from another, and the mechanism you use to identify the stage the document is at. For example: x.1, x.2, etc. denote documents in draft, incrementing with each new version that is published. These will continue incrementing (x.8, x.9, x.10, x.11, … x.19, x.20, … x.99, x.100, etc.) until the document has been fully approved. 1.0 denotes the first fully approved version of the document. 2.0 is the second fully approved version. And so on. If an approved document is to be amended, then the minor number is to be incremented (1.1, 1.2, 1.3, etc.) until that version has been approved (at which point the major number is incremented and the minor reset to 0). The status of the document is represented more clearly, though. A document can only be in DRAFT, FOR APPROVAL or COMPLETE states. Alternative words could be used for COMPLETE, such as APPROVED, FINAL (though, I wouldn't recommend either of those!), LIVE, etc. Using, the x.y notation, if y is not 0, then the document's state is either DRAFT (still in the works) or FOR APPROVAL (author thinks it's complete, but has yet to get important people's agreement). Once a document is COMPLETE, the y value is set to 0 and the x value is increased by 1. There really is no need for it to be more complex than that. In fact, I prefer a simpler arrangement: version numbers are just integers (1, 2, 3, 4, etc.), and the document state is the only indicator of the document's progression. Use a document property – where supported – to store theq document's version information As it makes more than just sense for the version information of a document to be expressed somewhere within the document, one often finds it in multiple locations: title page, page footers, page headers, introductions, etc. If these are each individually typed into the document, then each time the version is to change, it needs to be manually edited in all places in the document where it's expressed. Some people will miss some instances, and others will decide that it doesn't need to be updated until, say, a certain milestone is achieved. Both of these scenarios are problematic. Microsoft Word, LibreOffice Writer, OpenOffice.org Writer and many other document editing utilities allow for the configuration of fields that can be set in the document's properties and then referenced throughout the document's text. If the author updates this "field" or property and then instructs the document to update all references to it, all expressions of the document's version within it will be updated. Maintain the document in a networked location, and use links. Don't let documents be sent around as attachments to e-mails. No matter how hard you try, there is no way to make sure that all relevant people will pull up the correct version of all documents at all times. If, however, you send only a link to the document, then all recipients of your notification will be pull up the linked-to document (if they haven't saved it off somewhere!). In order to reinforce this I often put the following statement in a prominent location of a document: This document is maintained at <documentAddress>. The only official version of this document is at that address. If you are reading this document from some other location, you are advised to retrieve it from the above address in order to ensure that you have the most up-to-date version. In this scenario, copies and printouts of documents are immediately obsolete, not necessarily because the official version is immediately different, but because the copy or printout cannot track any updates to the official version. In addition to this, I would strongly recommend that everyone in the organisation have (at least) read-only access to the location where the document is being maintained without having to raise a specific request for this. This is very important. If there is no compelling reason to restrict access on documents to legitimate members of the organisation, then all documents should be accessible to all users without the need for instance-by-instance granting of permission. It's bad enough if someone has to supply a username and password every time they want to read a document, it's worse when that person has to wait a number of days to be supplied with a username and password. In this case, a number of risks arise: A legitimate reviewer of the document can't review it; Your deliverable is delayed while you await the granting of access; Or your reviewer has to provide comment on an unofficial, obsolete version of the document that had to be e-mailed to them (see above). This latter risk is especially important, as it might seem minor, but without rigorous application of your rules, it is the slippery slope that will make a networked location of the documents pointless. Think open: unless you have a good reason to hide it, you shouldn't allow it to be hidden. Don't embed documents Don't allow the embedding of documents within documents. This may well be a handy way to pass documents around, but it comes with problems. Documents aren't directories. That you can put one or more documents into another doesn't mean that you should. Embedded documents can't be maintained as flexibly as documents in a directory. Changes to embedded documents aren't independently trackable. Many would see a change to an embedded document as not requiring a version increment, but then others would not know that the embedded document has been changed. Comparing different versions of an embedded document, each in a different version of the containing document is, at the very least, a challenge. And, if you're in the habit of passing around links to a document, then there's no need to embed it. Remove older versions away. Don't keep older versions of a document (even the immediately previous version) in the same location as the current version. When someone lands in the directory or folder where the document is maintained, there should only be one version of the document available. This will make it completely clear as to which file should be accessed: there can be only one. If you need to retain older versions, and if you aren't using a revision control system that does this for you (see below), then copy those older documents into a different directory. If that different directory is to be a sub-directory of the document's normal home, then it should be named such that it's clear that live documents don't reside in there. (Call it Archive, previousVersions, Obsolete Documents or something like that.) In part 3 (of 2!), I finish going through my suggestions, and then will discuss one way of helping putting them into place. Footnotes: 1 Dreadful planning. This series initially started out as just 1 post, became a two-parter when I saw that there was more to say, and now it's a three-parter, largely because I've said too much! Documentation and versioning, Part 1 of 2Éibhear, 2015-07-29 20:59:00 CEST In all software engineering projects, documentation is critical. This is the first of two1 posts where I discuss my experiences and insights about project documentation – particularly how versions of documents are recorded – offering some simple suggestions for improvements that you might not yet have considered. Documentation serves to record things like why you're doing what you're doing, how you are doing it and how to pick up from where you left off. I've seen more than a few projects fall into big trouble – or cause serious post-implementation support problems – because of lax attitudes to documentation rigour. Most often, documentation best serves a project if the following is understood before-hand: What documents will be produced; When will they be produced; What benefit will they have; Who will review and/or approve them; What are the pre-requisites for each. Until there has been enough exposure to the expected documents, projects tend to worry about these matters and the impacts they will have on the success of each project2. One of the core the Problem(s): document versioning The aspect of documentation that – to my view – causes the biggest problems is versioning of the documents. Versioning of technical files, like source code files, seems not to be a challenge. For the technical staff, it's somewhat ingrained. For the non-technical staff, it's not massively important. If you agree with me, however, that the following two assumptions are correct, then we need to be as rigorous with our document versioning as we are with our source code files: A project's documentation is as important to the success of the project as all other artefacts, like source code. Project documentation doesn't magically appear out of nowhere: it's developed iteratively just like any other aspect of a successful project. Traditionally, I have required the same revisioning regime for our documents as for our code files. However, not all documentation can be maintained in this way, and not all projects operate in this way (even if it's technically feasible). Very often, revision control of documents is done in an ad-hoc manner. Also, the tools being used are not designed for the task (e.g. going back through old e-mails), are not up to the task (e.g. versioning by giving files different names) or don't integrate well with the revisioning tools used by the rest of the project (e.g. Microsoft SharePoint – unless, of course, you're using SharePoint for versioning of the rest of the project, in which case I suggest you stop reading this: your problems lie elsewhere…). And then there's the problem of consistency: in many environments, documents are versioned using the scheme that the author at that time thinks is appropriate. When you have many authors, each using a different scheme, each deciding on a case-by-case basis what his/her scheme is, you can get the following: 0.1 DRAFT 0.2 0.5 FINAL 1.0 FINAL Updated FINAL DRAFT – For approval FINAL FINAL 0.9 … which might describe the progression of just one document! And then there's the problem of internal consistency: I've often seen a single document with up to 3 different versions expressed in it: in the document's file name, in the title page of the document, and in the footer (or header, or both) of each page of the document. There are many who have had perfectly good documents rejected by me because they neglected to update the version information in all places in the document. In part two of this two-parter, I'll set out a small set of guidelines that would address the significant issues around document versioning. Once I have it published, I'll update this post with a link to it. Update: it's here. Footnotes: 1 Now three! 2 Though, it helps a lot if when project regards stability and quality as highly as time-to-delivery and costs Knowing more about the herdÉibhear, 2015-06-17 20:08:00 CEST On the 11th June, it was announced that a new case of BSE had probably been found in Ireland. This is, of course, disappointing; the week before Ireland was declared to have a "negligible risk" status as regards BSE. Ireland's status is probably going to be raised to "controlled risk", which happens to be the risk status it had when the US and some other important markets were opened to Irish beef in the last few months. In an article in the Irish Times the following day, we heard from the minister for agriculture, Simon Coveney, what was being done to determine the source of the infection. In discussing the rigour of the system for tracking and monitoring cattle in Ireland, Mr. Coveney is quoted as follows: He said Ireland "probably knows more about our bovine herd than we do about our people" and there was a "very, very detailed, credible system" in place for monitoring animals. OK. So he's saying that, as all details of all cattle are entered into a centralised database, we can know everything about the whole herd in Ireland (somewhere around 6,000,000 cattle), including, for example, where they were at any particular point in time. And that it's remarkable that we don't know this much information about the people in Ireland. While he is not suggesting that it's regrettable that we know more about cattle than people, it's staggering that a politician in a democratic country would make such a comment. In a republican democracy, it's supposed to work the other way 'round. To a republican democracy, it is repugnant for the government to know anything about any person except what is needed to provide a service to that person. That a government minister would say something like this lends validity to the growing desires of so-called democratic governments to infringe on individual's rights to privacy and free association. CVs and copyrightÉibhear, 2015-03-27 10:08:00 CET Yesterday, I posted a (long, unfortunately) discussion on using open formats for a CV, and why it's a good idea even if others think otherwise. One point I made is that recruiters make changes to candidate's CVs, even if that's only to place their branding on the document prior to sending it out to clients. This is an interesting practice, to say the very least. Consider this: if I downloaded a feature article from the Irish Times web site and changed its font and uploaded onto my web site (preserving, of course, the by-line and stating where the article originated), would that be legal? As soon as a work is created in Ireland, it's automatically protected by copyright, the control of which vests with the author. My CV is protected by copyright, and I'm it's author – therefore, I "own" the copyright on my CV. This is important: by sending my CV to a recruiter, one could argue that there's an implicit copyright license (if such a thing exists in Irish law) extended to the recruiter to make copies of my CV and to distribute those copies to hiring managers. As it happens, I exercise this right when I ask recruiters not to send my CV to any hiring company without my explicit agreement on a case-by-case basis. But recruiters don't tell me that they will put their branding on my CV. I can't agree to something I'm not told is going to happen. Therefore, recruiters don't have my agreement to make even that "small" change to my CV1. To do so is to violate my copyright, isn't it? If I'm wrong, I'd love to be pointed to the relevant court decision or statute. Footnotes: 1 It's never a small change, as – based on the recruiter-branded CVs I have seen, both my own and other candidates' – very often the flow of the document is damaged by this change Document Freedom Day, my CV and who owns itÉibhear, 2015-03-26 19:04:00 CET Yesterday, on Document Freedom Day, I posted the following on LinkedIn: Today is Document Freedom Day, when we celebrate being able to store our data in formats that will be available to us no matter what happens to the companies that create them. Today is the day when it is appropriate to ask: is there a good reason to require me to give you my CV in Microsoft Word format? "It's because we need it for our systems" doesn't count as a good reason. I maintain my CV in a plain text format, and I can export it trivially easily into either PDF or ODF, both of which are truly open standards, and can be implemented by anyone without having to ask permission (a.k.a. "buying a license"). I don't have access to Microsoft Office, in part because Microsoft will not make a version available for the computer that I use and in part because I am not prepared to accept the terms and conditions that come with it. Therefore, in order to provide a document in Microsoft Word format, I need to use a tool that can only do its best. Given the amount of work I put into my CV, it's annoying not to be able to verify that it looks the way I want it to before I send it on. Oh! and as it happens, I've never been asked by a hiring manager to supply a CV in MS Word. It would appear that none of their systems require it. And a buddy of mine, Conor, posted the following comment: Interesting that you view your CV as something your prospective employers should adhere to, rather than you, the person looking for the position, should facilitate. Right argument, wrong fight. Screening for prospective candidates is arduous at the best of time. Something as simple as taking an Adobe update through a corporate firewall is a reason for exclusion. So yes personal documents should be created and stored in a future proof manner, but your CV a point in time and should be received in the manner requested., ideals set aside. Here's my reply to this, which is too long for LinkedIn: First off, my CV is a product of my own efforts, and it should succeed or fail on that basis. Otherwise, it would be very easy for me to blame external factors for my CV not working (such as – for example – that the employer doesn't appreciate greatness when it's shown to him or her). The point of my CV is to allow an employer to glance quickly at it and say "that's the kind of person we need". The data-interchange format doesn't help with this: If my CV is in ODF, or PDF, or HTML, or PNG, or plain text, or on paper, it would still be able to do its job: to express the potential value that I can bring. By using an open standard (like any of those above!), the person receiving the document will not be bound to a specific tool to read the information. If you have a problem, for example, with Adobe's Acrobat reader, that's fine: get something else: http://pdfreaders.org/. As an open standard, PDF can be implemented by any tool, including Microsoft Office1. PDF is a specification committed preserving how a document should look, and so is ideal for communicating CVs, and far superior at that job than the Microsoft Word format, which allows local settings and version differences to have a say in how a document looks (just like Libre Office and OpenOffice.org – this isn't a criticism of a single tool or its vendor!). As I say, a hiring manager has never asked for my CV in any specific format. I send it to hiring managers in PDF on the grounds that my preferred look-and-feel for the document is preserved. I don't believe that the Microsoft Word format is preferred on its own merits for CV-interchange. Recruitment companies want it in Microsoft Word format because they will do two things to your CV: It will be uploaded into their "system" to be retained for analysis and searching purposes. Need someone with SQL Server experience? No problem, let's just bung "SQL Server" into our database and hey-presto!, look at all these likely candidates! Therefore, of course, the document needs to be in a format that the "system" can read, and sure, y'know, everyone has Microsoft Word, so let's support only that format2. Recruiters – though they won't tell you this – will change your CV before sending it out to the hiring manager. More often than not, the changes are cosmetic, but they will always put their own branding on the document. If the "systems" that the recruiters use for these purposes supported open standards, then they would take my CV in any format I care to give it. No quibbles. The recruitment game is tilted against the candidate. It has been like this forever, I expect. That doesn't mean it's right or acceptable. And it sure doesn't mean that I should be required to spend money I don't have, or accept software contracts I don't agree to, in order to be able to send my CV in a format that's controlled by a single organisation. There are many principles involved. But look at it practically: if I go to the effort to produce a CV that I believe will spur an interview, then the targeted recipient should be permitted to view the document as I intended, rather than as the middle-man and the reading tool decides. I suggest asking a graphic artist if it's OK for a third party to change a piece of work before the client sees it. This is the right argument, and also the right fight. I would be disgusted if I had to disregard a candidate just because of the file format of his or her CV! I've never seen the following in a restaurant window: Delivery drivers wanted. Apply within. Must own a Nissan. Footnotes: 1 I'm wrong. Microsoft Office can't really open PDF files. LibreOffice, can, though, using LibreOffice Draw. Score yet one more for Free Software! 2 This, by the way, is the sort of lazy, unprofessional, analysis that has shocked me the most throughout my career; shocking both because it happens and because it happens so much. How can encryption be regulated?Éibhear, 2015-03-18 11:32:00 CET So, the United States government and the government of the United Kingdom both think that it's right to weaken encryption schemes and to require internet companies to support governments' endeavours to decrypt private messages. Don't worry, they say, we're the good guys and we'll use this ability responsibly. For me, the most elegant argument against this notion is that if the American and British governments can force internet companies to comply with these schemes, so too can the governments of Germany, France, Hungary, South Africa, Italy, Sri Lanka, Egypt, China and Russia1. The ethic of complying with local laws (as trumpeted by all the global operators) has a cuts-both-ways property to it that is often missed by the dolts running the US and the UK. But there's another problem with the proposals that I can't see being easily addressed by governments. It is that the development of encryption technologies is not a capability exclusive to governments. What is to stop a group of independent researchers from developing an encryption technology that seeks to exclude all governments? This is not a silly speculation. PGP was developed without knowledge or assistance from any government, and in fact was initially intended for use as protection against government spying. Once such a thing exists (assuming that all the current encryption technologies have become no-longer effective!!), all a user will need to do is to encrypt their messages using this technology prior to committing them to a spy-enabling internet. Oh! you say. But the development or use of these technologies would be criminalised, you say. This is true, but given the border-less nature of the internet, it would have to be criminalised in every single country in the world to make a criminal of all potential developers and users. It's also the case that once a technology has been developed, it can't be undeveloped, and given that we're talking about information technology, restricting its movement would be seen, for example, as a restriction on speech. Not a problem for the likes of Ireland, France, Russia and other countries that struggle with the notion of free expression, but a big problem for the United States, whose Supreme Court upholds Free Speech vigourously. As a policy initiative, I see this dying a slow, agonising death as more and more politicians are clued in to its political and technical infeasibility. However, there's a long way to go, and while it's still on the table, the notion that governments are supreme over the people (i.e. the reverse of the definition of a republic) will continue to grow among the gullible and the ignorant. Footnotes: 1 Countries listed in order of Transparency International's Corruption Perceptions Index 2014, from least to most corrupt. The value of encryptionÉibhear, 2015-03-12 20:44:00 CET There have been recent calls around the world to restrict the use of VPNs. Variously, they're offered for differing reasons: VPNs are encrypted connections, possibly to servers outside your control, and therefore, you can neither eavesdrop on nor control what an internet user is doing. VPNs facilitate access to services outside the internet users' "market" area, thereby allowing them to avail of services that a monopolist would rather they not use. The reasons cited, however, are non-typical. Overwhelmingly, VPNs are used in business to allowing staff to connect to a company network so they can access the files and services that are within the company. A VPN helps here, as once connected through it, the staff member's computer is effectively within the company network, and there's no need for each application or service to be exposed individually to allow remote access. But here's another, simple, value to a VPN: I attended a job interview today. Prior to leaving the house, I reviewed the version of my CV that I had sent in, and I typed some notes into it to help me prepare. I saved the file, but forgot to check it in1. I parked the car outside the office, and had 15 minutes to spare, so I took out my 'phone to review my CV. Once I checked out this version, I noticed that not all the notes that I had prepared where there. No problem: I have a VPN server at home2. I connected to it on my phone, I then used ssh to connect to the computer I had been working on earlier, and I checked in my updated CV. Once done, I was able to check it out again, and presto I had the updated version! This was simply done, and done quickly. It would have been impossible without a VPN. And some people want to criminalise this sort of behaviour! Epilogue3 My 'phone is a Nokia N900, which is really nothing more than a standard computer running a Linux distribution called Maemo. It has a terminal application which means connecting to other computers using ssh is a easy as doing it from any computer. It's a genius 'phone, and I will miss it when there are none left! Footnotes: 1 Yes, I check my CV into a revision control system. I'm a software engineer. You should expect nothing else! 2 Running on a Raspberry Pi 3 An earlier version of this post has this section titled "Prologue". That was stupid.