Month: April 2008

The Secret Society of Liberal Artists

James Ashley2 Comments

secretsocieties

The IT industry is dominated by those with CS degrees.  Much criticism has been leveled at the CS degree of late, mostly on the grounds that it doesn’t provide the skills (or even teach the languages) that an aspiring software developer will need once she gets out into the real world.  Brian at Enfranchised Mind has a good post over on his blog about this.  He raises what he considers to be three misconceptions concerning IT and the CS degree:

  • Computer science and programming are separate things, and that it’s possible to know one without knowing the other,
  • That it is possible, at least in theory, to teach students everything (or most everything) they need to know in “the real world”, in a reasonable amount of time (four years), and
  • That the point and purpose of a CS education is to give you those “real world” skills.

He argues, correctly I believe, that the goal of the Computer Science Degree is not to provide students with a specific set of skills to do a specific job, but rather the sort of skills they will need to perform any IT job.  This has both practical and humanistic implications.  From a practical point of view, being trained to do a specific job in IT is inherently short sighted, since technology changes so quickly that the person trained to do the most needed tasks today — say MS BizTalk, or MS SharePoint, or SOA architecture — may find himself obsolete within five years. 

Job training is also wrong from the humanistic perspective, however.  To be trained for a job is basically to be trained to be a cog in a wheel.  This doesn’t work in professions that require the amount of energy, thought, and imagination required to successfully complete software projects.  Instead, some thought has to be put into developing the whole person to participate in the complex activity of software development, and this means equipping that person with the skills needed to not only understand the things that have to be done immediately, but also to understand the principles behind what they do, and the goals they are trying to achieve.  This in turn involves developing the whole individual in a way which, on the surface, appears to be useless.  CS majors learn obsolete languages and the principles behind building tools that have already been developed for them out in the real world.  Why learn to build a web server when there are so many already out there?

What is forgotten in these arguments against CS is that the goal of the degree is not to teach CS majors how to do any particular IT task, but rather how to think about IT.  In learning obsolete languages, they learn to think about software in a pure way that does not involve immediate applications or utilitarian motives.  They learn to appreciate computer science for its own sake.  In the long run, this useless knowledge can also become useful knowledge.  When code start breaking, when servers don’t work as advertised, it is the CS major who is able to step in and unravel the problems because they understand what the server or the code is supposed to do.  They understand the principles.  For a great article on the purpose of useless knowledge, I highly recommend Stanley Fish’s post from earlier this year.

While the IT industry is dominated by CS majors, it is not exclusive to CS majors.  Over the years accountants, actuaries, mathematicians, physicists, entomologists and ornithologists have also found their way into the profession, and have enriched it with their particular perspectives.  The rigor of their training has turned out to provide much needed additional skills to the mix.  The mathematician knows his way around algorithms much better than the typical CS major.  The ornithologist is trained to organize and particularize in ways those with CS degrees are not.  Accountants and actuaries know the secret paths of financial transactions that your common CS major cannot usually follow.  These specialists have basically learned on the job, and their prior careers have provided them with the techniques of methodical thinking as well as the strong grounding in mathematics necessary to make this transition possible.

But the IT industry is not exclusive to CS majors and emigres from finance and the sciences.  Within the hallowed cubicles of IT you will also find secret adepts of the Trivium, followers of disciplines which since the beginning of the 20th century have been generally acknowledged as being trivial.  These are the practitioners of truly useless knowledge: English majors, philosophy majors, psychology majors, comparative literature and art history majors.  You may work in an IT shop infiltrated by these people.  You may even have a French literature major working in the cubicle across from yours and not even know it.  Your DBA could be a history major.  The etiquette of the IT workplace prevents you from finding this sort of thing out.  You have no way of knowing.

But they know.  Liberal artists seek each other out, and have secret phrases they use to find each other that seem like gobbledygook to the rest of us.  Has a colleague ever asked, in passing, if you read Auden?  You probably gave a confused look, and the interlocutor quickly changed the subject.  You’ve probably even forgotten about the incident, not understanding the implications of the phrase. 

