Token based credit cards

Like so many others I have an account on the playstation network. I also have accounts on iTunes and on Amazon. What these services have in common is that they save you credit card information on their servers so you don't have to type them every time you need to buy something from them.

This makes it very easy for users to buy stuff from them once the users are logged into their systems. This design however has some serious flaws. A problem is that all the informations needed to withdraw money from your credit card is registered on each service provider. You have more or less handed out a master key to your bank account. Online trade is based on trust and although I do trust these sites not to misuse my creditcard details, they are just managed by humans and are therefore not perfect.

What I would like to see is some kind of token based credit card for the internet. For any site that would like to persist my credit card information I could create a token that they could use to withdraw money from my credit card in the future. This way I could remove their access to my credit card without closing the card entirely. If the token was compromised I could see from which site they got it.

If the tokens included knowledge of the site it was to be used with, it would also be possible for banks to invalidate all tokens issued for a specific site such as Playstation Network.

I just think the current creditcard technology on the net seems a bit outdated.

XPath - fixed!

As you might have read in my previous post, I'm not too happy about the way the XPath works with namespaces.

To make things better I have created some regular expressions that will allow me to write XPaths the way I want to write them and still have them work with real XPath engines out there. It makes the XPath ignorant towards namespaces that are not defined in my XPath query. Namespaces that are defined in my XPath query will be handled like before.

if(!xpath.StartsWith("/")){

xpath= "./" + xpath;

}

xpath = Regex.Replace(xpath,@"/(?[\w]+)\[","/*[local-name()=='${node}' and ");

xpath = Regex.Replace(xpath,@"/(?[\w]+)","/*[local-name()=='${node}']");

PS. I'll get back to the post and tidy the code up later

namespace mismatch

Once in a while you come across technologies that on their own are great, but put together are painful. Either you just live with the pain, you deselect one of the technologies or you try to improve the way they interact. This is the case with namespaces and xml/xpath.

Let me just explain that I am a big fan of XML and of XPath and XMLSchemas. They are related and work quite nicely. The schemas describe the data structure and can be used for validation. The XML is the datastructure and XPath is the query language for searching in the datastructure. Together these are very powerful.

Over the years I have heard a lot of people complain about XML, but often they are using it for the wrong purpose, they don't know the power of XPath to assist them or they are drowning in namespaces and prefixes in their xml documents.

Namespaces in xml are introduced to allow cross references across schemas and thereby allowing reuse of schemas. Every namespace, other than the default namespace, is given a prefix. For loosely structured documents this enables the writer of the XML document to specify on every single element, in what namespace it is defined. A good example of that is the XSLT documents. Here prefixes helps the writer of the xml validate only the elements that are part of the XSLT transformation logic. For this purpose namespaces and prefixes are great.

What I generally see with custom xml structures however is that the structure is more strictly defined and name clashes are less likely.

If I were to define the way xml and xsd would work with namespaces I would make the namespace prefixes optional on xml nodes where type and namespace could be derived from its placement in the structure. If the schema eg. only allows for one type of "address" element at a given location, why should I specify what type of address element it is? Only where name and type clashes occur would I demand namespace prefixes.

Namespaces should be treated as metadata of elements. They are just for validation and identifying the type of an element where name clashes could occur. For everything else they are irrelevant.

That brings me on to XPath and namespaces. Namespace information is metadata as far as XPath is concerned and you have to ask for the details if you want to use it in the query. It's a different story with prefixes. Actually the prefix is part of the name you can search for. This makes absolutely no sense as prefixes are only valid within a single document, and a the next document you receive might have other prefixes but be just as valid. The impact is that you have to make your XPath queries quite verbose to ignore the prefix and it really is a painful experience. If I could redesign XPath, I would make XPath ignore the prefixes of elements to be the default behaviour. Actually I don't see where anyone should use the prefix knowledge in a search.

When descission makers are clueless

It's a well known fact that you don't have to know anything to make a descision. Not knowing anything really speeds up the process of descisions and in some cases the descisions are just as good. In some cases they come with a price of being worthless or even disasterous.

When you don't know about what you are to descide upon a common aproach is to seek advice by somebody that know something about the subject.

Clueless descissions are most destructive when done in higher management because the consequences are often bigger. This includes politicians that are elected to make descissions. In Denmark there have rescently been some bad examples of such descissions regarding IT.

