Postpone decisions

February 27th, 2008

Delay the decisions until they solve themselves or disappear. Sometimes postponing is futile and a decision has to be made. Then make it, but not earlier than that.

Sometimes one need more balls to not decide than to decide.

( And or course… not making a decision is also a decision… )

>Bad menus

February 18th, 2008

>Since my first application with menus à la Mac/Win I have wondered over the semi standard menus.

So first we have File, a noun. There is supposed to be things to manipulate Files there.
Then comes Edit, a verb. Is this where you look for ways to edit things?

View which often follows is both a noun and a verb which is good because then you can have lots of stuff in it. Which is bad because you can have lots of stuff in it.
After this there is usually a group of menus that are application specific so I have no opinion of them.
Ending the group of application specific menus is the menu Tools that really is a misspelled acronym for Things Out Of The Standard; or possibly Things That Go Nowhere Else.
The finale is Help that contains ways to get help. And the version number of the application.

Am I the only one who feels this as a bit illogical?
Shouldn’t all top menus be nouns or am I missing something?

>Coloured layers

January 25th, 2008

>In a multi layered application one is bound to travel up and down and up again through the layers. It is usually not hard to keep track of where one is; just read the contents of the methods or check the namespace in suitable textbox.

But wouldn’t it be nice to have an extra signal? I am thinking of changing the colour of the background or frames or something. Not from red to green but something more subtle. Ridiculous thought? That is what I thought too when I first encountered coloured source code. “colouritis” whas my response. Today I cannot live without it and wouldn’t mind using different fonts the same way.

Ok, ok. “cannot live without” was an aggravation.

>How to raise an event

January 24th, 2008

>It is very simple to raise events in dotnet/C#.
But there is a caveat one should be aware of; especially since it probably will show itself intermittently and be hard to track down. It is when someone finishes his listening for the event between the does-someone-listen-for-the-event and the very firing.
The good news is that it is easily solved by a temporary variable like so:

internal event NavigateDelegate OnNavigate;

internal delegate void NavigateDelegate( NavigateTypes navigateType );

private void Raise_OnNavigate(NavigateTypes navigateType)
{
    NavigateDelegate tempEvent = OnNavigate;
    if (null != tempEvent)
    {
        OnNavigate(navigateType);
    }
}

If the above is hard to remember there is a snippet
    invoke
to use.  Just write it at a line and press Tab.

>The simplest possible solution, but not simpler than that

January 22nd, 2008

>This message will be repeated in english.

När man inom Agile pratar om den enklaste metoden menar man inte den lösning man först kommer på eller den som går snabbast att implementera.
Med enklast innebär den lösning som löser uppgiften med minst extra information och avsteg från befintligt mönster.

Detta kan tarva en förklaring.
Med minst extra information menas möten, dokumentation och implicit och explicit kunnande. Om lösningen följer gängse mönster behövs antagligen ingen dokumentation, varken som explicita dokument eller inline-kommentarer. Om lösningen är “rätt” krävs mindre möten, diskussioner, dokumentation, rådfrågningar och redogörelser.

Enklast är inte nödvändigtvis den lösning som kräver minst tankearbete eller minst jobb.

För att vara ärlig talar jag inte för hela den agila rörelsen. Texten ovan är min tolkning av begreppen, metoden, livet, universum och allting.

When the agile development movement talks about the simplest solution; they do not mean the first solution that pops up in the head or is fastest to implement.
Simplest means the solution that solves the problem with least extra information and sidesteps from the chosen/optimal path.

This might demand an explanation.
With least extra information means meetings, documenation, implicit and explicit knowledge. If the solution follows the chosen path, colour and rythm of other well written parts of the solution; it probably doesn’t need documentation, neither as explicit documents nor as inline comments. The “right” solution requires less meetings, discussions, documentations, questions and answers.

The simplest solution it not neccessarily the solution that requires the least amount of thoughts or work.

To be honest I cannot say I speak for the whole agile movement. The text above is my view of the terms, the method, life, universe and everything.

Everything is a bug

January 18th, 2008

This message is repeated in English below.

Allting är en bug. Eller snarare: allting är ett ärende.

Oavsett om ärendet skapar en krasch, är fel storlek på loggan eller innebär installation av en UPS är det något som skall tilldelas människa och tid.

