Thursday, September 6, 2007

I Am "using System.Xml.Linq;"

As you know, I've come to believe that REST is the correct default way for me to program web services. (Whether it's the correct way for you to do so is an entirely separate question.) Part of my experimentation in this space has been to embrace the idea that "XHTML is the new XML". That is, that data should be encoded using standard XHTML tags rather than custom XML grammars wherever possible.

 

The idea has enormous potential due not least to the fact that it makes your browser a debugging environment for your web services. However, browsers aren't the real target: custom web service clients are. And in the .NET space, there hasn't been a great API for consuming XHTML as an object graph. Oh, you could use XPath, but that's a bit messy. XmlSerializer would be preferable, but unfortunately it's no good at deserializing based on things like the value of a class attribute of a tag.

 

Now, however, we have Linq. So given a document like this:

<html xmlns="xhtml namespace">
<body>
<ul class="alternates">
<li>3</li>
<li>4</li>
<li>5</li>

</ul>
</body>
</html>

we can do things like this:

 

XNamespace xhtmlns = "http://www.w3.org/1999/xhtml"; 

var alternates = from ul in document.Element(xhtmlns + "html").Element(xhtmlns + "body").Element(xhtmlns + "ul")
where ul.Attribute("class").Value == "alternates"
select from li in ul.Elements("li") select li.Value;
 

which is extremely damn cool. Of course, I can do something even more useful and initialize objects with the results of my query doing something like this instead:

var alternates = from ul
in document.Element(xhtmlns + "html").Element(xhtmlns + "body").Elements(xhtmlns + "ul")
where ul.Attribute("class").Value == "alternates"
select
from li
in ul.Elements("li")
select new Alternate { Value = li.Value } ;


where Alternate is a class I've defined with a public property called Value. I imagine you can get it to work with an anonymous type, too, but so far that hasn't worked for me. Anyway, it's wicked cool nonetheless.

Wednesday, September 5, 2007

And Then There Were…Three and a Third

Coming soon [1] to a crib [2] near us:

 


 

[1] Around the end of March.

[2] OK, probably right in the bed just like the last one.

Friday, August 3, 2007

How To (Start to) Learn Lisp in 21 Days

My quest to learn Lisp continues, but I've reached a major milestone: I'm ready to start writing code. For me, learning a new technology usually starts with reading about it for a while, trying to form a mental model of the landscape. It took a bit of searching, but with some help, I was able to find three resources that were just what I needed. I thought I'd post them here for anyone else interested in the language. All three of these are free and available online in their entirety.

 


  1. Common Lisp: A Gentle Introduction to Symbolic Computation. A really excellent beginner's book. Extremely approachable, good narrative style, describes the important bits and leaves out the advanced stuff. Highly recommended.

  2. Common Lisp the Language, 2nd Edition. The Lisp book. The style is rather dense, but once you've got the basics, that's just what you want.

  3. Common Lisp HyperSpec. As you might suspect, this is the spec. Always useful to know where the spec is.

 

I'd suggest reading the first, skimming the second with dives into areas that you think you might need, and browsing the third as appropriate.

 

As for me, I've got an interesting idea for a utility that I want to write. There's nothing like trying to solve a real problem to fill in the gaps academic exercises like reading a book leave. I'm sure you'll hear more about it here when I'm done.

Thursday, August 2, 2007

FlexWiki 2.0 Beta 2 Released

I just posted Beta 2 of FlexWiki 2.0 up on SourceForge. Major differences from Beta 1 include:

 


  • SQL Server once again supported as a store. 

  • Improved SPAM protection via optional CAPTCHA requirements. 

  • Added ability to require HTTPS on a namespace-by-namespace basis. 

  • Multiple bug fixes.

 

There's other good stuff in there, too - the release notes detail everything.

 

The major remaining issue is performance: 2.0 Beta 2 is significantly slower than the latest released version of FlexWiki 1.8, although still usable. Performance work is ongoing, and significant improvements are expected before 2.0 is released, but for now production deployment is not recommended. That said, we're running it at http://www.pluralsight.com/wiki because for us the new security features outweigh the slowness. And perf aside, I feel good about the stability of the code, and others have echoed that it seems pretty solid.

 