What was really going on, though, was this: you were being approached by a Liberal Artist who, for whatever reason, suspected that you might also be a Liberal Artist.  Perhaps you dressed with a bit of extra flair that day, or took some care in matching your belt with your shoes, or applied a subtle and inoffensive amount of cologne.  There are lots of secret signs in the Liberal Artist community.  Whatever it was, you were then approached in a "contact" scenario to discover if you were in fact an initiate or merely someone who accidentally deviated from the norm of the IT dress code (i.e. golf shirt, khaki pants with frayed cuffs, tech gear worn on utility belt).  Your bewildered look, in turn, indicated one of two things: 1) I have no idea what you are talking about or 2) there are other people listening in — too dangerous to make contact now — come back later.

Other phrases that might be used by a liberal artist during a "contact" situation include:

    • I read an article in Archaeology Today that might be relevant to this.
    • I hear the Pinot Gris is especially tasty this year.
    • That is quite a moral quandary.  I wonder what Kant would say.
    • This debate over objects vs services reminds me of the Medieval debate between Realists and Nominalists.
    • Did you see that New Yorker cartoon?  You know the one I’m talking about.
    • That is not the proper usage for "begs the question."  What you meant to say is it "invites the question."
    • Are you as incensed as I am by Stanley Fish’s latest blog post?

 

This of course does not exhaust the list of occult phrases that may be used by the liberal artist during an attempted contact, but it should give you a good indication of the types of things you might look for in order to find signs of liberal artist infiltration of your organization.  Another way to identify liberal artists without breaking etiquette and outright asking them — thus revealing that you are onto their little game, and possibly placing yourself in a precarious position — is to ask what schools they attended.   Even better, surreptitiously check their resumes to gather this information.  Sometimes the matter may be ambiguous.  On the other hand, if you find that they attended schools with names like Bard, Brown or Bowdoin, then you can be fairly certain that you are face-to-face with a liberal artist.  Here is a list of other liberal arts schools you can use in your background check.

Why, you may ask, are liberal artists so secretive about their background, to the point that they require secret signals to identify one another?  An innocent explanation would be that they simply suffer from a bit of CS envy, and desire to blend in.  But this wouldn’t be the whole story.  Liberal artists help each other out.  By identifying each other in these esoteric ways, they not only form a cohesive unit within an organization, but put themselves in positions to help one another out.  Like a fifth column inside the corporate body, they concentrate power into the hands of like-minded individuals, and use this as leverage in order further climb the corporate ladder.

Consider how many of your managers might be liberal artists.  Liberal artists are often able to emphasize their communication skills based on their backgrounds, which tends to put them on a management track.  Once in management, they are in turn more likely to favor others with a similar background for promotions.  It is a vicious circle that leads, in many companies, to a situation in which you may find that while the IT staff is predominantly made up of CS majors, the class of employees tasked with managing the CS majors are almost exclusively humanities majors.  And how does this happen?  Through simple and apparently innocuous questions like "Do you read Auden?"

Don’t believe me?  Then consider that Carly Fiorini, the former CEO of Hewlett-Packard responsible for the merger with Compaq, is a medieval history and philosophy major.  Michael Eisner, one of the best paid CEO’s ever, studied English and theater.  Sue Kronick, one of the 25 highest paid executives in the U.S. according to Fortune Magazine, did Asian studies in college.  So the next time you are tempted to think of the Secret Society of Liberal Artists as a mere social organization, consider carefully who holds the reins of power in your company.  The Secret Society of Liberal Artists: a harmless networking tool?  Perhaps.  A dangerous anti-democratic cult out to gather power by any means?  Most definitely.

How do I know all this?  Because, my friends, I must confess that I am not only a software programmer.  I am also a recovering liberal artist.  And I am here to warn you: do not take the liberal arts lightly.

How to Read a Tech Book

James Ashley5 Comments

johnnymnomonic

My efforts to write about learning Silverlight in Seven Days are filled with omissions and gaps.  While each Silverlight "day" really does constitute one day’s worth of studying, they haven’t been contiguous days.  One large gap is due to a trip I had to make to Washington D.C. to settle personal affairs.  Others were job related since, like most of you, I have to maintain my day job even as I’m expending effort to learn new technology in my off time — which, however, will eventually feed back into my day job.  Which invites the obvious question of whether learning technology is really work time or private time.  I tend to think of it as private time, since I enjoy it immensely and grow personally by doing it.  All the same — and I believe this is not the case in most IT shops — my day job is actually forward looking about this sort of thing, and allows me to spend part of my day learning all the new acronyms coming out of Redmond — in some sense paying me to do something I love.  But an equally valid way of looking at it is that I am working to keep my IT shop informed about the best solutions for its upcoming projects, and the reward for the investment of time and energy I make in learning these technologies are ultimately reaped by my company.  I am, in effect, investing my company’s time wisely.

