I have many techy friends. They all have wifi. Which means, if I visit them, I have to go through a long and tortuous route to use their internet connection - because a combination of UK law and common sense make using encryption on your wifi really rather important.
I don't have this problem in hotels.
In hotels, When I try to use the wifi, they just intercept my DNS requests, rerouting me to a page where I can enter my credit card details. From this they can then give anyone with my MAC address access to the internet. It works well.
Why can't home routers do this?
When I go to a friends house, I should fire up my browser and get a login page. My friend can then either give me a guest password (which will give me access for a few hours), or give me a username and password of my own (to give me access whenever I want).
Now - this will only give MAC level security - which I guess isn't perfect 9although it seems to work for hotels), but it would also provide an easy route (over the web, once you've logged in) to provide all the other information needed to configure a computer to use the router's security features.
Thursday 27 May 2010
Monday 24 May 2010
Incredible Machines
It has become a running joke between me and my friends that satellites read my mind, and then distribute my ideas to other people (who make money out of them). I don't believe this (although the whole point of this website was to rip apart the satellite mind reader's monopoly on my ideas... also, possibly I should later write an article on the idea I have for selling peoples ideas via a satellite network...)
The first idea I remember having, which I quickly saw someone else creating, was for a computer game. My idea was that yo0u controlled a cartoon cat who had to maneuver items around a levels and ladders type screen to construct a Heath Robinson style machine to trap a cartoon mouse. This was back in the days of Tetris and similar puzzle games, you understand.
Not long after, I started seeing adverts for "The Incredible Machine", not quite the same idea, but similar enough - and different enough from existing games - to be a shock. At a still very young age I was having ideas in a similar league to professionals. (Of course - I now know that no professionals have ideas and better than those of a fifteen year old kid - but at the time it was a learning experience)
So, that is my story... except
Heath Robinson machines keep coming back. We've had Honda adverts with car parts rolling across our TV screens and winning awards. People like the Heath Robinson.
And we have graphic cards which render 3D scenes that look better than reality (actually, this is a lie - except for in football games. I now notice that football on TV looks significantly less good than in computer games). And we have physics engines.
Its time for the incredible machine to return. In 3D.
Or - if not the incredible machine - why not a similar 3D game about a cat trying to catch a mouse?
The first idea I remember having, which I quickly saw someone else creating, was for a computer game. My idea was that yo0u controlled a cartoon cat who had to maneuver items around a levels and ladders type screen to construct a Heath Robinson style machine to trap a cartoon mouse. This was back in the days of Tetris and similar puzzle games, you understand.
Not long after, I started seeing adverts for "The Incredible Machine", not quite the same idea, but similar enough - and different enough from existing games - to be a shock. At a still very young age I was having ideas in a similar league to professionals. (Of course - I now know that no professionals have ideas and better than those of a fifteen year old kid - but at the time it was a learning experience)
So, that is my story... except
Heath Robinson machines keep coming back. We've had Honda adverts with car parts rolling across our TV screens and winning awards. People like the Heath Robinson.
And we have graphic cards which render 3D scenes that look better than reality (actually, this is a lie - except for in football games. I now notice that football on TV looks significantly less good than in computer games). And we have physics engines.
Its time for the incredible machine to return. In 3D.
Or - if not the incredible machine - why not a similar 3D game about a cat trying to catch a mouse?
Thursday 20 May 2010
Simple Scanner
There are a number of portable scanners, like the Doxie and Fujtsu Scan Snap, all promising to make the paperless office a reality. And all requiring you to lug around a laptop in order to power them and download the scanned files.
A propose a portable scanner which can be charged like a mobile phone (over micro usb) and can then save the scanned documents onboard until you are ready to pull them off later. This way, you only have the portable scanner to lug around most of the time.
A propose a portable scanner which can be charged like a mobile phone (over micro usb) and can then save the scanned documents onboard until you are ready to pull them off later. This way, you only have the portable scanner to lug around most of the time.
Monday 17 May 2010
Voting Survey
As I write this, the election is drawing near in the UK. By the time you read this it will have been and gone, and we'll be in a brave new world, totally different fromt he one before May 6th. Or something.
Right now, there are many websites which allow you to say how much to like particular policies. You make your choices, and the site tells you who to vote for. A sample of 1 (me) suggests they work fairly well.
There is also a campaign called Power 2010. Power 2010 is interesting, it set itself up as a policitcal pressure group without any aims, then got people to vote for the goals the group should have.
Power 2010 was broken - because the voting meant they would focus on the top 5 policies - even though only a minority of people may have wanted those policies - and there may have been noone that agreed with all five.
My suggestion is different: take the voting survey, but track how people answer. From this, you might be able to find 'clumps' of policies that many people agree with - or at least that more people agree with more of than they do with any existing political party. In essence, you could reverse engineer part politics and come up with a more attractive framework than the one presently suggested. And you may find new ideas - like liberty or small c conservatism which transcend parties entirely
Right now, there are many websites which allow you to say how much to like particular policies. You make your choices, and the site tells you who to vote for. A sample of 1 (me) suggests they work fairly well.
There is also a campaign called Power 2010. Power 2010 is interesting, it set itself up as a policitcal pressure group without any aims, then got people to vote for the goals the group should have.
Power 2010 was broken - because the voting meant they would focus on the top 5 policies - even though only a minority of people may have wanted those policies - and there may have been noone that agreed with all five.
My suggestion is different: take the voting survey, but track how people answer. From this, you might be able to find 'clumps' of policies that many people agree with - or at least that more people agree with more of than they do with any existing political party. In essence, you could reverse engineer part politics and come up with a more attractive framework than the one presently suggested. And you may find new ideas - like liberty or small c conservatism which transcend parties entirely
Thursday 13 May 2010
Programming Tools: Versioning (and magic)
The programming tools series of articles (which, I know, I promised I had already finished) relied heavily on the version control system at its heart.
Today I want to talk about a new feature of versioning: Magic Files
Imagine, I check into the version control system my source code (or a gif), I want the facility to say to the VCS "now give me the compiled code" (or "now give me a jpeg version of the gif"). The VCS - not me - should know how to generate the file I'm asking for. Because there should be rules which tell the VCS how to generate the file
Now, because we can make a rule that any such process should be side-affect free, once the VCS has generate the file, it can keep a copy of it, at least until one of the files that were used in generating it has changed. And there is nothing to say that the VCS has to wait for someone to ask for the file before it generates it - if it sees free processor time, the VCS can spawn compilation.
We can take this further: why not just check out your test results file: that would run every test and tell you how it did. And running an individual test [by looking at the individual test results log] would just check out the files it needed to run - which means only the files needed to perform a test would be compiled - leading to the optimal code-compile-test loop.
In short, I'm talking about merging the version control system and make.
Its a different world - and one which probably requires far more storage (and a few extra VCS features such as a 'regenerate' option to regenerate a file which for some reason went awry) - but one which feels to me more inherently usable, and which provides us with more records of exactly what has and hasn't been run.
Today I want to talk about a new feature of versioning: Magic Files
Imagine, I check into the version control system my source code (or a gif), I want the facility to say to the VCS "now give me the compiled code" (or "now give me a jpeg version of the gif"). The VCS - not me - should know how to generate the file I'm asking for. Because there should be rules which tell the VCS how to generate the file
Now, because we can make a rule that any such process should be side-affect free, once the VCS has generate the file, it can keep a copy of it, at least until one of the files that were used in generating it has changed. And there is nothing to say that the VCS has to wait for someone to ask for the file before it generates it - if it sees free processor time, the VCS can spawn compilation.
We can take this further: why not just check out your test results file: that would run every test and tell you how it did. And running an individual test [by looking at the individual test results log] would just check out the files it needed to run - which means only the files needed to perform a test would be compiled - leading to the optimal code-compile-test loop.
In short, I'm talking about merging the version control system and make.
Its a different world - and one which probably requires far more storage (and a few extra VCS features such as a 'regenerate' option to regenerate a file which for some reason went awry) - but one which feels to me more inherently usable, and which provides us with more records of exactly what has and hasn't been run.
Monday 10 May 2010
Gluten Free Holidays
Sometimes an idea seems so obvious, you assume people have already had it, and I've just not noticed. This is one such idea - I can't believe it isn't already happening on some scale out there somewhere.
Nevertheless, I have not come across it. And so...
I like to travel. Its a change of pace, a breath of fresh air. And until recently, it was easy: just book a flight, find a hotel and go. The world was my marine mollusk.
Not any more.
Because I am gluten-intolerant. Which means I can't eat anything with gluten in it. At all. I notice even the slightest bit of contamination. And I know that any gluten I notice, means the lining of my gut has noticed even more - and even if I'm not paying for it now, I'll pay for it later.
A quick experiment of going back onto gluten fully showed it sapped more or less all of my energy, and slowed most of my thought processes. It took well over a fortnight for my body to even begin to adapt to coping with gluten again. I can't go back.
Which makes travelling hard.
Because before, I could pop into any restaurant and order whatever I fancied. Now I have no such option. Before I could eat anything and everything. Now I have to be careful. and in the UK, I know how to be careful. I know how to read the labels. I know what is and isn't likely to cause me grief.
But drop me on a street in Calcutta, and I'm going to be stumped.
So I propose Gluten Free Holidays. There are holiday companies that specialise in all sorts of things. Why not a company that specialises in a few trips each year for people who have allergies and intolerances to food. These trips will be 100% full board. The travel company will make sure that the hotels know exactly how to cater for the eating requirements of their guests. The travel agency will liaise with airlines to ensure the right quantity of special meals are laid on.
Much of the world doesn't use wheat as a staple - in India, for example, rice and chick-peas win. There is no reason why it should be hard to find appropriate and, where desired, culturally authentic food. I might just be talking about practical holidays here... but I might also be talking about gourmet tours.
In any event, Gluten Free Holidays would open the world to those of us who have shied away due to food finding problems
Nevertheless, I have not come across it. And so...
I like to travel. Its a change of pace, a breath of fresh air. And until recently, it was easy: just book a flight, find a hotel and go. The world was my marine mollusk.
Not any more.
Because I am gluten-intolerant. Which means I can't eat anything with gluten in it. At all. I notice even the slightest bit of contamination. And I know that any gluten I notice, means the lining of my gut has noticed even more - and even if I'm not paying for it now, I'll pay for it later.
A quick experiment of going back onto gluten fully showed it sapped more or less all of my energy, and slowed most of my thought processes. It took well over a fortnight for my body to even begin to adapt to coping with gluten again. I can't go back.
Which makes travelling hard.
Because before, I could pop into any restaurant and order whatever I fancied. Now I have no such option. Before I could eat anything and everything. Now I have to be careful. and in the UK, I know how to be careful. I know how to read the labels. I know what is and isn't likely to cause me grief.
But drop me on a street in Calcutta, and I'm going to be stumped.
So I propose Gluten Free Holidays. There are holiday companies that specialise in all sorts of things. Why not a company that specialises in a few trips each year for people who have allergies and intolerances to food. These trips will be 100% full board. The travel company will make sure that the hotels know exactly how to cater for the eating requirements of their guests. The travel agency will liaise with airlines to ensure the right quantity of special meals are laid on.
Much of the world doesn't use wheat as a staple - in India, for example, rice and chick-peas win. There is no reason why it should be hard to find appropriate and, where desired, culturally authentic food. I might just be talking about practical holidays here... but I might also be talking about gourmet tours.
In any event, Gluten Free Holidays would open the world to those of us who have shied away due to food finding problems
Thursday 6 May 2010
The Meeting Manager
This is a small part of a bigger idea - but this came first, and would be a useful product on its own.
Companies have meetings. When I invented this idea, I was part of a small startup, and we were having too many meetings. Within a few days of this idea popping unbidden into my head, the startup merged with another company, and the number of meetings skyrocketed. Now I've moved to a big corporate behemoth. I think all I do these days is meet. And prepare to meet. And sometimes have met. Also I write software, but that's strictly on my own time...
Meetings have a format. Its not hard - but so often people forget to follow it. And when the format is not followed, meetings become more and more of a waste of time.
The format - for those who don't know - is
An agenda is sent to all invitees. This allows people to decide if they need to come to the meeting (well, in general the people the agenda is sent to, are expected to attend - or apologise, the people it is cc.ed to can attend if they want)
A reminder is sent nearer to the time.
People arrive at the meeting. It starts on time.
The minutes of the last meeting are read out. People have the opportunity to accept them or reject them (this is tricky. In the email age, we can let people accept or reject minutes before the next meeting)
Each action from the minutes is discussed. The person who is actioned reports on their progress.
We then move through each agenda item in turn. At the end of each item it is decided if any actions need to be taken. These actions, and the people actioned are agreed upon there and then.
Finally we get to Any Other Business (AOB). In general there should not be any other business - you have had the agenda ahead of time, you should have been able to contact the writer of the agenda and get your item submitted so that people can prepare. The chairman needs to be firm here.
If it is agreed that a further meeting is needed, the time and date should be set.
Following the meeting - within the next 24 hours or so, minutes should be sent out - to all invitees. They should also be made available online to other people with an interest.
Much of this can be automated.
First - the list of invitees: this is often going to stay much the same for each meeting type. Sure, their may be the occasional guest or change in group member, but lists of group members can be maintained to ensure we know exactly who has been invited.
The agenda: this can be sent out by email (for people where an email address exists) and by post (for people where we only have a postal address). Software can make the decision as appropriate. But we can also provide a website which people can connect to to suggest changes or additions to the agenda. This makes collating the agenda an open and collaborative task.
The reminder: This can be automatically sent out
The meeting: Google have talked about an interesting trick - when they hold meetings, each agenda item is given a fixed period of time. On a screen the agenda and a clock are displayed - you know from this exactly what agenda item you should be on, and how long you have left to discuss it.
More importantly, you can display the current agenda item on a screen so that people know what is discussed. As decisions are made, or actions are assigned, these can be input into the computer by either the secretary or the chair. People can see them as they are added - this makes contesting the minutes later on harder.
You can also automatically import the action items from previous meetings for discussion as the meeting begins.
When the meeting concludes, you will already have half of your minutes. The secretary can add any additional detail from his or her notes, and then send them out to everyone involved (again, printing those which need to be posted). The minutes will also be automatically uploaded to an internal document repository (so they can be view by the appropriate people)
Since the new minutes are now online and available, people have the opportunity to comment on them - accept them or reject them straight away. This means revised minutes can be produced, making agreement more likely at the next meeting. people can also make notes on their own actions, so that their status is visible to everybody involved.
None of this is essential, and most of it could be done within some of the better business process and business document management tools. But a standalone tool which does this easily and perfectly without rough edges would be sure to win fans amongst those who like their meetings to run like clockwork.
Companies have meetings. When I invented this idea, I was part of a small startup, and we were having too many meetings. Within a few days of this idea popping unbidden into my head, the startup merged with another company, and the number of meetings skyrocketed. Now I've moved to a big corporate behemoth. I think all I do these days is meet. And prepare to meet. And sometimes have met. Also I write software, but that's strictly on my own time...
Meetings have a format. Its not hard - but so often people forget to follow it. And when the format is not followed, meetings become more and more of a waste of time.
The format - for those who don't know - is
An agenda is sent to all invitees. This allows people to decide if they need to come to the meeting (well, in general the people the agenda is sent to, are expected to attend - or apologise, the people it is cc.ed to can attend if they want)
A reminder is sent nearer to the time.
People arrive at the meeting. It starts on time.
The minutes of the last meeting are read out. People have the opportunity to accept them or reject them (this is tricky. In the email age, we can let people accept or reject minutes before the next meeting)
Each action from the minutes is discussed. The person who is actioned reports on their progress.
We then move through each agenda item in turn. At the end of each item it is decided if any actions need to be taken. These actions, and the people actioned are agreed upon there and then.
Finally we get to Any Other Business (AOB). In general there should not be any other business - you have had the agenda ahead of time, you should have been able to contact the writer of the agenda and get your item submitted so that people can prepare. The chairman needs to be firm here.
If it is agreed that a further meeting is needed, the time and date should be set.
Following the meeting - within the next 24 hours or so, minutes should be sent out - to all invitees. They should also be made available online to other people with an interest.
Much of this can be automated.
First - the list of invitees: this is often going to stay much the same for each meeting type. Sure, their may be the occasional guest or change in group member, but lists of group members can be maintained to ensure we know exactly who has been invited.
The agenda: this can be sent out by email (for people where an email address exists) and by post (for people where we only have a postal address). Software can make the decision as appropriate. But we can also provide a website which people can connect to to suggest changes or additions to the agenda. This makes collating the agenda an open and collaborative task.
The reminder: This can be automatically sent out
The meeting: Google have talked about an interesting trick - when they hold meetings, each agenda item is given a fixed period of time. On a screen the agenda and a clock are displayed - you know from this exactly what agenda item you should be on, and how long you have left to discuss it.
More importantly, you can display the current agenda item on a screen so that people know what is discussed. As decisions are made, or actions are assigned, these can be input into the computer by either the secretary or the chair. People can see them as they are added - this makes contesting the minutes later on harder.
You can also automatically import the action items from previous meetings for discussion as the meeting begins.
When the meeting concludes, you will already have half of your minutes. The secretary can add any additional detail from his or her notes, and then send them out to everyone involved (again, printing those which need to be posted). The minutes will also be automatically uploaded to an internal document repository (so they can be view by the appropriate people)
Since the new minutes are now online and available, people have the opportunity to comment on them - accept them or reject them straight away. This means revised minutes can be produced, making agreement more likely at the next meeting. people can also make notes on their own actions, so that their status is visible to everybody involved.
None of this is essential, and most of it could be done within some of the better business process and business document management tools. But a standalone tool which does this easily and perfectly without rough edges would be sure to win fans amongst those who like their meetings to run like clockwork.
Monday 3 May 2010
Micropayments (not quite dead yet)
Every so often someone suggests the saviour of the Internet will be micropayments. Well, I wasn't really aware the internet was dying, but assuming that it is, and I'm just not being very observant, I notice that none of the micropayment systems actually seem to work particularly well.
Lets assume that no-one cares about privacy here. But we do care that people can get started using the system with essentially no financial risk. And we only care about very small transactions - sub 10 UK pence.
Now, sub-10p prices don't make much sense from the perspective of credit card transactions - the transaction costs are to high. But we are not talking about the credit card world - we are talking about a world where the game is simpler, and the issues of protecting transactions are smaller.
Now, several people could set themselves up as micropayment agencies. Lets assume 3 companies do this, google, amazon and paypal.
They all choose to follow the same system - when a user goes to a micropayment site, the site displays a form following a particular microformat. The user enters their username and the address of their chosen server - this is transmitted back to the host, who we then are redirected to in order to complete the transaction. Finally we are sent back to the host, along with a special token signed by the issuing agency promising to pay some quantity of money.
So far so good. Buts its quite cumbersome. I assume each of these companies might provide a browser addon to recognise the payment microformat, and do all the work automatically - at least on approved sites.
But even this isn't enough. I don't want to pay any money up front, because I don't know if anyone will actually accept micropayments. But neither google, amazon or paypal know me... so they come up with different approaches to get me paying.
Paypal say: You already have a paypal account, stick some money in there, and we'll pass it on. You can always withdraw it if you want.
Google say: Since you haven't given us any money upfront, when we redirect you back to the site, we will embed it in a frame and show you some adverts. We will try to recoup the cash from the ads.
Amazon say: We're going to trust you. We'll sub you a bit of money, and then overcharge you later to try to make up our loss - and our rep.
So paypal will just work - the website returns its tokens and paypal hands over the cash (the token is signed to identify the owner and paypal, so there is no question of duplication)
But amazon and google are risky. Google hand over the money made by the adverts (up to 150% the amount the site was actually charging... google keep the rest). This means sometimes you get paid less than you asked by google, sometimes you get paid more. Amazon will pay some percentage of their weeks total income - which may mean they pay more or less again than the site requested... because amazon generally charge people 11p to enter a 10p site, they can make up for the fact that they earn nothing from people when they first start to use the service. In the amazon case, they may split their money between sites, as some sites may be frequented by people who pay a lot, while others may be frequented by freeloaders... this would encourage site owners to encourage their users to pay their dues.
In the end, site owners can look at the payment authority and make a guess as to what each penny you request from them is actually worth - with paypal it will be a penny - but with amazon, maybe it will be 1.1p and google it might be .8p... you then might decide to charge a google user more - and an amazon user less. Google might decide it is worth having a second signature for people who have put money into a wallet in order to avoid adverts - because those people are known for being good for micropayments.
So - is the transaction cost low enough? Probably. Everyone is going to find a bit of money dropping on the floor- the question is do you make enough in total, while being able to weed out enough of the freeloaders.
Will it change the world? I'm not sure micropayments are the answer... but if they are, this might be the best way to approach them.
Lets assume that no-one cares about privacy here. But we do care that people can get started using the system with essentially no financial risk. And we only care about very small transactions - sub 10 UK pence.
Now, sub-10p prices don't make much sense from the perspective of credit card transactions - the transaction costs are to high. But we are not talking about the credit card world - we are talking about a world where the game is simpler, and the issues of protecting transactions are smaller.
Now, several people could set themselves up as micropayment agencies. Lets assume 3 companies do this, google, amazon and paypal.
They all choose to follow the same system - when a user goes to a micropayment site, the site displays a form following a particular microformat. The user enters their username and the address of their chosen server - this is transmitted back to the host, who we then are redirected to in order to complete the transaction. Finally we are sent back to the host, along with a special token signed by the issuing agency promising to pay some quantity of money.
So far so good. Buts its quite cumbersome. I assume each of these companies might provide a browser addon to recognise the payment microformat, and do all the work automatically - at least on approved sites.
But even this isn't enough. I don't want to pay any money up front, because I don't know if anyone will actually accept micropayments. But neither google, amazon or paypal know me... so they come up with different approaches to get me paying.
Paypal say: You already have a paypal account, stick some money in there, and we'll pass it on. You can always withdraw it if you want.
Google say: Since you haven't given us any money upfront, when we redirect you back to the site, we will embed it in a frame and show you some adverts. We will try to recoup the cash from the ads.
Amazon say: We're going to trust you. We'll sub you a bit of money, and then overcharge you later to try to make up our loss - and our rep.
So paypal will just work - the website returns its tokens and paypal hands over the cash (the token is signed to identify the owner and paypal, so there is no question of duplication)
But amazon and google are risky. Google hand over the money made by the adverts (up to 150% the amount the site was actually charging... google keep the rest). This means sometimes you get paid less than you asked by google, sometimes you get paid more. Amazon will pay some percentage of their weeks total income - which may mean they pay more or less again than the site requested... because amazon generally charge people 11p to enter a 10p site, they can make up for the fact that they earn nothing from people when they first start to use the service. In the amazon case, they may split their money between sites, as some sites may be frequented by people who pay a lot, while others may be frequented by freeloaders... this would encourage site owners to encourage their users to pay their dues.
In the end, site owners can look at the payment authority and make a guess as to what each penny you request from them is actually worth - with paypal it will be a penny - but with amazon, maybe it will be 1.1p and google it might be .8p... you then might decide to charge a google user more - and an amazon user less. Google might decide it is worth having a second signature for people who have put money into a wallet in order to avoid adverts - because those people are known for being good for micropayments.
So - is the transaction cost low enough? Probably. Everyone is going to find a bit of money dropping on the floor- the question is do you make enough in total, while being able to weed out enough of the freeloaders.
Will it change the world? I'm not sure micropayments are the answer... but if they are, this might be the best way to approach them.
Thursday 29 April 2010
Programming Tools: Bugtracking
My final set of requests for a development environment involve the bug tracking system.
The initial observation that I wish to make is that bugs relate to a particular version of code. And that bugs stay with code until they are fixed. This means that bugs are related to the version control system. For any branch of the code, you should find exactly which set of bugs it has, and which bugs remain open. Closing bugs tends to relate to a particular point in a version control system: either "This is the fix for the code" or "This is the point where I verified that the bug no longer exists". When you split a branch, you take the bugs from that point in time - and when you merge a branch back into the main tree - or pick up the changes from one branch into another, you should pick up the changes to the bug database too.
In an ideal system, when you check out a branch onto a local machine, you should also be able to check out a copy of the bug tracking system... which you can make changes to - changes which will be applied when you merge back later. This allows you a full dev environment when away from the corporate network.
Bugs are also related to tests. Tests should be able to generate bugs... these bugs are probably along the lines of "Test xyz fails", providing links to an overnight test failure. Bugs should also be able to say "This test will identify this bug" so that you can get the test system to help verify when a bug has gone.
Bugs form trees (or rather directed acyclic networks), in a similar way to a version control system. For example the test system might generate the bug "Test xyz fails". I might take this bug and want to split it into two bugs "On windows test xzy fails because of foo" "On Linux test xyz fails because of something else". If I were to then notice that I already have a bug about windows failures due to foo, I should be able to merge that bug with it.
Bug entry needs to be easy. Really easy. When a test fails, I need to be able to add a few notes to it and WHAM! thats the bug added. Bugs are a place to store knowledge, and to allow me to find things that are outstanding.
Bugs also need to be integrated with email. I need to be able to send people questions, directly relating to the bug (so that the question, and the response, are stored in the bug). Bugs really are a chat system. This is not a bad thing.
Finally, Bug tracking and todo lists are tightly integrated. So much so, that most developers I know use bug tracking as their todo list. So when I send another developer a question - that needs to show up in their todo list - as an uncompleted part of a bug. And users need to be able to add their own private bugs, and import their emails into bugs to let them keep track of their own tasks.
I've talked about bug tracking for non-IT businesses elsewhere. And this bug tracker needs to support all of that.
The initial observation that I wish to make is that bugs relate to a particular version of code. And that bugs stay with code until they are fixed. This means that bugs are related to the version control system. For any branch of the code, you should find exactly which set of bugs it has, and which bugs remain open. Closing bugs tends to relate to a particular point in a version control system: either "This is the fix for the code" or "This is the point where I verified that the bug no longer exists". When you split a branch, you take the bugs from that point in time - and when you merge a branch back into the main tree - or pick up the changes from one branch into another, you should pick up the changes to the bug database too.
In an ideal system, when you check out a branch onto a local machine, you should also be able to check out a copy of the bug tracking system... which you can make changes to - changes which will be applied when you merge back later. This allows you a full dev environment when away from the corporate network.
Bugs are also related to tests. Tests should be able to generate bugs... these bugs are probably along the lines of "Test xyz fails", providing links to an overnight test failure. Bugs should also be able to say "This test will identify this bug" so that you can get the test system to help verify when a bug has gone.
Bugs form trees (or rather directed acyclic networks), in a similar way to a version control system. For example the test system might generate the bug "Test xyz fails". I might take this bug and want to split it into two bugs "On windows test xzy fails because of foo" "On Linux test xyz fails because of something else". If I were to then notice that I already have a bug about windows failures due to foo, I should be able to merge that bug with it.
Bug entry needs to be easy. Really easy. When a test fails, I need to be able to add a few notes to it and WHAM! thats the bug added. Bugs are a place to store knowledge, and to allow me to find things that are outstanding.
Bugs also need to be integrated with email. I need to be able to send people questions, directly relating to the bug (so that the question, and the response, are stored in the bug). Bugs really are a chat system. This is not a bad thing.
Finally, Bug tracking and todo lists are tightly integrated. So much so, that most developers I know use bug tracking as their todo list. So when I send another developer a question - that needs to show up in their todo list - as an uncompleted part of a bug. And users need to be able to add their own private bugs, and import their emails into bugs to let them keep track of their own tasks.
I've talked about bug tracking for non-IT businesses elsewhere. And this bug tracker needs to support all of that.
Monday 26 April 2010
Programing Tools : The Test Farm
In my discussions about programing tools, I've talked about there being a farm of build machines, so that builds can run in the background, and so that you always have a working build environment when you need one. The same has to be true of test.
Automated test is something which is more valuable to the software industry than anybody who doesn't have experience of it can imagine. It doesn't replace the test team, but it means they can focus their energies on finding new and better bugs rather than ensuring that old favourites don't rear their ugly heads.
As a developer, there are many things that stop me working. Sometimes its a problem, somthing I have to think about, mull over and ultimately solve. But sometimes I'm blocked by the fact that in order to do something, I first have to do something which is a hassle. Every time I am asked to test on a different platform, I feel that hassle. And I put off the move... on a bad day, I go to the warm (slightly tacky, a smelling of cheap perfume) embrace of the internet.
I wan't this hassle gone.
I want to say "Run this test in this environment" to my dev suite, and tlet the software find an appropriate machine.
And for that I need a test farm - just like build farm, it needs to have a number of daemon equipped machines, which are ready to run the tests I give them (and which ideally are able to clean themselves up totally - they really need to be able to reimage back to a newly installed state if I so wish)
But I also want wrriting tests to be easy. I must be able to go to my dev environment and say "now I want to write a test". It should give me a place to write that test, and appropriate tools to help me produce a working testable system.
Early stage test development is just a matter of setting appropriate applications running, and ammassing output. But I also later need to be able to write code to verify the output is correct.
And once I have tests that work, I need to be able to run them on every platform (perhaps scheduled overnight), and I need to be able to submit them, so that my tests enter the range of tests available to everybody.
Once I have those features, writing tests will be the standard way I choose to begin to develop my software. And as a company we will end up with many many tests.
The advantage of many many tests is overnight testing runs.
Overnight testing runs are really important. And they shouldn't just run overnight. They should run whenever there is spare time available on the test farm, testing every development build the build farm has generated. And they should report to the owner of a tree whenever a test failure is found.
On identifying a test failure, I need to know the history of the issue - has this failure occured before? On my branch? On the main tree? I need the system to binary chop for me, and find the point where the failure first occured. The test system, like the buiold system, needs to be fully aware of the version control system. And these failures should find their way into the issue tracking system. Ideally without my help - because if tests are failing, there is an issue - either with the test or with the application under test.
the test system should also be able to make decisions about the meaing of test failures - if a test begins to fail, that is important. If a test regularly fails intermittantly, that is less important. Tests which always pass need to be tested less often. Tests which regularly pass, but which also regularly break are the most important - every test suite has them, those tests which you recognise are the ones which regularly fail when you change something - the tests which are like a canary in a coal mine sniffing out impending doom. A test suite should be able to identify them and run them the most often, to identify problems as soon as they hit.
Oh, and the test team? Do they all go an sun themselves on the sunny sunny beaches of Acapulco? Maybe. But they have a new role. Because now they not only have a set of tools which make writing tests easier, they also have hundreds of tests being developed for them by developers... tests which migh themselves be buggy. They have a new range of applications to QA. But as tests are simpler applications, programs which can be held in ones head all in one go, they are more able to find the hidden defects, and ensure that the tests provide the QA the main application requires.
[Incidentally, I've ignored UI testing in this article. Thats because, frankly I know nothing about it. Testing that buttons work can be scripted. Testing that an application is usable will take more work. All I can say is that there is scope for manual tests which can be run by an individual with a script and be fed back into the same system. I don't quite know how this would work... consider it a reseash problem, and if you have any ideas, do get in touch]
Automated test is something which is more valuable to the software industry than anybody who doesn't have experience of it can imagine. It doesn't replace the test team, but it means they can focus their energies on finding new and better bugs rather than ensuring that old favourites don't rear their ugly heads.
As a developer, there are many things that stop me working. Sometimes its a problem, somthing I have to think about, mull over and ultimately solve. But sometimes I'm blocked by the fact that in order to do something, I first have to do something which is a hassle. Every time I am asked to test on a different platform, I feel that hassle. And I put off the move... on a bad day, I go to the warm (slightly tacky, a smelling of cheap perfume) embrace of the internet.
I wan't this hassle gone.
I want to say "Run this test in this environment" to my dev suite, and tlet the software find an appropriate machine.
And for that I need a test farm - just like build farm, it needs to have a number of daemon equipped machines, which are ready to run the tests I give them (and which ideally are able to clean themselves up totally - they really need to be able to reimage back to a newly installed state if I so wish)
But I also want wrriting tests to be easy. I must be able to go to my dev environment and say "now I want to write a test". It should give me a place to write that test, and appropriate tools to help me produce a working testable system.
Early stage test development is just a matter of setting appropriate applications running, and ammassing output. But I also later need to be able to write code to verify the output is correct.
And once I have tests that work, I need to be able to run them on every platform (perhaps scheduled overnight), and I need to be able to submit them, so that my tests enter the range of tests available to everybody.
Once I have those features, writing tests will be the standard way I choose to begin to develop my software. And as a company we will end up with many many tests.
The advantage of many many tests is overnight testing runs.
Overnight testing runs are really important. And they shouldn't just run overnight. They should run whenever there is spare time available on the test farm, testing every development build the build farm has generated. And they should report to the owner of a tree whenever a test failure is found.
On identifying a test failure, I need to know the history of the issue - has this failure occured before? On my branch? On the main tree? I need the system to binary chop for me, and find the point where the failure first occured. The test system, like the buiold system, needs to be fully aware of the version control system. And these failures should find their way into the issue tracking system. Ideally without my help - because if tests are failing, there is an issue - either with the test or with the application under test.
the test system should also be able to make decisions about the meaing of test failures - if a test begins to fail, that is important. If a test regularly fails intermittantly, that is less important. Tests which always pass need to be tested less often. Tests which regularly pass, but which also regularly break are the most important - every test suite has them, those tests which you recognise are the ones which regularly fail when you change something - the tests which are like a canary in a coal mine sniffing out impending doom. A test suite should be able to identify them and run them the most often, to identify problems as soon as they hit.
Oh, and the test team? Do they all go an sun themselves on the sunny sunny beaches of Acapulco? Maybe. But they have a new role. Because now they not only have a set of tools which make writing tests easier, they also have hundreds of tests being developed for them by developers... tests which migh themselves be buggy. They have a new range of applications to QA. But as tests are simpler applications, programs which can be held in ones head all in one go, they are more able to find the hidden defects, and ensure that the tests provide the QA the main application requires.
[Incidentally, I've ignored UI testing in this article. Thats because, frankly I know nothing about it. Testing that buttons work can be scripted. Testing that an application is usable will take more work. All I can say is that there is scope for manual tests which can be run by an individual with a script and be fed back into the same system. I don't quite know how this would work... consider it a reseash problem, and if you have any ideas, do get in touch]
Thursday 22 April 2010
Highstreet of Tomorrow
The Internet is killing the highstreet. Specifically it is killing some particular types of shops: the shops which sell a particular type of product that you buy based on its features rather than its feel in your hands.
Why?
Because in the days before google, when all we had was fire and that new-fangled wheel thing, people who wanted to buy - say - an SLR camera would go to their local camera shop and ask for advice. Then, having got the advice they would buy the camera. These days they go on the Internet and look for advice. If they find the advice they buy the camera on the Internet. If they don't find the advice, they go to the camera shop and ask. Before going home and buying the camera on the Internet.
No highstreet shops are only good for
Things you need right now
Things you need to look at and touch as you buy them
Leisure shopping
The expert is gone. Almost. Apple Stores are the exception.
Why?
Because Apple don't care if you buy things from their shop. If you ask advice in their shop, then buy online, Apple still win. Apple stores are a good deal for apple even if they only break even - the stores don't need to make a profit (though high footfall is a necessity)
So in the future we will see more shops run by the manufacturers of products, in order to provide assistance to people who want to buy their product.
This could be like the Apple store (for, say, canon cameras)
But it could also be a Google cafe (with lessons and tech talks, and free surfing)
Or a Heinz food shop (with cooking demos, and free recipes)
What we won't see in the future are mobile phone shops like "Carphone Warehouse", because they'll all be online. Instead we'll see more Orange stores. And Maybe HTC stores. Just possibly there will also be Android and Windows 7 stores too... Three different approaches, but none of them require the shop itself to make money - the shop is an added extra that you pay for in the price of the product you buy.
Why?
Because in the days before google, when all we had was fire and that new-fangled wheel thing, people who wanted to buy - say - an SLR camera would go to their local camera shop and ask for advice. Then, having got the advice they would buy the camera. These days they go on the Internet and look for advice. If they find the advice they buy the camera on the Internet. If they don't find the advice, they go to the camera shop and ask. Before going home and buying the camera on the Internet.
No highstreet shops are only good for
Things you need right now
Things you need to look at and touch as you buy them
Leisure shopping
The expert is gone. Almost. Apple Stores are the exception.
Why?
Because Apple don't care if you buy things from their shop. If you ask advice in their shop, then buy online, Apple still win. Apple stores are a good deal for apple even if they only break even - the stores don't need to make a profit (though high footfall is a necessity)
So in the future we will see more shops run by the manufacturers of products, in order to provide assistance to people who want to buy their product.
This could be like the Apple store (for, say, canon cameras)
But it could also be a Google cafe (with lessons and tech talks, and free surfing)
Or a Heinz food shop (with cooking demos, and free recipes)
What we won't see in the future are mobile phone shops like "Carphone Warehouse", because they'll all be online. Instead we'll see more Orange stores. And Maybe HTC stores. Just possibly there will also be Android and Windows 7 stores too... Three different approaches, but none of them require the shop itself to make money - the shop is an added extra that you pay for in the price of the product you buy.
Monday 19 April 2010
Programming Tools: The Build Farm
In my first essay on programming tools I suggested that you take some code, press a button and it builds.
What I didn't talk about was how it builds.
Firstly, it doesn't build on your local machine (it could, if you install the right tools, but that's an unnecessary addition. If you're working locally, you just use your version control system back to the online system to build...). Instead of local builds we have a build farm - a set of one or more machines which include all the tools for building for one or more particular environments. When you hit build, your code is shunted off to the first available machine that can build for the platform you require. The build is performed, and the results are returned.
Actually - its even better. Because this is always happening in behind the scenes, as you type. Whenever it gets a chance a new build of your code is scheduled... so usually when you press the build button the results are instantly available.
And by results I mean build errors and warnings. I mean binaries. I mean all outputs one would usually see from a build. Of course, you probably won't care about the binaries because for most of your development time you'll be using a test farm to cope with these. The errors are the important thing - and they'll be checked into the appropriate point in the version control system so that they are always instantly available
In order to make such a system work, each machine in the build farm will need to have a working build environment installed (its probably best to do this with a VM image, so that making clones is easy). They will also need a daemon process to control the build. Its probably best to think of this as being the build tool - the equivalent of make.
The build tool will advertise itself on the network (using zero-conf or rendezvous or whatever), along with advertising the systems it is capable of building for. Any machine with a tool put on the network will automatically be available to build
I've spent a lot of time thinking about what the ideal replacement for make would be like, but the long and the short of it is, the characteristics of the build system tool won't matter so long as it is possible to only need to rebuild those files which have changed... it could rely heavily on the vcs here, after all, it will know from the vcs exactly which files are different from the last build.
I do think, however, that directory structure is probably not a desirable thing to have. Rather, it should be possible to put files into groups either explicitly, or by smart groups (just as you have smart folders in itunes). A file can be in many groups. When a build tool needs an arbitrary structure, it should be possible to generate it on the fly by moving (groups of )files to the correct locations. This gets over the issues with - say - Microsoft's driver build environment, which only allows two levels of directory structure, and helps where the directory structures need to be different on different platforms. It also helps with version control: at the moment version control systems have to try to emulate every filing system their files may run on, so that permissions and so forth can be replicated correctly. Moving files around is a pain. With this system, everything can fall into build system metadata, and we can provide our own security features (such as restricting changes different code areas to different program groups) if we need them. Of course, build system metadata is stored in a file in version control - so if a file is merged or permissions need to be changed, those changes are tracked like everything else - transparently.
The end result of this complexity is simplicity. Once a build has been set up, it will 'just work' for everybody. If you suddenly need to build for another platform, its just a simple choice of a new platform to see if it works. You can test every platform quickly and easily without searching for appropriate machines and solving 101 build problems.
And because a build daemon is externally controllable - it is no effort at all to use it (and maybe a particular 'gold' machine) for scheduling nightly builds. Or rolling test builds of the code integration branch.
Programmers life is simpler. Builds are easier. Testing is easier. And everyones' lives can be made faster and easier still just by throwing on new hardware. Its a win for everybody.
What I didn't talk about was how it builds.
Firstly, it doesn't build on your local machine (it could, if you install the right tools, but that's an unnecessary addition. If you're working locally, you just use your version control system back to the online system to build...). Instead of local builds we have a build farm - a set of one or more machines which include all the tools for building for one or more particular environments. When you hit build, your code is shunted off to the first available machine that can build for the platform you require. The build is performed, and the results are returned.
Actually - its even better. Because this is always happening in behind the scenes, as you type. Whenever it gets a chance a new build of your code is scheduled... so usually when you press the build button the results are instantly available.
And by results I mean build errors and warnings. I mean binaries. I mean all outputs one would usually see from a build. Of course, you probably won't care about the binaries because for most of your development time you'll be using a test farm to cope with these. The errors are the important thing - and they'll be checked into the appropriate point in the version control system so that they are always instantly available
In order to make such a system work, each machine in the build farm will need to have a working build environment installed (its probably best to do this with a VM image, so that making clones is easy). They will also need a daemon process to control the build. Its probably best to think of this as being the build tool - the equivalent of make.
The build tool will advertise itself on the network (using zero-conf or rendezvous or whatever), along with advertising the systems it is capable of building for. Any machine with a tool put on the network will automatically be available to build
I've spent a lot of time thinking about what the ideal replacement for make would be like, but the long and the short of it is, the characteristics of the build system tool won't matter so long as it is possible to only need to rebuild those files which have changed... it could rely heavily on the vcs here, after all, it will know from the vcs exactly which files are different from the last build.
I do think, however, that directory structure is probably not a desirable thing to have. Rather, it should be possible to put files into groups either explicitly, or by smart groups (just as you have smart folders in itunes). A file can be in many groups. When a build tool needs an arbitrary structure, it should be possible to generate it on the fly by moving (groups of )files to the correct locations. This gets over the issues with - say - Microsoft's driver build environment, which only allows two levels of directory structure, and helps where the directory structures need to be different on different platforms. It also helps with version control: at the moment version control systems have to try to emulate every filing system their files may run on, so that permissions and so forth can be replicated correctly. Moving files around is a pain. With this system, everything can fall into build system metadata, and we can provide our own security features (such as restricting changes different code areas to different program groups) if we need them. Of course, build system metadata is stored in a file in version control - so if a file is merged or permissions need to be changed, those changes are tracked like everything else - transparently.
The end result of this complexity is simplicity. Once a build has been set up, it will 'just work' for everybody. If you suddenly need to build for another platform, its just a simple choice of a new platform to see if it works. You can test every platform quickly and easily without searching for appropriate machines and solving 101 build problems.
And because a build daemon is externally controllable - it is no effort at all to use it (and maybe a particular 'gold' machine) for scheduling nightly builds. Or rolling test builds of the code integration branch.
Programmers life is simpler. Builds are easier. Testing is easier. And everyones' lives can be made faster and easier still just by throwing on new hardware. Its a win for everybody.
Thursday 15 April 2010
Bug Tracking For Business
Lets assume that telecommuting is desirable. Lets also assume that this is going to bring in a new raft of management issue (which is why the current generation are still dragging their feet on the way towards it). One of the biggest issues is visibility
At the moment, managers can manage by walking around, coming up behind you, suprising you and occasionally overhearig what you are doing. They get a good idea of what is going on from the office atmosphere. With everyone apart, communicating by a number of channels, both public and private, they will lose this sense of being in touch.
The IT indisutry is, however, already full of people who don't like to talk. Or see each other if at all possible. And we write tools to keep track of what we ought to be doing - one of the most used is the bug tracking system. Each software bug is entered into the database, passed around between people who take responsibility for it, and eventually it is closed. At the flick of a swithc a manager can see which bugs are still a problem and (by reading comments) exactly how near a programmer is to solving it.
And in the IT industry we have learned to abuse the bug tracking system. Almost everywhere managers add new features to the bug trackign system, as a way of assigning new tasks to programmers. And at one place I worked, an early bug was "We have run out of milk in the kitchen" which later became "we keep runing out of milk and need to find a way to stop this happening"
I was shocked when I heard that other white collar industries don't have anything similar. Sure they have their emails, their outlooks, their calendars and maybe their todo lists, but a simple Way of tracking how far they are on each problem, and of collecting all the information on each task, so that, if they need to hand it over to someone else they can do so trivially, all while being visible to anyone interested is missing.
The problem is we call bug tracking systems bug tracking systems, and orient them towards the sort of tasks programmers do.
While I was wondering about my ideal system for implementing something like Getting Things Done in my own life, it became clear that I wanted all the characteristics of a bug tracking system behind everything. I wanted to create dependencies and to be able to see all open tasks. I wanted to be able to categorise tasks and filter my searching appropriately. I wanted emails to tell me what I needed to do and when.
And I think this would be a superb addition to any office environment, especially one where telecommuting was considered desirable.
Not a bug tracking system (that's too IT oriented) but a Workflow Organisation System. Something which does to bug tracking what Facebook did to email, something that makes it all friendlier and simpler, with all the complexities hidden.
And with one feature that most bug tracking systems miss: the ability to create private tasks for your own use... because that allows you to use it for everything in your life (or your worklife) not just those things a manager wants visibility on. And that makes it something that can become generally useful to everyone.
At the moment, managers can manage by walking around, coming up behind you, suprising you and occasionally overhearig what you are doing. They get a good idea of what is going on from the office atmosphere. With everyone apart, communicating by a number of channels, both public and private, they will lose this sense of being in touch.
The IT indisutry is, however, already full of people who don't like to talk. Or see each other if at all possible. And we write tools to keep track of what we ought to be doing - one of the most used is the bug tracking system. Each software bug is entered into the database, passed around between people who take responsibility for it, and eventually it is closed. At the flick of a swithc a manager can see which bugs are still a problem and (by reading comments) exactly how near a programmer is to solving it.
And in the IT industry we have learned to abuse the bug tracking system. Almost everywhere managers add new features to the bug trackign system, as a way of assigning new tasks to programmers. And at one place I worked, an early bug was "We have run out of milk in the kitchen" which later became "we keep runing out of milk and need to find a way to stop this happening"
I was shocked when I heard that other white collar industries don't have anything similar. Sure they have their emails, their outlooks, their calendars and maybe their todo lists, but a simple Way of tracking how far they are on each problem, and of collecting all the information on each task, so that, if they need to hand it over to someone else they can do so trivially, all while being visible to anyone interested is missing.
The problem is we call bug tracking systems bug tracking systems, and orient them towards the sort of tasks programmers do.
While I was wondering about my ideal system for implementing something like Getting Things Done in my own life, it became clear that I wanted all the characteristics of a bug tracking system behind everything. I wanted to create dependencies and to be able to see all open tasks. I wanted to be able to categorise tasks and filter my searching appropriately. I wanted emails to tell me what I needed to do and when.
And I think this would be a superb addition to any office environment, especially one where telecommuting was considered desirable.
Not a bug tracking system (that's too IT oriented) but a Workflow Organisation System. Something which does to bug tracking what Facebook did to email, something that makes it all friendlier and simpler, with all the complexities hidden.
And with one feature that most bug tracking systems miss: the ability to create private tasks for your own use... because that allows you to use it for everything in your life (or your worklife) not just those things a manager wants visibility on. And that makes it something that can become generally useful to everyone.
Monday 12 April 2010
Bring Back the Gentlemans Club
Working at Google seems to be an attractive proposition - free food, lots of colourful spheres everywhere, smart people. Its the sort of club I could cope with being a member of. But consultancy also appeals - working on my own schedule, for myself, total flexibility of lifestyle. A club with only one member, me.
I fully expect the IT industry (and indeed many white collar industries) to move over to consultancy model (or at least a telecommuting model). It makes sense. It's ecomental and everything. Once the current generation of senior managers move on and today's twenty and thirty year olds take their place, we'll see it more and more.
But working from home misses out all the benefits of having a place to work at - the enforced social interaction of a job. While you gain freedom, you lose all the fringe benefits... and you get cooped up in a place that its nice to get out from every so often.
The answer: lets reinvent the gentleman's club.
Not so fast: "what about co-working venues", you might ask. Co-working is a good first step. It gives you a workplace. It gives you people.
But when I take a job, the job self-selects the sort of people I work with. They are smart. They know their stuff. They are reasonably non-annoying (and I'm annoyed by pretty much everyone).
At a co-working venue, anyone who can afford the price of renting a desk can be your work buddy. The only selection category is, potentially, income.
And the co-working venue doesn't provide all the helpful features of an office. Nowhere to post your mail. No canteen to eat in at lunchtime. No rooms for meetings.
These are exactly the sort of features that gentleman's clubs had. Clubs attracted a certain type... and applicants who weren't that type were back-balled. Clubs had lots of fringe benefits - you had a bar, food was served, rooms were available.
I'm not suggesting we all sit in big chairs by a fireside, drinking snifters of whisky and making bets about how quickly we can travel around the world (although I'm sure there would be a club to attract the likes of Gorman, Wallace and Hawkes), and for people like me in the IT industry, I'm sure many of them would feel more like Google. Or Microsoft. Because what people want from their workplace, and what people want from their work are two different things.
I fully expect the IT industry (and indeed many white collar industries) to move over to consultancy model (or at least a telecommuting model). It makes sense. It's ecomental and everything. Once the current generation of senior managers move on and today's twenty and thirty year olds take their place, we'll see it more and more.
But working from home misses out all the benefits of having a place to work at - the enforced social interaction of a job. While you gain freedom, you lose all the fringe benefits... and you get cooped up in a place that its nice to get out from every so often.
The answer: lets reinvent the gentleman's club.
Not so fast: "what about co-working venues", you might ask. Co-working is a good first step. It gives you a workplace. It gives you people.
But when I take a job, the job self-selects the sort of people I work with. They are smart. They know their stuff. They are reasonably non-annoying (and I'm annoyed by pretty much everyone).
At a co-working venue, anyone who can afford the price of renting a desk can be your work buddy. The only selection category is, potentially, income.
And the co-working venue doesn't provide all the helpful features of an office. Nowhere to post your mail. No canteen to eat in at lunchtime. No rooms for meetings.
These are exactly the sort of features that gentleman's clubs had. Clubs attracted a certain type... and applicants who weren't that type were back-balled. Clubs had lots of fringe benefits - you had a bar, food was served, rooms were available.
I'm not suggesting we all sit in big chairs by a fireside, drinking snifters of whisky and making bets about how quickly we can travel around the world (although I'm sure there would be a club to attract the likes of Gorman, Wallace and Hawkes), and for people like me in the IT industry, I'm sure many of them would feel more like Google. Or Microsoft. Because what people want from their workplace, and what people want from their work are two different things.
Thursday 8 April 2010
Wiki-dating
Another approach to internet dating is to get rid of the computer.
Several of my friends are inveterate match makers. They look for ideal partners to pair up. This gives them satisfaction, and (apparently) some sort of meaning in life. I can exploit this for profit, right?
We've all seen "Hot Or Not". Why not have a dating site where you get to see the classified ads of one guy and three (random) gals, or one lady and three (arbirary) lads, and get to say "I think the best bet for this bloke or the wisest way for this woman is this one of the three". You could also say "Actually, I think these two are ideally matched"
And then you get to see
"Did I think the same as the rest of the crowd"?
and possibly, in the future, if that the guy writes to your choice of girl, you get points... and can ascend though a series of lables which mark out how good a match maker you are.
Meanwhile, the daters are using a dating website like normal. They see the ususal set of potential matches. But the matches are ordered, not by an algorithm based on a form they filled in (or their star sign and place of birth), but my what the people who are making the matching decisions suggest. You don't get matched by a soulless computer, but by people (and people have had centuries of evolution to get the art of matchmaking right. They probably know what they are doing)
And the final benefit of this idea? it could well go viral. Free advertising for your dating site. Which is what you need to draw people in.
Several of my friends are inveterate match makers. They look for ideal partners to pair up. This gives them satisfaction, and (apparently) some sort of meaning in life. I can exploit this for profit, right?
We've all seen "Hot Or Not". Why not have a dating site where you get to see the classified ads of one guy and three (random) gals, or one lady and three (arbirary) lads, and get to say "I think the best bet for this bloke or the wisest way for this woman is this one of the three". You could also say "Actually, I think these two are ideally matched"
And then you get to see
"Did I think the same as the rest of the crowd"?
and possibly, in the future, if that the guy writes to your choice of girl, you get points... and can ascend though a series of lables which mark out how good a match maker you are.
Meanwhile, the daters are using a dating website like normal. They see the ususal set of potential matches. But the matches are ordered, not by an algorithm based on a form they filled in (or their star sign and place of birth), but my what the people who are making the matching decisions suggest. You don't get matched by a soulless computer, but by people (and people have had centuries of evolution to get the art of matchmaking right. They probably know what they are doing)
And the final benefit of this idea? it could well go viral. Free advertising for your dating site. Which is what you need to draw people in.
Monday 5 April 2010
The allergy assistor
I am gluten intolerant. Which can make shopping a pain. I have to check the ingredients on all sorts of things to see if I can eat them. And even then, I'm not sure, without a 'gluten free' symbol, I'm still taking my life in my own two hands.
And I'm quite hip to all this. I know what I'm doing. There must be scores of people with fool allergies and intolerance's who don't know what to look out for, or what has passed tests.
So I propose a mobile phone app. One for the iPhone. One for Android. We can talk about Windows phone 7 or whatever they're calling it later.
The app would allow you to enter your intolerance.
It would allow you to scan bar codes of products and see if you can eat them (given your previously input intolerance's)
It would keep a user submitted wiki (photograph the ingredients, submit reports by phone) so that new products could be kept up to date in our database
We could also buy into some of the online allergy food directories. I know Coeliac UK offer one to their members, perhaps there is a way to license that.
And, if you could simply search by name, brand or product type, that would be very handy too.
Maybe the app could suggest alternatives to items you are allergic to (could you buy them online through it? is that an alternative to charging for the app?)
Maybe the app could also let you know if you're near a known good allergy-aware restaurant.
Moreover, this app is an itch that I actually have to scratch (damn gluten-intolerance-related psoriasis) so its something I would really quite like to work on.
And I'm quite hip to all this. I know what I'm doing. There must be scores of people with fool allergies and intolerance's who don't know what to look out for, or what has passed tests.
So I propose a mobile phone app. One for the iPhone. One for Android. We can talk about Windows phone 7 or whatever they're calling it later.
The app would allow you to enter your intolerance.
It would allow you to scan bar codes of products and see if you can eat them (given your previously input intolerance's)
It would keep a user submitted wiki (photograph the ingredients, submit reports by phone) so that new products could be kept up to date in our database
We could also buy into some of the online allergy food directories. I know Coeliac UK offer one to their members, perhaps there is a way to license that.
And, if you could simply search by name, brand or product type, that would be very handy too.
Maybe the app could suggest alternatives to items you are allergic to (could you buy them online through it? is that an alternative to charging for the app?)
Maybe the app could also let you know if you're near a known good allergy-aware restaurant.
Moreover, this app is an itch that I actually have to scratch (damn gluten-intolerance-related psoriasis) so its something I would really quite like to work on.
Thursday 1 April 2010
Programing Tools: New Version
Once we've asserted that your programming tools should run in a web browser, we can start deciding what back end functionality it needs. The most important is version control.
Now, there is nothing new about version control, so I won't go into it here... but I want to point out that my last article just assumed version control: I suggested you could go to the code and start to edit it. Of course, what I meant was
You log into the system
You find the code you want to edit
You pick a button marked new workspace
You enter that workspace and modify the code.
The workspace is a version controlled branch. There will be options to update your workspace, and merge your workspace into other workspaces.
But all of this is transparent - for the developer its just how you work. Each time you save, thats a revision (auto saves may or may not be revisions... I suggest not). You can tag revisions with comments when you reach points where that is useful.
One final clever bit: the version control system is one of the standard ones... or compatible with one of the standard ones. A distributed VCS, naturally - git or mercurial (I have almost no git experience, so assume I'm talking about mercurial here). So, if a developer wants to work outside of the online toolchain, they can simply download a brnach to their own machine and work from there. When they are done (or just want to compile - they can push their branch back to their online workspace, and take advantage of the compilation and test features provided.
But the compilation and test features are other articles...
Now, there is nothing new about version control, so I won't go into it here... but I want to point out that my last article just assumed version control: I suggested you could go to the code and start to edit it. Of course, what I meant was
You log into the system
You find the code you want to edit
You pick a button marked new workspace
You enter that workspace and modify the code.
The workspace is a version controlled branch. There will be options to update your workspace, and merge your workspace into other workspaces.
But all of this is transparent - for the developer its just how you work. Each time you save, thats a revision (auto saves may or may not be revisions... I suggest not). You can tag revisions with comments when you reach points where that is useful.
One final clever bit: the version control system is one of the standard ones... or compatible with one of the standard ones. A distributed VCS, naturally - git or mercurial (I have almost no git experience, so assume I'm talking about mercurial here). So, if a developer wants to work outside of the online toolchain, they can simply download a brnach to their own machine and work from there. When they are done (or just want to compile - they can push their branch back to their online workspace, and take advantage of the compilation and test features provided.
But the compilation and test features are other articles...
Monday 29 March 2010
Programming Tools: Getting Started
I'm a programmer. Not just for my job, but in my heart. Programming is one of the things I think about when I have nothing better to do. The other night I dreamed that I was multi-threaded (seriously - from now on I will blame all my problems on race conditions).
But this means I identify problems with programming tools quite frequently. Because these problems annoy me on a day to day basis, and I believe there is always a better Way to do things. But I have lots of ideas in this space, and they overlap quite a bit. So I'm going to try to break them down into a number of posts, each getting across a salient point.
Start up time is everything:
I have, several times in my life, started at a new company. The first day tends to involve getting your computer working the way you like. The second day involves learning how to build their code. Then the next year involves gradually picking up the accumulated knowledge of the test environments they have built, the build system, all that jazz.
IDEs make things so much easier. But are also so limited and constraining. I've never worked for a company where the IDE is the way we actually develop things.
But what I want is a quick start way to do development. Don't make me do it on my own PC. Give me a web page I can point at: a local intranet web page which I can edit code on (we have ajax now: why do I need to install a dev system on my personal PC... sure make it a possibility, but don't make it a requirement). Now let my press a button and get my code to compile (Or don't. Maybe the code compiles in the background while I'm working. That's even more useful). Let me press another button to run a test from the test suite (with a GUI app, this might be a problem... but int he future all GUI apps are web pages too, no?)... and let me edit the code for the test suite in place too.
I should be able to get going straight away. Get into the system straight away.
And while I might be able to work in a more powerful manner on my own PC (and it should be a possibility - make sure I can check out a local version of the code, and give me some way I can try to build it - or schedule a build of it) from my local box - these are power features which I can worry about later, when I need them. Not on day one, when I ought to be getting to know the new territory.
But this means I identify problems with programming tools quite frequently. Because these problems annoy me on a day to day basis, and I believe there is always a better Way to do things. But I have lots of ideas in this space, and they overlap quite a bit. So I'm going to try to break them down into a number of posts, each getting across a salient point.
Start up time is everything:
I have, several times in my life, started at a new company. The first day tends to involve getting your computer working the way you like. The second day involves learning how to build their code. Then the next year involves gradually picking up the accumulated knowledge of the test environments they have built, the build system, all that jazz.
IDEs make things so much easier. But are also so limited and constraining. I've never worked for a company where the IDE is the way we actually develop things.
But what I want is a quick start way to do development. Don't make me do it on my own PC. Give me a web page I can point at: a local intranet web page which I can edit code on (we have ajax now: why do I need to install a dev system on my personal PC... sure make it a possibility, but don't make it a requirement). Now let my press a button and get my code to compile (Or don't. Maybe the code compiles in the background while I'm working. That's even more useful). Let me press another button to run a test from the test suite (with a GUI app, this might be a problem... but int he future all GUI apps are web pages too, no?)... and let me edit the code for the test suite in place too.
I should be able to get going straight away. Get into the system straight away.
And while I might be able to work in a more powerful manner on my own PC (and it should be a possibility - make sure I can check out a local version of the code, and give me some way I can try to build it - or schedule a build of it) from my local box - these are power features which I can worry about later, when I need them. Not on day one, when I ought to be getting to know the new territory.
Thursday 25 March 2010
Reviews You Can Trust
I love Top Gear. I don't always agree with it, but I love it. And a while ago I figured out why: Top Gear is just Blue Peter for 'grown up' men. It has a similar number of presenters, exciting events, a totaliser (well, a board that says how fast people go around a track... but it has the same sort of feeling), a dog (whatever happened to Top Gear Dog? Well, they've got the Stig, which is much the same thing... or is he their Percy Thrower?), celebrity interviews and occasionally they show you how to make things. All its missing is badges that get you into places for free.
But Top Gear does something else... and what it does is an idea I have actually pitched in the past (it was passed on at the time, but I think it has value)
When Top Gear reviews things, it reviews them from particular perspectives. We all know what the interests of Clarkson, Hammond and May are. We all know what they are meant to think about things. When they review a car, we don't get told what the car is like: we get told how three personalities - three caricatures of their actual personalities think about things.
And this is good - because it helps up - the viewer - make up our mind.
When I read Roger Ebert's film reviews, I get a good idea of how the film is - what makes it good or bad. Everything is factual - or presented as factual. These reviews are superb - they are the best in the business - but what Top Gear gives is different, its what you get down the pub: opinions.
And when you get opinions from your friends in the pub, you filter them through knowing what your friends like and dislike.
This is a model which could be applied to anything which needs reviewing: why stop at cars. Why not review films from the perspective of a person interested in cinematography, another who likes complicated plots, and details characters and a third who likes special effects and action.
Or technology from the perspectives of a Mac, a PC and a Linux user.
Reviews are one thing. The big idea here is that opinions from particular points of view are more entertaining.
But Top Gear does something else... and what it does is an idea I have actually pitched in the past (it was passed on at the time, but I think it has value)
When Top Gear reviews things, it reviews them from particular perspectives. We all know what the interests of Clarkson, Hammond and May are. We all know what they are meant to think about things. When they review a car, we don't get told what the car is like: we get told how three personalities - three caricatures of their actual personalities think about things.
And this is good - because it helps up - the viewer - make up our mind.
When I read Roger Ebert's film reviews, I get a good idea of how the film is - what makes it good or bad. Everything is factual - or presented as factual. These reviews are superb - they are the best in the business - but what Top Gear gives is different, its what you get down the pub: opinions.
And when you get opinions from your friends in the pub, you filter them through knowing what your friends like and dislike.
This is a model which could be applied to anything which needs reviewing: why stop at cars. Why not review films from the perspective of a person interested in cinematography, another who likes complicated plots, and details characters and a third who likes special effects and action.
Or technology from the perspectives of a Mac, a PC and a Linux user.
Reviews are one thing. The big idea here is that opinions from particular points of view are more entertaining.
Monday 22 March 2010
Dating For Introverts
Computer dating took a new lease of life when the internet came along. It won't surprise me if, in a few years time, we get some figures suggesting some large portion of the population met their partners through dating websites. And while there are many popular websites, and they seem to be doing their jobs just fine, occasionally I think of new varients on the theme.
My favourite is Introvert Dating
As an introvert, this style of dating matches how I would like these websites to work.
To begin with the sites would be much the same as existing sites. You would enter a profile, save it and then be given a list of potential matches. However you would not choose to contact one of the matches, you would just signify that you are interested in them - or that you are not interested in them (maybe you give a star rating to help the recommendation engine... but thats outside the scope of this idea)
Now, once you have said you are interested, you are moved up the list of people your potential partner is matched with. The potential partner cannot see you are interested in her, but you are moved up on her list (and then sorted by either computer generated relevance, or by how many people you have said you are interested in - if you are interested in a lower percentage of yourt choices, you are moved up in the object of your affection's list)
Your partner may then decide she is not interested in you... if so, you vanish from her list of potentials, and you never hear anything more. Moreover, you are happy because you have never had to tell her that you are interested in her.
But if your partner clicks the "I'm interested" button, she gets told "He is interested in you too. Would you like to send him a message?" and is given the option of getting in touch.
So you only ever write to people you know are interested in you.
And what about those people who say "I'm interested" in everybody, just to see who is interested in them? Well, if someone is already interested, but the checker never chooses to write to them, then there is no problem - the interested person never knows anything has happened.
And because they are interested in a high percentage of their matches, they will turn up lower on the list of people interested in just a few others - and so be leess likely to be seen.
My favourite is Introvert Dating
As an introvert, this style of dating matches how I would like these websites to work.
To begin with the sites would be much the same as existing sites. You would enter a profile, save it and then be given a list of potential matches. However you would not choose to contact one of the matches, you would just signify that you are interested in them - or that you are not interested in them (maybe you give a star rating to help the recommendation engine... but thats outside the scope of this idea)
Now, once you have said you are interested, you are moved up the list of people your potential partner is matched with. The potential partner cannot see you are interested in her, but you are moved up on her list (and then sorted by either computer generated relevance, or by how many people you have said you are interested in - if you are interested in a lower percentage of yourt choices, you are moved up in the object of your affection's list)
Your partner may then decide she is not interested in you... if so, you vanish from her list of potentials, and you never hear anything more. Moreover, you are happy because you have never had to tell her that you are interested in her.
But if your partner clicks the "I'm interested" button, she gets told "He is interested in you too. Would you like to send him a message?" and is given the option of getting in touch.
So you only ever write to people you know are interested in you.
And what about those people who say "I'm interested" in everybody, just to see who is interested in them? Well, if someone is already interested, but the checker never chooses to write to them, then there is no problem - the interested person never knows anything has happened.
And because they are interested in a high percentage of their matches, they will turn up lower on the list of people interested in just a few others - and so be leess likely to be seen.
Thursday 18 March 2010
Giving X Factor the X Factor
X-Factor is hugely popular in the UK, and will be coming to the uS this autumn. But it is based on an old model - the tv premium line phone in vote.
Things have move on: with Glee we have seen the song of the week being released and hitting the charts in the week it is broadcast. And when I watch X Factor, I often find myself thinking: if that was a record, i would go out and buy it.
So why not do things differently.
Each week the singer, or group, or whoever, records a song. They might also sing it live on a weekly entertainment show - but the important thing is the recording. After the weekly show goes out, the recordings are put on sale: mp3s on iTunes and Amazon - no need to distribute them to record shops (record shops are so last century too...). The winner is announced the next week - based on one thing and one thing only - highest sales.
What you get is an artist who has managed not just to consistantly win phone votes, but to consistently sell to people who actually buy music.
Which is so much better than the bland forgettable winners of the show who are often forgotten before they get around to releasing their first album.
Things have move on: with Glee we have seen the song of the week being released and hitting the charts in the week it is broadcast. And when I watch X Factor, I often find myself thinking: if that was a record, i would go out and buy it.
So why not do things differently.
Each week the singer, or group, or whoever, records a song. They might also sing it live on a weekly entertainment show - but the important thing is the recording. After the weekly show goes out, the recordings are put on sale: mp3s on iTunes and Amazon - no need to distribute them to record shops (record shops are so last century too...). The winner is announced the next week - based on one thing and one thing only - highest sales.
What you get is an artist who has managed not just to consistantly win phone votes, but to consistently sell to people who actually buy music.
Which is so much better than the bland forgettable winners of the show who are often forgotten before they get around to releasing their first album.
Monday 15 March 2010
Act Now
I have many ideas. Some of my ideas are good, could change the world, possibly make me a million. Others are poor, or require skills and contacts outside of my capabilities.
But I never seem to act on my ideas. Maybe I share them with friends, or maybe they stay locked up in my head, just waiting for the day when I will be able to turn them instantly into a fully realised whole.
And, as that day never comes, the ideas are never realised.
The ideas in my head stay unused. They are not valuable ideas. Aside from the small amount of entertainment they provide me with they are worthless.
Pick A Possibility is an idea I had recently. It is an idea sanctuary. A place where I can put my ideas in public. A place where I can share them, make them available for anyone to read, and use, and be inspired by.
And so, the first idea I wish to share is just this: If you don't act on an idea quickly - and you don't keep acting on it - the idea isn't an idea which, on its own, is going to be worth anything to you. So don't hoard it - share it - create your own idea sanctuary... and hopefully in time we can start an idea breading programme.
All the ideas I offer in Pick A Possibility are free for the taking. Do with them what you will. My ideas are probably not unique. If you benefit from them, I would love to hear about it. If you want to discuss them, please contact me: I want to hear your ideas too.
And if you want to criticise my ideas, go ahead... but it isn't worthwhile. I'm not likely to put any of these ideas into practise, and in my experience it is always the ideas that make me think "that'll never work" which turn out to be the most powerful, once you get around one small sticking point.
The possibility is the thing. Pick a posisbility.
But I never seem to act on my ideas. Maybe I share them with friends, or maybe they stay locked up in my head, just waiting for the day when I will be able to turn them instantly into a fully realised whole.
And, as that day never comes, the ideas are never realised.
The ideas in my head stay unused. They are not valuable ideas. Aside from the small amount of entertainment they provide me with they are worthless.
Pick A Possibility is an idea I had recently. It is an idea sanctuary. A place where I can put my ideas in public. A place where I can share them, make them available for anyone to read, and use, and be inspired by.
And so, the first idea I wish to share is just this: If you don't act on an idea quickly - and you don't keep acting on it - the idea isn't an idea which, on its own, is going to be worth anything to you. So don't hoard it - share it - create your own idea sanctuary... and hopefully in time we can start an idea breading programme.
All the ideas I offer in Pick A Possibility are free for the taking. Do with them what you will. My ideas are probably not unique. If you benefit from them, I would love to hear about it. If you want to discuss them, please contact me: I want to hear your ideas too.
And if you want to criticise my ideas, go ahead... but it isn't worthwhile. I'm not likely to put any of these ideas into practise, and in my experience it is always the ideas that make me think "that'll never work" which turn out to be the most powerful, once you get around one small sticking point.
The possibility is the thing. Pick a posisbility.
Subscribe to:
Posts (Atom)