I have some short notes to make and it might not be blogworthy so having them on this page instead :) Will add to this from time to time. More...
Came across this Foundations of Programming Book by Karl Seguin (ebook actually) when I looked into CodeBetter.com
It contains articles that were previously posted on the site and I had the chance to scan/skim over it and wow, I'd have to say this is a must read for developers at any level (probably even the "guru"s need to have a look at it).
The book is 79 pages short. More...
Here's an interesting I came across in the recent Simple Talk Newsletter (by Red Gate Software).
It talks about issues with new SQL 2008 data types (date/time related) and it's effect on .NET 2.0 datetime data types when SP1 is installed or not. Something to be aware of and one of those times that you're glad you have a web rather than a desktop application. (you only have to install SP1 on the server(s))
SQL Server 2008 has introduced a few new data types, among others the
new date types, like date, time, datatime2 and datetimespan. Because
.Net 2 was released before SQL Server 2008 has introduced these data
types, there are no classes that map to these new types in .Net 2.
But this has changed with .Net 2 SP1, which introduces the DateTimeOffset structure.
Read full article from the following link :SQL Server 2008: new data types and .Net 2 with and without SP1
Just ran into this interesting article on MSDN Magazine about using LINQ to test stored procedures. It would be a bad idea to test stored procedures using other stored procedures too (eg. insert SP then verify presence of inserted value using select/load SP) so traditionally we do it using ADO.NET object (conn, commands) to build commands. But this LINQ approach seems very interesting. Easy of building commands, intellisense, compile time checking among others. That's another good use for LINQ which I'm really starting to like (hopefully even after trying it for n-tier projects)
The article also comes with a virtual lab for hands-on experience.
The need to test a program that accesses and manipulates a back-end SQL Server®
database is very common. In many such cases, the application interacts
with the back-end data through the use of SQL stored procedures.
In
this type of scenario, you can think of the stored procedures as
auxiliary methods of the system under test; and they must therefore be
tested just like any other module in the system.
Read full article here
I've been wanting to write about this for a long time and googling didn't return popular hits back then but just had time to write this but sharing nevertheless.
In a number of programming interview guides (most notably that of Joel Spolsky) it has been mentioned that one of the ways (note: only one and not the be all and end of it) to find out whether someone is "smart and gets the job done" is to ask them about recursion. And I agree in the sense that YES someone who has a good idea on recursion probably has good logic and flows and thus could be a good programmer but someone who might not know how to approach one might not be that brilliant but could still do the job (this one is of course my opinion).
Then it came to me that one doesn't necessarily have to know recursions or recursive functions if they do know how to approach the problem using stacks. Now why would I do that? The answer would be performance (very significant especially if the operation involves millions of level in the hierarchy and heavy operations for each node). The drawback is it is a little more code and possibly more complicated. But for most applications, the performance gain is very much worth it. More...