Should we choose to look at the matter in this way, then it is important that the time spent on learning technology be used optimally.  This is hampered by the fact that information about things like WCF, WPF, WF (the initial "W" is typically truncated, I assume, because it evokes notions of profession wrestling) and Silverlight are poorly disseminated.  Half of the effort spent on learning new tech involves tracking down the proper resources, weeding out the unhelpful books that misstate what they can offer and the ones that are just poorly written or misinformed, and finding the correct location for the online resources — including source code — that one needs.  Scott Galloway has a great post about this problem over on his blog: http://www.mostlylucid.net/.

The other half is spent actually engorging all the information that is available.  There is a scene from Johnny Mnemonic, that peculiar 1995 Keanu Reeves sci-fi vehicle, in which Keanu uploads 300 megabytes of data into his cerebral cortex.  In order to prepare for it, he puts a bite guard in his mouth, clamps down and, with evident consternation on his face, yells out "hit me."  This is how I feel whenever I prepare myself to sit down with a tech book.

A tech book is not a friendly beast.  You cannot curl up with it in bed.  You never giggle over a clever turn of phrase and beg your partner to allow you to read her a passage aloud.  Instead, it is a big heap of bound paper, generally printed in large type in an apparent attempt to make it seem weightier than it has any right to be, which you have to plow through in a Sisyphusian effort to reach the end.  In truth, no one ever gets to the end of one of these things because we all get bogged down in the details.  This is natural enough, because the presentation is typically all about the details after the initial chapter, and the initial chapter tends to alternate between vagueness and hello world samples to the point that it just can’t be taken very seriously.  But then we get lost in the details.  There is so much we don’t understand in reading through these tech books that we become frantic over the thought that we might be missing something important — the key that unlocks all the material we are trying to absorb.  The reading process becomes slower and more onerous until finally external affairs draw us back into the life-world or we throw our tech book to the wall where, with luck, it shatters into a million pieces and we never have to pick up reading again where we left off.

Scott Hanselman touches on this point in his post: Books: We Need More So What, Now What, And What For And Less Just What, though it might just as easily have been titled, "Why Tech Books Suck".  The essential problem with tech books is that they never work out the inherent paradox of all learning: one cannot learn the whole without understanding the parts; one cannot know the parts without understanding the whole.  In contemporary exegetics, this known as the hermeneutic circle.

Aristotle says in his Poetics that tragedies such as Oedipus Rex and Electra are higher and more philosophical than historical works because they aspire to truth, whereas histories merely offer details.  I think it is this desire to know the "truth" of a technology — its purpose, its potential, it’s meaning — from a medium so poorly suited to this task, the tech book, that typically leaves us feeling so frustrated and so drained.  We get bogged down in details because tech authors get bogged down in details, and it is the exceptional writer who knows how to navigate the hermeneutic circle in order to provide us with a usable tech book — the criterion for usability, in this case, being merely not making us want to throw it across the room.

The quality of tech books is out of our control, however, so we must turn to the quality of reading tech books.  Here are my suggestions for how to get the most out of a tech book, so that as little time is wasted on them as possible:

1. Read Online — I use Safari Books Online for my tech education, as well as MSDN and various tech blogs.  This tends to make my eyes bleed, but it has the distinct advantage of not lulling me into the illusion that tech books are like other books.  Once I start treating tech books like other books, I find that I fall into the habits I’ve acquired for reading fiction and even most non-fiction.  I look for a plot and my mind tries to work itself towards a narrative climax that never actually transpires.  Tech books don’t have plots.  They just are.  If you rip out the chapters and put them together in a different sequence, it generally doesn’t matter.  Tech books are heaps, not paths.  Reading online helps me to avoid this confusion — though it obviously isn’t for everyone.