1. Descissions about open document standards. Politicians kept OOXML in the loop although there was a better alternative that was more open at that time.
2. NemId was chosen as the new authentication for citizens of Denmark when communicating with the goverment. (about taxes and stuff). I have used it and its work nicely from the end users point of view. The problem with the solution is that is uses certificates with public/private keys...  The private keys are placed on a centralized server. They have broken basic security principles and I think that is a problem.
3. Rejsekortet is a new way of paying for public transportation. To do this they implemented their own encryption algorithm. The system has not been put into production yet, but the encryption algoritm has already been broken.
4. Digital elections. Computers can be used for almost anything else. Elections part of a democratic proccess is not part of what computers can be used for. Pure electronic elections don't support recounting of votes and tampering with all votes can't be guarenteed. Elections of less importance, with truely trustworthy third parties can be implemented. Everybody has a interest in a democratic election and there is no trustworthy part that can ensure that the votes are not tampered with. It has been decided by politicians that electronic elections will be tried out.

Dynamic method binding

One of the added features to C# 4.0 was dynamic objects. It gives late binding to C# so everything doesn't have to checked at compile time. In some cases this makes it a lot easier to use reflection as you don't have to use any of the .net API's to do so. You can act directly on the object as if you had the type at hand. All you need to know is the footprint of what you need to access. Most examples emphasize how this can be used when integrating with other technologies like old com objects etc, but I have been looking for usages outside that scope. One is ofcourse reflection, another one is dynamic method binding that I will try and explain.


Basic OO with cats and dogs.

I create the traditionel object structure to support me explain what I mean. Animal is a pure abstract concept, Cat is an Animal and so is Dog.

Make the animals make som noise

I have created a MakeSound method that operates on the interface and one for each of the classes. As there is no general sound that will match any animal I just print ????? to the screen when in the context of Animal.
What I want is to have a list of animals containing cats and dogs and then call the MakeSound for each animal in the list.

As in C# < 4.0

The big question is what method is actually called. The answer is that the method binding is done at compile time, the best match is the method that takes the interface as a parameter. All the objects are treated as of type Animal. This is the way it has always worked in C# and it should therefore be no surprise if you have been in a similar situation. The output is as follows.


Result of program with static method binding



Use of var keyword



With C# 3.5 the var keyword was introduced. One might think that this changed the way this would work as the programmer no longer defines the type and the framework should therefore be able to select a better method implementation automatically. The answer is that the var is just a way to have the compiler derive the type instead of the programmer. This is all done at compile time and the best match will therefore still be the method that operates on the interface.

Handle the objects as dynamic instead

The dynamic keyword was introduced with C# 4.0 and this changes the possibilities when writing code like this. When treating every object in the list as a dynamic object, the compiler won't bind to any method but will leave it to the runtime to make the connection. This means that the type of every object is considered and handled on its own and the items in the list won't nescesarily result in the same method being called. This can be very usefull when iterating tree structures etc. The downside is that you will have no intellisense and no compile time validation when writing the code.

As the best methods are now called, the output will be cat and dog specific.

Output when treating the objects as dynamic

This can definately clean up some of my code. I might write a comment along with the code so that people in the future can figure out my intentions.

Related posts:
Wrapping objects with interfaces
Dynamic duck typing in .Net 3.5

Testers vs. Developers

Some time ago I read somewhere that Microsoft had problems getting software testers in Denmark. They were puzzled by this as they found the workforce to be educated and they had no trouble finding developers.


Although testers and developers should share some common knowledge of technology, their personalities are completely different. Good developers need to be inovative to be able to find solutions to problem they have never seen before. They should focus on the big picture and always strive for the best compromise. Good testers on the other hand have to focus on details and they need to be able to repeat an exact action and follow a script. The qualities wanted are opposites and it will most likely never be possible to find a person that posseses both.

Links:

• My Prefered Developer Profile
• There is no such thing as perfect

http://www.version2.dk/artikel/14884-test-er-fy-ord-i-jobannoncer-microsoft-kan-ikke-hyre-danske-software-testere

5 years and still going

Yesterday it was 5 years since I started this blog. I started it because I needed somewhere to let steam out. (And I actually started it together with a friend) I wasn't sure I would be able to continue posting to it but after 5 years I still have issues I want to share (with myself). Luckily the world never stops changing and I never stop discovering things I hadn't thought of before.

The focus has been from very technical to philosofical about human nature. I'm looking forward for all the new blogpost that I am to write :)

Trust me, I know what I'm doing

