Life, Time and Nant

It’s already been two weeks since I posted anything. We’re in beta release of the software I’ve been working on for nearly a year now (on the 19th of May to be exact) for my company, Cubiks Ltd. (web site at www.cubiks.com). By linking to them, is my googlejuice gonna take over the first hit in google? Time will tell. Anyway, not much time between coding, changing my life throughout hopefully for the better, and rebuilding all the things I took for granted for the last three years. Getting yourself together is an on going job, and by not doing it earlier I pay the price now.

List of things in the pipeline:

·         www.coadserver.com yes I’m finally back at coding it, we’re preparing a lot of great stuff over there. Thanks to Mark, which I can really call a friend for always being with me, behind me and supporting me through all these years (yes mate, it’s already been years!)

·         www.cubiks.com with this top secret product I’ve been working on alone for a full year and that starts being usable and manageable.

·         My top secret project: Distributed garbage collection for .net, or how to enable garbage collection tracking of your objects in an automatic way across AppDomains (at first, I’ll go cross process later on). Lot of technology here, reflection, codeDOM, remoting, multithreading, etc. I’ll try to integrate it, once finished, with Roy’s Extensibility Application Block to leverage his work, and will try to produce an article from it. Side note, anyone wanting me to write about a specific subject for a publication, please let me know, I can now allocate enough time to do it and would love to get back to writing.

·         How to build, or rather How I build a NAnt based fully automated build system with SourceGear Vault, and how that helps the development team around me (well, should) will be something I’ll write as I’m head up in NAnt these days.

·         TechnoGeek would be my best nick, and as such, am spending a lot of time at the YMCA to try and get in shape. Already lost 7 kilos in 4 to 5 weeks, and the difference is really stunning (to me at least).

·         Say sorry to Julien Brunet for falling behind on helping him translating his articles. I spent a long time trying to cope with it all, and just couldn’t. I should’ve been more open about that. Sorry buddy, I promise I’ll pay you back on that one.

·         Installing and putting data on an internal Wiki (after the failure of trying to push people to blog internally). I love it, but it is so limitating that I may end up, if I ever get the time, rewriting one from scratch. Julien, interested into developing a distributed web services based SOA best of the cream architecture Wiki/blog/rss aggregation with an associated windows version, etc? :-)

·         Lookin for a new job. I’m staying at Cubiks for how long it will take to get our product out of the door, but we’ve reached a point where both parties can’t properly use each others resources, so I need to move on. I still feel a lot of deception that it didn’t work out for the best,  but sometimes requirements change, on both sides, and it just doesn’t work out anymore. Oh well… If you hear about a technical architect or a technologist position somewhere in London, drop me a mail ! :)

·         And finally, still working out ideas on a book I want to write. It’s still a very movable target but we’ll get to it.

Bit busy as you can see, but I’ll try to be more reactive and more involved in the coming weeks. It can only get better anyway! Right?

Ads

XSLT and the missing xml declaration

I was wondering why oh why after my xsl-t transformations the xml header was not outputted correctly… And guess what, hidden as a small side note, I see this:

Note   The <xsl:output> statement is ignored when the output of the XslTransform.Transform method is an XmlReader or XmlWriter.

Now this was well well hidden and explain a lot of things…

Ads

XPathDocument Stream closing

Today I encountered a really annoying documentation bug in the xml side of .net. Whenever you create an XPathDocument using the Stream based constructor, whenever the construction returns, your stream is closed.

                  documentStream = new MemoryStream();

                  XslFoEngine.CopyStream(message.BodyStream,documentStream);

                  documentStream.Position = 0;

                  XPathDocument document = new XPathDocument(documentStream); 

You wouldn’t expect the Stream to be closed, but it is. What is happening behind the scene is that the following constructors wrap whatever you throw at them with an XmlTextReader object, call the Init(XmlReader) method, which itself close the reader, in turn closing the stream.

Initializes a new instance of the XPathDocument class.

[Visual Basic] Public Sub New(Stream)

[C#]public XPathDocument(Stream);

[C++] public: XPathDocument(Stream*);

[JScript] public function XPathDocument(Stream);

Initializes a new instance of the XPathDocument class.

[Visual Basic] Public Sub New(String)

[C#]public XPathDocument(string);

[C++] public: XPathDocument(String*);

[JScript] public function XPathDocument(String);

Initializes a new instance of the XPathDocument class.

[Visual Basic] Public Sub New(TextReader)

[C#]public XPathDocument(TextReader);

[C++] public: XPathDocument(TextReader*);

[JScript] public function XPathDocument(TextReader);

Initializes a new instance of the XPathDocument class.

[Visual Basic] Public Sub New(XmlReader)

[C#]public XPathDocument(XmlReader);

[C++] public: XPathDocument(XmlReader*);

[JScript] public function XPathDocument(XmlReader);

Initializes a new instance of the XPathDocument class.

[Visual Basic] Public Sub New(String, XmlSpace)

[C#]public XPathDocument(string, XmlSpace);

Only way to go around the problem, create the reader yourself, but don’t close it.

                  documentStream = new MemoryStream();

                  XslFoEngine.CopyStream(message.BodyStream,documentStream);

                  documentStream.Position = 0;

                  XPathDocument document = new XPathDocument(new XmlTextReader(documentStream));

PS: I will respond to IanG comments on my ReaderWriterLock entry with some statistics later this week on when / how to use this pattern (high contention), as I fully agree with him that you shouldn’t just assume without testing. In this specific case, the contention is really high on a very high load long living threads environment. More on that later.

 

Ads