If you haven't read Part 1 yet, you can read it here.
After spending time creating my own caches of reflection data I found the NHibernate type information to be more complete and faster. Go figure. At this point I am using the SessionFactory's GetClassMetadata and GetCollectionMetadata to return IClassMetadata and ICollectionMetadata interfaces. So far this has given me every piece of runtime information I need and means that I don't need to do any nasty (and potentially fragile) walking through the property interface of the context object. Whew...
So to refactor my GetResource and CreateResource calls. GetResource is easy. GetResource passes in the query and the full type name (though the full type name may be missing in some cases). The query it passes it must resolve to a single result. That means I can simply execute the the query and if it returns more or less than one result, return an error. Once I have the result I can just check it against the full type name (if it was passed in) and return the value.
CreateResource is a bit more complicated. The IClassMetadata allows me to call their Instantiate method to create a new instance of the class but the new instance is not initialized with any data. Most notably, the missing detail is a key. In the case of many entities, this is fine (e.g. if zero ID is a valid "new" entity). But in others the key needs to be specified. (Customer in the Northwind database is an example of this.) The problem is that we have to keep a reference to the new objects so that when ADO.NET Data Services asks us to set properties, get properties and save, we have to have the object in the Session. But we can't add it to the Session with an invalid key. What to do? My solution for now is a local cache of objects that are not ready to be saved (only really happens with newly created objects). When we are ready to save, we'll just add it to the Session then (when its either valid or we'll throw an exception because its invalid).
Now a quick mention of GetProperty and SetProperty. These are both pretty easy as the IClassMetadata includes a similar method to set and get properties. The only wrinkle is that if you try and set a key using the GetProperty/SetProperty, the keys are not in the list of properties. Because of this I just checked to see if the property is part of the key and set the key instead, if its not part of the key we can just set or get the property. Now that we have the basic part of the interface complete its down to the hard parts. But that's for the next part!
If you deployed a Silverlight 1.0 application and are having trouble with it working well in Firefox 3.0, Tim Heuer has a fix for you. The fix is to replace the Silverlight.js from the Silverlight 2 SDK with the old 1.0 one. Its a little more elaborate than just that, and go to Tim's blog entry to read about how it works.
Ted Neward's blog is one of those blogs that *everyone* should read. I am always surprised when I hear of .NET guys who don't know him. I think because he's been firmly in all camps at the same time, he often gets dismissed for "being a Java guy". Too bad for you that don't know better. Subscribe today, read the backlog, learn and grow as a developer.
His post today espouses an opinion that I first saw in the Pragmatic Programmer, learn a new language every year. Read Ted's blog to understand why if you haven't heard this before as he explains it better than I can. I've been playing catch-up and trying out a lot of languages lately. Mostly F#, IronRuby, IronPython and Boo. I hear people talk about these languages as the new 'fix' for development and I can't really profess that I believe that but it does open up your expectations about how code is written. Ideas like immutability, duck typing, loose coupling and closures are all good ideas that are hard to see if you spend your day in a staticly typed language. Sure, coming from VBScript and JavaScript in ASP number of years ago, the idea of typeless/late bound make me crazy. But there are really good ideas here. Go experiment and play with a language, it opens up your mind to getting the job done. The only thing I really can't stand is white-space significance in Python...that's just plain wrong ;)
Now that the change to Wildermuth.com is complete I've gotten questions about broken links and such. I am keeping adoguy.com around and redirecting (permanent) the links so that old links aren't going to break. I don't plan on keeping it forever but for several years you can be sure. Its worth keeping them around.
I didn't just do a quick and dirty port to a new CSS look and feel though. This was a conversion of the old code. I don't use a blog engine but write my own code, mostly as a test bed for new ideas. What was it this time? Two thinks significant changed: Entity Framework/LINQ as the data access and the ASP.NET Routing Framework instead of .aspx links. Let's take these one at a time:
The use of the Entity Framework and LINQ was pretty straightforward. I used LLBLGen Pro in my old site to do the data access and it held up great. I only switched so I could test out the Entity Framework on a production-ish system. Not because of any limitations in the old code. Creating a model with the Entity Framework was a snap. My data is not complicated so I didn't have any complex scenarios. The only think I did do was change the collection names from singular to plural. Being able to use LINQ to do my queries, search and paging was just spectacularly useful. I am completely in the LINQ camp now.
The second testbed was the new ASP.NET Routing Framework . What is the ASP.NET Routing Framework you say? Many of you have heard of ASP.NET MVC. The ASP.NET Routing Framework is the code that does all the custom routing for MVC. The ASP.NET Routing Framework is going to be released with .NET 3.5 SP1, not part of MVC so its not expected to change nearly as much as I expect MVC to mature. In that light, I couldn't port my site to MVC wholly because of the limitations in ViewState and ControlState. I could have worked around these limitations but I wanted to be able to focus on the new pieces and not have to re-write every page of the application (or use client-side libraries). So I found the middle ground of the ASP.NET Routing Framework. I am using Phil Haack'd great WebFormRouting class to do much of the heavy work of not only routing to the pages but sending the same sort of context that I could have used with MVC. Its much better than digging into the Response variables IMHO. You will note that most of the pages are now tail-less (e.g. http://adoguy.com/rants.aspx is now http://wildermuth.com/rants) though the old tail'd versions still work for backwards compatibility. I was able to simple tail-less versions by using his class (note the 2nd one uses an optional URI part):
routes.Map("Search").To("~/Search.aspx");
routes.Map("Rants/{page}").To("~/Rants.aspx");
I also set up my Rant URI's like so:
routes.Map("{year}/{month}/{day}/{topic}.aspx").To("~/ViewRant.aspx");
routes.Map("{year}/{month}/{day}/{topic}").To("~/ViewRant.aspx");
There was a challenge I had that I wanted the tail-less URI's but I am hosted on Windows 2003 (which means IIS6). I bit the perf bullet though and mapped all requests through ASP.NET. This means that all requests are running through ASP.NET which can be slower but I thought it was worth the better URI model. IIS7 can do the tail-less URI's without having to resort to everything being a ASP.NET request. Here's a good article on setting up IIS6: http://biasecurities.com/blog/2008/how-to-enable-pretty-urls-with-asp-net-mvc-and-iis6/. You can also accomplish it with URL re-writing but if I wanted to do URL re-writing why'd I use the routing framework instead of re-writing them all?
Its been a fun exercise as well as a re-branding effort. I hope everyone likes the new site!
After a heavy month of re-creating the website (using ASP.NET's new routing framework, not a full ASP.NET MVC), I am finally ready to launch my new blog site. The old ADO Guy website is now Wildermuth.com!
As most of you know, I have been dipping into a lot of different waters and the moniker of ADO Guy has no longer been descriptive enough. Sure I won't every abandon my database-centric view of the world. Please update your links. I've attempted to keep as many of the old URL's working but I am apt to have missed some. Please let me know when you find them. All of the old content should now be available on the new site.
The old ADOGuy.com address will stay around a while, but please update your feeds to point to:
http://feeds.feedburner.com/ShawnWildermuth
Enjoy and feedback is welcomed!
UPDATE: Bad Feed Address. Please use http://feeds.feedburner.com/ShawnWildermuth
In this TechCrunch article, they report that Adobe has released a stripped down version of the engine that can parse the swf files and give back info that is useful for the indexing engines. Its unknown whether Google or Yahoo (the report doesn't mention Live.com as one of the search engines it gave the technology to) will use it, but I expect they will.
So the question comes up, what about Silverlight apps? Will SEO for Silverlight become a big bargaining chip? I hope Microsoft responds though with the .xap and XAML files, Silverlight is already pretty easy to consume. My one request would be that Silverlight 2 stop embedding the .xaml into the assemblies so that the search engines don't have to double dig to get to the XAML.
I have been diving pretty deep into ADO.NET Data Services (see an upcoming article about ADO.NET Data Services and Silverlight 2 coming soon). I've been looking at the story around non-Entity Framework models through a Data Service and thought that NHibernate through a Data Service would be a great example.
So I tried to get it to work with the NHibernate LINQ project. The example model that the project uses is a simple Northwind model. I thought I'd just take that model and expose it via ADO.NET Data Services. I crufted up a simple Data Context object for ADO.NET Data Model but it didn't work. ADO.NET Data Services was complaining about the fact that the end-points (e.g. IQueryable<Customer>) was pointing at an Entity. This was a bug...a but in ADO.NET Data Services. I hacked together a fix to get around it (and reporting it). If you're interest, the problem is that if the key of the entity is in a base class and *not* named "ID", it fails to find it. Again, this is a bug not a feature of ADO.NET Data Services.
Now that it was working, now what? I wanted to be able to make changes to the model but the NHibernate context doesn't support the updating interface: IUpdatable. (Though I sure wish they'd rename it IUpdateProvider to match the IExpandProvider interface). If you're not familiar with this requirement, note that only the Entity Framework currently support the IUpdatable interface (and is in fact implemented inside of ADO.NET Data Services not directly in Entity Framework). This means that DataSets and LINQ to SQL do not support it either.
That's where I went to the Rhino Google Group (the discussion point for this project) and offered to implement the IUpdatable for the NHibernate provider. I thought it would be a fun exercise to understand the guts of the ADO.NET Data Service stack.
My first chore was to attempt to find a solution to decouple System.Data.Services.dll from the rest of the LINQ provider. My reasoning for this is that ADO.NET Data Services requires .NET 3.5 SP1 and I didn't want to tie the changes to that version of the Framework. Interestingly this is the same tactic that the ADO.NET Data Services team took. This is why the Entity Framework does not implement the IUpdatable interface themselves, but the ADO.NET Data Service does it for them. For the rest of the world, it expects a IUpdatable implementation directly on the context object that is used as the starting point for the service. After running around a number of ideas and running it by the Rhino people, we've decided to table that problem and get the interface working. That will be a fight we fight later with a number of proposed solutions.
So now that architecture is out of the way, its time to start actually implementing the interface. For the first pass, I am going to implement IUpdatable directly on NHibernateContext and refactor it later for less tight coupling. While I am at it, I also want to add support for IExpandProvider so that we can do expansions through NHibernate.
After adding the interface to the context object, I looked through the interface (its about a dozen calls that need to be implemented) to determine where to start. I am starting with the simple calls (GetResource, CreateResource, DeleteResource). These calls are used by the service to do basic object manipulation.
For GetResource, I am handed a query and possibly a type name. GetResource is supposed to invoke the query to get the one and only one result (implementors should throw an error if the result returns more than one result) and then check the type name against the result. In some cases you won't get the type name, but in most cases you will need to verify that the type of the result is the same as the type name. This is used to make sure that derived types are correctly retrieved from the data provider.
In implementing CreateResource, I noticed that I needed to be able to look up type information. Type information is important as I need information about the containers (e.g. IQueryable endpoints) on the context object. This information is not readily available as its the classes that derive from NHibernate that add these end-points. I could get the type information via NHibernate's type information or using Reflection (neither are particularly cheap). For the first iteration I choose Reflection since I know that better, but I wanted to mitigate the cost with some caching. To that end, I've created some small in-memory caches of the reflection information that hopefully will help with the performance of these lookups. This type information will help act like a factory to create new instances of the object. Unlike other ORM's, NHibernate doesn't use factories but uses simple object creation so we can just use the reflection information to create the instance of the new object and attach it to the NHibernate ISession.
Lastly, the simplest of the three methods to implement is the DeleteResource as it passes in a query (again, should always only return a single result) and mark it deleted in the session. The change shouldn't be persisted (there is a SaveChanges call on the IQueryable interface that facilities the actual persistence to the data store).
Overall a fun couple of days. Now on to the rest of the interface. I'll keep you posted with my experience dealing with them!
Pete Brown called me out to answer the next round of "what about you" questionnaires floating around the blog-o-sphere. So here's my take:
How old were you when you first started programming?
I got a Vic-20 when I was ten and started pretty quickly into Commodore Basic. I voraciously read Compute magazine and can remember reading the programs in the back and hoping those data sections were typed right.
How did you get started in programming?
I would visit other geek friends and discuss Basic with them pretty freely through high-school. I remember programming a lot of 6510 machine language stuff (Poke and Peek in Commodore basic, one byte at a time). I tried it on the Apple ]['s at school too. It wasn't until I was sixteen that I got serious about how it really worked when I got a summer job learning and programming.
That first summer I was introduced to a CP/M variant called TurboDOS (a multi-user CP/M believe it or not) that ran on Wyse green screen terminals. I had to learn what a database was ("Why wouldn't you just have the data in a data block or something? Oh, its going to change over time...I get it...") Once the school year started, I became disinterested in school and did the job Co-op (working 1/2 days for credit and going to school 1/2 days). Soon after I just quit high school to program full-time. By the end of that year, I had written my first business package, a time billing system for a real estate appraiser.
What was your first language?
Commodore Basic was the first, but assembly for the Vic-20 and C64 were soon behind. Once I was being paid to do it, I cut my teeth on non-mainstream languages like FMS-80 (sorta like Pascal), dBase II, III, III+, 4 and on to Clipper eventually.
What was the first real program you wrote?
I don't remember the first program I wrote of any consequence. The first one I can remember was the time billing system for the Real Estate appraiser. It was all green screen magic. Sometimes I miss the simplicity of UI design for green screen terminals..
What languages have you used since you started programming?
From what I can remember: Commodore Basic, 6510 Machine Language, QBasic, TurboPascal, FMS-80, dbase II (et al.), FoxPro, Clipper, Visual Objects, Delphi, Paradox, Visual Basic, C, C++, JavaScript and even VBScript.
I use C#, VB.NET and even C++ once in a while. I have been digging into IronRuby, IronPython, F# and Boo lately.
What was your first professional programming gig?
My first job wasn't that professional as I was paid minimum wage to mostly learn so I won't count that. Soon after I got a job creating a dBase II system to store a filing system for Chevron's environmental compliance area. This job involved creating a database that stored the data on every file in their file room, all reports for that system and a backup system for the data.
If you knew then what you know now, would you have started programming?
Yes I would. Having started so young, I fought it somewhat but in my mid-twenties I finally figured out that this is what I love to do.
If there is one thing you learned along the way that you would tell new developers, what would it be?
Many people think of programming as a solitary job for loners. I am often asked if I find the solitude nice in the work. The reality is that this job is all about people, not lines of code. Learning how to communicate with your team members, your customers, your advocates is key to success. I would rather hire a good communicator than a good coder. You can teach code, you can't teach how to communicate your ideas.
In addition, I would encourage people to read code. Reading code is a lost art. Intellisense and debuggers has made most younger developers dependent on watching the code in action. I feel lucky that I didn't have a debugger for a long time. It taught me to read the code to understand it. If you read code, you're liable to write code that is easier to read. Find code that impresses you and emulate it (e.g. good strucutre, documentation, etc.).
What’s the most fun you’ve ever had … programming?
I know I am going to leave someone out when I say this but without a doubt it was working at DevelopMentor as a developer. Chris Sells assemblies an incredible team that was spread out around the world with a vision to build a product called Gen<X>. Before I went there, I was always "the guy". In most offices I was the hotshot developer. Going to work with Chris meant that I was never the smartest guy in the room. While this was hard on my ego, it certainly helped me understand how to listen to other ideas and stand up for my own. Even though it was not a commercial success, it was certainly critical to who I am today as a developer, writer and thinker.
So who's next?
I would nominate:
Now that Silverlight 2 is getting closer to a reality (and a Go-Live license) the 3rd party controls are starting to sneak out. None of these are in 'release' quality but I thought it might help to get my opinion on the current state of these controls. Some of the vendors are releasing previews of their entire Silverlight 2 suites while others are releasing teaser controls (and some are even free!).
Caveat: I don't think its fair to 'review' these suites, I have included some comments about what I like and don't like about the controls. Please don't take any of these comments as a 'review'.
In testing these, I simple was creating them ad-hoc with XAML. I did not test them with Blend at all. Here are the controls I've looked at so far (in no particular order):
ComponentOne Studio for Silverlight (M2 Preview Release):
This control suite looks like the most complete of the bunch. While I don't prefer the speed of the Tree control or the look/feel of the DataGrid, overall its a great set of tools. I particular like the input controls (e.g. MaskedEdit) and the Image Rotator. It comes with lots of examples and seems to abide by design standards pretty well. My biggest complaint is the sheer size of the library. The shared part of the library is over 500K and on top of that you layer one of a number of assembllies that contain the controls. This means that a typical app is bloated by about 200-400K (after xap compression).
DevExpress's AgDataGrid (Beta 1):
Another data grid that's been thrown into the mix, DevExpress's grid seems to perform pretty well though it is buggy with some of its implementation of ObservableColleciton...but it is Beta, right? Out of the box the Microsoft grid seems to do more than this grid but with a quick look under the covers its obvious that this is a powerful control. My only peeve is that they seem to be modeling this off their WinForms grid in its naming of common properties (e.g. DataSource instead of ItemsSource). But that's not a big complaint.
Telerik's RadControls for Silverlight 2:
I am less than blown away with these controls. This suite doesn't quite seem to know what it wants to be with a mix of different types of controls thrown together (rotating cube, video player, tree control, and uploader et al.) it seems like mix of single use controls instead of a suite for a specific market (i.e. ComponentOne seems directly aimed at Line of Business apps). For the most part the controls work as advertised but they don't behave well for measurement and arrangement (which means they are wonky in a Grid). This is the only suite that doesn't mark itself as a non-released version (there was no indication of Beta, CTP, Alpha, etc.) so I suspect its a very early cobbling of some of their controls to give us a preview of what they're capable of. In addition, there is no segmentation of their controls so you're required to use the entire 900K+ assembly even if you only need one of their controls.
Infragistics NetAdvantage for Silverlight CTP:
I used the UltraGauge and UltraChart to create a simple example using live data and was pleasantly surprised. The UltraChart was powerful and worked much like expected. The range of customization seemed deep and performance was good. The docs are a little lacking but at this point in their development they are what I would expect. The UltraGauge I was less happy with as it took a substantial amount of XAML to achieve even a simple radial gauge and setting values is not simple. This complexity is probably a benefit for customers looking for a very flexible Gauge, but for simple work it is a lot of work to get simple stuff to work.
Visifire Silverlight Charts:
The licensing (open source/free) is great. For straightforward charting, its a great solution. Two things that make me less than thrilled with it though: height/width must be specified (breaking design standards and annoying users); and will not dynamically display chart information. Adding data to the chart's series' simple does nothing. No redisplay no matter what I tried. The examples the site uses to show dynamic data involve updating external data and restarting the Silverlight application. Too bad too...
Netika Tech's GOA for Silverlight:
I decided not to review the GOA for Silverlight project as its really an implementation of Windows Forms for Silverlight and isn't really a control suite but a porting package.
Tim Heuer again to the rescue. I had started a Dynamic .xap file demo to figure out how all that dynamic .xap stuff worked when he released a new video detailing it exceptionally. Run over to Method ~ of ~ failed and see the other videos he has for you...