Trust is important to any social relationship or communication. While I was out for a run I listened to a podcast about this and it really made me think. It stated that trust is also good for business. If you trust your surroundings you will be more open for doing business. Societies based on trust have a higher growth than societies that do not incorporate trust. This is a great message that I will try to spread around.

On a personal level you will gain a lot by trusting other people as well. By doing so you can benefit a lot more from other people. If you for instance are an employer, but don't trust your employees the only value they can add to your organisation is doing the stuff you though of to begin with. Once you trust your employees, they will be able to add value to your organisation on their own. You will no longer have to supervise them and they will be able to inovate. They will have to take ownership and it will lead to a higher level of motivation.

Actually you should not trust me because I know what I am doing. You should trust me because it is in my best interrest to help you out and because you will benefit more if you let me do it my way.

Related posts:
http://dotnetexception.blogspot.com/2010/04/leadership-is-about-motivation.html
http://dotnetexception.blogspot.com/2009/11/flank-your-problems.html
http://dotnetexception.blogspot.com/2010/01/there-is-no-such-thing-as-perfect.html
http://dotnetexception.blogspot.com/2009/03/misunderstanding-path-to-new-ideas.html

Discuss this!

I have categorized discussions in 4 groups

Religious
When in the context of a religion, the main goal of a discussion is to reach an already given conclusion. Any valid arguments are discharted if they contradict the given conclusion.
This kind of discussion is often held by religious people such as evangelists (the software kind too) or sales people. It's also the favorite form for drunk people trying to argue that they are not drunk.
Religious discussions also occur if you are too specialized. If the only tool you know how to use is a hammer, you are bound to use a hammer to solve every problem.

Philosophical
These are discussions without a goal. That might sound useless, but it's not that bad at all. It's about questioning your own beliefs.
It's a mind opener. It's about challenging your ideas, getting the big picture.

Scientific
The scientific discussion is about reducing the complexity of a domain. The conclusions might be inaccurate, but it should result in the optimal solution all things considered. Issues like feasibility and return of investment are handled in these discussions as well as risks. It should be noted that a conclusion concluded today, might me changed tomorrow. Scientific discussions embrace and accept change.

Lawful
Law is about details. The more the merrier. When you reach the maximum amount of details any human can comprehend, you are about half way there. The downside is that often the big picture and reasoning is lost in the pursuit for details. Although the focus is on details, even the details are sometimes lost in discussions like that. The last man standing is the one with photographic memory and who can stay awake the longest. To succeed in this category I suggest that you give up on any social life and start nit picking on your surroundings. Although there can be a winner in such a discussion, the real looser is the common sense and productivity.
Law is a primal discussion form and we are trained to master it when we have arguments in kindergarten about what is right and wrong and which kid has more candy (milimeterdemokrati).


When it comes to software development, you might have these different discussions at different points of time on your project. The religious discussions occur in the beginning of a project, or when changes to the project occur. Although the religious debate has a high return in the short term, the long term might suffer.
As the philosophical discussion is about challenging your current beliefs, it's great for workshops or when a project is stuck in a dead end.
The scientific discussion is great for decision making on a project. What separates a decision derived from a scientific discussion from a religious discussion is the scope.
The lawful discussion comes into play on a software project when someone feels he's not treated right. The discussion often can't be resolved by the parties involved and a third party is then required.

Let the discussions begin!

Change the world, bit by bit

Although you meet resistance, you should still still keep on trying to change the world.

When it comes to software you are often met with statements like:

• This technology is going to be a mayor player.
• Its a strategic decission to use this product.
• Thats what the client wants.

If you are a software developer and know better than what has been presented to you, you should share this knowledge. If we let the world evolve by the words of marketing people, complexity will keep on increasing, with out any innovation. If you want to help reducing complexity, please do let the people around you know when they are mistaken.

Hierarchy of Information

Most enterprise software solutions deals with data. Actually I can't think of any that don't. Many enterprise solutions deal with lots of data. The application helps the user to deal with these massive amounts of data.

I think of different levels of information. Each level decreases in size, but increases in value. Data in its lowest level is not very valuable. A bit or a byte of data is quite useless out of context. When characters are added together to form a string, the value increases significantly. A string in the form of a sentence is easier to remember than a equally amount of random bytes. The amount of information has decreased, but its value has increased. We are now able to compress the information to something smaller. Raw data is refined to information, knowledge and wisdom.








The Earth computer in The Hitchhiker's Guide To The Galaxy is the ultimate example of this refinement of information. All the information in the world is refined to the very short and easy to remember result: "42". If this was not fiction, this result would be the single most valuable piece of information.


