Today I finished reading through Christian Wenz's Essential Silverlight Up-To-Date.  According to Amazon, the book ships tomorrow -- I was able to read it though my subscription to Safari Books Online.  From what I can get out of browsing the Amazon site, it is the first Silverlight 2 book to come out, and precedes the others by about two months.  It is, essentially, the only game in town for those planning to learn Silverlight 2 from a book.

It is a bit of a mixed bag, due not least to the difficulties involved in trying to write a book about a technology that is still in flux.  Breaking changes are expected during the transition from the beta 1 to the beta 2 of  Silverlight 2, and most book authors in this sub-genre of a sub-genre have adopted the better part of valor.  So thanks are due to Mr. Wenz for accepting such a difficult task and finding a way to meet his publisher's deadline.

That said, while the book offers a good overview of the Silverlight 2 technology, in doesn't go into any particular depth.  The labs are difficult to follow, at times, because some of the things he writes about do not appear in the Silverlight 2 beta 1, such as a project template for user controls.  Since his walkthroughs require the use of a user control, I was obliged to google the right way to create one, just so I could finish the book.

Frustratingly, the chapter on Programming Silverlight with .NET is extremely brief, despite the fact that this is perhaps the most interesting new feature of Silverlight 2.  Or perhaps this is merely an artifact of the way I read it, and the physical copy that will be placed on bookstore shelves will have more content.  At least I hope this is the case.

I was finally able to get a user control into my XAML page by following the official Silverlight 2 hands-on labs, found here.  Microsoft is not known for being good at documenting their bleeding edge technology, but these labs are actually quite excellent, and may currently be the best resource for learning Silverlight 2.  I'll know more tomorrow, as I plan to work my way through all the tutorials and labs on the official Silverlight site.

The trick with adding a user control to a XAML page, it turns out, is that a namespace declaration to the containing project has to be added to the page.  The page, for whatever reason, is not automatically aware of the assembly it is in.  Once the namespace is declared, however, Intellisense takes over and makes adding your user controls -- HelloWorld.xaml, in this case -- quite easy.

'Twas not a propitious day.  Installing the Beta 1 of Silverlight 2 was trying.  Finding the correct place to download the correct version of Silverlight 2 was a bit tricky, but I finally did get to it: http://silverlight.net/getstarted/.

I downloaded and installed the SDK without trouble.  On reading a bit more around the net, it turned out I also needed the correct version of the Silverlight Tools for Visual Studio 2008 in order to get the project templates I would require to do anything worthwhile, so I did.  This installation didn't go so well, and I received a message stating vaguely that I had previous software that needed to be removed.

I removed the Silverlight browser plug-in, but I got the same message.  Since the only other Silverlight component I had installed was the SDK, I decided to remove that also.  This did the trick.  It turns out that what is now being called the Silverlight Tools is actually a comprehensive install that includes the SDK, though at some previous point it wasn't.  Checking at the Microsoft Silverlight site, it also appears that the site has been updated with a clarification to make this change more obvious.

After getting everything installed, I fired up the Visual Studio IDE and started working through the examples in Chris Wenz's Essential Silverlight 2 -- Up to Date.  It is the only book on Silverlight 2 I could find, and the "Up to Date" postscript is meant to indicate that it will be updated on a regular basis as different versions of Silverlight are released.  The one I'm reading through is meant to be for the Silverlight 2 Beta 1, though the version being sold appears to have been written before the official release.  I was also told that this was the book which was distributed at MIX '08.

I tried downloading the sample code that is intended to go with the book, but it turned out to be a dead link.   Oh well, I thought, I can just build each project myself according to Chris's instructions.

At the end of the first chapter, however, I was instructed to create "a new Silverlight Control project within the current solution," and after 20 minutes or so trying to puzzle out what I was supposed to do, I finally realized that no such project template existed.  The version of the Silverlight 2 Beta 1 that was released turns out to be a different beast than the one he was writing about.  So I'll just skip this example and move on to the rest of the book, hoping that this is the exception that proves the rule, rather than the rule that proves the rule.

