October 18th, 2007
>This message will be repeated in english.
Häromdagen dök en konstig sak upp i testningen. Fel uppstod och försvann utan att vi gjorde något. Jag bygger system så att detta inte skall hända så det var dubbelt konstigt.
Jag satt med testaren på telefon och diskuterade vad han gjort och vad vi andra gjort; om något hänt mellan eller under hans tester. Vi diskuterade databaser, releaser, maskiner, applikationer, var han hämtar… Bingo! Testaren förutsatte att en installation var kompilerad innan han testade.
I efterhand kunde jag ha listat ut det eftersom jag var med och satte upp QA-reglerna men i min iver att få ihop den nya funktionaliteten och testa att leverera utan att testa glömde jag av testarens arbetsregler.
Så vi hittade felet; fel målbild. Målet var inte att ordna med ny funktionalitet utan att levererera denna nya funktionalitet till testaren.
The other day a wierd thing surfaced in testing. Errors sprung to life and disappeared without us changing anything. Considering me constructing systems so this will not happen made it double wierd.
I disussed this with the tester over phone. We discussed what he had done, what the others did; if something happened between or during his tests. We discussed databases, releases, machines, applications, where he fetches… Bingo! The tester fetched each new ready created installation and I hadn’t supplied one.
Looking back I can know I knew I had to create the installation before handing over the new functionality; but eager to deliver and try to deliver without testing made me forget the environment of the tester.
So we found the error; the wrong target. The target was not to provide new functionality but to deliver this to a tester.
October 17th, 2007
>This message will be repeated in english.
Free source är en etisk ståndpunkt. Open source är en pragmatisk.
Free source grundar sig på att allting du inte vet vad det är på din dator har du ingen kontroll över. Och för att ha kontroll över din data måste hela processen vara transparent; BIOS-OS-GUI-applikationer.
Open source grundar sig på att öppet är bra men att vår västerländska ekonomi inte är byggd för öppenhet. Alltså måste man ta avsteg från den perfekta vägen för att få fler användare.
Free source is an ethical viewpoint. Open source is a pragmatic.
Free source is based on that what you do not know about, you have no control over. And to have control over your data the whole process has to be transparent; BIOS-OS-GUI-applications.
Open source is based on open-is-good but that our western economy is not built on openess. Not ready. Therefore a different path than the perfect is used to allow more users into the community.
October 17th, 2007
>This message will be repeated in english.
En artikel med en skiss på hur länge man skall debugga. Ibland skall man lämna buggen innan man har hittat den.
Detta hänger bra ihop med min syn på bug/ärende-hanterare. Skriv ner buggen/ärendet och lämna det till någon – vem som helst som kan ta buggen/ärendet vidare och fortsätt med det du jobbade på när du hittade buggen. Nu ligger buggen/ärendet i listan över saker att göra och någon kommer prioritera den.
Märk att om du däremot skall rätta buggen så skall du ta reda på orsaken och inte bara rätta symptomen.
An article with a sketch of how far you should debug. Sometimes one should leave the tracking before the bug is found.
This corresponds well with my view of how a bug/issue-manager should work. Write down the bug/issue and leave it to someone else. Now the bug/issue is in the list and it will be prioritised.
Note that if you are supposed to fix the bug you have to fix the very cause and not only the symptoms.
From the article:
“…stops debugging it and files the bug. He doesn’t dig into the implementation itself to see where the memory leak is happening. He never gets to the exact cause. But, what he has done is find somebody to assign the bug to, and then he moved on…”
October 17th, 2007
>This message will be repeated in english.
Den “rätta” lösningen, d.v.s. den som en habil programmerare helst vill göra, är ofta den riktiga. D.v.s. den som är snabbast, billigast och/eller bäst.
Jag har inga siffror eller ens halvobjektiva mätningar eller exempel utan bara en känsla efter att ha drömt mig tillbaka i projekt. Felaktigt användande av “Rätt” lösning skapar måttlig extra kostnad medan felaktig lösning kan bli hur dyrt som helst.
Förutom att bli billigare, rent kontomässigt, gör det programmeraren gladare med. Han får möjlighet att skriva trevligare kod och kanske t.o.m. testa en teori. Detta ger bättre kod.
The “right” solution, the one the programmer prefers, is often the correct one. The one that is cheapest, fastest and/or best.
I don’t have any numbers or even halv objective statistics to support my case but only a feeling after having thought back att earlier projects. Implementing too many “right” solutions adds marginally to the cost while using the wrong solution has no upper limit.
Besides being cheaper in the long run the programmer is also happier with being able to create nicer code and even test a new theory. This gives better code.
October 14th, 2007
>One of the simplest but lovliest inventions by the Opera browser is to search google through writing “g” in the address bar like so:
g selfelected
It is easy to extend this to search Wikipedia through for instance “w”.
Meny:Tools->Preferences->Search->Add->Details
key: w <- e.g. address: http://en.wikipedia.org/wiki/Special:Search?search=%s
To let Google search wikipedia.
key: gw <- e.g. address: http://www.google.com/search?q=site:wikipedia.org+%s
More searches
October 8th, 2007
>This message will be repeated in english.
Free source är en etisk ståndpunkt medan Open source är en pragmatisk
Free source is an ethical decision while Open source is a pragmatic.
October 6th, 2007
>This message will be repeated in english.
Har du någonsin stått inför dilemmat hur metoderna och deras paremetrar i en klass skall se ut?
Skriv anropet först så får du en känsla för hur användaren vill göra.
Hur en metod ser ut kan vara viktigt, det kan till och med påverka arkitekturen.
Have you ever been sitting without being able to work just to figure out the name and parameters of a method?
Start by writing the call to get a feeling for the user’s preferences.
The looks and work of a method can be important enough to have an impact on the architecture.
October 1st, 2007
Dotnet WinForm has a control called Split container. It is a nice control for making forms scale properly when the user changes their sizes.
Now there is a bug in Vsnet that surfaces when you put split containers in each other and do not change their default names. splitContainer1, splitContainer2 etc.
The remedy is easy: change the name as you create the split containers.
Update:
The bug reveals itself by stopping the designer from rendering the form; instead a text like “a control cannot be in itself” shows.
If that happens you are not totally screwed even though there is no clue to what to do.
Open the .designer file and remove a split control. I have no idea of how to find out which split control messed up. Just remove one. Open the graphical designer (possibly close and open). Repeat until you have a form like usual but the controls you have put on the split controls are gone. Don’t dispair, they are not gone – they are just not placed anywhere.
Drop a split control on the graphical designer. Add controls to it through myListbox.Controls.Add( myTextbox )…. If you do it properly – like adding the right controls to the correct new split control everything is like before. Except possibly event handlers om the split controls. At least you didn’t have to remake the whole form.
September 27th, 2007
A great amount of comments might be a sign of lack of logic in the code.
Well structured code is easy to read and hence needs less comments. What should be commented is non obvious things.
My practical workflow is often like this: I write several lines of code. I insert comments to explain, business wise, what is done, I realise I can refactor into method calls instead of comments and then my method names replace the comments.
Things to comment:
– many if statements have their origin in business rules. This is not obvious when writing/reading code deep down in the layers. Hence the need of comments.
– some coding becomes more elegant with delegates, nameless functions, pointers, inheritance or other tricks that are hard to understand for the not-so-experienced. These blocks of code or one-liners are easier to understand with some comment explaining.
– everything not visible on the screen might be unseen or forgotten. So if a piece of code has a requirement that is not visible in the close surroundings (visible or logical surroundings) a comment might help to keep the code on track.
– sidesteps from the normal path. As a sole developer or in a team one is supposed to follow a standard or normal-way-to-do-things. In those cases this standard is overruled a comment is good; the reason for sidestepping the standard.
I have true tale here:
I was working with damage control at a project and the air was sometimes a bit tense. Especially when the customer was around.
Now this customer asked us if the code was commented. This customer was a pain in the ass to work with and I didn’t feel like behaving so I answered that I thought the need for comments in code was a sigh of crappy coding. The customer didn’t share my point of view. My colleague didn’t either. He also tried to explain that comments are good. I held my fort.
Now to the fun part: My colleague didn’t write comments while I did.
And yes, I was called in because my colleagues code didn’t hold up.
September 25th, 2007
I found a blog entry at http://www.matshelander.com/wordpress/?p=74 which although lengthy and wordy hits the spot. There is no good notation system for software architecting.
My words: Comparing software architecting to building houses is ridiculous. Just because they share the same name (architecting) doesn’t mean they have a lot in common. Compare a sea horse and a horse and you get the same useless result.
The romans would never be good at mathematics since they lacked a good notation.
What software architecting needs is a good notation. UML is one way but it is not very good for evolving solutions and finding bugs. Code is the best notation I know of but it is too close to the very program and not good at describing architecture.
Besides, after several thousand years of building houses we still miss the estimated cost.