Every business strives to find the secrets of making lots of money( or save the planet ), and every business application is build to expose these secrets.

Somebody has been reading my mind

This december I won a book (actually I won four, but the other ones were just not as great) in a technology contest. I don't know how I have missed out on this one. I have seen it on the booksshelfes but I have not read it until now. I must say that its brilliant. "The Pragmatic Programmer" is a pleasure to read.


The Pragmatic programmer is about thinking while you develop. It  promotes the obvious that is apparently not as obvious as we thought. Its as if the authors read my blog posts before I even wrote them :) This book really makes you think and I hope I can get my current collegues as well as future ones to read this so they can reflect a little about their actions.

Leadership is about motivation

Leadership is not a simple task, but I think you will come far if you focus on motivation.

How to motivate while you lead can be done in a number of ways. The first step is of course to understand your teammembers. Find out what makes them tick.
I think the best way to go is to find common interests and focus on that. Knowing the persons on your team makes it easier to find something that will naturally interest the individual.

Cool cash
This an easy way to motivate people. Money is a fundamental requirement for everybody. The problem with this is thats if this is your only motivator you can easily be outbid by others.
If we reflect this to training a dog this resemples giving your dog treats when it does what you tell it to. It will work as long as the dog is hungry and likes your treats. If someone shows up with better treats you have lost.

Fear
This is the opposite of the Cool Cash motivator. This is where you punish people if they don't do as they are told. This method has worked like a charm for many dictators in the past. The downside is that there can't be any alternatives to your leadership, and thats not easy to enforce in todays society. This works best if you have an uneducated workforce.
In dog training this resembles beating your dog untill it does it right.

Common interests
You need emphathy to succed with this one. You need to understand what drives the people working for you. If your workforce matches the tasks you have, it's going to be easy. They will more or less do it right whatever you say. This is about choosing the right team for the job. If you need to herd sheep, choosing a hunting dog would be a bad choice.

Once you have your team put together you need to know what drives your team members. Some people strive for acknowledgement by coworkers, some live by the shear technology challenge presented to them and other people strive by other things. It's important to realize that motivation is not just important as to maximize output by your team. If you don't know how to motivate your team, it will collapse. And chances are that it will influence other parts of your business.
In dog world this resembles: If you have a herd dog and don't provide stimuli, it will take your house apart.

Plans are just for a general direction

By now, it must be clear to most people in the software industry that software projects seldomly go as planned.

There is a lot of debate in Denmark about
large govermental IT projects that fail. It would have surprised me more if they didn't fail. They are large project with a vast number of details that must all be fullfilled for the projects to succeed. That's just not a realistic scenario.

An IT software project is about inovation and not about building something already known. If you encounter a bump on the way on the road, you shouldn't have to force your way through it if there is a more sensible way around that was not part of the project to begin with. There's bound to be some experimentation going on during any project and you must be able to change the requirements along the way as the parties involved get smarter and discover things about the domain at hand.

These days, the role of the project manager isn't to keep the project on track, but find a way when changes to the requirement ocur (not if, when).
If an IT software project is to support change, it's needless to say that it requires a lot of involvement from the client (the buyer of the project). You can't order some software that takes 3 years to build and expect it to be like you imagined it to be if it is build solely based on a document you wrote to begin with. If you want to benefit from a project you have to get your fingers dirty yourself.

Being disposable is a goal in it self

Your true value is shown if you are disposable and still have a job. This means that your work is actually appreciated. If you kling on to your job by having a bunch of old applications that just don't work unless you're around, then in my opinion you have failed.

The same goes with the applications that you make. If you make applications that depend on your future presence you are just gathering new responsebilities along the way. In the end you are not going to be inovative because your past will haunt you.

SAAS vs. thick client

The other day my work computer crashed. I took me quite a while to get up to speed. The IT department ofcourse provides a standard image they can put on my computer and get me part of the way. The programs I depend on and the antivirus provided are not good friends so I chose to install the computer on my own.

So... I'm down to installing the operating system, installing different office products to read documents and some development tools. A lot of time is spend finding the programs i need, and finding licence keys that match. After a days I'm still missing some programs that I will need later. Its a long and slow proccess...

Why does commercial software need to be so troublesome to install?.

If I could do with open source tools (thats not an option) i'm sure I could have set up an ubuntu with all the packages in an hour or so. I wouldn't have to find and download the software i need and I wouldn't have the trouble of typing in keys and trying to activate them and find out why they didn't activate properly.

