How come all digital calendars suck?

This can also be written: why haven't I written one of my own?

The digital calendars try to mimic their paper cousins the same way as Phillipinean food takes after ditto from USA. They have kept all the bad stuff and thrown away the good parts.

Number 1 bad thing with all the digital calendars I have run into is their obsession with hours. There is no way to enter "after job" or "in the afternoon" or "time will be decided later".
Number 2 bad thing with all the digital calendars I have run into is that there is no way to enter thing by week. I normally have vacation between week X and week Y (or dates X' and Y' if you prefer) and this is marked with a line in the margin. In my paper calendar that is. I cannot enter full day meetings because then my whole vacation is one big blob of "meeting" where I cannot find other stuff like sailing competition, midsommar or the dog's birtday.
Number 3 is the overview. For the ones living their life like Gantt the solution might be perfect. But for all us others...

Some 100 years ago I had an Apple Newton and for this one I bought a calendar that did what everyone using the paper calendar metaphor should do; throw it in the recycling bin. The solution was to just list things in chronological order with a line for week changes and bold for new day (or something like that) In reality I know that the meeting at the divers' club is at thursday evening and hence things above it is earlier and below it later on. This way of presenting my calendar turned out to be just the thing.

Last: if someone knows of a calendar program - please tell me.

Folding everywhere in the editor

I think I want an editor that can fold every branch in the source code; every if, every switch...

Then I think I want some sort of colour or font coded differentiation of regular code and error handling. This way it should be easy to see the difference between business logic and plumbing.
How to do this without taking up valueable source code lines I do not know.

Everything is a bug

This message will be repeated in english.

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.

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. Correction: everything is an issue.
Disregarding the issue creates a crash, is the wrong image size or installation and configuration and testing of a UPS it is somethign that shall be given a human and time.

My opinion is that everything should be in the same pile. With everything I mean everything. Then the issures are prioritized and picked off of the top. I you, dear reader, now recognizes 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 that it is a good method.

Further must every issue have a unique ID separated from the title of the issue. 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 issues 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-an-issue thing since there are several issue types and once you have chosen one there is no going back. To their defense 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.

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

Wanted: Tool to move your code elsewhere

I wish for a tool built into vsnet that easily moves your code elsewhere.

Like this:
You write a constant declaration right in you code, where you are, to quick and easy code andor debug. This constant should be elswhere, like in the class top or a common file. So just mark the constant and tell the IDE to move it to [choose here].
That would allow you to keep on coding without having to wind back and forth in the source. Doing this quickly would help you to avoid accidentaly forgetting to move the constant out of the method.