2. Plan to Re-read — if you set out on a new book knowing that you will re-read it, then you won’t get so bogged down in the details.  You can always go back and pick up what you missed later.  I generally read a tech book three times.  The first time I just skim through the chapter headings so I know what the book is going to cover and what I feel confident about skipping entirely.  This can be done in a few minutes.  On the second read, I just skim the whole book.  I don’t try to do any coding exercises.  I just get a good grasp of the principles involved, and the various materials I will need to understand.  The goal is simply to get to the end of the book, not to understand it in its entirety.  This can be done in a few hours.  The third read is used to go back and pick up the important stuff.  From the second read, I know that there are things I don’t understand, and hopefully I will have formed an opinion of what is important in the book and what is drivel.  In the third read, if a third read is even necessary, I pick up the important bits.

3. Give Yourself Permission to Skip — The fear of missing something important is a paralyzing fear.  You have to give yourself permission to skip things when you are reading a tech book.  Remember, a lot of the things in a tech book are just filler.  The author felt he had to push something in that is actually irrelevant, or the publisher has established a page count for him that he must fulfill.  Not everything in a tech book is important.  Marshall McLuhan developed a habit of reading only the right hand pages of any non-fiction book (he would read a non-fiction book in its entirety, however).  The way he explained it, a lot of non-fiction is just filler, and by his estimation, only 10% or so of any non-fiction book was actually worth knowing — and that was if it was a good book.  An intelligent person can fill in the gaps as he goes along.  More importantly, the way your mind fills in these interstitial gaps actually helps it to retain information better.  The mind learns not by simply replicating what it finds in a book, like some copying machine, but rather by trying to reconstruct and build things in the imagination.  In rhetoric, this is sometimes called an enthememe, or a logical argument with gaps.  The ancient orators discovered that by not completing a logical argument, but rather by letting an audience piece it out for themselves, they were better able to convince the audience of the rightness of their conclusions.  Laying things out for people leaves them unconvinced.  Making them work things out for themselves gives them possession of the information, and allows them to make it their own.

4. Talk About What You Learn — Reading a book is useless if you can’t retain what you’ve learned.  The best way to retain the information in a tech book is to use it.  Unfortunately we aren’t always afforded opportunities to use what we know.  We do, however, always have outlets to talk about what we know, and the process of talking not only forms new neural pathways in our brains, thus increasing retention, but allows us to correct our mistakes and misconceptions.  Talking to other developers working on the same technology is optimal.  If that is not possible, however, blogging or writing to newsgroups can serve the same function.  They keep the technology ever in your mind, and you can add on to it or take away from it as you go along.

All of this may be pretty obvious, but then one would think that figuring out how to write better tech books should also be pretty obvious — and it isn’t.  Learning new technologies is generally considered one of the "soft" problems of IT.  By now, however, we have all had enough industry experience with reading tech books that it is clear this is not the case, and it is probably time to throw tech books onto the mound with all of the other "hard" problems of IT, like how to retain good people and how to complete a project on time.

Navel Gazing

James Ashley1 Comment

orestes

In Greek, it is called Omphaloskepsis — though the provenance of this term appears to be fairly recent.  Its origins seem to be found in Eastern meditative practices in which the subject concentrates on his navel, the center of his being, in order to shut out all worldly distractions.  The significance of the navel is also found in the origins of Western culture.  Omphalos, literally "navel", was used to describe the terrestrial location from which all life sprang.  It was also the name of the stone found in the temple at Delphi, purported to be the stone which Rhea swaddled in baby clothes and which the titan Chronos swallowed, believing it to be his son Zeus, prophesied to one day overthrow him.  Because of its divine origins, the Omphalos was believed to be a point of contact between the celestial and the terrestrial, and gazing at the Omphalos was equivalent to gazing into the realm of the gods.

It is also a mode of reflection common in times of uncertainty.  The IT industry is at such a point.  Any software professional who went through the .NET bust at the turn of the millennium and through the financial decline following 9/11 has an ingrained sense that changes in the economy can radically alter the face of IT.  The past five years have seen the emergence and adoption of various tools and methodologies, from Agile to Responsibility Driven Design to Domain Driven Design to alt.net, all premised on the notion that things haven’t been going well, and if we all just put our heads together we will find a better way. 

Marshall McLuhan — I believe it was in The Medium is the Massage — tells an anecdote about a factory that brought in consultants to change their internal processes, resulting in a 10% increase in productivity.  A year later, for unspecified reasons, the factory reverted to its previous processes, and surprisingly increased productivity by another 10%.  This suggested to McLuhan that sometimes what one does to bring about change is not significant in itself.  Sometimes it is simply the message of change, rather than any particular implementation, which provides results.

