Random Disconnected Diatribes of a p&p Documentation Engineer
There's a well known saying that goes something like "Please engage brain before shifting mouth into gear". And another that says "If you can't stand the heat, get out of the kitchen". Yet, after what's now more than a year as a fulltime 'Softie, I've managed to avoid being flamed for any of my weekly diatribes; and neither has anybody pointed out (at least within earshot) how stupid I am. So I suppose it's time to remedy that situation. This week I'm going to throw caution to the winds and trample wildly across the green and pleasant pastures of generics, and all without a safety net.
OK, I'll admit that it's probably not going to be a hugely technical venture, so if you are expecting to see lots of indecipherable code and complex derivations of generic functionality, you're likely to be disappointed. You might as well get your email client warmed up now ready to fire off some nicely toasted opinions. I mean, it's not like I actually know much about generic programming anyway. No, where I'm going with this is more slanted towards the requirements of my daily tasks - the terminology.
You see, I'm of the opinion that when I write technical documents, they should be comprehensive enough to ensure that readers can follow the topic without having to dive off and consult an encyclopedia or dictionary every five minutes. While I don't want to reduce it to the "grandmother sucking eggs" level, which would just be boring to average developers and probably excruciatingly useless to the really clever people out there, I do need to make it reasonably comprehensive and self-sufficient. I mean, I really hate it when I'm reading something and have to keep stopping and re-reading bits to try and figure out exactly what the writer actually meant.
You've probably been through this process, where you come across what seems like a simple word but the meaning in the current context is not familiar. The person who wrote it probably knows the topic inside out, and so the meaning is obvious to them. Yet not grasping what it really indicates in terms of the surrounding text can make the rest of the article pretty much meaningless. You need to know the topic before you can understand the bits that will help you to learn about it. Like: "Ensure you check the reverse osmosis defractor for discompulation before remounting the encapsulator". Does that mean you need to buy a new one if it's gone rusty? Who knows...
Anyway, getting back to generics, I recently seem to have stirred up a discussion about the meaning of three fairly ordinary words without really trying. In fact, I suspect I've put our current project back by a week as all of the brains-the-size-of-a-planet people on the dev team try and figure out exactly which words mean what, and how we should use them. So what are these three amazingly complicated and unfathomable words? Would you believe "unbound", "open", and "closed". In fact, you can throw in "constructed" as well if you like.
These are the definitions according to Microsoft's Glossary of .NET Framework terminology (see http://msdn.microsoft.com/en-us/library/6c701b8w(VS.80).aspx):
It seems that most folks agree that a generic type can be unbound or constructed, and a constructed type can be open or closed. Microsoft seem a little shy about defining what an unbound generic type is, though in the Generics FAQ they mention that "the typeof operator can operate on unbound generic types (generic types that do not yet have specific type arguments)". And there are plenty of definitions elsewhere that firmly identify it as being a generic type where the types of the type parameters are not defined.
Meanwhile, it seems like most people also agree on what a "closed" type is, so the main issue is: what's the difference between an "unbound" and an "open" generic type. If an open type is also a "constructed" type, does that mean that it has the type arguments actually populated - even though the code that's executing to achieve this only contains the placeholders? Or does "constructed" in the realm of generics mean something other than the more usual "built" or "assembled"? Does a generic type start out as "unbound" and then, as it becomes "constructed", does it move through "open" to "closed"?
Perhaps there is a nanosecond or two, as the electrons fight their way through the layers of silicon in the CPU constructing and closing the type, that it's no longer unbound, but not quite closed yet? Smacks of Heisenberg's Theory of Uncertainty and Schrodinger's cat if you ask me. Maybe it's all wrapped up in particle and wave theory. Or could it be that unbound types don't actually exist at all? Maybe, as they aren't actually instantiated "things", they only exist in an ethereal context; or they only exist when you aren't looking at them. I suppose that, as the only thing you can instantiate is a closed type, we don't actually need to worry about the other types anyway.
Trouble is, when working with a dependency injection mechanism (like what I'm doing now, as Ernie Wise would have said) you need to discuss registering types and type mappings for generic types that do not have all of the type arguments fully defined as concrete types. So we're trying to decide if these registrations are for "unbound" types or "open" types. When you define a registration or mapping in a configuration file, you use the .NET Framework type name without specifying the type parameters or type arguments; for example MyApps.MyTypes.MyGenericType`2 (where the "back-tick" and number define the number of type parameters in the type). When you use code to perform the registration, you also omit the type parameters; for example RegisterType(typeof(MyTypes.IMyInterface<,>)). As you saw earlier, Microsoft says that "the typeof operator can operate on unbound generic types (generic types that do not yet have specific type arguments)", and these sure look like they don't yet have specific type arguments.
But could these registrations really be "open" rather than "unbound"? All the definitions of "open" talk about the types of the type arguments being provided by "an enclosing generic type or method". When I'm just creating a type registration, how can the type parameters be populated from an enclosing type? If I'm registering the generic child of a parent type, I can't specify what (who?) the parent will be. If I'm registering the parent, I can't prevent somebody adding a class that has a different child. And I can't register a method at all. So there is no way I can specify where the type arguments will come from.
The problem is that almost everything else I read about using dependency injection mechanisms talks about only "open" and "closed" types. It's like "unbound" types are unclean, or unattractive, or maybe just not worthy of use in a shiny new container. Perhaps it's a conspiracy, and we'll discover that NASA actually buried them all in the Nevada desert so they can't be used to confuse clever programmers. And if I talk about unbound type registrations in my documentation, will people just make those "phhhhh" noises and toss it aside with a comment such as "...obviously doesn't have any idea what he's talking about...", "...waste of time reading that...", and "...who let him out again...?"
Or, could it be that I'm the only one who knows the truth...?
A great many years ago, when I was fresh out of school and learning to be a salesman, we had a sales manager who proudly advertised that his office door was "always open". What he meant, obviously, was that we could drop in any time with questions, problems, and for advice on any sales-related issue that might arise. Forgotten what step five of "the seven steps to making a sale" is? Having problems framing your "double-positive questions"? Struggling to find "a response to overcome an objection"? Just sail in through that ever-open door and fire away. Except that the only response you ever got from him was "...you can always rely on one end of a swimming pool".
Now, I was young and a bit damp behind the ears in those days - and probably not the sharpest knife in the box. So it was several months before I finally plucked up the courage to ask one of the older and more experienced members of our team what he actually meant. "Simple", said my wise colleague, "he means that you can always depend on a 'depend' (i.e. deep end). In other words, no matter what the question or situation, you can usually get the upper hand by prevaricating".
I guess you only need to watch politicians on TV to understand that they all take advantage of this rule. But, strangely enough (and I don't want to give too many precious retailing secrets away here), it can be remarkably useful. Imagine the scene: your customer can't make up their mind about some particular type of plant food (OK, so I was working in the horticultural trade in those days). They ask "Will it be safe to use on my prize Dahlias?" You answer "Well I was talking to a chap last week who managed to grow double his usual crop of tomatoes!" Notice that I didn't say he was using any product he might have purchased from me, or that he actually used any fertilizer at all. Such is the power of vagueness...
All I need do now is overcome the objection, and toss in a double-positive question: "I'm sure that the quality and the results you'll get will be far more important to you than the exceptionally low price we're offering it at this week", and "Shall I wrap it up for you to take away, or would you like us to deliver it tomorrow morning?" Amazing - seems I haven't lost the touch.
So, having regaled you with rambling reminiscences for the last ten minutes, I probably need to try and drift back on-topic. Or, at least, to within striking distance. What prompted all this was reading the preface to our new Microsoft Application Architecture Guide 2nd Edition. In it, David Hill explains that you can always tell an architect because their answer to any question is invariably "it depends". He doesn't say if this behavior extends to things like "Can I get you a coffee?" or "Would you like a salary raise?", but I'll assume he is generally referring to architectural design topics.
And, even though I'm not an architect (INAA?), I can see what he means. In the section on validation, for example, it quite clearly states that you should always validate input received from users. Makes a lot of sense. But what about if you have a layered application and you want to pass the data back from the presentation layer to the business layer or data layer? Should you validate it at the layer boundary? Well, it depends on whether you trust the presentation layer. You do? Well it also depends on whether any other applications will reuse the business layer. Ever. And it depends if you have a domain model, and if the entities contain their own validation code. And then it starts to talk about how you do the validation, depending on what you are validating and the rules you want to apply.
You see, I thought at the start of this project that I could just learn the contents of the guide and instantly become "a proper architect". It's not likely to happen. What it does show is that, yes, you need to know the process, the important factors, and techniques that will help you to perform analysis and make good decisions about structure and design. And you need to understand about conflicting requirements, quality attributes, and crosscutting concerns. You have to understand the types of applications, and their individual advantages and liabilities. In fact, there is an almost endless stream of things that you could learn to help you "do architecture".
And that, it seems, is where the guide really comes into its own. It explains the process and the important elements of design. It lists the vital requirements, and provides guidelines to help you make decisions. It tells you what to look for, where to look, and where to find out more. It even contains detailed references to things like components, layers, tiers, technologies, and design patterns (see http://msdn.microsoft.com/en-gb/library/dd673617.aspx).
And, at almost every step, it proudly flaunts its "it depends" approach. Architecture is not, it seems, about learning rules. It's learning about software and applications, environments and infrastructure, requirements and conflicts, people and processes, techniques and technologies, and - best of all - having your say in how a small part of our technological world behaves. So, come on in - the water's lovely...
Suddenly, here at chez Derbyshire, it's 1996 again all over again. Instead of spending my days creating electronic guidance and online documentation in its wealth of different formats and styles, I'm back to writing real books. Ones that will be printed on paper and may even have unflattering photos of me on the back. And there'll be professional people doing the layout and creating the schematics. It's almost like I've got a real job again. I'll be able to do that "move all your books to the front of the shelf" thing in all the book stores I visit, and look imploringly at people at conferences hoping they'll ask me to sign their copy.
The reason is that we're producing a range (the actual number depends on how fast I can write) of books about the forthcoming version of Enterprise Library. I've been tasked with creating books that help people get to know EntLib and Unity, and get started using them in their architectural designs and application implementations. So the list of requirements includes making the books easy and enjoyable to read, simple enough to guide new users into understanding the basic features and their usage, deep enough to satisfy "average" developers who want to know more and learn best practices, and comprehensive enough to cover all of the major features that take over 1000 pages to describe in the online documentation.
They say that a job's not worth doing if it doesn't offer a challenge, so I guess this job is definitely on the "worth doing" list. And getting it all into books of about 250 pages will certainly be interesting as well as challenging. Maybe I can write very small, or use "txt speak". Need help using the Message Queuing feature of the Logging block? How about: "2 cre8 a msg q u use mmc & put name in cfg file thn cre8 logentry & snd. 2 c if it wrkd look in q". I can see my editor and proofreader having no end of fun with that approach.
But the hardest bit was actually deciding how (and whether) to provide sample code. Its likely there won't be room to print complete listings of all the code I use, which is probably an advantage in that readers can see and concentrate on the actual bits that are important. Of course, I need to build some examples to make sure what I'm writing actually does do what it's supposed to. So it seems sensible to offer the code to readers as well, like they do with most other programming books. But how should I present the code? As a pretty application with nice graphics and a delectable user interface? Maybe be all up to date by using WPF?
I remember when I first started writing books about "Active Server Pages" how we had no end of problems creating sample code that users could easily install and run. There was no SQL Server Express with its auto-attach databases mechanism, no built-in Web Server in Visual InterDev (this was the days before Visual Studio as we know it now), and you couldn't even assume that users had a permanent Internet connection (the vast majority were on a dial-up connection). So you had to create complicated sets of scripts and a setup routine, even for ASP samples, that registered the components you needed and populated the database, as well as providing a long list of prerequisites.
But things are much easier now. You can give people a zip file that they can just unzip and run. Even Windows Forms and WPF samples just work "out of the box". So, even though I haven't done much with WPF before, I thought I'd give it a try. I was doing OK with creating the form and adding some text and buttons, but then it came to adding a DataGrid. I thought maybe they'd forgotten to include it in the version of Visual Studio I'm using, but it seems that I wasn't prepared for the Wonderfully Perverse Features of WPF where you need to use Grids and ListViews and tons of stuff inside each one, then fight with Data Contexts and Binding Paths.
In ASP.NET I just grab a GridView and drop it onto the page. So should I do the samples as an ASP.NET application? That adds complexity with postbacks and maintaining state, and makes it hard to show some features such as asynchronous data access or cache scavenging. And it hides the real functionality that I want to show. Besides which, EntLib is really a library for helping you manage your crosscutting concerns, not a development environment for Web sites. How about Silverlight? Well, then I'm faced with a combination of the issues from WPF and ASP.NET. Maybe I should just take the easy way out and use Windows Forms. As a technology, I know it well and it provides all the features I need to create glorious user interfaces.
And then I remembered how long I've been writing code. Back in the early 80's, an attractive and intuitive user interface was one where you had a text menu on an 80 characters by 26 lines screen, and you could press any key you liked as long as it was one of those in the list. No need to mess about with sissy things like mice or trackballs, and no confusion about which things to click or where to wave your mouse pointer to see what things did. You knew where you were with applications in those days. And there's plenty of interest now in the old stuff such as text-based adventures and simple chunky graphic games like Asteroids and Space Invaders.
So why not follow the trend? Simple example applications that run in a Console window, have simple menus to select the specific sample you want to run, and use simple code to display progress and the results of the process. No need to run Visual Studio, the database will auto-attach to SQL Server Express, and readers can easily find the appropriate code in a single "Program" file if they want to read it all. In fact, I've seen this approach used by the guys from the data team here at Microsoft when they do presentations, and it really does seem to make it easier to see what's going on.
So that's where I'm going at the moment, at least until somebody else makes an alternative "executive decision" further down the line. What do you reckon? Do you want fancy interfaces for your code samples? Or are simple Console applications that focus on the "working parts" more useful and easier to understand? How about this for a flash-back to the past:
Or I suppose I could just publish the code as text files...
Oh well, back to work, holidays over for another year. At least I managed to morph from a sickly shade of pale to a faint shade of tan, and without catching airplane 'flu or any other weird tropical disease (at least not one that's shown up so far). In fact, it was one of the most hassle-free and relaxing holidays we've had. I even managed to forego the doubtful pleasure of email for a whole six days without caving in and searching for an Internet cafe.
Mind you, arriving home and deciding I should try to catch up with the mountain of emails that arrived while I was away was an interesting experience. It seems that my mailbox was upgraded to Exchange Server 2010 while I was away. While it doesn't affect using Outlook over HTTP, I'm battling vainly against the new version of Outlook Web Access. It seems to rummage around and collect every email it can find that vaguely corresponds to the one I'm trying to read, and then hides them all away in a tree view that you have to double-click to see the actual messages.
I suppose it's useful having all of the related messages collected together, even if it includes ones I sent, and even ones I've deleted (helpfully shown crossed out in the tree view). But I reckon it's going to take me a good while to get used to this approach. I spent the first ten minutes trying to figure out how to delete a collection of different emails - it seems like you can't just highlight them all and press delete any more.
And I can't find any options to go back to the old way either - in fact it took ages to find the option where I could turn off Out of Office Replies (which are now called "Tell people you're on vacation"). Maybe I'll just leave them turned on for good so I don't have to fight with OWA very often. Or just do what I ended up doing the evening when we got home and I was too tired to try and understand the new approach - use the cut-down "OWA Light" version instead. It's much like Hotmail (sorry, Windows Live Mail) - it just works like you'd expect.
Aha! (added later) I just found out you need click the little arrow next to "Arrange by" and uncheck "Conversation".
Anyway, getting back to last week's trip, I still haven't figured why it all went so smoothly compared to the usual hassle of traveling anywhere by plane. Yes, we did have to set off for the airport at 3:00 AM; but it's nearby, parking close to the terminal was easy, the check-in queue consisted of two people, there was time for a leisurely coffee, and then through security in less than ten minutes. Half an hour in departures chatting to people we know who happened to be on the same flight, then in the air fifteen minutes ahead (!) of schedule and arrival in Malta half an hour early.
With our taxi waiting at the airport, we were at the hotel within half an hour and ready to hit the beach! And it was just as easy coming home. Meanwhile, Malta is easy because they have real 250 volt electricity with UK-style sockets, and they drive on the proper side of the road (the left). Plus, all of the roads have meaningful road signs, even if every road you go down seems to take you back to the capital Valletta. Although the concept of giving way to others, even when they have priority, is more an option than a rule. I liked that all the roundabouts have a sign saying "Please obey the roundabout rules". I guess everyone does, in a roundabout way.
We did borrow a sat-nav with the rental car, and I'm really glad I didn't buy one like it. The helpful lady inside it had a habit of reading out the directions one turn early, then suddenly screaming "Turn left, turn left, turn left" just after you passed the junction (even when you should have turned right). I think the one word we heard most over the whole week was "Recalculating". Of course, it didn't help that the paper map of the island we were using to decide where to go contained English place names, while the sat-nav only had the Maltese equivalents. She even directed us up one street that started out about a foot wider that the car and then got even narrower, culminating in a right-angle turn. I got a lot of reversing practice during the week.
But if you are looking for somewhere relatively peaceful, pleasant, and full of history, Malta is worth a visit. Go in Spring or Autumn unless you like being burned alive, and - if you don't fancy driving - use the hop-on hop-off tour buses to see the sights. There are some lovely beaches, fabulous views, wonderful cathedrals and churches, a Roman villa, and an amazing walled city (Mdina) to see. It is a bit barren in places, and not the tidiest or best-maintained place I've ever been, but - hey - this is the Mediterranean. And everyone, everywhere, speaks good English. Here's some photos:
And, yes, I did find the house where I lived more than 40 years ago and even got to talk to the daughter of the guy who owned it back then! Meanwhile, I suspect we'll never be able to go on holiday again because it will never be this easy in future.
If all goes according to plan, I should be spread-eagled in a sun lounger on a foreign beach as you read this, with a copy of some second-rate espionage novel in one hand and a large and very cold beer in the other. Maybe even nodding to the passing waiter to bring another plate of canapés and a bowl of ready-peeled grapes, or passing the time of day with famous celebrities as they stroll slowly past splashing their feet in the warm clear blue water of the Mediterranean. I mean, we did book a really nice hotel; though - looking now at some photos posted on the Web by previous visitors of the construction site next door to it and the dilapidated street of half-demolished houses round the back - I'm not so sure.
But, still, it will be a break from the hectic document engineering thing I do all the rest of the time. Having finally got round to taking a holiday this year, we decided on a week in Malta - somewhere we've been planning to go for some years. When I was young, we lived there for four years (my father was in the Royal Air Force) and it will be interesting to see how it's changed. Some friends who went there a few years ago set me a postcard of their hotel on the cliff at Golden Bay, pretty much where I remember there being a military firing range. We kids regularly used to dig up clips of shells on the beach below, to the horror of our parents. I wonder if the tin shack with its cool box full of ice-cream (the only facility on the beach at the time) is still there. I doubt it.
To save the hassle of trying to coordinate flights and stuff, we just booked through a local travel agent. Let them earn their commission by doing all the hard work. But what's amazing is the volume of paperwork and the apparent complexity of organizing it all. When I book a trip to Redmond, I get a single PDF through email that contains all of the details of the flight, hotel, rental car, and other stuff. So far (and we hadn’t actually departed when I was writing this post) I've had over 40 pages of stuff from the travel agent for this trip. I've signed seven forms, and paid three different amounts on my credit card. There's so much bumph that they even send you a nice hard-backed folder to keep it all in. I wonder how much all that costs?
And when I fly to Redmond, I just need to turn up at check-in and wave my passport. This trip, I've got at least three pieces of paper that list all the documents I need to have ready just to check in. They include a 24 page booklet that contains flight coupons, details of the hotel, accommodation terms, flight times and destination information, health warnings, travel advice, and - best of all - two vouchers for a free drink on the plane. I especially like that these have a picture of two intertwined champagne glasses on the front, and a stern warning on the back that they are "not valid for alcoholic drinks, including champagne".
It also says I have to fill in a form with my name and home address, and the address of the place we'll be staying in Malta. Of course, they posted the form to me at my home address, and helpfully sent it along with a confirmation of the destination hotel address. You begin to wonder if it would have been less hassle just doing it all through Expedia from the start. Mind you, I was reading this week about a new ruling from the People's Republic of Europe that says if you are ill while on holiday, you can claim back your holiday and take it later. As you can generally rely on picking up some variation of airplane flu while travelling, maybe I'll be able to stay there until Christmas. They say the weather is nice there in the autumn.
Despite being a writer by profession, and regularly castigating my colleagues for being recalcitrant in reviewing stuff I write, I actually dislike doing reviews myself. When I was an independent author (before I signed my life away to Microsoft), I was often approach by companies offering to pay me to write reviews of their products for their Web sites and literature. Even taking into account the presumed integrity of the author, this type of review seems somehow to be tainted when compared to an independent review by someone who doesn't stand to gain from it.
Yet I depend on reviews and reviewers, of both the technical and editorial kind, not only as part of my daily job creating guidance, but also when buying stuff generally. If I'm looking to buy a new ADSL modem or NAS drive, I'm likely to check out the reviews from real users to see if the one I fancy (the product not the reviewer) is actually any good. A typical example is when recently researching mobile Internet connection dongles and packages (which, from the majority of reviews, all seem to be equally useless). If I'm looking to buy a book, I'll read the independent reviews from readers. Only when I'm buying something as personal as music do I tend to avoid being swayed by the opinions of others. But that's mainly because, underneath this suave and intellectual exterior (?), I'm really still a heavy metal fanatic with a weird taste in classic rock music.
So I always feel that I should do my bit by contributing reviews where I think I can add some useful feedback to the discussion. And there's no point in writing a review unless you tell the truth. OK, so my blog is not generally known for being exceptionally high in factual content, but I do try very hard to be fair and even handed. So, let me start by saying that the latest book I've been reading is not actually bad - in fact, in general, it's well-written, informative, useful, and I didn't find any glaring errors in it.
And as you are obviously now waiting for the "but", here is comes. I bought "Accelerated VB 2008" (APress, ISBN 1590598741) based on reviews and the publisher's blurb in order to provide the equivalent training for VB as I undertook with Jon Skeet's "C# In Depth" book (see Syntactic Strain). According to the aforementioned blurb, it covers precisely what you need to know to use VB 2008 (a.k.a. VB 9.0) and .NET 3.5 effectively. This includes the newer and more advanced features such as generics, operator overloading, anonymous methods, and exception management techniques. And a whole paragraph of the description talks about the coverage of LINQ, extension methods, lambda expressions, and other VB 9.0 features.
Yes, the book covers these. But the really new and exciting stuff only gets a very brief summary in the introduction (5 pages), and just the final chapter of 43 pages. And the new topics I'm interested in get about a page each, yet there are 14 pages on using LINQ with XML. It's not that the VB 9.0 stuff isn't covered at all, but it certainly feels like it was added as an afterthought. OK, so there is a whole chapter earlier in the book devoted to generics, which is really quite good, and there is certainly adequate coverage of other VB 8.0 features. But it feels like the book is actually "Accelerated VB 2005 updated to VB 2008". And having been an independent author in a previous life I know that this is what happens. As soon as a new version of a product is announced, the publisher is hounding you to update your previous book to the new version. In three months. And without them paying you much money.
I guess this is the core difference between the two books I've been using. "C# In Depth" feels like it's telling you a story, and the features of the versions of the languages are partially intertwined throughout so you understand how each addition to the languages serves a specific purpose and simplifies or extends previous features. "Accelerated VB 2008" feels more like a tutorial that aims to cover advanced uses of Visual Basic without really explaining the evolution and purpose of the language. For example, there's a whole 45 page chapter devoted to threading, which seems to me to be a feature of the .NET Framework rather than a feature of Visual Basic.
Perhaps I expected something different because I was looking for a book that covered the new language features in depth, whereas "Accelerated VB 2008" feels more like it is aimed at bringing VB programmers who basically still write like they are using VBScript into the real world. But it surfaces issues that I suppose I always recognized are part of the overarching view of programmers and programming languages (at least in the Microsoft world). It's like VB programmers have to be protected from reality; and must always be reminded how you define a class, use an interface, and handle exceptions - irrespective of the "advancedness" of the book.
Again, I must repeat that this is not a bad book. It is really quite good, and will be a useful addition to the Visual Basic programmer's library - especially if (like me) you are still a bit vague about generics, delegates, lambdas, and similar topics. It also helped me more clearly see how the process of creating and updating documentation is a lot harder than it may at first seem. When I work on updates to the guidance for new versions of our deliverables here at p&p (such as Enterprise Library) I try really hard to interweave the new features with the existing content. In the previous two versions, for example, we've completely reordered the sections and topics, added new overviews and "how to" sections, and modified the structure to give the new features the appropriate precedence alongside the existing ones. And it really can be tough to do when there's already over 1,000 pages of it.
And while Jon's "C# in Depth" book did wind me up with its repeated use of the term "syntactic sugar", "Accelerated VB 2008" also has one overarching feature that I found extremely annoying. Like so many other books, they insist on printing complete listings of the example code, even when it covers two or more pages, with the explanation only at the end of the listing. The result is much page flipping to understand what's going on. But worst of all, when there is a minor change to one line of code to illustrate a feature of the language, they print the entire code again with no highlighted line or indication of where the change is until you read the text after the listing. After a while I started just believing what the text said because it seemed too much effort to go back and try and find the changed line.
So here's a challenge. Is there a book out there that covers the language features of Visual Basic 8.0 and 9.0 without describing how to declare variables, write a class, handle exceptions, and interact with the basic .NET Framework classes? One that explains in detail how features such as extensions, lambdas, LINQ, and generics work, and which makes it easy to understand their purpose and usage? Or am I just expecting publishers to commission books that focus only on stuff that I've been to idle to learn about so far? Maybe a market sector consisting of one person is not a viable business proposition...
With appropriate acknowledgment to Phil and Kirstie, this week's random blather seems to have evolved with a dislocated theme; and rather more so than is usual in my weekly ramblings. It started with a series of events that made me wonder if I am somehow dislocated from the rest of my corporate employees and the huge organization of which I'm part. Mainly due to some unexpected emails that popped up in my Inbox.
The first was from a company that specializes in providing support for remote workers. I'm not sure if they meant remote as in working in the Outer Hebrides, or just remote as being home-based rather than enjoying your own cubicle or corner of an open plan office. Mind you, at 5,176 miles away from my office (according to KLM airlines, and not taking into account driving to the airport or continental drift) I guess I fit quite neatly into the "remote worker" category. Of course, this was just untargeted junk mail, but the following day I started to get more concerned when I found I'd been joined to one of our new corporate internal mailing lists called the "Remote Employees Group".
It didn't actually say whether the remoteness of employees was associated with a character trait or with physical location, but I'm assuming the latter until I see some emails on the list. Though, as they failed to include the posting email address of the list (the email they sent was a "no reply" one), it might be a while before there's anything useful on there. I have no idea how they actually found me either. I try and keep my head down most of the time, so maybe somebody sneaked on me. Worried I'm not getting enough support for my daily task of sitting in front of a computer writing stuff about enterprise application design. Perhaps they'll send me a life. Probably as a zip file.
It seems I'm also dislocated from my new Internet provider, as you may have inferred from last week's diatribe. Not dislocated in terms of physical connection, but just in terms of them actually accepting that I exist. No amount of contact with their customer services department can seem to unravel the mystery of where my account (if I do have one) resides. Although the fact that they got my name, address, phone number, and email address wrong on the one piece of paper that the fitters left me might somehow be a related factor. Mind you, while the ones and zeros continue to flow, I suppose I shouldn't complain. But I do wonder who is paying the bills.
And how about being dislocated from my hard disk? I reckon I've discovered how software companies force you to upgrade stuff. When I joined the brave new world of SATA drives and Vista a while ago, I discovered that my disk backup imaging software (Acronis True Image 6.0) couldn't read these drives, so I had to upgrade to version 10. But this doesn't recognize the hard disk in our new Media Center box, so I've had to upgrade again to the "2009" version. I wonder what is different about the SATA disk in this box that means I need the new version. Maybe it just looks at the earliest file dates on the disk and decides it's time I paid them some more money.
Though at around $50 it is a cheap solution compared to upgrading to Vista Ultimate just to be able to do disk images, and - more than anything - I trust it to actually do what I want. I managed to restore the old Media Center O/S with it more than once from saved disk images, and used it when replacing the boot drive in another machine. And a neat trick in the new version is that you can tell it to omit specific file types from the image it generates. So I don't have to include all the saved TV programs that Media Center stores in the Public Users folder. Otherwise the image process would probably take a week.
But, after all that, what really prompted this week's dislocated theme was hearing that a colleague was going into hospital to have his dislocated toe relocated. It sounded an odd term to use, and - as my understanding of the finer nuances of the American language is still somewhat less than comprehensive - I looked up "relocated" in the dictionary. It seems that it means "moved to a new location, such as a different office, building, or city". I suggested he have a word with the surgeons before they start to find out where it will be afterwards...
After what seems like a nightmare week of aggravation, it looks like I'm finally connectivity-wealthy. Downloads take seconds, uploads are relatively quick, and I'm probably even redundant connection-enabled. Though tests of the load-balancing and failover router have exposed some uncertainty around it's operating capabilities. Maybe it's something to do with the fact I bought the $250 one instead of the $1900 one that my colleague (who works for Cisco) recommended. I think he's planning a world cruise, and had his eye on the commission.
Mind you, the LinkSys RV042 is a neat piece of kit. The default setup was easy, though mainly because in my case it just connects to two separate modems (rather than having to handle PPoE or something equally esoteric). When configured to do load balancing, it pings a specified address to determine which connections are available, and shares the load between them - though it sometimes seems a little reluctant to pick up a lost connection when that service comes back up again. I suppose that repeatedly pulling the cables out of the back and plugging them in again confused the system after a while.
TIP: Run a tracert to a Web site to see the IP address of your ISP's host server that you connect to (the first entry after your own router), and use this in the service detection settings. If you point to the default gateway, it may not detect a fault beyond your own modem or router. If you point to your favorite Web site and it goes down, the router will think that the connection has failed.
The only other downside I found so far is that setting up protocol bindings seems to be a hit and miss affair. I wanted to direct all SMTP traffic from my internal server (such as status messages from WSUS, the UPSs, and other bits of kit) through one of the WAN connections and have everything else balanced across both WAN connections, but an hour spent playing with protocol binding rules proved totally futile. The help file is suitably vague about doing something as complicated (?) as this. It does say that you can have up to 100 protocol binding rules, so maybe I just gave up too soon. To be honest, I couldn't be bothered setting up one for every protocol for both connection ports to see if that worked...
Of course, as you can imagine, most of the aggravation this week was not with the router, but with the cable company. So, based on my experiences as a Virgin in this area, and there being No Time Like the present (if you're in the UK, this is a hint as to the cable provider), here's my top ten easy steps to getting cable-enabled:
So, after all that, was it worth the aggravation? The jury is still out on whether they will actually come round to accepting that I do exist, and I'm a little concerned about the technical capabilities of the support people in connection with business issues, but time will tell. But at least there are lots more pretty flickery lights in the server cabinet now. Maybe in December we can drag it into the lounge and save on buying a Christmas tree...