JobServe Labs - Articles

JobServe Job Search iPhone App v2.0 Released

2010-03-11T18:00:00Z

The newest version of JobServe Connect – Job Search is now available on Apple iTunes.Check out the features here and download it here (this link will open iTunes)

Job Search v2.0 to be released very soon

2010-03-09T00:14:00Z

We are pleased to announce that version 2.0 of our successful Job Search iPhone app is to be released very soon. We have listened to all the feedback over the last five months and believe that the new version of the JobServe Connect – Job Search iPhone app will be even more successful. Here on JobServe Labs we would like to give you a preview of what to expect and also a few screenshots of what is to come.

This release contains a major upgrade in new features, suggested updates and fixes.

New Features

Salary search option provided using our two ended slider – be as specific as you need.
Refine your search directly from the search results screen.
Apply for jobs quickly (see below for more details)
Register on JobServe quickly and easily via your iPhone.

Link to Online Job Seeker record on JobServe

Log in to your website account.
View your latest jobs applied for.
Run any of your Saved Searches from your online account.
Get useful candidate messages from your online account.

Applying For Jobs

JobServe announces the first fully featured Job Application system to be released on the iPhone – no web pages to navigate, completely in the app. This system fully compliments the application system provided by JobServe on the website.

You will need a candidate record and a CV on your account. You can simply log in to your account via a standard web browser and upload a CV or take advantage of the AddMyCV feature – details of which are provided on the iPhone app.

Once eligible you will be able to apply for jobs in as little as two taps. If you have answered all required questions before, you can simple review and tap "Apply". However to change any answers simple review each question in our easy step by step process and then Apply.

Useful updates to existing features

Main search screen remembers options between sessions.
Search assist remembers selections between sessions.
Fields are better aligned when keyboard is shown.
Useful keyboard toolbar buttons aid navigation.
Better feedback of activity via “Please Wait” dialog.
Auto scroll results to the top when paging.

And much, much more…

Don’t delay, download the app now and get the update from Apple as soon as it is available on iTunes.

Your Voice: let your voice be heard

2010-03-02T22:28:00Z

Today we are pleased to launch the newest member of the JobServe Labs project – Your Voice.

JobServe wants to make the features, products and services available to recruiters and job seekers as useful and effective as possible. The best way to achieve this is to listen to recruiters and job seekers – so Your Voice is your opportunity to influence what we have to offer to you.

Our first release of the JobServe Connect – Job Search iPhone app generated lots of very good feedback and questions which can now be presented on Your Voice for everyone to read and join in.

Your Voice is a simple discussion and comment forum where we will start some discussions on topics but more importantly so can YOU.

Get started with the following new discussions:

Making Job Searching even better – have views on Job Search – let us know.
Come and meet “Your Voice” in London – Your Voice is at a career event but what are your views on events?

“Let your voice be heard”

We help Microsoft fix Visual 2010 Help Manager

2010-02-10T11:33:56Z

In a previous post we described a bug in the VS2010 Beta 2 MSDN product which prevents you from getting hold of help collections etc when you sit behind an Http proxy.

In that post we provided a solution which involved leveraging Fiddler’s ability to chain together proxy authentication on an application’s behalf.

We also spotted this post on MSDN Forums and posted an answer indicating a possible solution for the person who opened the issue.

As you’ll notice from the bottom post – a request was made by an employee of Microsoft to see if we could help them test a fix that they had in mind. We did; the fix didn’t work completely, but we were then able to diagnose exactly why the fix didn’t work and have subsequently discovered how to make the Beta 2 MSDN 2010 Help Library Manager without having to use Fiddler. Based on our investigation, the team at Microsoft are now working on a fix – and might already have applied it in the Release Candidate of VS2010 – which released in the last week.

Use at your own risk!

Before we go into the details, it must be stressed that this fix is not offered officially by Microsoft and therefore carries no guarantees from them. We also make no guarantees about this fix either – it will involve changing registry settings and if this turns out to break anything else on your machine, then we will accept no responsibility for that. It’s your choice to follow our directions here!

Step 1

Modify the HelpLibManager.exe.config file found in Program Files [(x86) if on a 64 bit box]\Microsoft Help\v3.0 and add the following xml inside the <configuration /> node:

<system.net>
  <defaultProxy useDefaultCredentials="true" >
  </defaultProxy>
</system.net>

Save the config file.

On its own, this fix allows the help manager to ‘see’ the collections that are available for download – but it does not actually fix the problem of the download itself.

Step 2

This is the messy bit.

Open up the Registry Editor and make sure that registry value HKLM\Software\Microsoft\Windows\CurrentVersion\BITS\UseLMCompat is set to zero (the reason why is explained in a moment). If you need to change it, you should make a note of the previous value – or better yet, create a System Restore Point.

Restart the Background Intelligent Transfer Service, and then start up the help library manager. It should all now work without any problems – assuming you have internet connectivity at all; and that your user name and password allow you through the proxy in the first place :)

Why does it work?

We ‘discovered’ that Help Library Manager uses BITS (Background Intelligent Transfer Service) to initiate and manage the actual downloads of the content. Presumably this is because the files are typically rather large. This runs in a separate process and is communicated with over a COM interface, therefore the configuration file fix has no effect on that.

After some poking and prodding, we discovered that when a BITS transfer is initiated, the caller has the opportunity to specify the credentials to be used for the network connection. Working on the basis that the code in the Help Library can’t be setting these credentials (otherwise it would work), we looked for a way to get BITS to use default credentials. The article from the last link above provides the answer to that – which yields the registry hack.

Be aware that modifying this registry value affects all software that uses BITS – and therefore it’s just possible that other things might stop working as a result.

As we mentioned earlier – we don’t know if the bug has been redressed in the RC of Visual Studio 2010 – our findings, including this fix, were submitted to Microsoft on the 27th January – so it’s possible it was too late.

Hopefully, however, it’ll be fixed by the final release date!

That’s it for now, but stay tuned: We have some very exciting news on the way in the next couple of weeks; but we’re not allowed to talk about it yet ;)

Link Tag in Content Control not created as HtmlLink

2009-11-25T12:31:46Z

The Asp.Net System.Web.UI.WebControls.HtmlHead class is clever, especially when it comes to stylesheet <link> tags in master pages, since it magically rebases them (using Control.ResolveClientUrl) to be relative to the path of the page that is executing instead of the master page. This is especially necessary when a content page is declared in a different folder to its master page, because any CSS references are unlikely to work except by pure fluke.

With the advent of Visual Studio 2008, it has become common practise to have a content placeholder in a master page’s head section, which allows the page designer to add extra meta data, script references and CSS links on a content page as well. To be fair, this process started almost as soon as master pages came into being – except Visual Studio 2005 did not have design-time support for it, a deficit that was much bemoaned by K. Scott Allen at the time.

This website uses that ability so that our master page contains our common CSS references, but some of our content pages then have their own script references and styles. In order to get around the url-rebasing issue, we use a <base /> tag at the top of every page, so that we can use root-relative links for our urls, css and javascript references, then the browser will happily get them from the correct place. A recent article detailing a fix for a small bug with the Atom Feed link on one of our pages details this process a bit more.

Now we’re working on a new site, that will be using the Asp.Net MVC 1.0 Framework (and possibly 2.0 if it goes live before we’re finished). This brings even more potential problems with relative URL links, since every page URL is actually a folder. Although the <base/> tag is a solution, it’s not perfect since you then have to define a way to actually format out that base url. Many people use configuration, but it royally sucks for this, as it means that every time you move the site to a different machine (different developer boxes, QA box, staging box etc) or from a virtual directory to a website, you have to update the configuration.

Magic URL rebasing – the good

As mentioned in the introduction, any <link> tag that is placed directly inside the Head control of an Asp.Net page will be turned into an HtmlLink control – the magic for this is done in the HtmlHeadBuilder’s GetChildControlType method:

public override Type GetChildControlType(string tagName, IDictionary attribs)
{
    if (string.Equals(tagName, "title", StringComparison.OrdinalIgnoreCase))
    {
        return typeof(HtmlTitle);
    }
    if (string.Equals(tagName, "link", StringComparison.OrdinalIgnoreCase))
    {
        return typeof(HtmlLink);
    }
    if (string.Equals(tagName, "meta", StringComparison.OrdinalIgnoreCase))
    {
        return typeof(HtmlMeta);
    }
    return null;
}

Very simple indeed. As you can see, in order to get an HtmlLink created in place of a standard <link> tag within the head, you have to do, well, nothing at all (not even make it runat=server). When the HtmlLink control renders it’s output, instead of dumbly rendering the attributes (i.e. the href, rel etc) it does this:

protected override void RenderAttributes(HtmlTextWriter writer)
{
    if (!string.IsNullOrEmpty(this.Href))
    {
        base.Attributes["href"] = base.ResolveClientUrl(this.Href);
    }
    base.RenderAttributes(writer);
}

The ResolveClientUrl method is used to calculate the actual relative path to a resource, given a template-relative path (e.g. “~/Pages/page.aspx”, “~/Controls/control.ascx”, a master page virtual path or whatever) – which is retrieved from the first control up the parent-child hierarchy of the page that has one of these paths.

Magic URL rebasing – the bad

<script> tags don’t get rebased - ever

There is one tag in particular that is missing from the logic in the above code - “script”. Yes, that’s right, whilst <link> tags will be magically rebased, <script> references will not – which is indeed a stark omission from the Asp.Net framework. From the master page point of view, this means that you cannot really have <script> references in your master page’s header, unless all content pages will be in the same relative location from the target javascript file.

This problem can be solved in a couple of different ways. The first would be to pre-process the page content before it finally gets rendered, searching for any <script> references, parsing them manually, using Control.ResolveClientUrl to get the target script reference and then writing the fixed URL back to the content (indeed, this approach has been taken with a fix adopted by one frustrated Asp.Net user; see later).

However, the other approach is to write a simple server-side control to do it:

/// <summary>
/// Mimics the HtmlLink control - i.e. calling ResolveClientUrl at render time - 
/// except it's done on the 'src' attribute value.  Since HtmlLink writes the resolved
/// path back to it's Href member, this one does the same.
/// </summary>
public class HtmlScript : HtmlGenericControl
{
  public HtmlScript() : base("script")
  {
    
  }
  public HtmlScript(string tag) : base(tag)
  {
  }
  public string Src
  {
    get
    {
      return this.Attributes["src"];
    }
    set
    {
      this.Attributes["src"] = value;
    }
  }
  protected override void RenderAttributes(HtmlTextWriter writer)
  {
    Src = ResolveClientUrl(Src);
    base.RenderAttributes(writer);
  }
}

With this in place, you simply use the <#@ Register directive, or register a site-wide prefix via the web.config, to bring in a tag-prefix (e.g. “asp2”) for the control and then, in your ASPX source you change your <script> to:

