PDC bits are on their way
I got this e-mail back from Microsoft Certified Partner support on Wednesday…..
Thank you for your email in regards to the MSDN PDC DVD Set. This product is not available as yet, however I have placed an order for you for when these do become available. Please allow 2 - 4 weeks before you receive this shipment.
What can I say? Yay! I can’t wait for them to arrive. My “old” Athlon 1800 XP with GeForce4 should be just the machine to load Longhorn on to.
Comments
Code Generation Talk
I gave a talk at the local users group on code generation in .NET. I talked about the benefits and things to be aware of when generating code, some of the things in the framework that help when generating code, examples of where code-gen is used in the framework, and then a look at some tools (both in the framework and 3rd party) for generating useful things. Unfortunately I spoke for 1 hr (I was only supposed to go for 45 minutes), and didn’t get to finish my last (and best) demo which I had written the night before. It was an “end to end” demonstration of how you could use code-generation techniques to generate a “search” style T-SQL stored procedure, data access tier, middle tier and winforms GUI, (with a couple of helper classes thrown in where it didn’t make sense to generate things). I think it would have been a cool demo, but I was only able to demonstrate the generation of a “search” style stored procedure. It was the first presentation I’ve ever given that had a substantial “code” component. Hopefully I can do better the next time.
Perparing the demo did give me a good chance to road-test my XML-metadata-based ASP.NET style templating code generator (tentatively called M3RLIN). By using XML as my metadata source I can do XPath expressions in my templates, which are really powerful. Debugging is much better than XSLT, and I can leverage parts of the .NET framework like string manipulation etc that are hard to do (for me at least) in XSLT. Maybe the EXSLT GotDotNet workspace, and the XSLT debugger in Whidbey will tip the balance back to XSLT. I still don’t have syntax hilighting working properly in my generator (I’ve been using VS.NET to edit the templates), but apart from that it is probably ready to go up on GotDotNet. I am tempted to forget about syntax hilighting anyway after hearing about the cool things (like intellisense in the code-in-front) in VS.NET Whidbey that would make template editing so much better than anything I could do.
In general I’m finding templates to be a very productive way of generating code - make a changes to templates and then seeing the output almost immediately is great, and being able to easily add sections of literal text is also very useful. Unless I REALLY needed to generate things in multiple .NET languages (where I would use the CodeDom) or generate XML as my output (where I would use XSLT) I think I will stick with templates……for now.
Comments
Thanks.
Jason
Xml Serialization
I was just reading an item over at Daniel Cazzulino’s blog on XmlSerialization. He gave a nice overview of how xml serialization works, and gave a great tip on how to supress the deletion of the temporary files that are created so you can look at the gory details yourself. As I mentioned in the comment I made on his blog, if you use one of the overloads for the XmlSerializer constructor other than the one that just accepts a type you create a new temporary assembly each time you create a new serializer. »
Exam 70-315
I passed exam 70-315 today with a score of 874. I only started studying for this one a week ago, so I was pleased to pass. I read Essential ASP.NET by Fritz Onion, and the MSDN. Darren pointed me to this list of resources. Bring on 70-316!
Essential ASP.NET is a good book. I wouldn’t put it quite in the class of a couple of other titles by fellow developmentor authors (Essential .NET, Essential XML QuickReference are two of my favourite books at the moment) but maybe I just need to re-read it to appreciate it. It is certainly concise and well written. It also focuses on the fundamentals, rather than how to use particular tools etc.
»XPath Expression Tester
My first user sample is up on GotDotNet. It’s a visual XPath expression tester, and already I’m not that happy with it. I stupidly left the .obj files from the build in. I didn’t mention in the summary that it is a Visual Studio 2003 project (altho I have compiled it to support framework 1.0 and 1.1, and I have tested it on 1.0), and after I uploaded it I ran FxCop over it and noticed that there were a couple of methods that were nolonger called, but that I hadn’t removed. Yikes! I’ve also thought of a couple of ways to make it a little easier to use also. I’ll upload another version that fixes these problems some time this week.
Comments
Maybe the next project could be a XML Schema tester. Load a schema, load an XML doc and check to see if all is good? Just an idea :-)
Practices are more important than Tech
The other day I was bemoaning my lack of Yukon/Widbey betas, raving about XML Schema and InfoPath, and complaining loudly that there were far too many cool new technologes I wanted to check out and not enough time to look at them to a friend of mine over a cup of coffee. He’s a smart guy (well, smarter than me for sure) and he slapped me down (metaphorically) with the following simple phrase. Practices are more important than tech. You know what, I think he’s right. I like to think I write reasonable code, but I KNOW there are some practices I could use that would make my code better (like more automated testing). So why don’t I use them? Laziness? Apathy? Maybe I have my eyes on too many of the wizzy new high-tech toys that I don’t give myself enough of a chance?
Practices hurt a bit at first. If you’re used to writing imbedded SQL code and decide that you don’t want to be a victim of SQL injection attacks then making the transition to calling parameterized stored procedures might be a little painful. At first you have to write all this wrapper code around your stored procedures, then remember to give your user(s) permission to execute them. There are some things which are easier to do if you’re building a SQL string on the fly, and you’ll have to cross those bridges too. After a while you become used to it. Maybe you even automate the wrapper writing process, and calling a stored procedure becomes just like calling any other method. While your coding took a backward step for a little while, you eventually made up the deficit, and your applications will be more secure, easier to maintain, and possibly better performing as a result.
In light of my friends comments I’ve revised my TODO list a little. New tech is fun, but I’ve added a few things that aren’t quite as sexy (well, maybe I have a warped sense of sexy), but are cool, and will definitely lead me to better development practices. Maybe I’ll add “Code Complete” or “The Pragmatic Programmer” to my stack of books to (re)read. Does anyone out there in blogland want to tell me about a development practice they took up and now wonder how they ever considered themselves a programmer without?
Comments
http://f2.grp.yahoofs.com/v1/gGA6P9pGLZsOUSHkAMN5kUy-i6kD4YYLs698Mj_urQVupTarIQk72C6gXoDMR9L1srbs5-xkqANQ9b9oil_vKfVeDO0/TDD17Jul2002.pdf
XML Schema, Schema Object Model
My interest in code generation has lead me away from viewing the database schema as the "one true representation" of the system to thinking that maybe XML Schemas are a better of creating a single point of truth for a system. While I've known about and used scheams for a little while (in typed datasets for example) I was not aware until recently of the Schema Object Model (SOM) in the . »
Code Generation in the MSDN Mag
The august issue of MSDN Magazine has an articleon XSLT-based code generation. This is similar to some of the techniques I've included in my own code generatorwhich I've been working on in my 'spare time', and plan to release as a .NET workspace. Both the MSDN Mag generator and my generator transform a SQL Server database schema into an XML document. There are a couple of ideas I might pick up on in the example in the MSDN. »