Pro LINQ: Language Integrated Query in C# 2008, by Joseph Rattz (Apress, 2007), is an organizational mess that could have benefited greatly from more careful editing. The book can't decide if it's a "nutshell" style reference or a sequential tutorial. Rattz thoroughly covers LINQ to XML, objects, datasets, and SQL, but I felt like I'd read at least 50 pages of redundant material at the end of each section. Pro LINQ's crimes against the reader:

• Constantly reminds you of things you read just a page or two earlier or that you'll read about later (felt like he reminded me about the upcoming lessons in chapter 17 about 100 times--this is what the TOC is for!)
• Explains that you don't need to know subject X until chapter Y, but takes the time to talk about it anyway, even though he just does it again in greater detail later (again, that's why I have a TOC)
• Dedicates precious page space to repeating the same notes and warnings over and over again. In the Chapter 14, he prints the same note about method name differences between the beta and release version of the framework 6 times--some of them on opposite pages. WTF?

The blandness of the LINQ to SQL section finally chased me to internet resources like Scott Guthrie's blog, Channel9 videos, and <gasp!> MSDN tutorials, which I found far more effective than the book at preparing me to create a production LINQ to SQL app.

I'm reading through the new parts of C# 3.0 in a Nutshell by the Albaharis (O'Reilly, 2007) next. Joseph Albahari is the author of LINQPad, which is an extremely educational tool if you haven't played with LINQ yet. Hopefully that means the LINQ material in the book is good, as well.

I'm a huge LINQ fan, but the dark engine that is LINQ to SQL has been powered by my bitter tears far too often in the past month, and I need (and deserve) to complain a bit about the databinding WTFs. [As a side note, you can also power LINQ to SQL using alternative energy sources such as the charcoal produced by burning DBAs or harnessing the energy released by the spinning dynamo in E. F. Codd's grave, but the bitter tears of developers do seem far more renewable.]

So, I was already really disappointed that Table<T>.GetNewBindingList() returns an IBindingList that doesn't even implement Find(), but now I've experienced the ridiculous WTF that DataContext.Refresh() and ChangeConflicts.ResolveAll() bring to .NET databinding. Let's say you've bound a control in your UI to a property on an object using DataSourceUpdateMode.OnPropertyChanged. In this mode, your UI control depends on the bound object to fire the proper events when a bound property changes, or the UI will not accurately reflect the bound object's current state. If you're designing an object for use as a datasource for .NET databinding, you would either implement a <PropertyName>Changed event for every bindable property, or (preferred) implement INotifyPropertyChanged and fire the PropertyChanged event. The entity objects generated by LINQ to SQL all implement INotifyPropertChanged, and their implementation works great with the OnPropertyChanged databinding mode in all instances except when you call Refresh() or ChangeConflicts.ResolveAll() on the DataContext, which you need to do for important stuff like refreshing an entity's state from the database or to resolve the inevitable conflicts that result from concurrent database access.

When you use ResolveAll() or Refresh(), you must provide a member of the RefreshMode enum to determine how to treat the target entity. The options are:
KeepCurrentValues
Forces the Refresh method to swap the original value with the values retrieved from the database. No current value is modified.
KeepChanges
Forces the Refresh method to keep the current value that has been changed, but updates the other values with the database values
OverwriteCurrentValues
Forces the Refresh method to override all the current values with the values from the database.
I don't know about the rest of you, but to me, swap/keep/override implies that something is going to happen to the target entity--something that should invoke the PropertyChanged event when the expected behavior occurs. Instead, LINQ to SQL clones the target entity during these operations, applies the expected property modification behavior to the duplicate, then replaces the original entity in the model with the new one. In other words, you get great databinding support right up to the point where you need it most critically--when you're trying to ensure the integrity of your entities' individual member values during manual database refreshes or conflict resolution.

WHYYYYYYYYYYYYYYYYYYYY!? This is so dumb I don't even know where to start. OK, I guess I can start here: How did anyone think it was a better idea to orphan entities they KNOW are in use, rather than just modifying the original and then firing PropertyChanged events during these circumstances? Unless I'm completely misunderstanding, this only makes sense if the LINQ to SQL team wants to systematically break the spirit of anyone who tries to use databinding. I know I accused the Windows Installer team of being staffed by idiots in an earlier post, but there are so many brilliant things about LINQ to SQL that I just don't want it to be true about this team.  I'll be whining about this later today on the LINQ to SQL MSDN forum.

In a really good blog entry about MIX '08, Mono/Gnome founder Miguel de Icaza had some nice things to say about Jensen Harris's presentation at MIX '08 entitled The Story of the Ribbon, so I thought I'd give it a look. I liked the first few minutes of the 90 minute video so much that I showed it to Molly and we watched the whole thing together on the big screen. We both really enjoyed the story--and the design and planning processes Jensen draws out of the story--of how the Office UI came together at the various release dates in history. Definitely worth watching if you are into any aspect of design or UI--or planning of either.

Jensen Harris: An Office User Interface Blog : The Story of the Ribbon

VW unveiled a concept diesel hybrid in a Golf form-factor at the Geneva Motor Show this week. It might end up being pretty pricey, but they're claiming 70mpg. I've stated before that VW inflates their European car mileage by about 20%, at least on the UK site (even after you convert UK gallons to US gallons), which is a pretty big margin for error. In any event, some glib mother trucker responded with a comment about how the Honda CRX and Geo Metro had modern hybrids beat "decades ago". This stuck in my craw, because I've spent time in the CRX, the Metro, and the Prius, and there's just no comparison between these cars. I'm tired of hearing how great the nanocars of yesteryear were, so I did a little research and came up with some numbers for comparison. What follows is the full version of a comment (with links) I posted as "JD" to the Autopia article:

The 84-87 CRX HF (highest-MPG CRX model) specs:

• Two doors
• A backseat suitable for small children only (I rode as a child and it sucked)
• A 58hp engine
• Weighed 1300 lbs LESS than a Prius or Golf

And STILL only got 46mpg on the new EPA cycle.

90-94 Metro XFi (highest-MPG Metro model) specs:

• Two doors
• Same tiny backseats (they felt a LOT smaller as an adult)
• Detuned 49hp engine that sounds like hell on wheels after 30k miles
• Weighed 1400 lbs LESS than a Prius or Golf

And got the exact same 46mpg on the new EPA cycle. Not much progress for a decade having lapsed between the first CRX HF and the last Metro XFi, even with less HP and lighter curb weigh in the newer Metro.

The worst part is that nobody seems to remember both of these models had breathless engines, no air conditioning, no power steering, manual transmissions, and no safety features--not to mention the lack of cup holders, mirrors, tape decks, and defrosters. There were more feature-rich models of the Metro and CRX, but they didn't get the storied mileage that everyone remembers these models as having advertised. People's rose-tinted marketing goggles have completely obscured the fact that the full-trim models of the CRX and Metro had 40% more horsepower, 30% lower mileage, and outsold the more efficient models by orders of magnitude.

The truth is that there's no comparison between the size, interior room, increased power, and safety features of those vehicles and a four-door, ~3000lb Golf or Prius. The Prius (and more so Golf hybrid concept, if the numbers are true) IS revolutionary if you consider the size and engine displacement compared to CRX or Metro. Anyone who looks back fondly on those vehicles never spent any time riding in the back seat, or hasn’t spent any time in BOTH a Prius and a CRX/Metro to gauge the qualitative difference. Mileage is actually improving in hybrids, even while weight and fancy electronics are increasing.

Would I prefer that we were putting the latest tech into CRX- and Metro-sized cars to get 80+mpg? Hells yes, but I don’t get to design cars. Besides, the only vehicle that has remotely attempted this for the US market is the Insight, and they forgot to even fake the backseats. WEAK, considering the small high mileage euro diesels all have them.

Those are my crazed rantings. I also commented a lot of smack about the VW hybrid concept and Autopia's head-over-heals infatuation with it, but I'm full of crap most of the time, so get your salt ready if you're going to read it all ;)

VW Golf Diesel Hybrid | Autopia from Wired.com

The writers and actors have managed to increase the tension to the point of being almost unbearable this season. Seeing McNulty fall back into his drinking/whoring patterns, watching the never-ending line of jaded, burned out cops sign up for Freamon and McNulty's fake serial killer caper (and their ridiculous under-estimation of the public and police force's involvement in it at any point), and waiting for the inevitable final collision in the slo-mo train wreck that is Scott Templeton's career...it's just amazing how they've kept up the pace so solidly over the 9 episodes aired so far. I feel even more fear and empathy for the characters' situations than when Bunny Colvin had the Western wrapped up in Hamsterdam last season. Somehow after the amazing spectacle that was the 4th season, they found a way to raise the emotional stakes. This is great drama--I can hardly believe this is a considered a simple police procedural by most people. Watching episode 9 last night was almost painful; I was on the edge of my seat the entire time and had no idea what was going to happen next.

Anyhow, I'm not sure if it's 10 or 12 episodes this season, but if episodes 8 and 9 are any indication, I'll be enjoying every single second of whatever else is left. Kudos to all involved in this amazing show--you're pulling off a hell of an exit.

Express, Evaluation, and Developer versions of SQL Server 2005 disable all remote connections by default. Express is very desirable for small custom applications, but first you have to wrestle with the network configuration--particularly if you're in an environment where security is tight. This is by no means a definitive accounting of SQL Server 2005 firewall issues, but it's enough to get started, and is based on my real world experiences on a recent project.

Enabling Remote Connections

To enable remote connections over TCP/IP, open the SQL Server Surface Area and Configuration applet, and click the Surface Area Configuration for Services and Connection link. Under your default or named instance's Database Engine node, click Remote Connections and configure like so:

Once you click OK and restart SQL Server, you're network-ified.

Firewall Configuration

If you install your SQL Server 2005 installation as the "default" instance, it will listen on TCP 1433, and you don't need the assistance of the SQL Server Browser service. Firewall setup couldn't be easier--open TCP 1433, and the rest is an exercise in database security configuration.

If, however, you use the installer defaults and create a named instance, such as "SQLEXPRESS", a random port is assign as the TCP Dynamic Ports value. You can see what port your server decided to use in the SQL Server Configuration Manager:

The easiest way to enable remote clients to access our imaginary SQLEXPRESS named instance through a firewall is to create firewall exceptions for the SQL Server Browser executable and for the SQL Server Express instance executable. Once you do this, your applications can connect to servername\SQLEXPRESS without fiddling with ports at all. Just make sure the SQL Server Browser service is set to automatically start, and you shouldn't have any problems. Detailed instructions can be found here.

If you don't want the SQL Server Browser service running for some reason, you can disable it and just create a firewall exception for the TCP port number you found in the Configuration Manager tool. However, if you do this, you won't be able to access the named instance unless the connection string on all your apps includes the port number, formatted like "Data Source=servername\SQLEXPRESS,3510". Hope you really like that port number, because you just married it--at least for that named instance.

Look for a future article on SQL Server logins and user mappings from a n00b's perspective. Operational security is often difficult for even seasoned database designers and transact sql masters to explain or configure. Hopefully I won't make it any harder ;)