Once upon a time there was a maaaaagical spell called the Telephone Protection Service. The TPS was a spell you could cast upon yourself so that the evil phone goblins wouldn't ring you all hours of the day and night trying to sell you things you couldn't afford and didn't want. The people of the land were happy with TPS and there was much rejoicing as the peasantry got to have a proper bath without having their souls tarnished by idiots trying to sell them double-glazing.
Wednesday 30 June 2010
Money Laundering
You know that your life is really going well when you find yourself grubbing around the house for each and every bit of loose change (even the horribly crusty fused mass of coins and dead flies in a jar on the kitchen windowsill) so you can take it to Tesco and run it through the change counter in the hope it will magically turn into real money.
You know that pride is a rod for your own back when you find yourself chucking all the ghastly verdigrised copper into the sink so you can wash it all shiny-clean because heaven forbid someone see you using dirty money.
You know that pride is a rod for your own back when you find yourself chucking all the ghastly verdigrised copper into the sink so you can wash it all shiny-clean because heaven forbid someone see you using dirty money.
Tuesday 29 June 2010
No Homeo
Today the British Medical Association voted to call for the NHS to stop funding Homeopathy.
In a word, Yessss! My natural indifference to seeing stupid people being defrauded of money via their stupidity tends to not quite work the same when the stupid people in question are civil servants or government ministers spending other people's money.
One could point out that homeopathy (a word my spellcheck quite rightly fails to recognise) offers some psychological benefits to some people via the placebo effect, and that just being able to play pretend doctors with someone who lends a sympathetic ear to their problems is of great benefit to many people, but I would argue that such people are stupid people who live in fairy make-believe land and evidence-based pain and suffering are deeply therapeutic for a case of the stupids.
Today, I am more bitter than Bitrex, a fine practical example of the use of negative re-enforcement in the treatment of stupidity.
In a word, Yessss! My natural indifference to seeing stupid people being defrauded of money via their stupidity tends to not quite work the same when the stupid people in question are civil servants or government ministers spending other people's money.
One could point out that homeopathy (a word my spellcheck quite rightly fails to recognise) offers some psychological benefits to some people via the placebo effect, and that just being able to play pretend doctors with someone who lends a sympathetic ear to their problems is of great benefit to many people, but I would argue that such people are stupid people who live in fairy make-believe land and evidence-based pain and suffering are deeply therapeutic for a case of the stupids.
Today, I am more bitter than Bitrex, a fine practical example of the use of negative re-enforcement in the treatment of stupidity.
Monday 28 June 2010
Good Enough
It often amuses me when people talk of something being "second-rate", or if they're feeling especially venomous, "third-rate". They're referring back to the old Royal Navy "system of rating" that was used to classify ships back in the age of sail; very roughly, ships of a hundred guns upwards were classed as first-rate, ships of 90 to 98 were second-rate, ships of 60-80 were third-rate and so on down to the sixth rate 20-24 gunners.
The interesting thing is that bigger was not necessarily better. The backbone of the Royal Navy from the mid 18th to early 19th centuries was the third-rater, as it was for most other fleets- the French came up with the definitive third-rate in their "seventy-four", a number of which we made off with and liked so much that we built our own 74-gun ships to replace our less-seaworthy 70s. A third-rater had less firepower and durability than the larger first and second rates, but was more seaworthy, faster and gun-for-gun, significantly cheaper to build and operate. While you'd want your first and second rate ships for fleet engagements like Trafalgar, most of the day-to-day work of war at sea was performed by third rates.
The third rate was "Good Enough". You might need two third-raters to engage a first-rate, but for the cost of a first-rate, you might be able to build three third-raters, and for a navy maintaining a blockade of Napoleonic France and responsible for protecting a maritime Empire spread across the planet, the third-rater was the way to go.
So next time you're accusing your local football team of being third-rate, you're accusing them of being exactly Good Enough.
The interesting thing is that bigger was not necessarily better. The backbone of the Royal Navy from the mid 18th to early 19th centuries was the third-rater, as it was for most other fleets- the French came up with the definitive third-rate in their "seventy-four", a number of which we made off with and liked so much that we built our own 74-gun ships to replace our less-seaworthy 70s. A third-rater had less firepower and durability than the larger first and second rates, but was more seaworthy, faster and gun-for-gun, significantly cheaper to build and operate. While you'd want your first and second rate ships for fleet engagements like Trafalgar, most of the day-to-day work of war at sea was performed by third rates.
The third rate was "Good Enough". You might need two third-raters to engage a first-rate, but for the cost of a first-rate, you might be able to build three third-raters, and for a navy maintaining a blockade of Napoleonic France and responsible for protecting a maritime Empire spread across the planet, the third-rater was the way to go.
So next time you're accusing your local football team of being third-rate, you're accusing them of being exactly Good Enough.
Intelligent Agents
Note to recruitment agencies: Please don't ask if I sound tired and grumpy "on account of being hung-over after the football". There's so much wrong with that particular assumption, I don't know where to begin; oh wait, I do!
I DON'T WATCH THE SODDING FOOTBALL, AND I'M NOT SO PATHETIC THAT DEFEAT-BY-PROXY IN A GAME SEEMS LIKE A GOOD EXCUSE TO TIE ONE ON. IF I SOUND GRUMPY, IT'S BECAUSE IT'S EIGHT IN THE MORNING AND I HAVE TO GET READY TO GO TO THAT LITTLE RAY OF SUNSHINE, THE JOBCENTRE.
I hate the Jobcentre, I hate unemployment and I hate you. No, not you-the-reader, the Agent-you. You-the-reader, I love. I'll love you even more when I set up AdWords and you click on some of the links...
I DON'T WATCH THE SODDING FOOTBALL, AND I'M NOT SO PATHETIC THAT DEFEAT-BY-PROXY IN A GAME SEEMS LIKE A GOOD EXCUSE TO TIE ONE ON. IF I SOUND GRUMPY, IT'S BECAUSE IT'S EIGHT IN THE MORNING AND I HAVE TO GET READY TO GO TO THAT LITTLE RAY OF SUNSHINE, THE JOBCENTRE.
I hate the Jobcentre, I hate unemployment and I hate you. No, not you-the-reader, the Agent-you. You-the-reader, I love. I'll love you even more when I set up AdWords and you click on some of the links...
Sunday 27 June 2010
Graceful Degradation
Hooray for the latest, greatest indignity of being on t' dole:
- I am out of toilet paper.
- I cannot afford more toilet paper until the government pays me some more Jobseeker's allowance, which will happen on Monday.
- It will take until Wednesday at the earliest for the money to actually be cleared into my account.
What am I doing about it (aside from desperately trying to get a job)? Well, in the medium term, the fact I can't afford food either is helping somewhat. In the short term? I may have a solution for that too.
Parents, eh?
Back when I was only half-orphanned, I was watching a DVD of Lord of the Rings: The Return of the King with my mother, as she loved fantasy-themed stuff. It was the siege of Minas Tirith and the Orcish catapults are catapulting the crap out of the city in fine style:
"It must have been terrible living in those days..."
"What, when Orcs and Elves roamed the land?"
Apparently she meant back in the days of medieval sieges of walled cities, but I have my doubts.
"It must have been terrible living in those days..."
"What, when Orcs and Elves roamed the land?"
Apparently she meant back in the days of medieval sieges of walled cities, but I have my doubts.
Friday 25 June 2010
International Man of Mystery
Today I have mostly been visiting other countries.
I had an interview north of the border so I found myself visiting Scotland for the very first time. Almost exactly half-way between hither and yon, I drove past Gretna Green where I am reliably informed my father was born. No mysterious nostalgic feelings occurred, nor did any ghostly highland music play, although the latter may have been drowned out by KMFDM ripping the system, said system being the car stereo of my totally kicking Toyota Avensis (Diesel).
The fuel cost being what it was (and the train costs being about the same) I am now officially unable to buy any shopping until probably the middle of next week, which means that as my current supplies run out on Sunday, I'm going to lose some weight. Hooray!
It also turns out I am deeply confused by windmills. The new generation of wind-power generators are absolutely huuuuge. The problem is that modern material science and aerodynamics being what they are, the windmills actually look too spindly for their size, so my brain processes them as being smaller than they are. The speed of the blades looks deceptively slow right up until you realise how big the blades actually are and then there's a moment of contextual confusion as the true size becomes apparent. It's all very odd.
And I am very tired. Sleepy-nappy-nap-nap-time is now.
EDIT: In the penultimate sentence of my penultimate paragraph, what I meant to say was "the blades seem to be moving too slowly until your brain realises how big they are, at which point you also realise how fast they're moving", but fatigue was making me gibber more than usual. I should not be allowed to post when tired. Or when not tired.
I had an interview north of the border so I found myself visiting Scotland for the very first time. Almost exactly half-way between hither and yon, I drove past Gretna Green where I am reliably informed my father was born. No mysterious nostalgic feelings occurred, nor did any ghostly highland music play, although the latter may have been drowned out by KMFDM ripping the system, said system being the car stereo of my totally kicking Toyota Avensis (Diesel).
The fuel cost being what it was (and the train costs being about the same) I am now officially unable to buy any shopping until probably the middle of next week, which means that as my current supplies run out on Sunday, I'm going to lose some weight. Hooray!
It also turns out I am deeply confused by windmills. The new generation of wind-power generators are absolutely huuuuge. The problem is that modern material science and aerodynamics being what they are, the windmills actually look too spindly for their size, so my brain processes them as being smaller than they are. The speed of the blades looks deceptively slow right up until you realise how big the blades actually are and then there's a moment of contextual confusion as the true size becomes apparent. It's all very odd.
And I am very tired. Sleepy-nappy-nap-nap-time is now.
EDIT: In the penultimate sentence of my penultimate paragraph, what I meant to say was "the blades seem to be moving too slowly until your brain realises how big they are, at which point you also realise how fast they're moving", but fatigue was making me gibber more than usual. I should not be allowed to post when tired. Or when not tired.
Thursday 24 June 2010
Things to do Before an Interview
Everyone should know the 7 P's of Preparation- Prior Proper Planning Prevents P***-Poor Performance, so here are a couple of things to do before an interview to ensure things go well:
Whoops...
- Get a good night's sleep. The human body is still synchronized to the diurnal dance of day and night, so since it's summertime right now and the nights are short, a couple of hours sleep will do perfectly.
- Good communications are vital if you're travelling a long way for the interview, so make sure your phone is up to scratch by flashing the software to a new version the night before. It is certainly possible that the flashing process may fail part-way through, turning your handset into a shiny and expensive brick, but that hardly ever happens. I mean, you'd have to be using a somewhat ropey fossil laptop and some really terrible flashing software for anything like that to happen, wouldn't you?
Whoops...
Wednesday 23 June 2010
Friendly AND Helpful
Today I have been to NextStep, a "friendly, face-to-face careers advice service". Very friendly.
Here is the friendly view from their friendly car park:
Yes. That is a US Prison-grade electric fence there. A very swish and expensive looking electric fence it is too.
The offices were similarly swish and expensive looking, being a relatively new purpose-built construction on the former site of some exceptionally bad early sixties flats, burying the failed social housing experiment of that era with a particularly mocking rejoinder to the largely jobless people who would once have lived there. Plenty of publicity and glory-shot marketing material covered the site in the particularly hideous puce that Salford council favour these days.
I show up for my appointment as promptly as one might expect given how much free time I have to be on time these days.
The young lady behind the inch-thick optically-perfect bulletproof lexan sneeze-guard asked me for my details which I in turn gave her. Some tapping of keys followed. Then a phone call. Then another phone call.
"I'm sorry, we've no record of you having an appointment."
"But I definitely made one. I have a confirmation letter."
"We don't have you down for an appointment. I'm sorry."
"But I have a letter!"
"I'm sorry."
"Is anyone available, perhaps?"
"I'm sorry, you need to make an appointment."
"Can we make an appointment then?"
"I'm sorry, you need to phone up to book an appointment."
As it turned out, the electric fence must only get switched on at night.
Here is the friendly view from their friendly car park:
Yes. That is a US Prison-grade electric fence there. A very swish and expensive looking electric fence it is too.
The offices were similarly swish and expensive looking, being a relatively new purpose-built construction on the former site of some exceptionally bad early sixties flats, burying the failed social housing experiment of that era with a particularly mocking rejoinder to the largely jobless people who would once have lived there. Plenty of publicity and glory-shot marketing material covered the site in the particularly hideous puce that Salford council favour these days.
I show up for my appointment as promptly as one might expect given how much free time I have to be on time these days.
The young lady behind the inch-thick optically-perfect bulletproof lexan sneeze-guard asked me for my details which I in turn gave her. Some tapping of keys followed. Then a phone call. Then another phone call.
"I'm sorry, we've no record of you having an appointment."
"But I definitely made one. I have a confirmation letter."
"We don't have you down for an appointment. I'm sorry."
"But I have a letter!"
"I'm sorry."
"Is anyone available, perhaps?"
"I'm sorry, you need to make an appointment."
"Can we make an appointment then?"
"I'm sorry, you need to phone up to book an appointment."
As it turned out, the electric fence must only get switched on at night.
Monday 21 June 2010
An end to progress
Stop it! Stop it right now!
Stop what?
Going forwards.
I am sick to death of hearing people use the phrase "going forwards". They use it when one might say "in the future" or "from now on", but as a phrase it has a special taste to it derived from its origin in management-speak. Specifically, it means "Mistakes were made (by the speaker), but (despite the fact that if the listener had made a mistake even one-tenth as serious, they would be fired so fast, air friction would set them on fire) we are all going to pretend we have learned a special lesson from this experience AND NO-ONE IS TO EVER MENTION THIS EVER AGAIN, especially when we make the same exact mistake six months from now, which you can be sure that we will".
When you say "going forwards", you're basically showing the world what a horrible piece of slime you are, so stop it.
Stop what?
Going forwards.
I am sick to death of hearing people use the phrase "going forwards". They use it when one might say "in the future" or "from now on", but as a phrase it has a special taste to it derived from its origin in management-speak. Specifically, it means "Mistakes were made (by the speaker), but (despite the fact that if the listener had made a mistake even one-tenth as serious, they would be fired so fast, air friction would set them on fire) we are all going to pretend we have learned a special lesson from this experience AND NO-ONE IS TO EVER MENTION THIS EVER AGAIN, especially when we make the same exact mistake six months from now, which you can be sure that we will".
When you say "going forwards", you're basically showing the world what a horrible piece of slime you are, so stop it.
Does he get a Blue Peter badge for that?
In pointless celebrity news, I've noticed that my favourite newspaper columnist Charlie Brooker is getting hitched to alarmingly attractive former Blue Peter presenter Konnie Huq. This is good news both because I like it when people I like have nice things happen to them, but also for me as it boosts my belief that despite looking like a sack of particularly lumpy potatoes, I too might yet lure in a beautiful female type using my sarcastic wit and charm.
If wit and charm fails, I shall try chocolate.
If wit and charm fails, I shall try chocolate.
Thursday 17 June 2010
So Horny (Horny Horny Horny)
This week I have been listening to football fans weeping bitter tears over the Vuvuzela and how much it is spoiling their enjoyment of the world cup.
Two points:
1. Go watch some newsreel footage of any British football match up to the sixties. Every time there's a crowd shot, you'll notice that everyone in the crowd has a very large wooden football rattle (and a wooly bobble-hat, but that's beside the point). No doubt contemporary newsreel audiences in South Africa and then-Rhodesia were cursing those idiots with the rattly things for ruining the atmosphere and giving them headaches. The point is that football culture varies from time to time and place to place, so perhaps it shouldn't be a surprise when you see some of those differences at the World Cup.
2. The Vuvuzela is the very embodiment of the sound of football. Seriously. Whenever people start talking about football, to me it sounds exactly like someone blowing a Vuvuzela for hours on end. HOW DO YOU LIKE IT, EHHHH?
Two points:
1. Go watch some newsreel footage of any British football match up to the sixties. Every time there's a crowd shot, you'll notice that everyone in the crowd has a very large wooden football rattle (and a wooly bobble-hat, but that's beside the point). No doubt contemporary newsreel audiences in South Africa and then-Rhodesia were cursing those idiots with the rattly things for ruining the atmosphere and giving them headaches. The point is that football culture varies from time to time and place to place, so perhaps it shouldn't be a surprise when you see some of those differences at the World Cup.
2. The Vuvuzela is the very embodiment of the sound of football. Seriously. Whenever people start talking about football, to me it sounds exactly like someone blowing a Vuvuzela for hours on end. HOW DO YOU LIKE IT, EHHHH?
Wednesday 16 June 2010
Adventures in interviewing; also, locks.
Today has not been a good day.
I was supposed to be interviewing for a position up in County Durham today, but a lack of properly defined processes got in the way.
At least that's my excuse.
What happened? Well, for a start, the JobCentre failed to meet a defined constraint by paying my Jobseeker's Allowance on time, meaning I didn't have any money for travel. At the moment, thanks to the Flexible New Deal, I have to pay travel expenses out of my own pocket and then give receipts in order to get reimbursed, which is assuming the FND provider in question has any money in petty cash, because if they don't, well they won't.
This led to a failed early GO/NOGO decision gate and caused an unplanned mission hold prior to FINAL COMMIT until I scrounged up enough pennies for Diesel, with the decision gate only being passed quite literally at the last possible minute. Unfortunately in the mad panic, a critical flaw in the whole procedure arose.
When changing into my interview attire, I neglected to pick up my keys.
Locking yourself out of the house is never good. It is doubly not good when you need to be somewhere else in order to secure your financial future, whose present parlous state means you can't afford a locksmith or replacement glass for a punched-out window.
End solution: Rapid application of Human Resources to Technical Problem. I shoulder-barged the door.
Springing the door was surprisingly easy. Worryingly so, in fact. Remarkably little damage was done to the door frame; a couple of longer screws should fix things right up, along with some no-more-nails or Polyfilla, perhaps.
I wonder if I should add "Intrusion Specialist" to my CV and go for a job in Internet Security?
I was supposed to be interviewing for a position up in County Durham today, but a lack of properly defined processes got in the way.
At least that's my excuse.
What happened? Well, for a start, the JobCentre failed to meet a defined constraint by paying my Jobseeker's Allowance on time, meaning I didn't have any money for travel. At the moment, thanks to the Flexible New Deal, I have to pay travel expenses out of my own pocket and then give receipts in order to get reimbursed, which is assuming the FND provider in question has any money in petty cash, because if they don't, well they won't.
This led to a failed early GO/NOGO decision gate and caused an unplanned mission hold prior to FINAL COMMIT until I scrounged up enough pennies for Diesel, with the decision gate only being passed quite literally at the last possible minute. Unfortunately in the mad panic, a critical flaw in the whole procedure arose.
When changing into my interview attire, I neglected to pick up my keys.
Locking yourself out of the house is never good. It is doubly not good when you need to be somewhere else in order to secure your financial future, whose present parlous state means you can't afford a locksmith or replacement glass for a punched-out window.
End solution: Rapid application of Human Resources to Technical Problem. I shoulder-barged the door.
Springing the door was surprisingly easy. Worryingly so, in fact. Remarkably little damage was done to the door frame; a couple of longer screws should fix things right up, along with some no-more-nails or Polyfilla, perhaps.
I wonder if I should add "Intrusion Specialist" to my CV and go for a job in Internet Security?
Tuesday 15 June 2010
Nuts and Gum, together at last
Latest in the big list of surprising things that have surprised me is news that two of my favourite authors, Terry Pratchett and Stephen Baxter are working on a collaboration.
I would never in a million years have expected a collaboration between these two particular authors. I was going to write a post about how to Baxter, the universe is a cold, dark place that cares nothing for humanity and its interests because it *cannot* care, whilst to Pratchett uh...
Actually, to Pratchett the universe is also a cold, dark place that cares nothing blah blah blah; he says as much repeatedly, especially in the books with Death as a major character. To him, people are what create the islands of warmth and light in an uncaring universe, even if "warmth" and "light" are just concepts we make up to feel better about ourselves.
And whilst Baxter's universes are generally bleak and uncaring backdrops against which we labour for naught in the face of oblivion, even his characters manage changes for the better; they end a futile ten-thousand year long war that has consumed tens of trillions of human lives, or they may manage to help build a defence against a galaxy-spanning catastrophe that will extinguish all intelligent life, even if they can't stop the more immediate catastrophe that's going to kill off all the intelligent life in the Orion Arm, including Homo Sap.
So really, both Pratchett and Baxter are deep-down optimists in a realist world.
I would never in a million years have expected a collaboration between these two particular authors. I was going to write a post about how to Baxter, the universe is a cold, dark place that cares nothing for humanity and its interests because it *cannot* care, whilst to Pratchett uh...
Actually, to Pratchett the universe is also a cold, dark place that cares nothing blah blah blah; he says as much repeatedly, especially in the books with Death as a major character. To him, people are what create the islands of warmth and light in an uncaring universe, even if "warmth" and "light" are just concepts we make up to feel better about ourselves.
And whilst Baxter's universes are generally bleak and uncaring backdrops against which we labour for naught in the face of oblivion, even his characters manage changes for the better; they end a futile ten-thousand year long war that has consumed tens of trillions of human lives, or they may manage to help build a defence against a galaxy-spanning catastrophe that will extinguish all intelligent life, even if they can't stop the more immediate catastrophe that's going to kill off all the intelligent life in the Orion Arm, including Homo Sap.
So really, both Pratchett and Baxter are deep-down optimists in a realist world.
Sunday 13 June 2010
Suddenly, It's all about the Revision Control
Nerd Time is NOW, so normal folk should go grab some beers and get drunk, or alternately read the post and play "Guess-When-Zinc-forgot-the-point-he-was-going-to-make"
Aaannyway, this week I have been playing around with a Revision Control System on my laptop, a pleasing exercise in avoiding writing actual code.
When you're part of a team writing software, it's nice if everybody can see the code that is being worked on. In Olden Times (1992) at my very first job with computers, we just whacked all the source code into a shared directory on the network so everyone could see it, and that was that.
This lead to problems.
The biggest set of problems it causes are to do with Concurrency, or what happens when two many cooks are working on the same pan of broth. One cook decides that the broth needs some salt and goes to get the fancy salt cellar from the bread bin (which is a perfectly sensible place to keep salt, I don't care what you think). While he's away at the other end of the kitchen, one of the other cooks also decides that the broth needs salt and wanders off to find wherever it is that his idiot co-workers (none of whom ever talk to each other) have hidden it. In the meantime, first cook comes back and adds salt. Delicious! However, second cook is still out there looking for the salt and eventually (after he either finds the salt or goes out to buy more) comes back and adds some more. Now it is too salty and all this sodium makes the customer's heart sad :(
Actually that was a terrible analogy but I'm leaving it in because I like soup. In programming terms, what can happen is that both programmers start out with a copy of the same file (version 1) and make their changes. Programmer A finishes his changes and saves the file, which is now Version 1.1A. Eventually, programmer B finishes his changes, but is unaware that Programmer A has changed the file already, so when he saves his changes, he overwrites Programmer A's changes and replaces Version 1.1A with his own version 1.1B.
You could fix this by implementing a file "locking" mechanism so that when programmer A starts making his changes, he locks the file under edit so that no-one else can touch it (or at least get lots of whiny prompts about the file being locked and read-only when they try). This still leaves you with a couple of problems, one new and one old.
The first problem with this is that it can lead to a situation where half your programmers are sat around being forced to search the internet for nude pictures of Karen Gillan because they all want to make changes to the same file. It rather makes having a central copy of the source a waste of time if it limits the numbers of programmers who can use it at any given time. The next thing you know, everyone's making local copies of the source "to work on" and things get very bad very quickly.
The second problem is what happens when say two programmers are making changes to separate files, File A and File 2... er, File B. Great, no problem! Except that the changes in the new version of File A are dependant on File B, and specifically they were dependant on the old version of file B, which just got changed. No-one's changes have been lost, but the central copy of the source is now in an uncompilable state if you're lucky (at least that way tracing the problem is relatively straightforwards) or worse still, crashes at runtime and you're going to have to do a boatload of debugging to find out what's going on.
How do you solve these problems? Well, hopefully you install a Revision Control System like Subversion. It won't exactly prevent these problems, but it helps you fix them when they show up.
How's it manage that then? Well, basically files stored in a Revision Control System are stored as a set of changes to the repository. Create an empty repository, that's revision 1, add a file to the repository, that's revision 2, make some edits to the file for revision 3 and add another file for revision 4. Note that file versions differ from repository revisions; version 1.0 and 1.1 of a file might be revisions 56 and 1441 respectively if a lot of other files were changed between the two versions .
Users don't work directly on the repository, they work on local copies of the files stored in the repository, copied by the Revison Control System at a given revision level which is usually the "latest" or head revision at the time the local copy is requested or "checked out". The programmer can then edit their local copy and then submit their changes back to the repository as a new revision (a given revision can potentially affect multiple files in the repository). This gets rid of the first problem with locking as everyone can work quite freely on their local copy.
So what about the concurrency issues that locking was supposed to stop? Well, with a Revision Control System, the magic happens when the user submits their changes. The system looks at what is being changed and checks if it has had any other changes to those files since you took your local copy. If it has, the user has to go through a merge process where they inspect both sets of changes and combine them into one good working set. This may be as simple as spotting that neither set of changes conflicts and adding them both to the same file automatically, or it may require rather more complex editing. Once you've done, you can check in your merged changes.
In the case of changes to two separate files whose interdependency is only going to show up at compile time, chances are that the Revision Control System won't spot any potential problem itself, but will give the developers the tools to spot potential problems and to deal with them much more effectively when they do arise. The Revision Control System can show you if your local copy is still out-of-step with the actual repository after you've made a submission, indicating that the potential exists for a dependency conflict. A reasonable developer will then check out the latest head revision of the code and do a quick build to make sure everything's all right.
A better developer might do an update-and-build smoketest before they submit their changes to the repository in an attempt to not check in code that won't compile. I say that as a fan of Continuous Integration, who tried to instil in my colleagues a terrible fear of breaking the nightly build.
If something does slip through, the Revision Control System offers help. You can browse through all the submissions since the last good revision to see if any of them look problematic, which can help speed the fix along. You can also check out earlier revisions than the bad one if you need to keep working on something else while other developers work on fixing the problem.
All in all, Revision Control Systems are an absolutely vital part of modern software development, to the point that I use one on projects where I'm the only person working on them, as the ability to track development history and easily manage branches and releases are just as vital as preventing concurrency issues on a shared codebase. The funny thing is that even now, new programmers are managing to come straight out of college/university with no experience in these vital tools, or much of any experience in working as part of a development team. It's a conflict between the need to train good developers who are going to have to be good team-workers a lot of the time, and the need for the college to be able to individually assess the progress and ability of their students.
Aaannyway, this week I have been playing around with a Revision Control System on my laptop, a pleasing exercise in avoiding writing actual code.
When you're part of a team writing software, it's nice if everybody can see the code that is being worked on. In Olden Times (1992) at my very first job with computers, we just whacked all the source code into a shared directory on the network so everyone could see it, and that was that.
This lead to problems.
The biggest set of problems it causes are to do with Concurrency, or what happens when two many cooks are working on the same pan of broth. One cook decides that the broth needs some salt and goes to get the fancy salt cellar from the bread bin (which is a perfectly sensible place to keep salt, I don't care what you think). While he's away at the other end of the kitchen, one of the other cooks also decides that the broth needs salt and wanders off to find wherever it is that his idiot co-workers (none of whom ever talk to each other) have hidden it. In the meantime, first cook comes back and adds salt. Delicious! However, second cook is still out there looking for the salt and eventually (after he either finds the salt or goes out to buy more) comes back and adds some more. Now it is too salty and all this sodium makes the customer's heart sad :(
Actually that was a terrible analogy but I'm leaving it in because I like soup. In programming terms, what can happen is that both programmers start out with a copy of the same file (version 1) and make their changes. Programmer A finishes his changes and saves the file, which is now Version 1.1A. Eventually, programmer B finishes his changes, but is unaware that Programmer A has changed the file already, so when he saves his changes, he overwrites Programmer A's changes and replaces Version 1.1A with his own version 1.1B.
You could fix this by implementing a file "locking" mechanism so that when programmer A starts making his changes, he locks the file under edit so that no-one else can touch it (or at least get lots of whiny prompts about the file being locked and read-only when they try). This still leaves you with a couple of problems, one new and one old.
The first problem with this is that it can lead to a situation where half your programmers are sat around being forced to search the internet for nude pictures of Karen Gillan because they all want to make changes to the same file. It rather makes having a central copy of the source a waste of time if it limits the numbers of programmers who can use it at any given time. The next thing you know, everyone's making local copies of the source "to work on" and things get very bad very quickly.
The second problem is what happens when say two programmers are making changes to separate files, File A and File 2... er, File B. Great, no problem! Except that the changes in the new version of File A are dependant on File B, and specifically they were dependant on the old version of file B, which just got changed. No-one's changes have been lost, but the central copy of the source is now in an uncompilable state if you're lucky (at least that way tracing the problem is relatively straightforwards) or worse still, crashes at runtime and you're going to have to do a boatload of debugging to find out what's going on.
How do you solve these problems? Well, hopefully you install a Revision Control System like Subversion. It won't exactly prevent these problems, but it helps you fix them when they show up.
How's it manage that then? Well, basically files stored in a Revision Control System are stored as a set of changes to the repository. Create an empty repository, that's revision 1, add a file to the repository, that's revision 2, make some edits to the file for revision 3 and add another file for revision 4. Note that file versions differ from repository revisions; version 1.0 and 1.1 of a file might be revisions 56 and 1441 respectively if a lot of other files were changed between the two versions .
Users don't work directly on the repository, they work on local copies of the files stored in the repository, copied by the Revison Control System at a given revision level which is usually the "latest" or head revision at the time the local copy is requested or "checked out". The programmer can then edit their local copy and then submit their changes back to the repository as a new revision (a given revision can potentially affect multiple files in the repository). This gets rid of the first problem with locking as everyone can work quite freely on their local copy.
So what about the concurrency issues that locking was supposed to stop? Well, with a Revision Control System, the magic happens when the user submits their changes. The system looks at what is being changed and checks if it has had any other changes to those files since you took your local copy. If it has, the user has to go through a merge process where they inspect both sets of changes and combine them into one good working set. This may be as simple as spotting that neither set of changes conflicts and adding them both to the same file automatically, or it may require rather more complex editing. Once you've done, you can check in your merged changes.
In the case of changes to two separate files whose interdependency is only going to show up at compile time, chances are that the Revision Control System won't spot any potential problem itself, but will give the developers the tools to spot potential problems and to deal with them much more effectively when they do arise. The Revision Control System can show you if your local copy is still out-of-step with the actual repository after you've made a submission, indicating that the potential exists for a dependency conflict. A reasonable developer will then check out the latest head revision of the code and do a quick build to make sure everything's all right.
A better developer might do an update-and-build smoketest before they submit their changes to the repository in an attempt to not check in code that won't compile. I say that as a fan of Continuous Integration, who tried to instil in my colleagues a terrible fear of breaking the nightly build.
If something does slip through, the Revision Control System offers help. You can browse through all the submissions since the last good revision to see if any of them look problematic, which can help speed the fix along. You can also check out earlier revisions than the bad one if you need to keep working on something else while other developers work on fixing the problem.
All in all, Revision Control Systems are an absolutely vital part of modern software development, to the point that I use one on projects where I'm the only person working on them, as the ability to track development history and easily manage branches and releases are just as vital as preventing concurrency issues on a shared codebase. The funny thing is that even now, new programmers are managing to come straight out of college/university with no experience in these vital tools, or much of any experience in working as part of a development team. It's a conflict between the need to train good developers who are going to have to be good team-workers a lot of the time, and the need for the college to be able to individually assess the progress and ability of their students.
Subscribe to:
Posts (Atom)