<asp2:HtmlScript src="../myscript.js" type="text/javascript" language="javascript">
</asp2:HtmlScript>

Okay, so this isn’t a perfect solution – a site-wide refactoring like this could take some time! However, the best it yet to come…

Content controls in the head – even <link>s don’t get rebased

This is possibly the biggest problem, when you use a content control to inject extra links, references or whatever into a page head section from a content form, the magic CSS <link> rebasing no longer works. Why? The clue is in the above code snippet from HtmlHeadBuilder.GetChildControlType. Consider the following master page, and content page:

Master Page <head> section:

<head runat="server">
  <title>
    <asp:ContentPlaceHolder ID="TitleContent" runat="server" />
  </title>
  <link href="../../Content/Site.css" rel="stylesheet" type="text/css" />
  <asp:ContentPlaceHolder ID="CustomHeadContent" runat="server" />
</head>

Content Page Content Placeholder:

<asp:Content ID="customHead" ContentPlaceHolderID="CustomHeadContent" runat="server">
    <link href="../../Content/Site.css" rel="stylesheet" type="text/css" />
</asp:Content>

Okay, so in this example, both pages are referencing the same stylesheet, so it’s slightly contrived. However, assuming that the css files are in ~/Content/, the master page is in the ~/pages/masters/ folder, and the content page is in the ~/pages/content/ folder, this will work fine when it is run.

However, if we’re using something like MVC (or using the HttpRequest.PathInfo property like we do for our articles, projects etc) in order to beautify your urls, then we will run into problems. For example, if the content page in question is actually displayed in the browser with the url “/home/”, then the CSS link rendered from the head on the master page will correctly come out as “../content/site.css”, however the CSS link from the page’s content control will be left untouched (indeed it will be rendered as a literal), and will generate a 404 when it hits the browser.

This is because in order for the <link> markup in the content control to be turned into an HtmlLink, instead of being left as raw markup, the control builder that parses the <asp:Content> control (ContentBuilderInternal – no MSDN link because it’s understandably undocumented!) would have to have the same logic in it that the head section does – since the ASP.Net build engine sees the <link> tag as a child of the Content Control, not the HtmlHead that the content eventually gets merged into.

This is clearly a bug, or at the very least an oversight, in the Asp.Net framework – and has been reported on MS Connect by Nathanael Jones, who came up with the aforementioned page-parsing solution on his blog. However, this solution does not fix design-time problems (since the VS designer doesn’t run all of the page code when rendering it in the designer), and it is also quite a weighty solution which will inevitably slow down page rendering; our sites get tens of thousands of hits per day, and adding extra load on the servers is just not an option.

Our solution

Our solution fixes rebasing of all css <link> tags in the head of content pages, and it also automatically picks up and rebases all <script> references as well. You’ll need the HtmlScript control, whose source code was presented earlier on; then add this code:

/// <summary>
/// It's a placeholder, really - it simply tells the framework to use the RebasingContainerBuilder to 
/// create the controls that will emit the html.  Then, the designer is set to ControlDesigner - 
/// the same one that the ContentControl uses.
/// That ensures design-time support for the CSS and Javascript links on content pages.
/// </summary>
[ControlBuilder(typeof(RebasingContainerBuilder)), 
  Designer("System.Web.UI.Design.ControlDesigner, System.Design, " + 
  "Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"), 
  ConstructorNeedsTag(false)]
public class RebasingContainer : HtmlGenericControl
{
  public RebasingContainer()
  {
  }
  protected override void RenderBeginTag(System.Web.UI.HtmlTextWriter writer)
  {  /*doesn't render it's own tag*/ }
  protected override void RenderEndTag(System.Web.UI.HtmlTextWriter writer)
  {/*doesn't render it's own tag*/}
}
/// <summary>
/// This class is almost identical to HtmlHeadBuilder.  It's purpose to ensure that embedded
/// links and script tags are always rebased for the client during rendering.
/// The HtmlHead control does this for CSS link tags only, and the functionality is lost 
/// on content controls on content forms.
/// This builder is used by the <see cref="RebasingContainer"/> control
/// </summary>
public class RebasingContainerBuilder : ControlBuilder
{
  public override bool AllowWhitespaceLiterals()
  {
    return false;
  }
  public override Type GetChildControlType(string tagName, System.Collections.IDictionary attribs)
  {
    /* copied this code from System.Web.UI.HtmlControls.HtmlHeadBuilder */
    if (string.Equals(tagName, "link", StringComparison.OrdinalIgnoreCase))
    {
      return typeof(HtmlLink);
    }
    if (string.Equals(tagName, "script", StringComparison.OrdinalIgnoreCase) 
        && attribs.Contains("src"))
    {
      //only rebase script tags that have a src attribute!
      return typeof(HtmlScript);
    }
    return null;
  }
}

If you’ve placed this code inside the same assembly and namespace as the aforementioned HtmlScript class, then register a tag-prefix for that assembly/namespace (as before – the best place is in the web.config so it’s available on all pages) and you can start using it.

In order for content page script and css references to get rebased you simply change this:

<asp:Content ID="indexCustomHead" ContentPlaceHolderID="CustomHeadContent" runat="server">
  <link href="/Content/TestSite.css" rel="stylesheet" type="text/css" />
  <script src="/Content/script.js" type="text/javascript" language="javascript" />
</asp:Content>

To this:

<asp:Content ID="indexCustomHead" ContentPlaceHolderID="CustomHeadContent" runat="server">
  <asp2:RebasingContainer runat="server">
    <link href="/Content/TestSite.css" rel="stylesheet" type="text/css" />
    <script src="/Content/script.js" type="text/javascript" language="javascript" />
  </asp2:RebasingContainer>
</asp:Content>

Note that the asp2: prefix here depends on what prefix you actually register with Asp.Net. At run-time and design time, the RebasingContainer control doesn’t render it’s own tags – it simply acts as a placeholder to instruct Asp.Net to delegate to RebasingContainerBuilder which, in turn, contains the logic to map <link> and <script> tags to the server side controls that will perform the magic rebasing – just like the HtmlHead control.

Similarly, you can use the rebasing container to rebase <script> tags in the master page’s <head> content (or indeed any page’s head content) – simply move all your existing script tags into a new RebasingContainer, and it will work (don’t worry about the <link> tags – since the HtmlHeadBuilder will take care of those for you).

When you first do this, the designer might get upset and tell you that it doesn’t recognise the RebasingContainer – simply do a full build, and it will update. Now flip to design view on one of your content pages that previously didn’t work and smile at the fact that any extra stylesheets are now working in design view! Notice also that inline javascript will pick up intellisense from any script references that have had to be rebased in order to be picked up.

A better, but near-impossible, solution

One solution that has been suggested by the community is to sub-class HtmlHead and it’s HtmlHeadBuilder in order to force <link> tags to be always mapped to HtmlLink controls. There are numerous problems with this, the first and most crucial is that HtmlHead is a sealed class, so that’s impossible. Even it were possible, however, it wouldn’t really help because, as explained earlier, the HtmlHeadBuilder is only used to parse the direct content of a runat=”server” <head> control, and would never actually get a chance to process the ASPX markup for a page’s Content control.

Another solution that we researched was to do a similar thing, but for the Content control; that is, sub-class the Content control and it’s associated control builder class, making it <link> and <script> aware. This would have meant simply changing the control tag used on a content page to inject content in the page’s header. The big problem with this, however, is that the Content control uses an control builder that’s internal to Asp.Net: ContentBuilderInternal, which by definition cannot be subclassed. It’s possible to call into internal classes and methods (using dynamic code generation – e.g. via Linq Expression Trees or DynamicMethod), but we didn’t have the time to build a proxy and all the code generation logic.

In the meantime, we hope that this explains the problem and provides you with an easy-to-use solution!

VS2010 Beta 2 – Fatal Error Occurred installing Help

2009-11-13T17:14:35Z

Update (10th Feb 2010) – a more thorough investigation of this issue has been carried out by us (after being asked to help Microsoft fix the problem) and a new fix is detailed here.

We’ve been playing around with the beta 2 of Visual Studio 2010 and really like the Web Install idea - although the actual VS2010 part of the download appears to be throttled at around 4Kb, which is a little frustrating!

At the very end of the installation you get to install the new MSDN Help 3 Collections, choosing online or local help as your primary source. If you’re running behind a web proxy that requires authentication you will see a “fatal error occurred” message pop up, and that’s it – there’s nothing you can do to get help on to your machine (except to get your SysAdmin to allow you out of the building without going through the proxy).

However, we have found a rather cheeky solution to this problem – the rather marvellous Fiddler Http Web Debugging Proxy.

To get it to work

Scenario 1: All you should have to do is download Fiddler, install it and run it, then hit the ‘Get Content Online’ link again. Eventually you’ll see all the content offerings, select the ones that you want and then hit the Update button.

You should see web requests in Fiddler going through to packages.mtps.microsoft.com once the transfer starts. Don’t worry if they appear to take for ages to complete – you’re watching a multi-part download, and nothing really interesting is going to happen until it’s finished!

Scenario 2: If this doesn’t work – then it’s possible you might have to force Fiddler to remember your credentials for your proxy. The best way to do this is to load a page in IE, and you should see a proxy login box appear. Enter the correct credentials for your proxy and check that the web page then loads correctly.

Now try to get the help content again – it should work.

Why does Fiddler make it work?

Here’s our theory: Obviously the Help installer client is not proxy-aware. So it attempts to make a connection to the package download location, but hits the system proxy. When this happens, the proxy returns a request for credentials, but the code isn’t written to send them over, and so it simply crashes.

The reason why fiddler makes it work is because if it receives a Proxy Authentication request (Http Status Code 407) from the upstream proxy, it responds with the identity of the user running Fiddler (Scenario 1), or a token that has previously been known to work for the current session (Scenario 2).

If that isn’t good enough, it then pushes the 407 back to the client. Now we already know that the Help Installer itself can’t cope with this, so in our Scenario 2 we use Internet Explorer to cheat, since it displays a login box when credentials are required.

IE then sends those credentials to Fiddler, which in turn are then sent to your proxy – if the proxy then lets the request out, Fiddler will cache that authentication token to be used with ALL future requests (not just those coming from IE). So when the Help Installer then makes another request, it signs that request as authenticated even though the Help Installer didn’t know it needed to.

Remote debugging code on Windows 2003 from Vista or Windows 7/2008 R2

2009-11-05T12:30:10Z

We’re in the process of upgrading our development environment from Windows Server 2003 x64 to Windows Server 2008 R2. Apart from the desktop experience being far superior, we’re also moving our web servers up to IIS 7.5, therefore we want all our web developers to be running the same. Windows 7 is of course an option for this (and it works extremely well as a web development environment – unlike Windows XP Pro), however it doesn’t offer Hyper-V, which is a must for many developers who want to run their own database servers and mock web servers.

