February 2010 - Posts
In my MSN Messenger today, a one-line text advertisement proudly proclaims
“<product XYZ> is now fair trade”.
I suppose the maxim “better late than never” applies, but what a shame they waited until consumer pressure shamed them into that decision. Why wasn’t the product always fair trade? The company that _I_ want to spend my money with is the one that can say “our products have always been fair trade”. Integrity is what you do when no-one is looking. My friend Dan Goddard taught me that. Sometimes, doing the right thing hurts you. Those companies that can still do the right thing even when it hurts them are the ones I want to do business with.
On Monday 21st February, I’m giving a live demo to some local entrepreneurs and academics to show how, for me, Windows Live Writer has revolutionised blogging.
Some of the topics I’ll cover and expand upon during the demo are:
My Approach to Blogging
-
Visual appeal trumps content (but the content must still be worth reading!)
Compare these examples. Which one makes you want to stay on the page?
http://msmvps.com/blogs/chrisl/default.aspx
http://community.tigranetworks.co.uk/blogs/TiGraNetworks/
-
Link as much as possible. “Givers Gain”
-
Have something to say. Don’t just blog to keep to a schedule.
What is Windows Live Writer
Live Writer is a tool that makes it easy to create and manage blog content accross multiple blogs and service providers.
Setting Up Live Writer [Demo - G-Blog]
Multiple accounts
Live Writer can manage multiple accounts on multiple blog providers. It’s easy to cross-post content or to switch content between blogs.
4. Editing a Post
Linking: Why link to other blogs?
When you link to another blog, this creates a TrackBack on that blog, which links back to your blog. This will enable more people to find your content and will help the search rank of both sites.
Auto-linking
Live Writer has good support for auto-linking and lets you build up a glossary of common links. One obvious use for this is to link to your company web site whenever its name is mentioned in the blog. This is a big time saver and makes sure you link back to your company web site.
Images
Images make blogs interesting. Pages of text are boring. Live Writer has fantastic support for images. Use the Screen Snipping tool (built into Windows Vista and Windows 7) to capture images from the web.
Demo – Screen Snipping and Image Formatting
Views – Edit/Preview/Source
Live Writer shows you exactly what your blog post will look like – before you post it. Handy for tweaking to get that final polished look.
Save Draft
Demo - Save local draft / Save draft to blog
As you do more and more blogging, the ideas start to come, but you don;t always have time to complete a finished article. Save part-completed articles as drafts and come back to them later.
Plug-ins
Live Writer has some built-in plug-ins and many third party plug-ins available, for embedding multimedia and specialist content. Two examples, are the Live Photo Gallery plug-in and the Bing Maps plug-in, as shown here:
GTi Suite, Valleys Innovation Centre
Have you been following this fascinating series on BBC 2? It examines some of the social and cultural repercussions of one of mankind’s greatest achievements – and it’s not all good! Today, I find it quite impossible to imagine life without The Internet, yet only 20 years ago, I had never even heard of it.
The BBC’s web site has some detailed background information and the episodes are available in a 3D series explorer interactive. There’s a blog, too.
There’s an interactive experiment that you can participate in to find out what sort of ‘web animal’ you are; in other words, what are the characteristics of your online behaviour. I’m a ‘Web Elephant’ which means:
Slow-moving - Web Elephants like you browse the internet at a stately, methodical pace - just like real-world elephants who rarely see a reason to rush things.
Social - Real-world elephants and Web Elephants are both highly social. Real elephants are able to keep track of their own extended family trees and may even mourn love ones. As a Web Elephant, you often use social networking sites to keep track of your friends of family and are happy to rely on information from sites whose content is created by its users.
Adaptable - Real-world elephants owe their adaptability to their large brains and versatile trunks. As a Web Elephant you are similarly adaptable and are well-suited to carrying out several different tasks at the same time.
Find out your web animal at the BBC Lab UK web site and share your results on facebook.
It never ceases to surprise me when doing software development, how quickly you can get into territory that very few people seem to have explored, making it difficult to troubleshoot problems. I’ve wasted the best part of a day on an SSL problem. I need to make requests from a web server that insists on SSL, but which has a self-issued certificate, i.e. it is not in my computer’s trusted certificate list. You’d think this was a really common situation that many people would have encountered, but the breadcrumb trail in the net says otherwise. This is what separates a professional software engineer from an amateur – at this point the amateur would probably give up, or put a horrendous hack into the code.
When making the request, the underlying protocol stack bubbles up the following exception:
It seems that System.Net.WebClient (or rather, its underlying protocol stack) has a default policy not to accept self-signed certificates. This is the same situation in Internet Explorer where you get the certificate warning and then the red address bar.
There’s no obvious way to override this behaviour and the solution is not obvious. Here’s what you need. First, implement a method that is responsible for validating X.509 certificates. My method simply returns True, which means it accepts all certificates, no matter what. You might need to be a bit more selective in your situation:
/// <summary>
/// Implements an SSL Certificate Policy for this application.
/// </summary>
class CertificatePolicy
{
internal static bool ValidateSSLCertificate(object sender, X509Certificate certificate,
X509Chain chain, SslPolicyErrors sslPolicyErrors)
{
return true; // All certificates are considered valid, no matter what.
}
}
Next, your application needs to ‘wire up’ this method so it will be called any time an SSL certificate needs to be validated. This obviously must be done before attempting to make any web requests. I chose to do this in my Main method.
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
System.Net.ServicePointManager.ServerCertificateValidationCallback
= CertificatePolicy.ValidateSSLCertificate;
Application.Run(new Form1());
}
And that’s it. Self-signed SSL certificates will now be accepted. Easy when you know how!
For best compatibility, ASCOM drivers and applications developed with .NET languages should target 'Any CPU'.
Some background facts.
- 32-bit processes can run on a 64-bit system.
- 32-bit processes can call into 64-bit code.
- 64-bit processes cannot call into 32-bit code.
- .NET assemblies compiled as 'x86' can only run in 32-bit processes.
- .NET assemblies compiled as 'x64' can only run in 64-bit processes.
- .NET assemblies compiled as 'Any CPU' are JIT-compiled into the 'bitness' of their host process (not necessarily the machine architecture).
- Visual Studio (including 2010) is a 32-bit process. It can debug 64-bit applications but with some limitations.
Truth Table: Where can an assembly execute?
The only scenario that guarantees 100% compatibility is: 'Any CPU'.
There may be a temptation to think that compiling an assembly (ASCOM driver) as 'x86' means that it can run on any system. In fact, most of the time that will be true, but as soon as there is a 64-bit host process then the driver will fail.
On 64-bit systems, by default, 64-bit host processes include: Windows Scripting Host (VBScript/JScript). To see this in action, compile your driver for 'x86' then try to script it on a 64-bit system. Your driver will fail to load.
Development and Debugging in Visual Studio
The above advice notwithstanding, during development you'll face a different set of problems. Visual Studio is a 32-bit process so when it builds and registers your projects for COM Interop, it will do so as a 32-bit process. This means your driver will not operate correctly as a 64-bit driver on your development system. There are also some restrictions on debugging 64-bit processes, for example 'edit and continue' doesn't work. I put this situation to Scott Guthrie and his recommendation was to develop and debug in 32-bit mode. He mentioned that in Visual Studio 2010 the same situation exists and they changed the default project settings to 'x86' for that very reason.
The solution I've used is to create multiple configurations in Visual Studio. My Debug configuration builds in 'x86' mode and my Release configuration builds in 'Any CPU' mode. There are lots of permutations but those would be the minimum.
I’ve had a miserable experience with RSS feeds in Outlook. There are feeds (suc as those from teh Stack Overflow Trilogy sites) that I just know should update at least every few minutes, yet Outlook often takes an hour or more to show any changes. Today after an email exchange with Jeff Atwood (@CodingHorror) I think I’ve finally figured out what is going on.
Right, here’s what I think is happening. When a feed is added to Outlook, the default settings (which are hidden under the ‘Advanced’ button) are to use the publisher update recommendations.The publisher of the feed can specify a Time To Live setting, this is the time that content is expected to remain cached before it is refreshed. Outlook interprets this setting as the minimum update interval. Outlook will not check a feed for new content more often than this minimum interval.
The <ttl> element is optional and some feeds (such as those from teh Stack Trilogy) don’t contain it. When Outlook doesn’t find a <ttl>, everything defaults to 60 minutes. So in this default situation, Outlook will check for updates at most once per hour.
To avoid this default one-hour situation, it is necessary to instruct Outlook to ignore the publisher’s recommendations (even though the publisher hasn’t made any explicit recommendations, the absence of a recommendation implies a 60-minute update cycle by default). To do this, when adding the feed to Outlook, click the Advanced button and uncheck the box outlined in red in the screen shot above. Note the yellow highlighted text indicates that the publisher has not specified an update policy.
Unticking that box does allow faster updates, but there is another wrinkle. We;ve removed the minimum interval, but the default settings for the Send & Receive Groups is 30 minutes. So even when the minimum TTL is lowered to 5 minutes, Outlook still will not even try to check more often than every 30 minutes; this is the default setting of the default Send & Receive Group. So, to get full control, it is necessary to uncheck the “Use publisher’s recommendation” box, AND to create a custom Send & Receive group (or modify the settings of the default group). I don’t recommend modifying the default group.
So, create a new Send & Receive group and in its properties, select the RSS feeds that you want to update at the higher rate.
The screen shot above shows my Server Fault RSS feed being prepared for updates every 5 minutes.