The various methodologies, philosophies and practices of the past few years seem to have made improvements in some software houses, but it is not clear that this is due to the inherent wisdom of the prescribed techniques rather than, as McLuhan might say, the simple message that things aren’t quite right with our industry.  The acolytes of each methodology that comes along initially cite, quite properly, Fred Brooks’s influential articles The Mythical Man-Month and No Silver Bullet.  What they rarely do, once their movements achieve a certain momentum, is revisit those early arguments and evaluate whether they have accomplished what they set out to do.  Did they solve the problems raised by Fred Brooks?  Or do they just move on and "evolve"?

Besides all the process related changes that have been introduced over the pass few years, Redmond is currently caught up in a flurry activity, and has been releasing not only new versions of their standard development tools, but a slew of alpha and beta frameworks for new technologies such as Presentation Foundation, Silverlight, Entities Framework, and MVP which threaten to radically alter the playing field, and leaves developers in a quandary about whether to become early adopters — risking the investment of lots of energy for technology that may potentially never catch on (DNA and Microsoft’s DHTML come to mind) — or stick with (now) traditional windows forms and web forms development, which may potentially become obsolete.

We also face the problem of too many senior developers.  There was a time when the .NET bubble drove all companies to promote developers rapidly in order to keep them, a tendency that kept expectations high and that did not really end with the collapse of the bubble.  Along with this, companies set the standard for senior developers, generally the highest level developers can attain short of management, as someone with ten years of development experience, a standard which, given the compact time frames of the IT industry, must have seemed a long way off.  But now we have lots of people in lots of IT departments with 10 years of experience, and they expect to be confirmed as senior developers.  Those that are already senior developers are wondering what their career path is, and management is not particularly forthcoming.

The combination of these factors means the IT population is graying but not necessarily maturing.  Management in turn is looking at ways to outsource their IT labor, under the misapprehension that IT fits into an assembly line labor model rather than a professional model in which system and business knowledge should ideally be preserved in-house.  IT, for most companies, falls on the expense side of the ledger, and one expects to find ways to make it more efficient.  The immature state of the profession, compared to medicine or teaching or even engineering, makes these efficiencies difficult to find.

Add to this an economy headed toward a recession or already in recession, and we have all the necessary ingredients for a period of deep navel gazing.  My feed reader recently picked up three, and I suspect this is only the beginning.

 

Martin Fowler’s Bliki contains a recent entry on SchoolsOfSoftwareDevelopment which deals with the problem of competing methodologies, and the Habermassian problem of agreeing on a common set of criteria upon which they may be judged.

Instead what we see is a situation where there are several schools of software development, each with its own definitions and statements of good practice. As a profession we need to recognize that multiple schools exist, and that their approaches to software development are quite different. Different to the point that what one school considers to be exemplary is considered by other schools to be incompetent. Furthermore, we don’t know which schools are right (in part because we CannotMeasureProductivity) although each school thinks of itself as right, with varying degrees of tolerance for the others.

 

A Canadian developer, D’Arcy from Winnipeg, wonders what the new Microsoft technology map entails for him.

For the last 7 years we’ve been learning the web form framework, learning the ins and outs of state management (regardless of your opinion if its good or bad), how to manage postbacks, and how to make the web bend and do summersaults based on what our needs were. And here we are again, looking at the next big paradigm shift: Webforms are still around, Rails-like frameworks are the new trend, and we have a vector based Flash-like framework that we can code in .NET. I find it funny that so many are wondering whether web forms will go away because of the new MVC framework Microsoft is developing, and *totally* ignore the bigger threat: being able to develop winform-like applications that will run on the web using Silverlight.

 

Finally, Shawn Wildermuth, the ADOGuy, has posted an existential rant on the state of the industry and the mercenary mentality on the part of management as well as labor, and the long-term implications of this trend.

In some sense we developers are part of the problem. Quitting your $75K/yr job to be hired back at $75/hr seems like a good deal, but in fact it is not a good deal for either party.  Your loyalty is to the paycheck and when you leave, the domain knowledge goes with you…

At the end of the contract you just move on, forcing you to divest in a personal stake. I miss that part of this business.  I have had more enjoyment about projects that didn’t work than all the mercenary positions I’ve ever held…