In this first chapter, I also learned a new acronym to add to my bestiary of strange and exotic technical terms.  An RIA is a Rich Internet Application, not to be confused with an AJAX client, or a thin client, or a one-click client, or a rich client application.  Silverlight is an RIA, as is Adobe Flash, Adobe AIR, JavaFX and Google Gears.

Despite the frustrations of this first day, I am still excited about Silverlight.  The contradictory and confusing nature of the various Silverlight resources can be chalked up to the entry cost for learning bleeding edge technology.  And perhaps it is even intended to discourage those not willing to bear some burden as the price for acquiring new knowledge. 

On another front, I've decided that the best place to renew a study of Husserlian Phenomenology is with Franz Brentano.  I have a translation (which you can read here) by Benito Müller of a series of lectures given by Brentano on descriptive psychology from 1890 entitled Psychognosie, which include Brentano's influential analysis of the concept of intentionality -- the sine qua non of phenomenology. 

In his introduction, Müller is good enough to provide the most succinct explanation of intentionality I have ever come across. "Every psychical act is intentional in that it is directed upon an object."  Would that tech book authors could achieve a similar standard of clarity.

Bill Ryan is a man spoken of in awed tones at the Magenic offices in Atlanta.  There are various ways to develop a reputation in the computing world.  Some people post to technology discussion groups.  Some people write books.  Some speak at conferences.  Some people are good at making friends with Microsoft developers in Redmond.  Some strive to get abbreviations tacked onto their names like MCAD, MCSD, and MVP.  The problem with all of this is that the more time you spend on these particular pursuits, the less time you actually spend coding, and so there can be a certain hollowness to these technical reputations.  The people writing the books on how to use certain technologies are often the last people you want actually building a system for you using those technologies because, as a consequence of their writing and speaking obligations, they don't actually have any real world experience using them.

Bill, as people at Magenic say, is "the real deal."  He talks the talk and he walks the walk.  Speculation around the water cooler is that he could have only accomplished all that he did, while with Magenic, by never sleeping.

He is basically the living ideal of what a software consultant should be.  The fact that the consultants I work with, who in their own right are all remarkable technicians and gentlemen, view Bill in this way says much.

What is the genesis of such a reputation, and such a high level of technical competence?  My guess is that Bill is just hardwired that way, and was born to greatness.  In a blog entry from 2004, however, he provides a different origin story, one that has an almost Horatio Hornblower quality to it.

This is my third pass at learning “Patterns” and it's going a little easier.  I tried reading the GoF book but it might as well be written in Martian b/c while I can read it, I have a mental block or something because absorption isn't there.  So my first goal of the new year (starting three days ago) is to get proficient with at least 20 Data Access Patterns.

...

My next goal is to have a full command of all of the new ADO.NET 2.0 Features BEFORE the new framework is released.  Made a lot of progress so far but have a long way to go.

I want to be able to build a fairly sophisticated Sharepoint portal without “Having” to look for help.  That's not to say that I'd ever want to build anything without referring to some stuff I've read - but if I know I can do it if I had to - I'll be where I want to be.

Ditto for Biztalk -

This fragment provides a fair portrait of what Bill was up to at the end of 2004.  He gave himself some extremely ambitious goals -- accomplishing any one of these would have propelled your typical developer into an architectural role in most companies -- and, more amazingly, accomplished them.

It has been roughly three years between that post and this, which shows what can be accomplished in a so brief time.   His attitude is inspiring, and so I'll give it a shot also, in the same way a Greek youth might once have repeated a mantra he overheard outside the walls of the Parthenon.