Min åsikt är att lägga allting i samma hög. Och med allting menar jag allting. Sedan prioriterar man ärendena och plockar från toppen. Om detta liknar valfri agil metod är det inte för att Henrik Kniberg, Kent Beck och jag har kommunicerat utan för att det är ett bra tillvägagångssätt.

Varje ärende måste ha ett unikt ID. Ett ID som inte hänger ihop med ärenderubriken. Detta unika ID måste gå att säga och skriva; jag föreslår konsekutiv numrering, 1, 2, 3…
För icke-databasssystem använder jag dagens datum följt av 01, 02, ..99 (20080118.01) för att jag brukar kunna hålla antalet ärenden idag i huvudet och har ännu inte råkat ut för fler än 99 på en dag.

Det här med en och samma ärendetyp har Microsoft Team Foundation missat. När man skapar ett ärende i det kan man välja mellan olika ärendetyper och när man har valt kan man inte ändra. TFS är konfigurerbart så man kan säkert välja bort alla ärendetyper utom en, men att det överhuvudtaget finns känns konstigt för mig.
Uppdatering: 20170810: Sedan några år kan man byta typ på ärendet i TFS.

Jag önskar mig ett ärendehanteringssystem där man får en översikt av sina ärenden mer än som bara listor med rubriker. Jag önskar mig en sorts bollar med snören emellan där man smidigt kan se vad som hänger ihop och hur mycket som påverkas om man drar i en av bollarna.

Everything is a bug. Or rather: everything is an task.

Disregarding the issue creates a crash, is the wrong image size or installation and configuration and testing of a UPS it is something that will be given a human and time.

My opinion is that everything should be in the same pile. With everything I mean everything. Then the tasks are prioritised and picked off of the top. I you, dear reader, now recognises and starts looking at your books about agile project methods this is not a coincidence. I am not saying that Henrik Kniberg, Kent Beck and I have communicated but because it is a good method.

Furthermore every task must have a unique ID separated from the title of the task. It must also be short enough to say and write – I suggest just numbering them from 1 and on as they are created. In spreadsheets and other non-database systems where I cannot track the unique key I usually use the format yyyymmdd-nn because one can probably store the number of tasks that day temporarily in the head and I have never written more than 99 issues in one day.

Looking at Microsoft Team Foundation I say that they have stumbled regarding the everything-is-a-task thing since there are several task types (In TFS a task is a special kind of task/issue/item/todo item/bug/…) and once you have chosen one type there is no going back. To their defence I have to mention that TFS is configurable and one can choose to use just one of the types. But the very existence of non-changeable issue types is strange.
Update 20170810: Since a few years it is possible to change the type of an issue in TFS.

On my wish list is an task manager where the browsing and handling of taks are outstanding. I wish of something like balls interconnected with strings and when you juggle one ball you se whatever it pulls/affects.

>Replace Notepad with something better

January 17th, 2008

>This message will be repeated in english.

Notepad.exe är en editor knappt värd namnet. Den väger in på 68k vilket inte är så mycket för en windows-app.
Men så innehåller den två kända buggar också. En som plockar bort text om du använder notepad mycket / har stora filer och en som inte klarar av vissa teckenkombinationer i början.

Tidigare använde jag NoteTab som är en alldeles utmärkt editor som är gjord för att ersätta Notepad. Den både hade “.log -i-början-av-filen”-funktionaliteten och i installationen ingick det en fråga om man ville byta ut Notepad. Det ville man.

Men sedan WinXP har inte det gått. Testa att byt namn på Notepad.exe i %windir%\System32 och den poppar rätt tilbaka igen. Så om du undrar var din hårddisk tagit vägen så ligger det uppenbarligen 2 st operativsystem på den.

Men räddning finns: http://blogs.msdn.com/omars/archive/2004/04/30/124093.aspx

Notepad.exe is an editor hardly worth mentioning. It lacks functionality but has still managed to cramp in 2 bugs into 68k.

I used to use NoteTab earlier which was built as a Notepad replacement. It even had the “.log -in-the-beginning-of-the-file”-functionality and the installtion procedure contained a question whether to replace Notepad. That was the obvious choice.

