deap on .net
This blog belongs to Dan Petterson, a .net developer in Stockholm, Sweden.
Interesting internet findings (weekly)
-
Difference between "throw" and "throw ex" in .NET
Useful info on throw; vs throw ex;
Blogit (weekly)
-
The Anatomy of a Perfect Web Page - Hit Reach
Rejäl genomgång av en perfekt webbplats anatomi från Hit Reach (via @papperstiger)
tags: Webdesign webstrategy bestpractice guidelines markup video blogit
-
6Unheap3 - 23A tidy repository of jQuery plugins6e
ChatJs - Facebook style Instant messaging for your web app.
tags: jquery chat signalr programming blogit
Blogit (weekly)
-
Why Facebook is blue: The science of colors in marketing - The Buffer Blog
Why Facebook is blue: The science of colors in marketing http://t.co/H7NnoPdVKQ
Blogit (weekly)
-
log4net Tutorial - CodeProject
A nice tutorial on logging in .Net with log4net.
tags: programming log4net blogit
Blogit (weekly)
-
Interesting guide about writing testable code.
-
Nice manifesto for team of developers.
-
Some good points on legacy code and why we are so eager to throw it away but shouldn't.
- It’s harder to read code than to write it. This is why code reuse is so hard. This is why everybody on your team has a different function they like to use for splitting strings into arrays of strings.
- The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed.
- Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it's like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.
- These problems can be solved, one at a time, by carefully moving code, refactoring, changing interfaces.
- Even fairly major architectural changes can be done without throwing away the code.
- So half the functions started with "_" and half with "m_", which looked ugly. Frankly, this is the kind of thing you solve in five minutes with a macro in Emacs, not by starting from scratch.
- You're just going to make most of the old mistakes again, and introduce some new problems that weren't in the original version.
-
Compare better in TFS with WinMerge
At my new job I’ve moved from Subversion to TFS for source control managing. Today I reacted over the fact that the compare algorithm in the built in compare tool is really bad. I had pretty much only removed some unnecessary try/catch blocks and that made the whole block of code look replaced/edited in the TFS compare view.
I was pleased to google out that the wonderful WinMerge application can be used as a compare tool and decided instantly to do the necessary setting. Now I got a much better compare view where I could see what actually changed.
For best change comparison in WinMerge I prefer to make sure the following options are checked:
And if you’re using the merge features of WinMerge and are certain about what you do I would deactivate the creation of backup files by unchecking “Folder compare” and “File compare” on the “Backup files” page of the WinMerge options dialogue. That way you wont end up with a lot of ugly .bak files all over the place.
What Compare/Merge tool do you like?