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.

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.

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!

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.

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!

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.

The MTPS Content Service - A SOAP Success Story

When I wrote the MTPS Content Service (was that a year ago already?) I didn't really expect people to use it much. I figured there'd be a few small and interesting apps - for instance, I wrote msdnman mostly for fun - but that it would largely be a useful but little-used service.

 

I was quite wrong.

 

The other day I found out the usage numbers for the service. The conversation went something like this:

 

Kim: "Hey, I wanted to tell you the stats are in for the content service."

Me: "Oh really? I'm curious - what are they like."

Kim: "Here, I'll email you the numbers."

Me: "Wow! It's only been a year and there's been 1.3 million hits - that's a lot!"

Kim: "No, that was for yesterday."

Me: "…"

 

I was quite literally speechless. Which, if you know me, you know is a rare thing. :) That's fifteen requests per second, so perhaps I can be forgiven my momentary surprise. (Traffic has since subsided to a mere 600K requests or so per day - an average of around seven requests per second.)

 

I have to say I'm fairly proud of having written a web service that can sustain those sorts of loads. Of course, the credit is not due all nor even (close to) mostly to me: the service is a fairly thin wrapper around the MTPS system, and I was only one part of the team that did that. Plus, without a crack ops team it doesn't matter how good your software is - you're not scaling. Kudos to those guys as well. All I had to do was not screw up the translation to SOAP. :)

 

We don't really have good data on what applications are creating all this traffic. We do know that the recently-released PackageThis is responsible for somewhere around a third of the traffic. We know that because PackageThis is the only app currently sending an AppID header with their requests. An AppID header is just a short string that identifies the application making the request. This is something we added rather late in the development cycle, never really documented, and made optional. So maybe it isn't surprising that it's not showing up in a lot of the requests. Hopefully we can fix that at some point.

 

Sandcastle also uses the service, and I wouldn't be too surprised if it accounts for the bulk of the remainder of the traffic. They're adding an AppID header soon, so we'll have better data then. It certainly will be interesting to see - personally I'd love it if there were still a whole bunch of unknown apps in the traffic pattern, as it would suggest that lots of people have found good ways to use the service. Which was our hope when we wrote it.