• I will learn Silverlight 2.0 thoroughly before the official Go Live license is released with the beta 2, sometime in May.
• I will strive to understand the inner workings of WCF until I can understand half of everything Juval Löwy, a technical theoretician of the highest caliber, might have to say about it.
• I will complete a code generation tool that actually builds a fully working CSLA business tier, instead of only allowing class by class generation.  Ideally, I will make it work inside the Visual Studio IDE and also have it generate a Silverlight GUI to sit on top of the business layer -- if a future release of Silverlight gets all the databinding features working correctly.  I will accomplish this before Rocky Lhotka finishes his next CSLA book.
• By the end of the year, I will finally get to the last chapter of Wheelock's Latin.
• By the end of the year, I will get back into phenomenology, and write a short monograph on the relationship between Husserl's phenomenology and virtual reality.

Yoda said,

"Try not. Do or do not. There is no try."

Mr. Miyagi, more prolix, but with equal sagacity, said,

"Walk on road, hm?  Walk left side, safe.  Walk right side, safe.  Walk middle, sooner or later get squished just like grape. Here, karate, same thing. Either you karate do "yes" or karate do "no." You karate do "guess so" -- squish just like grape."

Cicero couched the same insight in these terms:

"Ut enim qui demersi sunt in aqua nihilo magis respirare possunt si non longe absunt a summo, ut iam iamque possint emergere, quam si etiam tum essent in profundo, nec catulus ille qui iam appropinquat ut videat plus cernit quam is qui modo est natus, item qui processit aliquantum ad virtutis habitum nihilo minus in miseria est quam ille qui nihil processit."

Methodology is one of those IT topics that generally make my eyes glaze over.  There is currently a hefty thread over on the altdotnet community rehashing the old debates about waterfall vs. agile vs. particular flavors of agile. The topic follows this well-worn pattern: waterfall, which dominated the application development life cycle for so many years, simply didn't work, so someone had to invent a lightweight methodology like XP to make up for its deficiencies.  But XP also didn't always work, so it was necessary to come up with other alternatives, like Scrum, Rational, etc., all encapsulated under the rubric "Agile". (Which agile methodology came first is a sub-genre of the which agile methodology should I use super-genre, by the way.)  Both Waterfall and the various flavors of Agile are contrasted against the most common software development methodology, "Cowboy Coding" or "Seat-of-the-pants" programming, which is essentially a lack of structure.  Due to the current common wisdom regarding agile, that one should mix-and-match various agile methodologies until one finds a religion one can love, there is some concern that this is not actually all that distinguishable from cowboy coding. 

For an interesting take on the matter, you should consult Steve Yegge's classic post, Good Agile, Bad Agile.

I have a friend who, in all other ways, is a well-grounded, rational human being in the engineering field, but when the topic of Druids comes up, almost always at his instigation, I feel compelled to find a reason to leave the room.  The elm, the ewe, the mistletoe, the silver sickle: these subjects in close constellation instill in me a sudden case of restless legs syndrome.

Not surprisingly, discussions concerning Methodology give me a similar tingly feeling in my toes.  This post in the altdotnet discussion caught my eye, however:

I also don't believe it is possible to do the kind of planning waterfall requires on any sufficiently large project. So usually what happens is that changes are made to the plan along the way as assumptions and understandings are changed along the way.

Rather than belittle waterfall methodology as inherently misguided, the author expresses the novel notion that it is simply too difficult to implement.  The fault in other words, dear Brutus, lies not in our stars, but in ourselves.

Rabbi Gershom Ben Judah, also known as the Light of the Exile, besides being a formidable scholar, is also notable for his prohibition of polygamy in the 10th century, a prohibition that applied to all Ashkenazy jews, and which was later adopted by Sephardis as well. The prohibition required particular care, since tradition establishes that David, Solomon, and Abraham all had multiple wives.  So why should it be that what was it good for the goose is not so for the gander?

Rabbi Gershom's exegesis in large part rests on this observation: we are not what our forefathers were.  David, Solomon, and Abraham were all great men, with the virtue required to maintain and manage  polygamous households.  However, as everyone knows, virtue tends to become diluted when it flows downhill.  The modern (even the 10th century modern) lacks the requisite wisdom to prevent natural jealousies between rival wives, the necessary stamina to care for all of his wives as they deserve, and the practical means to provide for them.  For the modern to attempt to live as did David, Solomon, or Abraham, would be disastrous personally, and inimical to good order generally.