Inevitably, however, we still have to support our existing codebase - all of which runs on Windows Server 2003. Occasionally, therefore, we need to debug something that’s running live because a problem arises that is not easy to reproduce in a model office environment. This typically means installing the Visual Studio Remote Debugger on the server that’s running the code and then attaching to it from the local Visual Studio. Many people would say that this is bad practise; in our opinion bad practise is to go the whole hog and install Visual Studio on the server machine! Remote debugging, on the other hand, is a reality of working as a developer in a technology-driven business.

The problem

Today we had to do just this, but when we tried to connect to the remote machine we got the error message "a security package specific error occurred". If you do a web search for this error, you’re likely to see this link from MSDN forums, where the user eventually solved the issue by creating a local user on both the target and local machines, and ran both VS2008 and the Remote Debugger as that account.

The solution presented is to:

Create two, administrator-level, identical local users on both the debugger machine and the debuggee machine
Run the msvsmon.exe application (the Remote Debugger binary) as that local user on the debuggee
Startup Visual Studio on the debugger machine as that local user
Attach to the debuggee

We weren’t happy with this resolution, because it points to a more fundamental problem – if Remote debugging works between two Windows 2008 R2 or Windows 7 machines, using the same VS binaries, why wouldn’t it work when talking to a Windows Server 2003 machine? Equally, we don’t want to have to go around creating local users on developer machines and servers just to get remote debugging to work. When you’ve reached this stage, it typically means that you’ve got an error you can’t reproduce any other way and you just need to ‘get it fixed quick’. Also, in a TFS environment, the Visual Studio instance in which you’re doing the debugging will not be able to connect to TFS, because the local user that you’re using is unlikely to have access to source control etc.

The root cause of this problem turns out to be slightly more subtle than the user on the aforementioned MSDN forum post assumed. It is indeed authentication that is failing, but not the authentication of the user doing the debugging against the server they wish to debug. In fact, after the remote debugging service receives a request to attach, it then authenticates back to the machine that the request originates from, and it is at this point that authentication is going wrong (we were able to generate the error that is described in that previous link by using a local account for the debugger service on the target machine but without creating it on the development machine).

Even though our service was running as a domain account which has logon rights to the development machine, for some reason the NTLM network logon token for that account that is sent back by the debugging service would appear not to work properly.

By enabling network level NTLM auditing (in Local Security Policy, enable the two settings “Network security: Restrict NTLM: Audit Incoming NTLM traffic” and “Network security: Restrict NTLM: Audit NTLM Authentication in this domain”) we were able to see the logon occur, but then the logon session is destroyed (presumably as a result of the “Security package specific error” that occurs).

A (slightly) easier solution

The good news from this is that we can offer a streamlined solution to the one provided in the above MSDN link, the bad news is that you’ll still need to create the local users:

Create the two users as before on the two machines – however, it only needs to be an administrator on the target machine.
Modify the remote debugger service on the target machine to use the new local user, start the service.
Run Visual Studio 2008 as you would normally (no need to run as the local user), and attach the debugger as normal.

Tell Microsoft!

We have logged a bug on Microsoft Connect so that the VS team can investigate the issue – if you are affected by this issue then please vote for it! At present we do not know if this also affects Visual Studio 2010 (we have a development lab set up and will investigate), if you can verify that it does, then add your experience to that bug so that we can ensure that at least the next version of VS isn’t plagued by this issue, even if it doesn’t get fixed in the current version.

Important update to iPhone Job Search

2009-10-28T22:37:47Z

A few of you had noticed that when entering a location in the iPhone App (i.e. not using the Jobs Near Me option) the numbers of results did not match similar searches on the website. Also it appeared that changing the proximity distance for these searches had no affect – in fact all searches were running “zero miles”.

Yesterday we made a change to our core web services supplying Job Search to the iPhone and we can confirm that now the proximity distance is having the desired affect.

We would like to thank those candidates alerting us to the issue – please continue to feedback to us as you can help to make this app and others in JobServe Labs more effective.

The JobServe Labs Team

Job Search iPhone App Update

2009-10-27T09:47:37Z

The JobServe Job Search iPhone App (available here) has been on the App Store for just under a week and we are very pleased with the overall reception so far. In this article we would like to discuss the feedback so far and explain some of the issues experienced.

Thank you to all the users that have taken the time to email us with constructive and useful feedback, we have had over 3,000 downloads and at least 50 emails which range from feature requests and suggestions to possible issues with the search or function of the app.

Key features requested:

Provide Salary/Rate search options
Allow user to set the number of results displayed per page
Access Saved Searches from the JobServe website
Apply for Jobs directly from the App
Display the Job Reference and recruiter Telephone number if available
Allow results to be displayed in Best Match or Posted Date Descending order

Suggested improvements to current functionality:

Change the layout of the results to fit more jobs on the screen – better use of real estate
Make the settings option more visible to users

Issues highlighted:

Jobs Near Me functionality causes app crashes for some users
Email job from Full Description screen fails

So we have a good set of request and suggestions already. Currently under review by Apple is a new version v1.01 which will provide new features 2 and 5 above. Cosmetic changes to the layout will display more jobs per page and the settings option is more visible.

In terms of bugs all should be fixed in this new release.

Jobs Near Me – This uses the iPhone API CLLocationManager class and for many users when selected this class returns the location co-ordinates quickly and accurately. However some users experience when in certain locations that this crashes – we have many reports of the same user using the app successfully in different locations but crashing in other locations. Under all testing scenarios we did not experience this, and although not a perfect excuse, we released this with belief that the required precautions were taken. On closer analysis it appears that the CLLocationManager may be returning two results very quickly – even though we have requested specifically to stop updating the location. Users experiencing the crashing sometimes saw results very quickly or just bombed out on the first screen. Users could then use the Location box for searching instead as a workaround.

The new release will be out as soon as possible and we value your continued feedback.

Following this release we will be planning another release which will contain Sort Order options and Salary Searching.

We are also working on the Application platform which will allow users to apply for jobs directly from their phone using our Job Application process similar to the JobServe website. The only requirement will be to have a JobServe candidate record and maintain a CV on the website.

JobServe Connect – Job Search for the iPhone released

2009-10-21T15:21:02+01:00

We are happy to report that the JobServe iPhone app “JobServe Connect – Job Search” has now been approved by Apple and is available from the App Store on iTunes. We thank all the users that pre-registered for the app and you should all have received your launch link to download the App.

So far response has been very good and we encourage even more of you to send us emails with suggestions and general feedback, we’ll post details of what features will be making the next release as soon as we can.

If you would like to get the iPhone app now please use this link to download from iTunes

JobServe Connect – iPhone first mobile platform soon

2009-10-19T16:23:18+01:00

Currently we are awaiting confirmation from Apple that our Job Search iPhone app is going live (more details below) and this will pave the way to continued reach of JobServe services to other devices. The rise of smart mobile devices, with 35 Million iPhones and 65 Million Blackberry devices worldwide, shows that this is a popular channel to reach our customers – Job Seeker and Recruiter alike.

JobServe Labs has been committed to providing different ways to access JobServe, we have launched the Google Desktop Gadget and the Windows Vista Sidebar Gadget, both have proved very popular and are often being updated with new features.

Currently we are concentrating on providing Job Seekers more ways to search for jobs and with the imminent release of the first JobServe iPhone App we will bring the ease of job searching and the large number of UK, US, Canadian, Australian and global jobs to even more people. Like all developments within the Labs project the iPhone Job Search app is only the first iteration. We have already planned updates and other apps which will make up the family – JobServe Connect.

JobServe Connect – What is it?

JobServe Connect is the umbrella term for the suite of products developed by JobServe Labs to bring JobServe products and services to more users and to enable better communication between Job Seekers and Recruiters as well as JobServe and its customers. We will provide more and more channels to enable anyone to talk to JobServe and help shape the job board of tomorrow through useful features and technology. We want feedback, we provide our Twitter feed @JSLabs and we have our articles with news of what we are working on. So we encourage you to read, email, tweet about articles you like and help Spread The Word – Tweet This Article.

No iPhone? What else

We asked the same question to our Job Seekers and we have had some predictable but great results. Not too surprisingly the top non-iPhone platform requested was Blackberry. We can confirm that we are now working on porting over our Job Search iPhone app so as soon as possible we will have a Job Search Blackberry App. Remember that JobServe Labs will contain information on this and future releases.

Popular other platforms were Symbian based devices, Android and Windows Mobile. Keep an eye on JobServe Labs as these apps get released in the coming months.

Any more news on the Job Search iPhone App?

The JobServe iPhone app is called “JobServe Connect – Job Search” and will launch very soon as a sneak preview here is the main screenshot as well as a list of the primary features you can expect. There is still time to get a priority link – simply email iphone.interest@apps.jobserve.com the word iPhone.


UK Version (Home screen)	UK Version (Results)

Features:

Simple JobServe Job Search
Search Jobs Near You
Settings providing Proximity, Days since Job posted and Country
Favourite Jobs
Email Favourites or individual Jobs
Suggested Jobs - Get a custom list of other jobs you may be interested in
Automatic Search History - Only type the search once
Search Assist - The new iPhone search wizard helps you build a search

Version 1.0 of the Job Search iPhone App has concentrated on ease of use and speed.

We will let you know as soon as the iPhone App is live.

Website update 16th October 2009

2009-10-16T13:57:00+01:00

