How to get good ideas

Sometimes, a good idea can save a lot of time in programming. A simple change of the specifications can literally save more than half of the programming hours. But how do you get these good ideas?

I get good ideas, when I get fed with the right information in a situation where I have plenty of time to think about possibilities.

One way to get this information, is from another person, a partner. It depends on the situation, what kind of person is most suitable. For an introvert, trust is very important, so that the introvert thoughts are not disturbed by extroverted worrying about the situation.

In order to be a good partner in this, you must be prepared to accept, that the things you say are not always treated as truth. Only by uncovering incorrect perceptions of reality, you can create a new understanding which can provide business value.

A good partner doesn't say "That's wrong", but tries to explain, why she thinks it is wrong, and accepts the idea as good, until it has been proven otherwise.

Sometimes, you cannot find a good partner, either because your field of expertise is too advanced, people around you are not prepared to do it, or just because you're not in the mood to talk with other people. In these cases, you must trust your own intuition and develop your idea until the point, where you have enough documentation to persuade others easily.

A recent study in Danish companies shows, that almost all good ideas were not created at work. I guess there's room for improvement, here.

Merry Christmas!

Soft hyphen in ISO-8859-1 and Unicode

I just came across this blog post about Unicode and ISO 8859-1 being unclear on how to show a soft hyphen.

The article contains links to other blog posts and documents about this topic.

I will not give a resume on the problem - read the articles if you're interested. However, I have a strong opinion on the topic: The character set standard should not define the application.

Sometimes you want to create an editor, that exactly shows the contents of a file, so that the user is able to see all bytes in the file precisely. And sometimes the editor has another purpose, like making it simple to create a sales brochure.

In the first case, a soft hyphen should be visible to the user. Think notepad... the character 0xAD should be clearly visible in notepad, no matter where you put it. In the second case, a soft hyphen character can be used to implement an application-specific soft hyphen functionality, where the hyphen is only shown when it makes sense according to the application's purpose.

Some of the articles even mention the use of soft hyphens in HTML. That's really out of scope, since HTML already redefines the layout of so much. It seems somebody has forgotten that the primary purpose of HTML is to render things differently.

Bundling the internet connection with software

Mobile phone service providers are now discussing to pay the mobile phone companies for data traffic generated by their online services.

What happens if the phone service provider doesn't pay? Is this the first step towards a situation, where the feature set of your phone is dictated by your phone service provider?

It has been hard to sell software for a long time, without bundling support, hardware or online services. However, this time we're moving towards a situation where the internet connection itself is bundled with functionality. Imagine that you could no longer use Google if you switched to another ISP...

Don't use passwords. Use passphrases.

We still use passwords everywhere, and they're usually stored as hash values in the database of the service that we log into. I ran into this story about a guy, who looked up the md5 hash value on Google and this way reverse engineered a password. His conclusion is, not to use a password that anybody else on this planet may have used.

The reason that this is a problem, is that many users use the same passwords in multiple places, so if you know their password in one place, you can probably log into other services using that password. If you store all passwords as hash values, and you lose these hash values to people that may abuse them, it is important that they cannot get the original password from it. There are many ways to crack passwords, and lostpassword.com is a good site to know, if you want to know how easy it is to crack passwords.

But how fast can md5 hashes be cracked? Let's try to imagine that we produce all thinkable passwords and generate their md5 hashes, and then use the resulting list as a lookup table, sorted by md5 hash. Let's make a few presumptions:

• The password is only using lowercase letters and digits, 36 different characters in total.
• It is totally random.

Let's say the password has the length n. The md5 hash is 32 bytes, so each lookup item is size=32+n. There will be 36ⁿ records, using (32+n)×36ⁿ bytes of space. How long would it take to find a password for an md5 value? With binary lookup it would use c = log₂(36ⁿ) = n×log₂(36) = n×5 lookups. This is the space needed for various values of n, assuming that a lookup takes 20ms:

• n=5 uses 2GB crack time: 100ms
  
• n=6 uses 82GB crack time: 120ms
  
• n=7 uses 3TB crack time: 140ms
  
• n=8 uses 112TB crack time: 160ms
  
• n=9 uses 4163TB crack time: 180ms
• n=10 uses 1×10¹⁷ bytes
  
• n=15 uses 1×10²⁵ bytes
• n=20 uses 1×10³² bytes

You can buy 1TB drives today, so these are realistic amounts of storage up to n=10. If you want to use a good password, you should therefore ensure, that it's at least 10 characters, and if you want to be well protected, also in the future, go for at least 15 characters.

As you can see, these are bad passwords:

• j4fsk2
• this is fun
• my dog ate my homework (somebody else probably used that, too)
  

These are good passwords:

• slashdot8fischk (15 characters, spelling errors etc.)
  
• roskilde/1997/annie (25 characters, but who is Annie and why Roskilde?)

It is a good thing that a long password can be typed very fast, so it usually needs to contain some real-life words, but make sure to pick some words that other's wouldn't use.

As a programmer, you can help your users make better passwords by providing more space to type the password. Usability research has shown, that this actually helps, although I cannot remember the source for that information. Some systems also use the word "passphrase" instead of password in order to encourage users to type more characters.

Delphi interfaces and implementation

One of the things that makes Delphi unique is the division of all source code files ("unit"s) into several sections: interface, implementation, initialization and finalization.

Everything that other units need to know, is put into the interface section at the top. This reduces the time it takes to understand how to use a file significantly - you don't have to scroll through implementation details. The interface section contains const, function declarations and types, but no statements. Class members are declared, but methods are not implemented here.

The implementation section contains the implementation of all the items from the interface section. The initialization section contains statements that should be run before the application starts, which are local to this unit, and the finalization section can clean up resources in a similar way.

Delphi's compiler contains many neat features to enable faster compilation. For instance, a change in the implementation section, or a change of a typed const in the interface section, will not enforce recompilation of other source code files. Only significant changes in the interface section will make other parts of the source code recompile.

You can benefit a lot from these sections, if you manage to keep the interface section small, making sure that it has few lines of code. If a file has one function, and nothing else, in its interface section, it is much easier to use than if you have a huge class type with lots of private and protected members in the interface section. Unfortunately, this also means that the full benefits are not achieved if you do OOP the traditional way. Sometimes, it even makes sense to write a small unit, which has a very simple interface section, but where all implementation is about making calls to another unit that has a very difficult interface section.

Example:

unit SimpleApi;

interface

function CalculateSomething (parameter:string):string;



implementation

uses
  SysUtils, ComplexApi;   // Which other source files are used/linked

function CalculateSomething (parameter:string):string;
var
  object:TComplexApi;
begin
  object:=TComplexApi.Create;
  try
    Result:=object.CalculateSomething (parameter);
  finally
    FreeAndNil (object);
  end;
end;


initialization
  // This is where you could write code to initialize
  // something for this unit at application start


finalization
  // This is where you could write code to clean up stuff
  // after the application has stopped running


end.

The teddy bear principle in programming

It's very simple: Put a teddy bear on your desk. When you have a programming problem, explain what you are doing to the teddy bear. Eureka is a likely outcome of this method.