But since WinXP this has not been possible. Locate Notepad.exe in %windir%\System32 and change its name. A new Notepad.exe will pop up from nowhere. So if you wonder where all your hard disc space is gone you now know – there are two installations of Windows on it.

But Notepad can be replacede byt following this link.

>Build list classes

January 17th, 2008

>This message will be repeated in english.

(dotnet-kod)
Gör listklasser av dina klasser.
D.v.s. gör en egen klass
    class UserList : List
    {
        …
    }

För då blir anropen

    UserList userList = new UserList( “whatever parameters” );
    User user = userList.FindByName( userName );

istället för

    List userList = GetUsersByWhatever( “whatever parameters” );
    User user = FindUserByName( userList );

Lika många rader kod och ungefär lika lättläst men bättre “information hiding” i de senare exemplet.

(dotnet code)
Make list classes of you classes.
Make it like

    class UserList : List
    {
         …
    }

Then you can have calls like

    UserList userList = new UserList( “whatever parameters” );
    User user = userList.FindByName( userName );

instead of

    List userList = GetUsersByWhatever( “whatever parameters” );
    User user = FindUserByName( userList );

About as many rows of code and about as readable but better information hding in the latter example.

>Dogfood and Kopain

January 17th, 2008

>This message will be repeated in english.

“Eat you own dog food” är ett uttryck för att använda det man själv tillverkat. I mitt fall bestämde jag mig för att använda Kopain från den förste i år.
Det är en enkel editor med RTF-möjlighet och framför allt en hierarkisk meny på sidan. Helt enkelt en rip-off av KeyNote som jag använt i flera år.

När jag började använda Kopain hade den 2 kända buggar. När jag använt applikationen en dag hade jag hittat fem till. Plus att ett par av sakerna på feature-listan (någon som vet en översättning av “feature”?) hade eskalerat till buggar i och med att de störde användningen för mycket.

Varför bygger jag en ersättare till KeyNote? (i den mån den kan kallas ersättare då den inte kan en bråkdel så mycket)
För att jag vill. Och för att jag kan.
Men framför allt att den sparar på ett format jag inte gillar. Det sparade formatet måste vara lätt att läsa och läsbart med något annat än ursprungsapplikationen.

Är det någon som vet en editor/ordblandare jag kan integrera som sparar annat än RTF? Jag vill ha något som är mer lättläst och generellt typ HTML då RTFstandarden verkar vara ungefär “det som WordPad lämnar från sig”.

Jag är nu inne på den 17e användningsdagen av Kopain och jag har fortfarande två kända återskapningsbara buggar. Jag har kraschat applikationen en handfull gånger och den har en gång zappat 2 dagars noteringar. Jag är nöjd.

“Eat you own dog food” is an expression for using what you have created. In my case I started using Kopain from the first day this year.
It is a simple editor with RTF possibility and above all an hierarchical menu to sort the notes. Simply put a rip off of KeyNote which I have been using for several years.

When I started using Kopain it had 2 known bugs. When I had used the application for a day five more had surfaced. Plus two things on my feature list had escalated to Bug status since they had to big an impact on the usability.

Then why did I build a replacement to KeyNote? (if it can be called a replacement at all since it contains a fraction of the functionality)
Because I want. And because I can.
But above all that is saves in a format more easily read. The saved format must require the original application to read.

Is there someone who knows of an editor with formatting capabilities I can integrate instead of the RTF thing I have today? I must be able to save in a more open and easily read format like HTML since the specification for RTF seems to be “whatever WordPad spits out”.

I am now on my 17th day of eating. I still have 2 recreatable bugs. I have crasched a handfull of times. I have lost 2 days of work. All summed I am satisfied.

>Central objects in the domain model

January 4th, 2008

>This message will be repeated in english.

Bli inte förvånad att det centrala på en fabrik inte är det centrala när domänen modelleras.
I kvalitetssäkringen av en rörfabrik är inte nödvändigtvis rören som är centrala utan istället alla mätvärden; och inte ens dem utan den lilla biten som säger om mätningen är godkänd eller inte.

Do not get surprised when the central object in a factory is not the central object in the domain model.
When creating a system for quality assurance in a tube factory it is not neccessarily the tubes that are central in the domain model but the measurements; and not even them but the small bit that tells if the measrumenent is approved or not.