Firstly, our apologies to some of you over the past few days who’ve had problems accessing our site feed from your browsers’ RSS auto-discovery icon. We’ve been catching some errors at this end where some of you have apparently been trying to access our feed url (http://www.labs.jobserve.com/jslabs.svc/feed) from one of our virtual sub-folders (such as the Articles.aspx sub folder that you’ll see in your browsers address bar on this page).

We’ve modified our master page now so that the feed url specified in the RSS <link /> tag will always be correct – we hope this didn’t stop you from being able to access our site feed!

Why did it happen?

A lot of work has gone into this website at our end to make it easy for us to develop, test and deploy. Part of this is ensuring that the site works as well under an IIS virtual directory (which is what developers usually do) as it does as its own IIS root website (when it’s deployed to our live servers).

Usually you can use the ‘~/’ notation in Asp.Net to work around this problem; however a lot of our pages, although they are ASPX pages, do not use server-side controls and tags. This is to keep the load on the webservers to a minimum, but it also means that we can’t always use virtual paths on our links, images and all the other stuff that makes up a web page.

Throw into the mix that we’re using the HttpRequest.PathInfo property on many of our pages (an idea garnered from Scott Guthrie’s article on URL rewriting for SEO purposes) – which means that a lot of relative paths can no longer be taken for granted.

For example – a <head> link to styles/labs_base.css works fine if the page in the browser is simply Articles.aspx (since that’s in the root of the website), but since all articles are actually served from Articles.aspx/[Article-Title], then your browser will incorrectly make a css request for Articles.aspx/styles/labs_base.css – which, of course, doesn’t exist.

A typical solution this problem would be to change the path in the master page to /styles/labs_base.css – but this would break the site in development, unless we always enforce our developers to run their development site in a website in IIS (using the Cassini isn’t an option because there are a few other tricks being employed by this site which don’t work when running in that). Equally we could make all our <link/>s, <a hrefs et al to be runat=”server” – but that’s making the web server do more work than it really needs to.

How do we fix the problem, then? We use a <base /> tag, which is placed within the <head /> section of every page – this tells your browser that all relative Urls start from a given location – in our case www.labs.jobserve.com – which means that we can then use relative links everywhere for everything. Our code for calculating the base Url is partly taken from the request’s Url, as well as the application path:

public string BaseAddress
{
  get
  {
    //stick "http://" or "https://" in front of this as required
    return string.Format("{0}{1}",HttpContext.Current.Request.Url.Authority, 
      HttpContext.Current.Request.ApplicationPath);
  }
}

This code works reliably regardless of whether or not the site is running in a virtual directory or under its own website; meaning that our development team can develop the site however they want and we can deploy the site however we want in the future.

The original problem with our site feed link from the master page was that it was relative, i.e. jslabs.svc/feed, but unfortunately it appears that some, if not all, browsers, were ignoring the <base /> tag. Now, our feed link is rendered absolute – including the http:// bit, and it should work on every page.

So there you go – if you’re developing an Asp.Net website, then coding around base url of your site at deployment time and during development will be an inevitable problem. You can take a brute force approach, force Website/Virtual Directory configuration to be the same from Development to Live – or you can find a more elegant approach that ultimately makes your code much more portable. Ours is just one solution; there are many more floating around out there.

If you were affected by this – we hope that you now enjoy unfaltering access to our site feed!

JobServe Job Search coming to the iPhone

2009-10-14T22:05:36+01:00

The JobServe app for job searching is coming to the iPhone and iPod Touch very soon. We are very excited about the imminent launch of the first JobServe app on this platform and we want as many of you to join in the release as possible.

If you would like to be sent a priority link to download the JobServe App as soon as it is available simply send an email to iphone.interest@apps.jobserve.com with the subject line iPhone.

We will be posting much more information on this app and the other apps in development, very soon. Also we are going to bring JobServe to as many platforms as possible in the coming months.

The app - “JobServe Connect – Job Search” will be released very soon and your feedback will be very important to helping shape future releases.

Keep up to date with information from us on the website or follow us on Twitter @JSLabs

Google Desktop Gadget v0.2 released!

2009-10-14T18:00:46+01:00

Following on from the recent release of v0.3 of the Windows Sidebar Gadget, as promised we’ve now updated our Google Gadget to include most of the same feature-set.

If you want to go and test drive it now, simply go ahead and download it! If you’ve previously downloaded it from the Google Gadget Directory, then you can still download it straight from us – but it’ll also appear as an update in your gadget list after few days of it being live.

So what’s changed?

The original gadget allowed you to search for jobs with a particular skills keyword search, in a particular location and country. The first minor improvement we’ve made is to add a new country: ‘All’:

As you can see above – the country selection is ‘All countries and areas’. Be careful with this one if you are after a single location in the world. In the query above, for example, I’ve searched for SQL jobs in ‘London’. This could mean London, UK; or London, ON in Canada (or indeed any one of the other numerous locations around the world that are called ‘London’.

Other classic ambiguous locations are Birmingham, Cleveland and Colchester (all UK/US location cross-overs); of course we can’t provide an exhaustive list here!

The real power of a worldwide search, however, is if you are the kind of person who regularly moves all around the world – the IT contractors among you, for example may well fit into this category.

The Options Dialog

Talking of Contractors, we also have four new options that you can use to modify your search. You’ll notice the spanner/wrench icon next to the ‘search’ button above. Clicking on this launches the new options dialog:

The emphasis here is functionality – not look and feel!

A quick run through of the different options:

Job Type: Select from Any (the original default), Permanent or Contract.
Per Page: The results from our web services are paged, previously you were fixed to 20 results per page, but now you can configure it in steps up to a maximum of 100 jobs per page.
Job Age: The previous search defaulted to pages posted in the last 7 days. Now you can select from 1 to 7 days; as well as the ‘Today Only’ option – which will include only jobs posted since midnight GMT today.
Distance: Allows you to specify the maximum distance a job is allowed to be from your specified location in order to be included in your search. There is no unit selection (miles/km) because it is interpreted differently according to the country in which you search. E.g. on a UK search the value is interpreted as miles, but on a US search it’s interpreted as kilometres.

What’s next?

The next iteration will see industry selection and ‘email me this job’ functionality which we have already released in our Windows Sidebar Gadget. We will endeavour to get this out as soon as possible, but we hope in the meantime that this will satiate your job-searching needs!

As always, keep coming back to this site, or subscribe to our Atom feed – as we have some very exciting developments on the way in the next few months!

Sidebar Gadget v0.3 Released!

2009-10-07T11:19:14+01:00

Today sees the launch of the next enhancement to the Windows Sidebar Gadget: v0.3. To get hold of it, simply download it now!

The key enhancements are:

New ‘Distance’ selection dropdown on the settings dialog. Provide a hint to our search engine as to how far you want to travel out of the location you specify on a search.
New ‘Industry’ selection list. Now you can isolate your searches to one industry, or a combination of industries, within which our recruiters post jobs. So now, if you’re only looking for ‘Sales’ jobs, you can select that industry only and then use the skills search field to specify kind of sales job you want.
Added ‘Today Only’ option for job age. If you use our gadget frequently (and we know that a good number of you do!), then you can now restrict your results to only those jobs that have been posted today. An important thing to note with this feature is that at midnight UK time, all results will reset and your search will start to build up new results.
Added an “All Countries” selection in the country dropdown on the settings dialog.
Added ‘Email me this job’ feature. On our settings dialog you can now provide your email address (Note: we never give out your email address to anybody, so it’ll be in safe hands!). If you do this, then when you expand the full-job details, you’ll see a new link in addition to the Apply Now link. When you click on the ‘Email me this job’, we will send you the full-text of that job and a link to apply to it. You can only queue one email request per job in one 24 hour period; but there is no limit on the number of jobs you can receive by email.

Screenshots

The new settings dialog. Note the 3 new fields: Email, Distance and Industries.

New Job Details Page – when you’ve entered an email address on the settings page, run a new search and open up a job’s details. You will see the ‘Email me this job’ link. When you click on the link, its text will change to let you know whether or not the email has been sent:

If you’ve already been sent an email for this job within the last 24 hours, then the link will change to “Already Sent Today!”.

What about my Google Gadget?

Yes, if you’re a fan of the Google Job Search Gadget, you’ll be wanting to know when all these features, plus the rest of the configuration features that were added in V0.2, will be available. Rest assured, we are working on this as we speak and you can expect an updated version soon.

Anything else in the pipeline?

You bet! We are expanding the idea of “JobServe any place, anywhere” and there are some very exciting developments on the way very soon indeed. Keep coming back to the site, or subscribe to our Atom feed to keep yourself in the loop.

Building Labs – Writing an OpenSearch Suggestions provider in C# with WCF

2009-08-17T16:50:53+01:00

This is the second in a series of articles on how we’ve built JobServe Labs and some of the projects that are available. In the first article we described how we’re using Windows Live Writer to manage our content, and how we’ve written an XML RPC backend for it to talk to, using WCF in C#.

This time, we’re going to look at the suggestions service that we did for our Web Browser Search Provider, and how you can set up your own.

Before you start reading, please feel free to download the source code that is built by following this walkthrough – it also shows how to output the images in the suggestions that are supported by IE8.

What is OpenSearch?

Originally, OpenSearch enabled a website to expose to interested consumers (be they web browsers, search engines or anything else) any of the search capabilities that they might have. The notion of extracting this out to a standard meant that a consumer could be automatically compatible with lots of search engines once the code had been written to interpret one.

The search facility of a website typically takes the form of a URL that can accept a URL-encoded search phrase in the query string – for example, many people will be familiar with Google’s query string format, since each search results page is represented by a different URL:

http://www.google.co.uk/search?hl=en&q=jobserve – first page of a Google Search for ‘jobserve’

http://www.google.co.uk/search?q=jobserve&hl=en&start=10&sa=N – second page – note the additional ‘start’ parameter, which tells the search engine which result should come first.

If you’re looking to implement OpenSearch for your website, then you should, at a minimum, have a URL that can also ‘seed’ a search in this way.

The interactive suggestions-part of OpenSearch is an extension that was suggested after the original spec was drawn up, and is, primarily, a convenient way that a search service can help users narrow down their search without having to first run multiple searches. For example, a lookup into a known keywords list, a list of popular searches, both of these, or more besides.

Our search suggestions service, for example, responds with actual job results which (in IE8 only, unfortunately) take you directly to the job page.

Before you start

Assuming you do have a URL on your site that you can use to launch your search – you should then take a look at the OpenSearch spec, which is the standard around which your suggestions service is going to be built, and which is one of the easier to understand standards. In particular, you should review the OpenSearch Suggestions Extension specification, which details the URL format that your service should ideally support and format of the data that you should be returning. One thing to note here is that the specification describes the response data you should return in terms of JSON-formatted objects; however this is not your only option. Microsoft have adapted and extended the OpenSearch Suggestions Extension into XML format for use with Internet Explorer 8, and with this you have additional capabilities in IE8, such as separators and images in your suggestions list:

In the above screenshot, you can see the top result has an associated image, and the search service is also using a separator to embed a link to an information page about Microsoft’s newly branded Bing search engine.

When it comes to the choice between the JSON or XML suggestions format, you don’t necessarily have to chose either/or – IE8 supports both, whereas Firefox, for example, only supports the JSON format. However you can expose two services in one OpenSearch Description Document, and both browsers can hang off the one document quite happily (IE8 will favour the XML service when faced with both).

Project Setup

We use Visual Studio 2008 here, so these steps are based on you using that environment.

Create a new C# Asp.Net Web Application
Leave the project’s web properties so that it runs from the Visual Studio Development Web Server – it’s considerably easier to do testing with this - however you will want to manually specify the port so that later on your code knows the base location of the URLs to be generated.
Now add a new WCF service – call it ‘OpenSearch.svc’ (Hint: the ‘WCF Service’ item template is found in the ‘C#’ root folder on the add dialog).
When you create WCF services, the wizard automatically modifies the web.config to add WS-HTTP and Metadata Exchange (MEX) endpoints – you can remove these from the configuration as we’re going to be working with the zero-configuration WebServiceHostFactory which is great for creating RESTful services for XML and JSON.
Also, the wizard abstracts the service implementation from it’s operation contracts by creating an interface, IOpenSearch in this case – which you can delete.
Open the code-behind for the service (OpenSearch.svc.cs) and remove the IOpenSearch interface from the class, and get rid of the ‘DoWork’ method declaration from the class body.
Finally, you need to add a reference to the System.ServiceModel.Web assembly – this brings in the aforementioned WebServiceHostFactory class, as well as the WebGetAttribute and UriTemplate classes, which we need in order to expose our service on the URLs of our choice.

Results Classes

In order to support both the JSON OpenSearch suggestions format (supported by Firefox) and XML OpenSearch suggestions format (used by Internet Explorer 8), we unfortunately have to split our class definitions between the two uses. This is because the JSON format is based on a parallel array approach, with the Completions, Descriptions and QueryURLs being specified in three separate arrays, whereas the XML format is object-oriented, with all three pieces of data being specified as child values of a common suggestion element.

These two approaches can’t easily be represented in one set of classes for WCF serialization purposes, so to solve this problem in the way most convenient for us, our primary result classes on the server are going to be the ones that’ll produce the XML results for IE8 (to provide class->entity mapping for the XML), and we’ll create another standalone class for our JSON result format that can be constructed from those.

The first type you need is for each individual suggestion itself:

[DataContract(Namespace = "http://schemas.microsoft.com/Search/2008/suggestions")]
public class Suggestion
{
  [DataMember(EmitDefaultValue = false)]
  public string Url { get; set; }
  [DataMember]
  public string Text { get; set; }
  [DataMember(EmitDefaultValue = false)]
  public string Description { get; set; }
  [DataMember(Name = "Image", EmitDefaultValue = false)]
  public SuggestionImage Image { get; set; }
}

The keen eye will notice that we’ve also got a dependency on the ‘SuggestionImage’ class, which should be specified as follows:

public class SuggestionImage : IXmlSerializable
{
  public string Source { get; set; }
  public string Alt { get; set; }
  public int Height { get; set; }
  public int Width { get; set; }
  public XmlSchema GetSchema()
  {
    return null;
  }
  public void ReadXml(XmlReader reader)
  {
    //we never actually load our results from XML
  }
  public void WriteXml(XmlWriter writer)
  {
    writer.WriteAttributeString("source", Source);
    writer.WriteAttributeString("alt", Alt);
    if (string.IsNullOrEmpty(Height.ToString()) == false)
      writer.WriteAttributeString("height", Height.ToString());
    if (string.IsNullOrEmpty(Width.ToString()) == false)
      writer.WriteAttributeString("width", Width.ToString());
  }
}

This class might seem a little odd – since it doesn’t use any DataContract or DataMember attribute declarations. The reason for this is because the XML OpenSearch format requires that the image data is specified in XML attributes; this requirement is initially a total show-stopper, because the WCF DataContractSerializer doesn’t natively support XML attribute serialization via its attributes. However, you can take over the XML serialization yourself and write attribute strings for a given type if you simply implement the IXmlSerializable interface.

Now, we need to define the outer types in which we’re going to place our suggestions. If you take a look at the aforementioned XML suggestions format, you’ll see that a root-node is expected, called ‘SearchSuggestion’, inside which we have an element called ‘Query’, and then one called ‘Section’, inside which each of our suggestion items should be written. In order to achieve the latter correctly, we have to use the CollectionDataContract attribute, which allows us to define the inner element that’ll go within the <Section/> element, and give our list the name ‘Section’ at the same time:

[CollectionDataContract(Name = "Section", 
   Namespace = "http://schemas.microsoft.com/Search/2008/suggestions", 
   ItemName = "Item")]
public class SuggestionsSection : List<Suggestion>
{
}

Note the use of the List<> generic here.

And then, finally, we define our outermost result, that our search suggestions service is actually going to return to our callers:

[DataContract(Name = "SearchSuggestion",
  Namespace = "http://schemas.microsoft.com/Search/2008/suggestions")]
public class Suggestions
{
  [DataMember]
  public string Query { get; set; }
  [DataMember]
  public SuggestionsSection Section { get; set; }
}

One of the things that might be confusing about all our [DataContract] classes here is that we repeatedly specify the namespace. We have to do this, otherwise the DataContractSerializer will, (un)helpfully take our class’ namespace and use that. Being XML, the namespace is very important, and IE8 will refuse to parse the XML results you throw back if there are errant namespaces in your returned data. By specifying the same namespace on every class, the DataContractSerializer will only output the namespace on the root node, as it will be satisfied that no namespace changes occur as it drills down through the data that it serializes.

We don’t have to worry about this on our SuggestionImage class, because it is our responsibility to write the namespace attribute out - because we’ve implemented IXmlSerializable – as a result, we simply don’t bother.

Adding support for the Separator element

You will notice that we’re not supporting the <Separator /> element of the XML format - this oversight is for brevity in this article. If you wanted to support this you would need to introduce a common interface, ‘ISuggestionItem’, which the Suggestion object could implement. Then you’d introduce another class, called ‘SuggestionSeparator’, which also implements the same interface. Note here that to support titles on your Separators you’d also need to implement IXmlSerializable again, because the title is expected to be an attribute and, as we saw with the SuggestionImage class, we have to take over serialization when we want to do this.

Finally, you’d change your declaration of the SuggestionsSection class so that it inherits from List<ISuggestionItem>, and add two [KnownType] attribute declarations to that class so as to support Suggestion and SuggestionSeparator.

Moving on to the JSON Result object

As previously mentioned – and as is outlined in the aforementioned specification – the JSON results format is, curiously, not a structure, but an array of arrays. This poses an interesting problem for the DataContractSerializer, because it’s JSON capabilities, provided by the DataContractJsonSerializer, are geared to produce JSON structures with fields mapped to the properties of the .Net type being serialized. The answer? To have your JSON object masquerade as a JSON array, and to add what you would normally think of as fields to that array on construction:

[KnownType(typeof(string))]
[KnownType(typeof(string[]))]
public class JSONSuggestions : List<object>
{
  private string Query;
  private string[] Completions;
  private string[] Descriptions;
  private string[] QueryURLs;
  public JSONSuggestions() { /*default Ctor required by WCF*/ }
  public JSONSuggestions(Suggestions source)
  {
    //build the individual members
    Query = source.Query;
    Completions = new string[source.Section.Count];
    Descriptions = new string[source.Section.Count];
    QueryURLs = new string[source.Section.Count];
    int current = 0;
    foreach (var result in source.Section)
    {
      Completions[current] = result.Text;
      QueryURLs[current] = result.Url;
      Descriptions[current] = result.Description;
      ++current;
    }
    //then add them to the inner list of objects in the 
    //order that the JSON suggestions format decrees.
    this.Add(Query);
    this.Add(Completions);
    this.Add(Descriptions);
    this.Add(QueryURLs);
  }
}

Note that we’re not using the DataContract/DataMember attributes on this class – instead we’re simply leveraging WCF’s POCO support introduced in .Net 3.5 SP1. The solution presented by this class is quite subtle, and worthy of study. First, the class inherits from List<object> – this is because we need to be able to serialize both a string (for the ‘query’ data) and arrays of strings (for the completions, descriptions and URLs data). As a result, we also have to lend the DataContractSerializer a helping hand by using the KnownType attribute, so that it knows in advance that the list could contain either of these two types.

Our only constructor takes in our Suggestions object that we’ve prototyped in the previous section, and simply leeches all the data out of it into temporary holding variables. Finally, these holding variables are added to the list in the order that the OpenSearch suggestions format specifies. When this object is serialized by the JSON serializer, it will be written out as an array, because the outermost type is a collection type.

The Query Page and the Search Service

Now, we’re not going to write an actual search service here – what you’ll be left with is the skeleton code in which you can easily plug your search engine code. We’re going to focus instead on the sprint finish to getting something returned to your browser. We also need a few pages in our website project:

A search page that accepts a query string search parameter, as explained in the opening section
A few additional pages that we can present as actual search results

Our demo service is going to be query-string agnostic; so, although it will accept a query string, the results it returns are not going to be influenced by that input string – that’s for you to do. The final step after this is to craft our OpenSearch description document so that web browsers can pick up our search provider.

So, quickly:

Add three content pages to your web project – we’re going to call ours ‘Result1.aspx’, ‘Result2.aspx’ and ’Result3.aspx’. Put some basic content on there that you can use to discriminate the three from each other.
Add another page, and call it ‘Search.aspx’. Modify the code-behind as follows:

public partial class Search : System.Web.UI.Page
{
  private string _searchPhrase;
  public string SearchPhrase
  {
    get
    {
      if(_searchPhrase == null)
      {
        if (Request.QueryString.Count == 0 ||
          (_searchPhrase = Request.QueryString["q"]) == null)
          _searchPhrase = "";
      }
      return _searchPhrase;
    }
  }
}

Now, open the mark-up for the page, and replace the body with:

<body runat="server">
  <div>
    <h1>
      You searched for '<%= SearchPhrase %>'</h1>
  </div>
  <div>
    Results:</div>
  <div>
    <ul>
      <li>
        <h2>
          <a href="Result1.aspx">Result 1</a>
        </h2>
        The first result page
      </li>
      <li>
        <h2>
          <a href="Result2.aspx">Result 2</a>
        </h2>
        The second result page
      </li>
      <li>
        <h2>
          <a href="Result3.aspx">Result 3</a>
        </h2>
        The third result page
      </li>
    </ul>
  </div>
</body>

With all that in place, it’s now time to go back to our OpenSearch.svc and expose our XML and JSON endpoints.

The first step is to open the .svc mark-up itself and add the highlighted code to it, to enable the WebServiceHostFactory:

<%@ ServiceHost Language="C#" Debug="true" Service="OpenSearchDemo.OpenSearch" CodeBehind="OpenSearch.svc.cs"
Factory="System.ServiceModel.Activation.WebServiceHostFactory" 
%>

Now we open the code-behind file and write our two service methods – one for XML and one for JSON:

[ServiceContract()]
public class OpenSearch
{
  [OperationContract]
  [WebGet(UriTemplate = "suggestions?q={query}",
    RequestFormat = WebMessageFormat.Xml,
    ResponseFormat = WebMessageFormat.Xml)]
  public Suggestions GetSuggestions(string query)
  {
    //TODO: replace with your real search engine code.
    Suggestions toReturn = new Suggestions() 
      { Query = query, Section = new SuggestionsSection() };
    //for brevity, we've fixed our dev web server's port so that we know exactly where
    //these URLs need to point.  In reality you'll either use auto-discovery by taking
    //a look at the WCF WebOperationContext, or via a configuration file.
    toReturn.Section.Add(new Suggestion()
    {
      Description = "Result 1 Description",
      Text = "Result 1",
      Url = "http://localhost:37082/Result1.aspx"
    });
    toReturn.Section.Add(new Suggestion()
    {
      Description = "Result 2 Description",
      Text = "Result 2",
      Url = "http://localhost:37082/Result2.aspx"
    });
    toReturn.Section.Add(new Suggestion()
    {
      Description = "Result 3 Description",
      Text = "Result 3",
      Url = "http://localhost:37082/Result3.aspx"
    });
    return toReturn;
  }
  [OperationContract]
  [WebGet(UriTemplate = "json/suggestions?q={query}",
    RequestFormat = WebMessageFormat.Json,
    ResponseFormat = WebMessageFormat.Json)]
  public JSONSuggestions GetJSONSuggestions(string query)
  {
    return new JSONSuggestions(GetSuggestions(query));
  }
}

Note how the implementation of the JSON service is simply a piggy-back off the XML one. When you’re writing XML and JSON services in this way, typically all the code will either go in one half of the implementation, or in another common block of code that both can call. The contents of the WebGet attribute are very important at this point – and you should familiarise yourself with RESTful programming in WCF if you’re going to be writing more of these kinds of services.

NOTE: In the downloadable source code, we’ve included the ‘Image’ property for each of these results, so you can see the attribute-based image data in action as well.

Testing the services

At this point you should be able to build and run without any errors. Once done, you should be able to open the url http://localhost[:devwebport]/suggestions.svc?q=Hello+World and, although you might not actually see any output in the browser, if you open the source for the current page you’ll see the XML response in the format the IE8 will be expecting.

Also, if you instead open http://localhost[:devwebport]/json/suggestions.svc?q=Hello+World, you should be prompted to initiate a file download which, when you open it in notepad, will be a JSON array of arrays as per the actual OpenSearch suggestions spec.

If in doubt, use Fiddler2 to debug the web traffic. Note that you cannot get other people to call this yet, if you’re using the development web server that is, because it only responds to requests from the local machine.

Writing the OpenSearch Description document

Again, we’re not giving a full description of the OpenSearch spec here – everything you need to do is available from the OpenSearch site, we’re just giving you the XML you need to get up and running. Add a new XML file to your web project, call it OpenSearch.xml, paste this in after the <?xml> directive:

<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/" 
                       xmlns:moz="http://www.mozilla.org/2006/browser/search">
  <ShortName>JSLabs OpenSearchDemo</ShortName>
  <Description>Expose OpenSearch on your Website, with suggestions!</Description>
  <InputEncoding>UTF-8</InputEncoding>
  <!-- used by all opensearch compatible browsers -->
  <Url type="text/html"
       template="http://localhost:37082/search.aspx?q={searchTerms}"
       method="Get"/>
  <!-- suggestions - used by IE8 only -->
  <Url type="application/x-suggestions+xml"
       template="http://localhost:37082/opensearch.svc/suggestions?q={searchTerms}"
       method="Get" />
  <!-- suggestions - used by Firefox -->
  <Url type="application/x-suggestions+json"
       template="http://localhost:37082/opensearch.svc/json/suggestions?q={searchTerms}"
       method="Get" />
  <!-- best practise to include a link to self -->
  <Url type="application/opensearchdescription+xml" 
       rel="self" 
       template="http://lostlhost:37082/opensearch.xml" />
  <!-- not required, but another extension supported by Firefox -->
  <moz:SearchForm>http://localhost:37082</moz:SearchForm>
</OpenSearchDescription>

Final Step – Wiring the OpenSearch document up for the browser

As this excellent article on MSDN describes – there are a few ways to promote your OpenSearch provider. One is auto-discovery, which is the recommended standards-based way to do it, and is supported by both IE7/8 and Mozilla Firefox 2/3. To enable auto-discovery for our demo site, open up your Search.aspx page, and add this to the <head> region:

<link title="JSLabs OpenSearch Demo Provider" rel="search"
   type="application/opensearchdescription+xml"
   href="http://localhost:37082/opensearch.xml" />

Save the mark-up – and now, open IE 7/8. Browse to /Search.aspx (no query string required) – and you’ll see the quick search box change colour:

Click on the down-arrow and expand the ‘Add Search Providers’ pop-out menu.

Confirm the dialog box that comes up (in IE8 make sure that the ‘Use suggestions from this provider’ box is ticked). Once done, expand the list again, and select the newly added ‘JSLabs OpenSearch Demo’ provider (there’ll be two very similar, it’s the one with the magnifying glass) and start typing, you should see your three suggestions appear:

If you select either of the three results, notice that they take you straight through to the Result[1-3].aspx pages, rather than simply launch the search page again with that suggestion (this is how our Job Search suggestions end up taking you straight through to the job page).

For Firefox, the process is nigh-on identical, browse to the page, the search box will highlight and you can select the provide from a dropdown list:

Again, you’ll be asked to confirm whether you want to use suggestions from this provider, which you do.

At this point you can immediately start typing in the quick-search box, and our suggestions will appear:

This is where Firefox is a bit of a let-down, however (and why our job search provider does not provide suggestions in Firefox), if you select any of these results, you’ll notice that instead of browsing directly to the URL we’re passed back in the results (like IE8), Firefox simply launches the search page with the string ‘Result 1’, ‘Result 2’ or ‘Result 3’ (it’s whichever Completion string is selected). This is a bug in the Mozilla browser, and was raised quite a while ago – we await to see if it’ll be fixed.

The other way to get your provider added to a browser is to use the non-standard AddSearchProvider method of the window.external property – and have a hyperlink or button that users can click to add the provider manually to the browser:

<a href="#"
   onclick="window.external.AddSearchProvider('http://localhost:37082/opensearch.xml')"
   >Add JSLabs OpenSearch Demo provider</a>

This is the technique that we use for our Web Browser OpenSearch Provider, primarily because we are hosting our provider on a different sub-domain to the main site.

As is mentioned in the launch article for the Web Browser OpenSearch Provider, Chrome and Safari do not support OpenSearch. Opera 9 should, according to the documentation, support the auto-discovery method of supplying OpenSearch to the web browser. Support doesn’t just have to stop at the browser, though - remember that there are websites out there which could leverage your OpenSearch capability (not the suggestions, just the basic search url) in order to better your content to a wider audience. All in all, installing OpenSearch into your website is a worthwhile effort – and with WCF, supporting the suggestions extension is surprisingly simple.

Download the source code for this article now!

Search for Jobs from your Google Desktop!

2009-07-27T11:20:13+01:00

If you just want to get going without reading this article - download the gadget now.

Soon after JobServe Labs was launched, we launched the Windows Desktop Job Search Gadget – which enables you to execute job searches, and view full job details, directly from your Windows Desktop. Immediately we saw huge interest in this gadget (as a result we updated it to version 0.2 today), which has convinced us that providing our services in ways other than the web-browser is the right way to move forward.

Not everybody was happy, though, because not everybody is running Windows as their preferred desktop operating system, and even if they are it’s still likely to be Windows XP or 2003 – which doesn’t support the Windows Sidebar platform.

So, immediately we got back on the case and started looking at an alternative Job Search gadget that could be used by even more people; and which can be accessed from Linux, Mac OS-X or Windows. Mac OS-X, like Windows Vista or 7, has it’s own proprietary Gadget platform – the Dashboard and it’s Widgets, and we did look at developing a stand-alone version for that. However, in the end, we’ve decided to go for the Google Desktop Gadget Platform as it’s the one that probably has the most users, and it is indeed available on all three aforementioned OS flavours.

What does it look like?

Here are two screenshots of the Gadget:

This is from one of our Windows Server 2003 x64 development boxes. Click on the image for a larger version.

This is from an Ubuntu 9.04 virtual machine that we’re running inside Virtual PC on a Dev machine. We used these very helpful steps to get everything up and running, and all-told it took just 15 minutes. If you have a windows domain-based corporate web-proxy, however, you might want to get your support team to allow your Ubuntu box out of it without having to authenticate (or push it through another proxy that doesn’t require authentication), as we couldn’t get web access working properly until we did that. Firefox’s proxy configuration worked fine, but the system-wide proxy configuration didn’t – there appears to be a bug with NTLM authentication.

Incidentally, if you’re running the Ubuntu Jaunty and you need to install Google Gadgets for Linux, then you should find it on the package manager in the ‘Internet’ section – there’s a GTK and a Qt version. If you’re running openSUSE, then the binaries are also included in the official repository. The GGL team have written some excellent documentation about where to get the binaries from, depending on the distribution that you run.

If you’re running Google Desktop for Mac OS-X, you should be able to use this gadget as well, as we’ve followed all the guidelines on how to ensure cross-platform functionality. Despite all this, however, there is still an element of the dark-arts about this, and we’d really appreciate any feedback from Mac users as to how successful we’ve been in delivering a desktop search for you guys.

Is it as fast as the Windows Sidebar Gadget?

In a word, yes. The code is using exactly the same JSON web service that the windows gadget uses, the only differences are:

How the UI has been implemented – since the Windows Gadget platform is html and JavaScript based, whereas the Google Desktop Gadget platform uses a proprietary XML format for UI, and strict JavaScript for application code.
How we talk to the web service. In the Windows Gadget we’ve embedded the excellent jQuery library, and use it’s $.getJSON method to get the search results. With the Google Gadget we have to program against XMLHttpRequest directly in order to be sure to maximise cross-platform compatibility.

How to use it

You have two editable textboxes to use to specify your query terms. The ‘skills’ box is what you’re looking for, and the ‘location’ box is, clearly, where you want it to be. This should not be a country – since you also have a country dropdown that you should use for this – it should ideally be a town, village, county or state. Our skills search query (and location query for that matter) supports Boolean operators (AND, OR, NOT) and quoted expressions (“Visual Basic”, “Business Objects”, “Management Training”). For example, if you want a C# job that also involves Sql Server (quoted expression), but you don’t want to work in London – then this is the kind of search you need:

The gadget will always remember your last search parameters, so if you remove the gadget from your desktop and put it back on again, your last search will already be pre-filled.

The gadget is fully resizable whether it is docked or not. The value of resizing horizontally beyond a certain width is pretty minimal, however, resizing vertically is a huge plus as it means you can see more results in one go.

The inner results list is scrollable by using the green buttons that appear at the top and bottom. We would like to have used a scrollbar for this, however, the scrollbars for DIV elements and list boxes do not appear within those elements when the gadget is docked. We could have used the Scrollbar control to implement this, however the problem with that is that it takes away valuable horizontal space in which to display our job results.

Our solution was to use the beginAnimation method of the View object when either our up or down buttons are clicked. The gadget calculates the page size, in terms of result-count, that can currently be displayed based on its height. This is turned into pixels (by virtue of the fact that each of our results is a fixed height), and then we slide the results list up or down by that number of pixels in our animation call-back. This article contains lots of examples of how to animate your own Google gadget; the thing we like the most about this is that it’s not tied down to directly visible attributes of the UI: the beginAnimation method is simply a timed slide between two values, therefore how you interpret that value is entirely up to you.

Ideas and suggestions

As always, we’ll be looking for ways to make this gadget even better to make it easier and faster to use; we also really want your ideas and suggestions for this or any other gadget or feature. You never know, you could be the source of the next idea to come out of JobServe Labs!

Sidebar Gadget v0.2 Released!

2009-07-24T14:23:28+01:00

We’ve updated our Windows Gadget – you can download the latest version here.

We’ve had a phenomenal response to the initial version of the Windows Sidebar Gadget, we’re seeing a lot of people from all over the world running searches and applying for jobs – so we’re really pleased that our hard work has been appreciated!

We’re really impressed, also, with the number of different countries that people are looking for jobs in, and we hope that those of you who experience low bandwidth to our servers are finding the response times for this search to be excellent.

As proof of our continued support of this alternative way in which you can access JobServe’s services, we’ve added a couple of new features that we hope will make the gadget easier for you to use. They mainly centre around the options dialog (screenshot taken from Windows 7 RC running on Virtual PC 2007):

Added Job Type selection, so you can now specify Permanent/Contract or both.
Added Job Age selection, so you can narrow down you searches only to jobs that have appeared in the last n days up to 7.
Added Results Per Page selection – now you can have as few as 5 jobs per page, up to a maximum of 100 jobs per page! (Note, this limit is imposed at the server-side, so any attempt to increase it, either by editing the .js files or by manually firing the query from the browser will unfortunately fail!).

You’ll also notice a Help icon on the main body of the gadget, this just offers a few pointers on how to search. Also, we have now introduced auto-update functionality – the next time we update the gadget, you’ll see a little yellow exclamation mark that you can click on, which will contain a link to download the latest version of the gadget.

The final big difference with this version of the gadget, is that it is now digitally signed by authenticode using the signtool.exe utility – and all of our future Windows Gadgets will be, too (therefore be wary of any gadgets that pretend to be JobServe gadgets). When you install the gadget now you should see ‘JobServe Ltd’ as the publisher:

You can download the new gadget from here. If you have the previous version installed, it won’t necessarily be overwritten – simply remove the old gadget from your sidebar/desktop, and then uninstall it from the Gadget gallery.

Notes to anybody who downloaded the gadget from the original article written about this gadget: The download links were changed in the old article to point to the new version at the same time that this article was published.

As always, please direct any of your comments to the feedback email at the bottom of this page!

Happy job hunting!

JobServe needs your talent

2009-07-20T23:56:00+01:00

There are great things going on in JobServe Technology and we are always on the lookout for talented, enthusiastic, results driven developers to join the team. If you are an experienced .NET developer then read on, if you are a Java Developer – ever thought what it would be like on the Microsoft side?

HANG ON : JobServe doesn’t always want only IT people – check out JobServe recruitment for other positions.

We have two positions available to join the IT Development team here in JobServe UK, working from the head office in Tiptree, Essex (not far from Colchester or Chelmsford). We have a very experienced team of developers, spanning many years of job board development but we are always looking for new blood to “stir”, “question”, “challenge” and “integrate” with our team. The coming year of development projects is nothing more than staggering and is leaving our team pale at the prospect – Can you come and help them out?

So what do we want?

Experience : ASP.NET/C#/VB.NET of at least 4 Years for the Developer Role or 1-2 years for the Junior Role

Desirable Skills : Team Foundation Server, SQL Server or other relational database, exposure to web technologies. Demonstrate clear commercial project experience.

You must be able to self-motivate, stick to tight deadlines, work very well in a team and be a top analyst.

Benefits : Developer role to £40K, Junior Role to 28K. There is a pension, performance related bonus and technically challenging work.

If you want a challenge, want to use new technology, want to make a difference in a small company with massive ideas then Apply NOW.

Simply forward your CV along with why you want to work for JobServe to labs.personnel@apps.jobserve.com

or Apply Online for the right jobs here

Building Labs – XML RPC Backend for Windows Live Writer in C# with WCF

2009-07-10T17:48:31+01:00

In the first of our series of articles about how JobServe Labs is built, we’re going to look at how we’re using Windows Live Writer (WLW) to publish our articles, and how we’ve setup a blog service internally with WCF for WLW to talk to. If you’re planning a similar deployment, or if you’re looking for a way to build page-based content management for a website, then you might want to read through – as we point you in the direction of how to build it yourself.

Why use Windows Live Writer?

We needed to be able to create rich content with the minimum of fuss, with the ability to embed content such as video, pictures etc only a few clicks away. While there are ready-made javascript-based HTML editors out there (TinyMCE and FCKEditor are two excellent and very popular examples) we tend to find that non-technical users don’t get on with them too well – many people will copy and paste from word processing applications, but inevitably the resulting content is messy and doesn’t translate to the web page very well.
Writing our own WYSIWYG X-Html editor, whilst not impossible, would have taken far too long.
With WLW, users get a recognisable interface on which they will require minimal training (a real consideration in an enterprise environment).
We can extend WLW through it’s very slim and easy to use plugin APIs, all you need as a developer is to install it, and you have the SDK.
We’re already using WLW to post to our own internal blogs, which are hosted on Microsoft Office Sharepoint, and many of our colleagues are already using this, so all we’re really doing for these guys is adding an additional information outlet for them to post to in an environment they already understand.
WLW already knows how to talk to many popular blogging engines such as Wordpress, Blogger and MetaWebLog-based engines such as BlogEngine.Net. One of our developers is already using it blog to his own personal blog, and we therefore we knew that some of our expectations could be achieved so long as we stuck to a recognised standard.

The architecture

Unlike other out-of-the-box blogging sites/engines, you will not find our blog endpoint on our website. The primary reason for doing this was to minimise attack vectors to the site – if you present a callable endpoint to the outside world then somebody will try to hack it. Anybody that could ever want to interact with the articles on our site will either be directly on our enterprise network, or connected to it remotely via a VPN.

The basic architecture, then, is:

Blog capabilities

The first stage was for us to decide which common blog functionality we wanted to support on our blog, and from there we could then determine which Blog spec we would code against. Using the Windows Live Writer default capabilities listings, we decided that we would use the MetaWebLog specification as our baseline, as it’s the closest to what we wanted. There were a couple of additional features we wanted to add, but these can be done using the <options> element of the wlwmanifest.xml file that our website presents to Live Writer – for those who are interested, here’s the complete listing from ours:

<options>
	<clientType>Metaweblog</clientType>
	<supportsPostAsDraft>Yes</supportsPostAsDraft>
	<supportsFileUpload>Yes</supportsFileUpload>
	<supportsCategories>Yes</supportsCategories>
	<supportsCustomDate>Yes</supportsCustomDate>
	<supportsCommentPolicy>Yes</supportsCommentPolicy>
	<supportsExcerpt>Yes</supportsExcerpt>
	<supportsNewCategories>Yes</supportsNewCategories>
	<supportsNewCategoriesInline>Yes</supportsNewCategoriesInline>
	<supportsMultipleCategories>No</supportsMultipleCategories>
	<supportsHierarchicalCategories>No</supportsHierarchicalCategories>
	<supportsKeywords>No</supportsKeywords>
	<supportsPingPolicy>No</supportsPingPolicy>
	<supportsAuthor>No</supportsAuthor>
	<supportsSlug>No</supportsSlug>
	<supportsPassword>No</supportsPassword>
	<supportsTrackbacks>No</supportsTrackbacks>
	<supportsPages>No</supportsPages>
	<supportsPageParent>No</supportsPageParent>
	<supportsPageOrder>No</supportsPageOrder>
	<!--additional live writer options-->
	<supportsEmptyTitles>No</supportsEmptyTitles>
	<requiresHtmlTitles>No</requiresHtmlTitles>
	<requiresXHTML>Yes</requiresXHTML>
	<supportsScripts>Yes</supportsScripts>
	<supportsEmbeds>No</supportsEmbeds>
	<characterSet>UTF-8</characterSet>
	<maxCategoryNameLength>40</maxCategoryNameLength>
	<supportsAutoUpdate>Yes</supportsAutoUpdate>
</options>

If you’ve had any experience customising Live Writer from the manifest file, you might be wondering why we are specifying values that are the same as the defaults for the MetaWebLog spec. Part of it is to ensure that if Live Writer’s understanding of this spec changes in a future version, it’s understanding of our blog will not. It’s also to make it easier in the future should we wish to add capabilities – changing an existing value from No to Yes is simply faster than having to write the element in first.

An important point to note, if you’re going to develop your own blog engine like this, is that the MetaWebLog specification implies the Blogger specification as well, and WLW mixes it’s XML RPC calls between the two for the different features where the MetaWebLog RPC methods supersede the Blogger methods.

As an example, it will use the metaWeblog.editPost method instead of the blogger.editPost method when you re-publish an existing post; but it will use the blogger.deletePost method to delete a post because MetaWebLog doesn’t define an alternative method for doing so.

XML RPC

The next step was to decide how we were going to expose the blog to Live Writer – which is expecting an XML RPC endpoint to talk to. There is a very popular .Net Framework implementation of XML RPC, called XML-RPC.net, which we did look at, however we are moving all of our network coding over to WCF because your code is then not tied to a particular transport or protocol.

The problem with that is that WCF does not come with built-in message formatters and operation selectors compatible with XML RPC; so we were looking at writing our own. As we all know, however, as developers, we must always exhaust the community first to see if somebody else has done it, and to our joy we stumbled across a project by Clemens Vasters – a senior developer at Microsoft – where he’d been developing just such a thing for DasBlog. The zipped solution, which he talks about and links to on his blog, includes WCF operation selectors and formatters for XML RPC support in the same way that you write any other WCF hosted service (i.e using the ServiceContract attribute and OperationContract attribute). All we did was to take his ServiceHost setup code and move it to a core component that we could then host either in a console application (as in his example), which was great for development, or in a windows service for when we actually released it to the rest of the business.

Helpfully, he also includes WCF-contracted interface definitions (and the corresponding classes for their related structs) for Blogger, MetaWebLog and MovableType, as well as an in-memory implementation of his Blog Engine that runs from the command-line (which Live Writer will happily connect to). We didn’t use these directly, but if you’re following the same path as us, then you can go straight ahead and do so. Clemens stacks his interfaces up like this:

//define the interface for the actual blog api that will be called
[ServiceContract]
public interface IBlogAPI : IMovableType
{
}
//define the interface for the IMovableType interface
[ServiceContract(Namespace = "http://www.sixapart.com/developers/xmlrpc/")]
public interface IMovableType : IMetaWeblog
{
	//example
	[OperationContract(Action = "mt.setPostCategories")]
	bool mt_setPostCategories(
		string postid,
		string username,
		string password,
		Category[] categories /* MovableType category */ );
	// rest of the method definitions ommitted.
}
//define the interface for the IMetaWebLog interface
[ServiceContract(Namespace = "http://www.xmlrpc.com/metaWeblogApi")]
public interface IMetaWeblog : IBlogger
{
	//example
	[OperationContract(Action="metaWeblog.editPost")]
	bool metaweblog_editPost(
		string postid,
		string username,
		string password,
		Post post, /* MetaWebLog post struct */
		bool publish);
	// rest of the method definitions ommitted.
}
//finally, define the base interface for IBlogger - the base API used by all
[ServiceContract(Namespace = "http://www.blogger.com/developers/api/1_docs/")]
public interface IBlogger
{
	//example
	[OperationContract(Action="blogger.deletePost")]
	bool blogger_deletePost(
		string appKey,
		string postid,
		string username,
		string password,
		bool publish);
	// rest of the method definitions ommitted.
}

One of the challenges is that many of the specifications share ‘struct’ definitions that are called the same thing, but which are subtlely different. The MetaWebLog Post struct, for example, is not the same as the Blogger Post struct. Clemens’ code namespaces each of the above interfaces and the classes that they require according to the blog API they implement. As a result, you will find yourself implementing some methods from different interfaces which use slightly different structs even if they have the same name. Thankfully, Windows Live Writer will always send the right struct version for the particular method it’s calling!

Now, to setup your real blog API, you simply declare a class that implements the root IBlogAPI (it’s actually IBloggerAPI in Clemens’ code – but that’s easy to confuse with the Blogger interface!), get Visual Studio to stub out all the interface methods you need, and then start coding against your database. We used Linq to Sql for our database interfacing layer because it’s really quick to get up and running, and is resilient to schema changes; it’s also hack-proof. Read through Scott Gu’s excellent series on using Linq to Sql.

We’re not going to go through hosting the service and the C# code required to do that – it’s all in Clemens’ project.

Bugfixes required to Microsoft.Samples.XmlRpc

During development, we discovered a couple of minor bugs in the XmlRpcDataContractSerializer class – which we had to patch for our use. Unfortunately, we can’t make the amended version of the file available here as it’s got Microsoft’s Copyright on it, so we have sent our amendments to Clemens and hopefully he’ll patch the release that we’ve linked to above. To patch it yourself, open up the file XmlRpcDataContractSerializer.cs and make the following changes:

/* -----------------------------------------------------------------
 * Change 1: Line 65, adding else statement to if block that starts
 * if (dataMembers.ContainsKey(memberName))" on line 44:
 * Fixes: A crash that occurs if a struct field is sent that is
 * not part of the class being used to represent the struct in .Net
 * -----------------------------------------------------------------*/
else
{
	reader.Skip();
}
reader.ReadEndElement(); // value
reader.MoveToContent();
reader.ReadEndElement(); // member
reader.MoveToContent();
/*-------------------------------------------------------------------*/
/* ------------------------------------------------------------------
 * Change 2: Line 128, Replace case statement which deserialises
 * an XmlRpc DateTime value
 * Fixes: Crash when parsing DateTime values passed by Windows Live
 * Writer when setting an explicit publish date on an article.  
 * XML RPC date format is not a .Net date time format.
 * ------------------------------------------------------------------*/
case XmlRpcProtocol.DateTime:
try
{
  returnValue = Convert.ChangeType(reader.ReadElementContentAsDateTime(), targetType);
}
catch
{
  string dateTime = reader.Value;
  //have to fix the current reader position (dirty fix).
  reader.Read();
  reader.Read();
  reader.Read();
  returnValue = XmlConvert.ToDateTime(dateTime, "yyyyMMddTHH:mm:ss");
}
break;
/*-------------------------------------------------------------------*/
/* ------------------------------------------------------------------
 * Change 3: Line 249, replace the else-if
 * Fixes: This is the mirror fix to change 2 - ensures that outgoing
 * DateTimes are formatted correctly.
 * ------------------------------------------------------------------*/
else if (valueType == typeof(DateTime))
{
  writer.WriteStartElement(XmlRpcProtocol.DateTime);
  //modification here to write a 'proper' Xml RPC DateTime.
  if (value is DateTime)
    writer.WriteValue(((DateTime)value).ToString("yyyyMMddTHH:mm:ss"));
  else
    writer.WriteValue(value);
  
  writer.WriteEndElement();
}
/*-------------------------------------------------------------------*/

Layout and Preview modes for WLW

So now we have our blog service ready to go (assuming you’ve done your database and your XML RPC Endpoints are setup) the last thing we have to do is to tell Live Writer where our blog is, and what our pages look like.

Before you begin this bit, you should have a website that can display your blog posts – at a minimum this must have a root page which shows either all posts, or the most recent n posts – the top post should be the one that was posted most recently. Use this as your blog’s homepage from WLW’s point of view. Ours is our All Articles page.

For the best editing experience in WLW you should also have two additional Html Files, one for WebLayout view (editing view in WLW) and WebPreview view (the preview shown in WLW). The Live Writer Team have written guidance on MSDN as to how to make these two files – they use placeholders for the title and the article body – so the most basic version of these would simply look like this:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<body>
	<h1>{post-title}</h1>
	{post-body}
</body>
</html>

Live Writer simply substitutes the {post-title} and {post-body} macros for the content that it’s got from the current post – if the page requests CSS or Image files, then WLW will go and download them.

From our experience with this process, we also have a few suggestions and guidelines for you to follow regarding these files:

WebLayout View

If your site has a graphical theme and funky layout (ours, for example uses a master page that puts the header and footer on, surrounds most content with a rounded border, and sticks a load of other links on), you’ll typically leave it off this page so as to maximise the default editing experience.

For example, this article looks like this in my editing view:

Note how the title is much larger than it appears on this page, and how there are no borders anywhere. The font and link styles, however, are maintained.

WebPreview View

This one should be as close to the design used for the page that displays a single article (in this case the page that you’re looking at right now) – ours, for example is an aspx page that includes the master page and a lot of the extra HTML layout content.

Because you’re likely to be throwing all manner of CSS tricks at this page, it’s possible that it’ll not be identical to the actual web page; my preview, for example, takes a few liberties with the placement of our Feeds and Categories panels on the right hand side (WLW does a good job of it’s HTML compliancy, but it’s not perfect). However, the important thing is that it accurately displays the post inside the rounded panel surrounding the content:

The manifest file

Now that you have your preview and layout htmls, you can write your manifest file. From the information that we’ve mentioned so far, you’ve almost got what you need to do it. First, I’ll link again over to the Windows Live Writer Customisation API topic on MSDN, so you’ve got all the material to back you up.

Let’s assume that you are going to implement MetaWebLog exactly as is, with no customisations. Let’s also assume that your homepage is default.aspx, and that your WebLayout and WebPreview htmls are called ‘WebLayout.html’ and ‘WebPreview.html’. Your manifest file is going to look something like this:

<?xml version="1.0" encoding="utf-8" ?>
<manifest xmlns="http://schemas.microsoft.com/wlw/manifest/weblog">
	<!-- leave the options bit out, because we're sticking with what
		live writer uses as the defaults for MetaWebLog -->
	<weblog>
		<serviceName>My Blog</serviceName>
		<homepageLinkText>http://my.domain.com/default.aspx</homepageLinkText>
	</weblog>
	<views>
		<default>WebLayout</default>
		<view type="WebPreview" src="/WebPreview.html"/>
		<view type="WebLayout" src="/WebLayout.html"/>
	</views>
</manifest>

As the MSDN documentation states, if you place this file in the root of your website and call it ‘wlwmanifest.xml’, then Windows Live Writer will be able to auto-detect it. If, however, you need to point Live Writer specifically at a particular file (we actually have two Blog endpoints for our site, one for our Articles and one for our Projects, so we need two manifests), then you use a <link> tag in the <head> section of the blog’s homepage. Here, it’s the ‘rel’ and ‘type’ attributes that do the magic:

<link rel="wlwmanifest" type="application/wlwmanifest+xml" href="MyWlwManifest.xml" />

With this in place, Windows Live Writer can auto-discover the manifest that you want it to use.

Final Step – Adding your Blog to Windows Live Writer

If you’re at this stage:

1) You’ve got a website that has a manifest file for Live Writer to download as per the last section – let’s say that the address is http://localhost/default.aspx for homepage.
2) You’ve got your blog API listening on an address on a local machine as per the section about Xml Rpc. Let’s say that’s on http://localhost:9999/blog/api.

Then you’re ready to go!

Go to the ‘Blogs’ menu of Live Writer and select the bottom option “Add Blog Account”
Select ‘Other Blog Service’
Set the web address of the blog to http://localhost/default.aspx
If you’ve added permissions to your blog, then set the username and password. Click next.
Now WLW wants to know what type of provider it’s going to be talking to – select “Metaweblog API”
In the address box type http://localhost:9999/blog/api, click next again.

That should be it (other than confirming your blog’s name). If Windows Live Writer shows a message about making a temporary post in order to detect the theme of your site, then either it hasn’t picked up your manifest file, or it’s not been able to grab the WebPreview and WebLayout files referenced in the manifest. Review those URLs (ours use absolute paths to ensure that there can be no confusion) and try again (best to remove the account and add it again).

Debugging the XML RPC Calls

As with all situations where you have an application calling another by a remote mechanism, it’s nice to be able to see what is actually being sent to and fro. What we’ve done during development is to use Message Logging and Tracing in WCF (however, it’s not exactly real-time, because until your app shuts down it doesn’t actually sign-off the trace files, causing the Service Trace Viewer to throw errors) and to use Fiddler to debug the Http traffic travelling between Live Writer and your service. Unlike Internet Explorer, which automatically uses Fiddler when it starts up, you have to tell Live Writer to use your local proxy. There’s a setting in Tools –> Options –> Web Proxy which controls this; as soon as you change that you’ll start seeing your Xml RPC Payloads going to and fro.

Conclusion

There are a lot of content management systems out there, and they all offer a huge amount of features. One of the primary areas of distress for anybody wanting to roll out such a site, however, is the ability to get content, update it and post it again in a way that offers the most flexibility. By using a rich WYSIWYG offline editor like WLW you get a whole host of features immediately after installation, plus you also get a platform upon which you can build very quickly, thanks to its plug-in interface. We have a plug-in purely for sending up additional files (like the Vista Sidebar Gadget .gadget file) to the blog, because WLW only automatically uploads media content. Developing this took one day to achieve.

After hooking WLW into your blog, you’re then free to code the workflows behind the service that it uses. This post, for example, will be posted to our blog as a draft for another member of the team to open and review. They can use WLW to download the draft from it’s ‘Recently Posted’ feature. If that person is happy with that content, they can send it back to the blog as a published article simply by hitting the ‘Publish’ button.

We also have some role-based security behind the scenes, which hangs off of Active Directory, which means that only some people are allowed to actually publish the articles. The rest are restricted to posting drafts, which must then be ‘properly’ published by someone with permissions.