My Rants and Raves about technology, programming, everything else...
The PDC talk is heating up and it is clear to me that there is a huge number of 'wow' features that will be unveiled in LA. It seems like most of the other bloggers are talking about what I think is protected behind the multitude of NDA's I've signed. So to be safe I am keeping my mouth shut...tightly. What I can say is that what you'll see at the show about Whidbey, Yukon and Longhorn are phenomenal. Some of it is evolutionary, but much of it is revolutionary. I think you’ll be pleased... I am.
Since Don (Box) can’t seem to not talk about it, Indigo has gotten me really intrigued. I haven’t seen any of it, but I really want to know everything I can about it. That’s where I will spend my time at the PDC.
On a more mundane note, it looks INETA is going to be fielding its own band at the PDC. So far I know its Richard Hale Shaw, Carl Frankin and I. But I expect it to be a blast a number of people to come out of the woodwork to play.
This is a small announcement of a presentation at Purdue of the electrical engineer that invented Ctrl-Alt-Delete. I never gave it any thought. It should have occurred to me that some has all sorts of odd inventions on their resumes. I remember an article a year or so ago attributing the ':)' to someone on a BBS in the '70s. Go figure...
I finally finished downloading Office (System) 2003 from MSDN and found out that it did *not* include OneNote. It is like breaking a toy on Christmas morning. I admit I am one of the converted. I just love using it for a multi-tasking note taker. I don't just use it in meetings (which I have very few of any more), but all day. As I get an idea about something I am not working on immediately...it goes in OneNote. I just noticed that the MSDN website says the rest of the Office System will be available October 1st. Arg!
I finished my talks today at VSLive. I am very impressed with the conference. I have never been before. The conference facilities and hotel are exceptional. Much kudos goes to Fawcette for putting together such a great conference.
I love getting to speak to people using ADO.NET and see how they are using the tools. It seems that there is some difference of opinion between what other ADO.NET writers/speakers are teaching about DataSets. I would love to do a panel discussion sometime with some of the other writers to investigate the different opinions.
I was a big Active Directory fan a ways back. Not for the usual reasons, but for application specific data. After dealing with the fiasco that was the LDAP store in Site Server, it was nice to see a large-scale robust LDAP store. The problem was that the data store was tied to the domain model too tightly.
With that in mind, I was very happy to see that Microsoft noticed and has released Active Directory Application Mode (ADAM). I really like where it is going. While the tools for managing the ADAM stores are pretty deplorable, the data store is pretty solid.
For the LDAP uninitiated, LDAP stores (like ADAM) are made to store non-volatile hierachical data and are tuned for reading, not writing. LDAP is not a replacement for databases, but a different data tool in your toolbox. It has this very specific purpose. What is nice, is that LDAP is a very mature standard. LDAP v3 is a protocol that has been with us for a quite a long time and implemented across the industry (IBM, Sun, Oracle, Novell, etc.)
Everytime I add a app.config file to a new C# App, it never does what I want. I want the app.config file to be deployed to the build directory so I can make changes to the app.config file and have it propogated. With the release of VS.NET 2003, us C# developers now have pre and post build steps. So I now have to remember to add the following to the post-build event:
xcopy /s $(ProjectDir)app.config $(TargetPath).config
I know I could write an "Add New Item" to make it happen, but I just haven't had the time. I just wish MS had done it for me.
Chris Sells has alerted me to the fact that if your project has a app.config file, VS.NET 200X will copy it and rename it for you. My bad. I could have sworn that I tried this before and it didn't work : (
I have been spending a lot of time writing about technology lately. After a phone conversation with Tim Ewald, it got me thinking. During the first half of writing the book, I was working full-time writing ATL/C++ apps mostly and trying to get up to speed with ADO.NET at night. While my girlfriend minds, I don't really.
While in this phase of the project, I learned a lot about the technology and the class signatures, but it was very hard to grasp the big picture of the real problems that people will/are facing.
Soon after I got a full-time position developing a large scale .NET application. This really helped me appreciate the nature of the techology. I started to get really excited about how ADO.NET would help people solve these problems. Later on I started doing a tour of .NET User Groups to talk about ADO.NET and this was enlightening as well. People were asking me real-world questions that I did not always have great answers for. In the end, both of these experiences definitely helped me write a better book IMHO.
I have been thinking a lot about how Typed DataSets are generated and was spelunking through the code again when it got me thinking. The Typed DataSet generator doesn't really generate the code based on the .xsd, but on the DataSet. It simply loads the .xsd into a DataSet then interrogates the DataSet directly for everything (tables, columns, relationships, constraints). So if the Typed DataSet Designer cannot handle something (like relationships *without* constraints, see below), but the DataSet schema allows it...simply create the DataSet and save the .xsd file to see what it produces! This gets around some fundamental problems with the designer. It does require you start looking and understanding .xsd, but it is a useful skill to have anyway...right?
So my first relevation was how to add unconstrained relationships (no foreign key constraint, simply a way to navigate the data). Since the designer does not allow this, I looked at the .xsd and found that the DataSet handles this with a schema annotation:
<xs:schema> <xs:annotation> <xs:appinfo> <msdata:Relationship name="ta2t" msdata:parent="titleauthor" msdata:child="titles" msdata:parentkey="title_id" msdata:childkey="title_id" /> </xs:appinfo> </xs:annotation> </xs:schema>
The five pieces of data in the
msdata:Relationship element are the four pieces of data required when setting up a relationship. Pretty simple huh!
I hear from a lot of readers that they are creating 3-tier ASP.NET apps and I always wonder if they know where the middle tier is.
In my opinion, the web server is the middle tier and client tier is the browser. Creating another set of machines to host the data layer isn't really necessary and, in fact, hosting the data layer on the web server is easier to scale. We know how to scale out web servers. Inventing a new set of machines forces you to figure out how to scale them out and it does not increase your scalability by scaling out both the web server and a fourth tier.
If you disagree, please e-mail me and let me know what you think.