I'm very pleased by how quickly we've moved from Beta 1 to Beta 2, and even more happy about the fact that developer activity has picked up - Beta 2 sports input not just from me, but from Derek Lakin, John Davidson, and Keith Brown (apologies if I've forgotten anyone). I'd also like to thank all the users that gave us feedback on Beta 1 and the interim builds - we fixed a pretty good number of bugs thanks to their input.

 

Beta 2 is likely to be the last Beta before release. I'm currently working on the last major thing that I think needs to go into a full-up 2.0 release: reimplementing caching. My hope is that I can quickly implement a reasonable story there that will bring us back to FlexWiki 1.8 levels of performance. There will be a few cleanup things to do after that, but really, that's the bulk of the work. I won't be so stupid as to give a timeline for when I think that will happen - even if perf work were easy to estimate there's the fact that I've missed every estimate I've given for this project - but I will say that I'm pretty motivated to get this done. Devoting nearly three years of spare time to something will do that. :)

 

Anyway, download and enjoy, and watch for RC1 in the not-too-distant future!

Monday, July 30, 2007

Link to Rory

Apparently, Rory needs links. We lovable nutjobs (my insanity is better hidden…I think) have to stick together, so I'm obliging.

Thursday, July 5, 2007

Hello Lisp

I believe it's a good idea to learn at least one new programming language a year. If nothing else, it keeps me from getting bored. You might think I'd choose Ruby, as that's pretty hot right now (in certain circles). And in truth I'm interested. I've even read some of The Pickaxe Book. But the language I've decided to devote my time to is Common Lisp.

 

There are a number of reasons for this. I won't go into all of them, but here are a few:

 


  1. I've been meaning to really learn a Lisp for a long time. Probably since I took SICP as a freshman. (One of the more intimidating moments of my life: having Hal Abelson as a student in a class I taught. Really nice guy, fortunately.)

  2. I do a lot of work where I turn set-based data (from a database) into hierarchical data (XML). A language based on lists and conses seems worth investigating.

  3. Lisp has a pretty interesting reputation as "the most powerful and elegant programming language". That's quite a claim, and begs to be investigated.

  4. Every new feature that C# has sprouted has been available in Lisp for decades.

  5. I read this and was intrigued.

 

Of course, I'm going to continue to do my paying work in C#, if for no other reason than that no one in their right mind would pay me to write production Lisp code right now. But starting now, I'm going to make an effort to write all the code that I can in Lisp.

 

If you're interested in getting started yourself, it's as easy as going to download an implementation. I'm using CLISP, as it's free and seems to be pretty mature and broadly supported.  

 

Should be an interesting ride!

Monday, July 2, 2007

The Failure of SOAP

It may seem odd to see the title of this post, seeing as it immediately follows one entitled "The MTPS Content Service - A SOAP Success Story". But it was always my intention to write these two back-to-back, because my experience writing the MTPS service was a major part of my most recent revelation: SOAP is no longer my default choice for writing web services.

 

You've seen some of this story already. I said I've been thinking like Tim for a while now. That thinking has really solidified for me over the last few weeks, to the point where I'm ready to essentially walk away from ASMX/WCF/SOAP in all but a few edge cases.

 

There have been three main ingredients in this solidification of my "conversion". First, I managed to finish RESTful Web Services, by Sam Ruby and Leonard Richardson. This is a first-rate book. It is going on my shelf right next to Transactional COM+ as a "must read". Not that I necessarily agree with everything in it - in particular I'm not sure that PUT and DELETE are appropriate choices for most web services - but the way it helped me think about URL structure in particular puts it on the "must read" list for me.

 

The second ingredient was a series of conversations I had with John Elliot, one of the better-known posters on the Win Tech Off Topic list. He's been telling me for years about his ideas about web services, so I took the time to correspond with him to get clarification, and it really resonated. In a nutshell, his position is that web services should be accessible via a web browser, an idea I really like. This implies a read/execute bifurcation along GET/POST, metadata via HTML Forms, and XHTML as a the primary payload. Tasty. (Apologies to John if I've misstated or over-simplified his position.) 

 

The final (and key) ingredient was the realization that SOAP is the COM+ of the modern era. I did a lot of COM+ back in the day, even going so far as to teach classes about it and to write an MSDN article on it. So for some value of "expert", I was an expert on the technology. And yet, my main piece of advice to clients these days is: don't use it unless you have to.

 

Note that I'm not saying that either SOAP technologies or COM+ don't work. They do. If your problem fits the solution (e.g. multi-object transactions in COM+, single-URL RPC interfaces in SOAP, for example), then go ahead. It's just that I get enough benefits and avoid enough overhead from doing it at the lower (and simpler) level in each case that it's not my default choice any more.

 

It's also interesting to note that in both cases it was Microsoft - the vendor with a vested interest in me adopting the technology in question - that was the primary source of the information that led me to go down the SOAP/COM+ path. I'm not questioning anyone's integrity - it's just the nature of information that of course the COM+ message was going to be "use it for everything". And similarly SOAP. The failure to analyze whether the technology in question was the most appropriate for my problems was, of course, entirely mine. But hey, like Tim always says, "I reserve the right to get smarter." :)

 

If this seems like a repeat of things I've said already, well, I apologize. But I just had to share - the realization of the parallels between my personal journey with COM+ and my personal journey with SOAP just struck a real chord with me. Your mileage may vary.