So do I have a call for action?  No. I think that domain knowledge is an important idea that both developers and companies need to address, but I don’t have a nice and tidy solution. This is a shift that I think has to happen in software development. Both sides of the table need to look long at the last five to ten years and determine if what we’re doing now is better than before.  Does it only feel better because each line of code is cheaper to produce (mostly a product of better platforms, not better coders). I hope this can change.

 

Something is in the air.  A sense of uneasiness.  A rising dissatisfaction.  An incipient awareness of mauvaise foi.  Or perhaps just a feeling that the world is about to change around us, and we fear being left behind either because we didn’t try hard enough, or because we weren’t paying attention.

Learning Silverlight: Day Five

James Ashley1 Comment

 hunt

 

Day five picks up with unsolicited errata and general notes for the remaining Quick Start tutorials from the Silverlight.net site.

Notes to Interaction Between HTML and Managed Code (there is only one tutorial in this section, as of this writing):

Accessing the HTML DOM from Managed Code — This is a pleasant tutorial showing how to use the Silverlight Host Control as basically a wedge between code behind and the HTML DOM.  From the user control hosted in the host page, you can basically grab the DOM of the container page and manipulate it.  Because there is a lot of code, this is primarily a copy & paste style of tutorial, which means some useful information is left out.  For instance:

  • If you name your Silverlight project qsHB, the code will work better, depending on how much you copy & paste and how much you write by hand.
  • The HTML controls you add to the Test html page should go in the same div tag that contains the Silverlight Host object.
  • By default, the dimensions of the Test html page generated with your project are 100% by 100%.  Change this to 10% by 10%, otherwise your controls will be off the bottom of the browser window.

 

Notes to Programming with Dynamic Languages (this section only has one eponymous Quick Start):

Notes to Programming with Dynamic Languages: [Skipped] — some day I may want to learn managed JavaScript, IronPython, or IronRuby.  Right now, however, I can’t really see the point.

 

Notes to Additional Programming Tasks (includes one Quick Start):

Using Isolated Storage and Application Settings — This tutorial walks you through working with the System.IO.IsolatedStorage.IsolatedStorageFileStream, which allows the application to store files in a sandbox on the server.  The application is very rich, which unfortunately means the tutorial itself involves a lot of copy — paste — compile.  To understand what is going on, you basically need to read through all the code you copy & pasted after it is all done.  When a tutorial becomes this complex (and to my chagrin I have written a few like that) it is perhaps best to give up on the idea of doing a tutorial and actually do a "lab", in which the code is already all written out, and the author’s job is merely to walk the reader through what is going on.  This is a cool little application, all the same, and I foresee using it as a reference app for lots of future projects.

 

Whew.  That’s it for the Quick Starts found on http://silverlight.net.  Tomorrow I’ll start on the labs.

Learning Silverlight: Day Four

James Ashley2 Comments

HMS_Surprise_large

Day Three concluded with finishing the QuickStart series on Building Dynamic User Interfaces with Silverlight, from the official Silverlight website.  Day Four continues with notes and unsolicited errata on Networking and Communication in Silverlight.

A. Sending and Receiving Plain XML Messages with Silverlight — I learned a new acronym in this very brief tutorial.  POX stands for plain ol’ XML.  The System.Net.WebClient class allows us to call a web service (in this case, a DIGG service) and pass the results to a callback method.

B. Building a WCF Web Service and Accessing It by Using a Proxy — Very nice.  A somewhat sophisticated small application combining Silverlight and WCF, explained clearly.  Someone went through and proofread this particular walkthrough, and the effort shows even in the details — like stating what namespaces need to be referenced before one actually needs to use them.

C. Accessing Syndication Feeds with Silverlight — Very simple tutorial on how to access an rss feed in Silverlight using the System.ServiceModel.Syndication.SyndicationFeed class.  The only problem is that if you follow the instructions precisely, it will not work.  The sample code uses the Silverlight.net rss feed, http://silverlight.net/blogs/microsoft/rss.aspx, as its source.  Unfortunately, in order to access an rss feed, the server hosting the feed must have a policy file set up to allow cross-domain access, which the Silverlight.net rss feed does not.

A tad annoying, no?  Or perhaps this is a some sort of Zen exercise intended to reinforce the principle that a Clientaccesspolicy.xml or Crossdomain.xml file must always be properly configured on the feed server. 