What giants of virtue must have once walked the earth.  There was a time, it seems, when the various agile methodologies were non-existent and yet large software development projects were completed, all the same.  It is perhaps difficult for the modern software developer to even imagine such a thing, for in our benighted state, stories about waterfall methodology sending men to the moon seem fanciful and somewhat dodgy -- something accomplished perhaps during the mythical man month, but not in real time.

Yet it is so.  Much of modern software is built on the accomplishments of people who had nothing more than the waterfall method to work with, and where we are successful, with XP or Scrum or whatever our particular religion happens to be, it is because we stand on the shoulders of giants.

I find that I am not tempted, all the same.  I know my personal shortcomings, and I would no more try to implement a waterfall project than I would petition for a second wife.  I am not the man my forefathers were.

I use Windows Live Mail to access my Comcast email account.  Whenever I try to send emails, I get this lovely message:

A TCP/IP error occurred while trying to connect to the server.

Subject 'Re: REQUEST FOR URGENT BUSINESS RELATIONSHIP'
Server: 'smtp.comcast.net'
Windows Live Mail Error ID: 0x800CCC15
Protocol: SMTP
Port: 25
Secure(SSL): Yes

Normally I wouldn't care, but in this case there is a former general's widow in Nigeria who wants to offer me a lucrative business proposal.  I can't go into details, of course, but it is basically a sure-fire thing, and the only thing now preventing from being a very wealthy man is this problem with sending emails to Comcast's SMTP server.

The problem turns out not to be on Comcast's end, however.  My problems with Comcast typically involve billing and service interruption, not basic technology.  Consequently, I began looking elsewhere to track down the issue.

The culprit turns out to be my virus scanning software.  There are lots of posts on the Internet claiming that it is the email scanner which muffs up sending.  This is a red-herring, and turning off virus scanning for your emails is, all things considered, not such a great notion.  It also doesn't really make much sense -- why would scanning incoming emails prevent the sending of emails?

I did a little more investigating and found this McAfee log file, which reveals what is really going on.

4/5/2008    12:04:39 PM    Blocked by port blocking rule     C:\Program Files\Windows Live\Mail\wlmail.exe    Anti-virus Standard Protection:Prevent mass mailing worms from sending mail    76.96.30.117:25
4/5/2008    12:14:01 PM    Blocked by port blocking rule     C:\Program Files\Windows Live\Mail\wlmail.exe    Anti-virus Standard Protection:Prevent mass mailing worms from sending mail    76.96.30.117:25

 

Ho ho.  McAfee is blocking my port 25, purportedly to prevent zombies from taking over my machine and sending out spam messages.  Which makes perfect sense, since if I can't send out emails, then a zombie impersonating me on my own computer will also not be able to send out emails.  It's a let's bomb them all and let God sort out the emails sort of solution -- effective, but somewhat heavy handed.

So, with your permission, I'm going to disable my anti-virus software's port 25 blocking.  I'm not sure of the ultimate impact upon humanity, but it would be rather convenient for me.

Some of my favorite blogs have closed down over the years due to the difficulty of maintaining a high quality blog -- Teju Cole, Heaven Tree, Varieties of Unreligious Experience, Giornale Nuovo.  If mine goes down in the near future, however, you will know that it is due not to the high quality of the writing -- which happens not to be one of its virtues, I fear -- but rather to the incredible wealth that has fallen into the author's lap.  I've read many sad final posts over the past year, but mine shall certainly be a felicitous one: this blog has closed down because the author moved into a higher tax bracket!

Thank you, thank you my anonymous Nigerian general's widow.  And a pox upon McAfee, whose spam blocker almost prevented me from concluding this fortuitous enterprise.