This series can be broken in 2 parts. The first 3 books form the main story arc while the last book seems an afterthought and the "action" happens a while after the events in the first 3 books.
The firat 2 books are pretty good. It's somehow refreshing to read a fantasy book in which the main character is not the usual guy but a middle aged woman. The book pacing is good with the action flowing nicely. I was pleasantly surprised by the series when i finished the second book. But the disaster stroke....i don't know what happened because the third book (which ends the main story arc) just plain sucks. Topped by a crappy unsatisfactory ending.
You could get away without reading the last book (and you won't miss much) but if you decide to read it.....simply put it it's just meh.

Much to my surprise, once i started digging, it seems that the difference between the C# and VB.NET implementation of query expressions are quite big. Case in point : C# doesn't support the "distinct" clause and VB.NET does.
Also the compiler is quite "strict" when you're using expressions :
var g = from w in words where w.Length > 5 .Distinct() select w; This seems a valid query (especially when you "map" logically query expressions to SQL) except it won't compile. It will crap out with a totally uninformative and wrong error message. On the other hand, this will compile and run just fine :
var g = from w in words .Distinct() where w.Length > 5 select w; The point i'm trying to make is that it seems to be "easier" to write code using query operators directly instead of query expressions. The code will be longer but when you read it you won't have to switch back and forth mentally from different query expression implementations :
var g = words.Distinct().Where((string w) => w.Length > 5);

When you talk about data constraints there's always a debate about where to put them : database versus application.
I noticed that some programmers go with the application (especially the O/RM guys) while the more "database savy" insist on placing them on database. While i'd go with the application approach there are some ups and downs that must be considered before taking a decision :
- the upside of putting them at the app layer is that they are easier to change/extend and they're database independent.
- the downside is that sometimes data integrity can be compromised. For instance if somebody decides to implement a check constraint at the application level in a very high traffic application there is the possibility for the following sequence to happen : checks for value X in a certain column from 2 application instances which succedes. Now if both users enter the same value the data integrity is compromised.
But, keeping the same check constraint example, also note that this unoque constraints can't be implemented at the database level either (you can't put a unique constraint on nvarchar(4000) field in Sql Server 2005 for instance because the index size would be too big).
So make sure you're aware of the limitations of each side before you implement the solution.

I've been digging in WCF for a while now and i like what i've found. The biggest thing is by far the shifting (both mentality and implementation) from remote objects (a la .NET Remoting) to messages (WS).
On the downside lots of WCF goodies are available only when using a few bindings (TCP and WS Duplex mostly). If you "craft" a solution who's implementation is based on these goodies then you're stuck with these bindings. And of course you're missing one of the best features of WCF (binding switching...and implicit transport optimizations, by modifying the config file).
If i'd have to go with a intranet distributed app then i think i'd go with WCF now. But for the internet i still think the .NET WS stack is a better solution ( why ?.....because the WS stack is a lot simpler than WCF).

It seems that there are 2 simple requirements to get a .NET 2.0 client to call a 3.5 WCF service.
- install WSE 3.0 (and make sure is enabled in the client project when you reference the service)
- the WCF binding must be set to basicHttpBinding for this to work.
Hope it will help someone.