Learning Silverlight: Day Three

James Ashley3 Comments

 Tomadevaldivia

Today I have been working through the Microsoft QuickStarts for Silverlight, which include walkthroughs as well as code source.  Here are the high level topics available:

  • Getting Started with Silverlight Development [Skipped]

  • Building Dynamic User Interfaces with Silverlight

  • Networking and Communication in Silverlight

  • Interaction Between HTML and Managed Code

  • Programming with Dynamic Languages

  • Additional Programming Tasks

     

    Notes to Building Dynamic User Interfaces with Silverlight:

    A. Writing Handlers for Silverlight Input Events [Skipped] — this is covered in most introductory materials.  Didn’t see a point in reviewing it.

    B. Changing the Appearance of an Existing Control in Silverlight — this is interesting, since it covers both styling an app as well as skinning it with ContentTemplates.  ContentTemplates do more than set properties for certain elements in your Silverlight app the way CSS does for HTML elements.  They also let you switch out your Silverlight element with a custom element such that, say, everywhere you have specified a button in your app, you now get whatever is created in the button’s ContentTemplate.  It works a bit like a global replace.  On the other hand, whatever events you have hooked up to your button in order to fulfill business requirements will still work, whatever you do with the ContentTemplate.

    This QuickStart is mostly a copy / paste sort of tutorial.  That said, there are some errors in it such that, if you follow the instructions to the letter, you will end up with a useless application that hangs.

    • In section one of "To create a ControlTemplate for a button," your control template needs to include a TargetType attribute set to Button.
    • In section two of "To create a ControlTemplate for a button," name your grid "RootElement" rather than "ELEMENT_Root", as the instructions tell you to do.
    • Section two of "To specify the appearance of the control" instructs you to Add the following elements after the closing </Grid.Resources> tag, at the comment "Add the elements that specify appearance here." 
    • It ought to read Add the following elements after the closing </Grid.Resources> tag, at the comment "Add child FrameworkElement objects here." 

    C. Creating Custom Controls for Silverlight — an eye opening walkthrough.  We create a custom Silverlight control by first creating a standard class that inherits from Control, and a separate XML file with an xaml estension.  XML file is aware of the control class, but the control class knows nothing about the XAML file.  We reuse some of the ContentTemplate techniques from the previous QuickStart to give form to our Silverlight custom control.  Here are some minor issues with the walkthrough:

    • Be sure to add the following using declaration to your control class: using System.Windows.Controls.Primitives;
    • You need to understand Dependency Properties in order to get the most out of this walkthrough.  The article provides a dead link to the MSDN article on Dependency Properties.  It should have linked here, instead.
    • Dependency Properties are a cool concept.  For the most part, they are like property bags, except with special Silverlight hooks.  The terminology, however, is either not fully worked out, or just ill-conceived.  Here’s a sample definition of a dependency property, from MSDN:
    • Dependency property: A property that is backed by a DependencyProperty.  (Oh really?)
    • The tutorial has you start using a Background attribute in your ContentTemplate without first having you add it to your custom class.  You need to add this to your class in order to avoid a runtime exception:

    public static readonly DependencyProperty BackgroundProperty =
    DependencyProperty.Register("Background", typeof(Brush), typeof(NumericUpDown),
                    null);

    public Brush Background
    {
        get { return (Brush)GetValue(BackgroundProperty); }
        set { SetValue(BackgroundProperty, value); }
    }

    D. Displaying a Splash Screen While Loading a Silverlight-Based Application — this QuickStart seems to work.  I actually can’t completely tell what’s happening in the walkthrough, though it seems like it will make a great reference if I ever need to customize a splash screen.

    • E. Working with Data Collections in Silverlight — this useful QuickStart explains data binding and the DataTemplate.  No obvious errors, but a few lacunae.

    • Life will go much easier if you name your project Quickstart_Bookstore.
    • The ObservableCollection type belongs to the namespace System.Collections.ObjectModel.

    Learning Silverlight: Day Two

    James Ashley

    hms_victory 

    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.

    Learning Silverlight: Day One

    James Ashley

    cuttysark

    ‘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.

    Resolutions

    James Ashley2 Comments

    Friedrich.Wanderer Above the Sea of Fog

    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."

    Waterfall and Polygamy

    James Ashley1 Comment

    polygamy

    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.