July 6th, 2007
[This message will be repeated in english.]
Jag laddade precis uppdatering för Acrobat till 8.1.
Det är 30 meg. För en läsare! En uppdatering!
Jag tvivlar på att Microsofts Word reader är så stor. Jag tvivlar på att ens Word självt är så stort när clipart och diverse bös är borta. Jag har typ 15 typsnitt installerade i Acrobat så det är inte det som tar plats heller.
Jag kollade i Program Files-katalogen och hittade nästan 100 megabyte! *kollar igen* Jäpp, jag såg rätt. För en läsare…
Undrar hur mycket de har lagt i system-katalogen?
Då har jag inte ens nämnt starttider. Word, en mycket mer komplex applikation, startar på en bråkdel av tiden det tar för Acrobat att starta.
Uppdatering:
Jag avinstallerade Acrobat och påinstallerade den igen. Knappt 23 meg, d.v.s lite mindre än en uppdatering. Nu är installationen på nästan 170 meg! 90 av dem verkar vara en installationsfil – jag testar att ta bort den. Önska mig lycka till.
Förutom att Acrobat tar lång tid att starta så tar det ibland ännu längre tid att avsluta. Ibland avslutar den nämligen inte alls utan ligger kvar i ett snabbstartsläge. Det är ok. Men varför 20 meg primärminne för att snabbstarta en läsare?
—-
I just downloaded update 8.1 for Adobe Acrobat.
It is 30MB. For a reader! Update!
I doubt MSWord’s reader is that big. I doubt even MSWord itself is that big when the clip art is removed. I have like 15 fonts installed in Acrobat so that is not the issue.
Checking the program files and I se almost 100 megabytes! *rechecking* Yes I saw right. For a reader…
Then comes starting time.
MSWord, a way more complex solution, starts in a fraction of the time Acrobat starts.
Update:
I uninstalled and reinstalled Acrobat. Almost 23 megs. Slightly smaller than the update. Now I have an installation on almost 170 megabytes. 90 of them seems to be a copy of the installation so I delete it. Wish me good luck.
Besides starting slowly Acrobats sometimes takes forever to quit. I mean it – sometimes it goes into some sort of fast start mode and occupies 20meg of RAM for this.
[ this article is as uninteresting as Mark Russinovich’s are interesting ]
July 6th, 2007
You have set a panel to autohide in VSNet but suddenly it decides to not.
So irritating.
The solution without having to grab the mouse (I am normally writing code with both hands) is to select the panel through ctrl-tab and arrows. Then press Esc and the ctrl-tab again.
July 1st, 2007
In VSNet2005 there is a handy option to show a start page with earlier projects/solutions, developer news from MS and some other stuff.
Then when one chooses a project/solution this page does not close.
Of course it should close – I am probably not interested in news _after_ I opened the project. If I was, I would have opened the news item to start with.
June 30th, 2007
Could someone please create a keyboard shortcut to grab the handle to resize the query/result window in SQLServer Management Studio? There used to be one (ctrl-B) but it disappeared with the 2005 version. Now one have to use the mouse to se more of the query or result.
The MS people writing the tools for SQL Server have always had a wierd view of what is user friendly. Even though SQLServer is a typical server installation one is forced to use a mouse to navigate.
An article about roughly the same: http://hci-matters.com/blog/?p=8
June 18th, 2007
Continuing with the above/earlier I say that even the table to create a many-to-many relationship should have a simple primary key.
E.g.:
Table User_Role
– field UserRoleID PK
– field UserID FK
– field RoleID FK
As long as harddisk space is cheap and a simple PK does not create a performance impact there should be no reason to not have a simple primary key.
June 17th, 2007
The discussion whether to design software bottom up och top down died with intellisense/typeahead/whateveryoucallit; it was so much easier building bottom up. Then refactoring tools entered and suddenly made it easy to program top down again.
Personally I believe the two methods should be mixed. Not like “these methods or modules we design top down and these bottom up” but more like “these methods we design no matter the way”.
Like this:
Here is a method I’d like to have. Here is the call. There is the method signature automagically created. Then some implementing code. And further calls to yet non-existing methods. Which are automagically created. Until we get all the way to the bottom. Where we adjust a couple of parameters. And refactor this up again. And adjust. And refactor. Until we are back where we started with code that is readable both if you track it from the top or the bottom.
Or the other way around if you prefer.
As long as the code gets readable. And updatable.
June 17th, 2007
Anything simple.
Anything simple but not something the user knows about.
A 32 bit integer, a GUID, a string. But not the CustomerNumber or PostalCode or EmailAddress. No matter what the user/customer/client says – those things are not unique. I have been harrassing customers whether the CustomerNumber is unique or not. It has been unique for two weeks until someone remembered about foreign offices with their own numbering system or that they sometimes are changed.
Alas – do not use anything you find in the business logic as primary key.
A more technical comment on why we use int is found here.
June 17th, 2007
I have a rule (not a rule really, simpler than that) that if I can’t explain a thing or defend a standpoint in a minute or two I am probably not correct.
I am necessarily not wrong but I am not correct either.
Some issues take more than 2 minutes to clearify but then the problem lies elsewhere, in a bigger scope.
June 5th, 2007
Not totally correct;
Since comments don’t compile.
But…
too often when I look through code I step on comments that say one thing and code that says another.
This has even made me waste time hunting bugs along the wrong track.
June 5th, 2007
>If you (the reader) is familiar with TQM the following three rows should be familiar:
Don’t inspect quality in.
Constantly improve the system.
Break down barriers between departments.
If you are not familiar with TQM it is perhaps the reason Japan’s industry creates things faster, cheaper and better than the west. Deming is a name to remember for this.
Now… what can we learn from this?
Don’t inspect quality in.
In a large enough project there are special testers that apply their magic when the code already is written. Wouldn’t it be nice to not write the bug in the first place?
Constantly improve the system.
When did you last look over you development method? Your debugging method? Your deployment method? There is even a book written about it called Debugging the Development Process.
Break down barriers between departments.
Does your project have “programmers”, “designers”, “architects”, “testers” and “project leaders”? Why does it? Because the need arouse or just because that is how it was done last time?
The inspiration for this article was found here.