Just when I started working on my little toolbox I read this series on dependency injection for events which was great inspiration.
Read more here.
When I was working on the WithProgress extensions I learned something about Progress<T> that I didn't expect.
As you may know if you followed my blog before; I like to roll my own fake. For interfaces it is pretty straight forward with explicit implementation of the interface and properties with delegates for implementation.
If you liked my old series of articles covering TAP and especially the different extension methods I showed. Then you will be even happier now.
A couple of weeks ago I had just read Dan North's article about how he saw six things he thought he would never see because they were impossible. I had no idea I would myself see the seventh impossible thing just a few days later.
A few weeks ago the dynamic IP address restriction feature was announced for Azure Web services.
Several years ago I told a story about a project that proved that estimation was a waste of time once the work was split up in small enough chunks. Not necessarily equal size of chunks but manageable size chunks. But sometimes you need to do estimations because somebody wants to know the cost of some project or large feature.
1973 days ago I moved away from my private blog and started writing here. I have now decided that it is time to reclaim the control over the platform I'm using. That is why I will be posting here (blog.cellfish.se) from now on. I'll continue to cross post a summary here for some time for your convenience.
A long time ago I mentioned that triggers is rarely a good option in your database. I recently read this article (requires free registration) that shows you a solution to prevent developers from updating a full table (or deleting it all) by mistake because they failed to ad a WHERE clause to their query. Is this a good reason to add triggers to your database? I think not! There are so many things wrong here in my opinion...
First of all the script proposed the example have the same trigger duplicated three times (once for update, delete and update/delete triggers each) when that could have been avoided easily since the script is just building a string to run anyway. So from the start the script proposed could easily contain bugs depending on the type of trigger added.
Second this is only protecting against the most simple mistakes where you forget your where clause. What if a query has a where clause like "WHERE ID > 1" (assuming there is at least one record not satisfying that condition. You are probably still miserable.
I would still say that the use of stored procedures and proper security setup so that users can only execute stored procedures and not modify data is the solution. That way the stored procedure can be reviewed. Even checked automatically for things like always having a where clause. The stored procedure can also be tested with some unit tests. All that should be enough and better than adding triggers that gives you some false sense of protection. And remember your backups in the case you failed to catch something like this earlier. But that goes without saying whenever you work with a database I think.
Any kind of backups other than straight file copies have Always been magic to me. Mostly because in the early years of my career it was so rare that the backups actually worked when needed because nobody evern tried the backups to see if they were actually working... This post (free registration needed to read) goes over some SQL server myths that are backup related. Way to many screen shots for my taste but interesting.