For my personal stuff I have moved everything to google apps. This means that once I have a browser up and running I'm good to go. This and the fact that I don't have to think about backups etc. is a sure winner for me!

Predictability is a key feature

You can run a rally car on ice. You can travel under water. You can create a fast program based on slow components.

This is all due to predictability. While racing on ice you know more or less what friction you will get and what it will take to change direction. You will know how far you need to see ahead to be able to stay on track. If that criteria is met you can go as fast as possible.

On the oter hand, if you are racing on a mixed surface, you have to go slower. While you have traction you have to drive with a big margin to be able to control your skid if you suddently loose traction. While you lack traction you have to drive slower because if you skid around the corners and reach a high friction area you will end up in the ditch. Given the choice I would definately choose the high predictablity over max traction.

If you know all the parameters of a software project up front you are pretty safe. If you know all the parameters up front, you will also be the first in history to do so. Are you so sure of your requiremetns that you can choose components that fulfill your requirements but are not flexible enought to handle requirement changes? Are you so sure of your performance demands that you  can choose components that perform well but don't scale if your demands change?

Flexibility is often a an underrated feature. Its hard to put in sales brochures. Its hard to tell customers that the extra cost is to support their requirements in the future that they are not aware of yet. Often it has to do with how mature an IT project organisation you are dealing with. The more mature it is, the greater the chance of it expecting changes in the future and the more flexibility it wants from its IT systems. My experience is that these changes will amerge before the end of the project and the flexibility will end up saving them money before the project has ended.

Whats your projects focus?

My diagram illustrates the focus in a project. The blue on the left hand side is the business and the red on the right is the techonolgy focus on a project. The focus on any technology project will go from somewhere on the left towards the right.

In the 'A' section focus is on the business processes. Its The Why of the project. This is where you have to justify the business processes. Are the business processes really business processes or are they in fact based on limitations in old systems. If there are any mayor improvements to the busines process, this is the place to discover them.

In the 'B' section business and technology are equally important. Its The How of the project. This is where you figure out the technical specifications for the project. There might be some adjustments to the business to make it feasible.

In 'C' its mostly about technology. Its The Where of the project. Here there is little you can do to the business. You just have to implement the stuff that has been decided.

A mistake I have seen on a lot of projects is that they focus on technology. They skip to "The How" or "The Where". They haven't realized that the real benefit from technology comes when you also change the way you operate and the way you think. The reason for skipping "The Why" is often that they claim its a technology project and they already know about their business. Some people are actually offended if you suggest improvements to the way they work. Its very sad to be on such a project.

Many projects I have worked on are based on contracts that include a lot of requirements. If they have not recieved guidance in making these requirements, they have missed out on a lot of possible proccess improvements. If your project is all in the C section the benefits from the project will be minimal, and the project will be more or less pointless.

My recommendation is to keep the focus as far to the left as human possible. Thats where the sweet honey is :)

The diagram can also be applied to technical documentation or books. They will and should start by outlining what it is all about. As you proceed through the text it will focus more and more on the technology. For me I find the first half of a technical book easier to read than the last half.

HTML5 to the resque!

I have previously written that I was disappointed with silverlight as a platform for rich user interfaces in a browser. It probably has a lot of nice features, but as a web technology it's not really important if it is not platform independant.

I went to see a demonstration of HTML5 the other day. I don't think there is much you can do in Silverlight or Flash that you can't do in HTML5. Silverlight and Flash are bound to fade out and their domain is going to be taken over by HTML5.

Internet Explorer is currently the only mayor browser not supporting HTML5. You can however install a plugin that will allow HTML5 to be displayed correctly.

Being a Generalist

Thats me!

I dream in abstracts and concepts and avoid anything with substance.

Some people like using their time getting better at what they already know. I seldomly have more than one book on a subject and have a hard time focussing on a single issue long enough to get any real experience with it. As soon as I have basic knowledge of a subject I tend to move on. This doesn't mean that I don't have a lot of books or isn't constantly on the lookout for new input. Au contraire.

If we take databases as an example. My interest stops at tables and what you can do with ANSI SQL. What features each database implementation has is not really important to me. I can look that up if I need it later.

The disadvantage of this approach is that I'm dependend on my team to complete anything. Luckily I like working together with people.

The advantage is that the knowledge I gather isn't easily outdated and it can therefore accumulate over time. In other words I don't have to start from scratch every other year by learning new technologies.