Internet Explorer 9 and its features are another great example of this paradigm, which is why we instantly decided to implement its features on our platform. The seamless – but not obtrusive – integration of core website functionality in the actual browser window and thus in the operating system itself is right in line with the general trend of “living in the web”, an ever-ongoing process whereby the overall experience on the computer becomes the web experience itself. It actually reminds me of previous ideas such as the Active Desktop that came with Internet Explorer 4 (wow, how time flies… XING didn’t even exist back then!) – or, of course, the Outlook Social Connector, which you can also use to keep up to speed about what’s going on within your XING network.

XING now supports Microsoft Pinned Sites, which allows any website to be added to the user’s Start Menu using browser commands available in the IE File and Page menus (Add to Start Menu), or by dragging and dropping the address bar pin icon into the Start Menu. This functionality means that XING.com can be listed in the “All Programs” menu, allowing us to provide a fully branded experience similar to any native Windows application.

Once the user has pinned our site we support Jump List Tasks, which are application-specific actions tailored to XING.com. We provide a set of static URIs that can be accessed at any time even if the browser instance isn’t running. What’s more: Tasks provide a mechanism for XING end users to easily access our core functionalities even when they are not on the site. XING also enables end users to quickly access Messaging, Events, Groups, Contacts and the Jobs section.

On top of this, XING communicates certain notifications to end users by displaying an overlay icon above the taskbar button. MS SiteMode provides an API to surface overlay icons. This functionality is actually used to notify our users of new private messages and new contact requests. Overlay icons are designed to grab users’ attention when the view to the Pinned Site browser window is blocked. This might be when the browser window is minimized or when the browser window is concealed by another window.

We like nothing better than making networking easier and saving time for our users, click by click. We’ve recently done a lot of intensive polishing up of the platform – and the next few months will bring even more cool stuff for our back-end front end, and most importantly, for you. Because, as we like to say: All business is social.

And it’s not just our partners who are driving things forward – we are also continually developing the system. You can read about the latest developments in our weekly Release Flash which lets you know about all of the improvements we have made to our apps. For the last few weeks we’ve been working on a monster of a project which involved updating the XING OpenSocial infrastructure from version 0.8 to 0.9. This may only seem like a small step, but in fact it’s a proverbial giant leap for the infrastructure.

Our Aim: Silent Migration

So what does updating to OpenSocial 0.9 mean for XING users? Well, nothing for the meantime as we want this migration transition to take place silently. In real terms this means that all existing apps on OpenSocial 0.8 will continue to run on the latest version without the developers making any changes. So a key part of our work is to ensure backwards compatibility within the XING Partner Ecosystem.

Technical Improvements in OpenSocial 0.9

The update to version 0.9 also adds a number of new features to improve the quality of our apps even further. Features include templates for various frequently used areas of the user interface, and tags (small code snippets) that can be added to certain entities using OSML (OpenSocial Markup Language), an SGML-based language, in much the same way as with HTML. This means that the code used for typical OpenSocial app functions is much shorter, with one such example being <os: PeopleSelector> which is used to select contacts.

So what is the benefit for you as a user other than having access to a standardized interface? Firstly, developers and third-party users have access to these standards, which in turn reduces the amount of time required and the number of potential sources of error. This results in more resources being available to continue developing the app.

The latest version of OpenSocial now also includes what is known as data pipelining, which in principle is a simplified and standardized request within the app based on the user’s social graphs. This was also possible in the past, but only by using wieldy JavaScript routines.  User privacy is not affected by the pipeline with users retaining their previous privacy settings.

The switch to OpenSocial 0.9 is due to take place in March 2010. Please visit the OpenSocial Foundation website or the XING OpenSocial Group for more information.

You can then see all our positions (and the Boolean value for their awesomeness) by inspecting the Object:

Feel free to check the source code here.

If your individual coding awesomeness also gets a 1 – apply now! Of course, there’s still the conventional way as well – the careers at XING website. This article – and many more can also be found in the XING Devblog!

Hooray: it’s been a long time in the making, but today we’re finally launching our XING Developers Blog, where you can keep in touch with our developers and all the stuff they’re up to, including but not limited to working with languages and platforms like Ruby on Rails, Perl, Java or Javascript.

Head over to devblog.xing.com or subscribe to the RSS feed!

These peaks tell us something...

I love monitoring. This is no news to all my coworkers at XING, as I have a reputation in the company for being the guy who even graphed his daughters diaper weights… anyway, here’s one of my favorite graphing applications: Monitoring our site via user comments on twitter.

Last Thursday we had a really short network glitch around 2pm due to some necessary ad hoc maintenance. Parts of the site were down for roughly ten minutes. As I said, only certain parts of our platform was down. But still, our users noticed it (of course!) and twittered about it (see the image on the right).

For several months I have been playing around with a graph showing the number of XING tweets per hour – normally around 30 (in case you’re bad at math, that’s one #XING tweet every two minutes), but whenever it peaks, that’s an indicator of something, well, irregular. Just have a look at 2pm on Thursday: the network switch, I mean glitch…

Now, I only have to find a way to plug the graph into a completely automated alarm of some sort…

Even in teams that are running smoothly there’s often not enough time besides the regular quality assurance (QA) of newly developed features to execute manual regression tests. Every new line of code that’s added to a program has the potential to break existing functionality. Therefore it’s not enough to test new functionality – the existing one also needs to be tested. This is done by re-executing test cases from previous development cycles and called “regression testing”. Of course engineers write automated tests themselves that should prevent existing code from breaking but those tend to be on a unit or component level. System tests that use the frontend to enter data and verify all layers take a lot of time to run and would hinder engineers in their daily development work.
The usual solution for this problem consists of testers creating automated regression tests.

The tools for regression testing

The QA department at XING has developed a framework, which is used by testers inside project teams to create regression tests. This framework is based on TestNG and Selenium.

TestNG is a JUnit-like test framework that (besides the usual unit test capabilities) makes it possible to assign test methods to groups.  A test method that’s testing a search functionality in a backend interface will be assigned to “search” and “backend”. Since the test method is run in short acceptance tests it will also be assigned to “acceptance”. These groups can be used to create different suites, filtering all test methods for certain groups. That way we’re able to run short acceptance tests (filtering for group “acceptance”) and full-blown system tests (no group filtering) from the same test code. It’s also possible to run a test that focuses on parts of the system, e.g. the search.

Selenium is a test engine for most common browsers. While a lot of the web testing frameworks operate on a HTTP level and verify against the HTML code of a website, Selenium acts like a real user inside the browser. This is what actually allows us to test websites like XING with a high amount of JavaScript and AJAX.

We have now extended these tools quite heavily, although they were very powerful in the first place. The extensions start with improved logging mechanisms (results are written both in a database and our wiki) and don’t stop with default methods for the core functionalities of the XING platform (e.g. login and logout).

Automated test cases and their advantages

A usual automated test case looks like this:

@Description("TC-UC5-01-01\nsearch for string that is not available (neither company nor have)")
@Test(groups = { "frontend", "search" })
public void TC_UC5_01_01() {
String keyword = "abcdefghijklmnop";
login(TestUser.dont_care);
openCompanyPages();
searchCompanyByKeyword(keyword);
verifyCompanyCount(0);
verifyCompanySearchNoResult(keyword);
}

This has a couple of advantages:

1. The first thing to notice in this example is the speaking names of the methods. These shall ensure that even people without a deep technical knowledge understand what the test is about. This is especially helpful in case of a failing test.
2. Another advantage of these methods is the separation of test workflow and actual HTML frontend. Maintenance efforts are greatly reduced this way, since frontend changes lead to a change in a single isolation method instead of many changes in multiple test workflows (see below)

public void openCompanyPages() throws IOException { String locator = "//*[@href='/companies/']"; waitForElementIsPresent(locator, Timeout); clickAndWait(locator, Timeout); }

3. The third advantage can be found while writing the automated tests. Since the workflows use the isolation methods, they can be created without having to use the actual frontend of the application. As soon as the frontend is available the isolation methods need to be implemented and the tests can be run.

In some sprints we managed to have the automated tests up and running before the manual testing finished.

The automated regression tests created by the project teams are executed on a daily basis in addition to the tests written by the engineers, to achieve a maximum of resistance against regression defects.

A recent example: Company profiles

Regression tests tend to grow over the lifespan of a project. In the past half year we’ve been automating more than 500 test cases that form part of the “Company Profiles” project. This is equivalent to about 60% of the specified manual test cases and takes about two hours to execute. The tests written by engineers, by comparison, consist of 330 test cases and take 83 seconds to run.

As you can see by the spikes in this chart, the regression tests found some errors which were then successfully fixed before the release. Most of the “noise” coming from errors and failures persistent throughout the whole chart can be attributed to an unstable server that the tests were executed on. This noise remains constant even as the amount of test cases increases, keeping the investigation efforts also at a constant level.
Using the powerful logging mechanisms we have in place it’s easy to determine which tests do more harm than good. These will be made more robust and if that’s not possible they will be deactivated.

Having an extensive suite of automated regression tests in place gives QA professionals both freedom and security: freedom to concentrate on the newly developed features and security that the old features are still working as intended. Using the techniques mentioned above, the costs for maintenance are lower than the costs for manual regression tests and a lot lower than the costs for bug fixes.

One week after the GoLive of the second version of Company Profiles we can see that the effort involved in regression test automation and manual testing was well worth it. There was a total of three reported bugs, all of them minor and fixed within a week. Compared to 624 person days of development effort, three bugs really are negligible.

XING is fully available 99.85% of the time.

It happens pretty rarely, but sometimes our platform is affected too by operational faults and malfunctions. Of course we try to keep these hiccups to an absolute minimum. Our content is stored and supplied from two different data processing centers for instance, which means that our users can be re-routed from one to the other dependently on demand and performance.  All systems have a failover cluster operation guaranteeing high performance and stability, as well as having sufficient reserves to cope better with peak loads. Making sure our platform is both available and fast is our number one priority.

Sometimes though, like last Wednesday’s morning for instance, we do encounter unforeseen problems. There isn’t an IT system anywhere that is 100% fault-tolerant – there will always be systematic single points of failure that will send part or all of the entire system crashing with them. In this latest case a defect network component corrupted a mechanism, which was specifically required to safeguard against failure (Spanning Tree Protocol). We will be analyzing and intercepting this error to make sure it doesn’t crop up again.

A look at the figures for the past twelve months shows that we are very close to our high targets, an average uptime ratio of 99.95%. In other words, this means that XING should not be offline for more than four hours and 2 minutes over the entire year. Or to put it yet another way: This is equivalent to around 44 seconds a day. Crashes affecting just certain parts of the platform have also been included in this statistic.

Here are the availability figures for the past twelve months:

To form a meaningful graph from these figures the vertical axis needs to be scaled up dramatically in order to see any fluctuations at all:

Chart: XING availability during the last twelve months.

Despite this record, every minute of downtime is a blow to us – as we know how important it is that our members can send messages, make contacts and network at any time. That’s why we’ll keep doing everything in our power to maximize stability and availability of our platform.

Susanne Reppin (left) and Dr. Johannes Mainusch on the wjax stage.

Just how agile is XING? How agilely do we feel? At this year’s w-jax 09, Johannes Mainusch and myself talked openly about the XING culture, what kind of people we are, what we’re aiming for and what’s important to us. XING releases weekly updates on the platform, innovating therefore all the time during ongoing operation of the platform. We don’t want to have to put a halt to anything, and not when it comes to agile software development either.

XING already develops projects effectively using Scrum (see also Scrum @ XING – a case study). Alongside this, we’ve been working for nine months to put Kanban in place for one our maintenance teams – as both a methodology and philosophy. The initial idea for this came from Ralf Wirdemann, who’s an agile coach. Selecting Kanban fits in with our belief in agile and lean software development and to drive this forward in the future.

People took a great interest in our speech (here’s the slideshare and our PDF with notes, both in German). We explained why Scrum is so well-suited to our project work, as it protects the team from disruptions during the sprints – but that precisely this protection is contra-productive when applied to a team operating in close interplay with live operation of the platform. Kanban is considerably better suited to integrating disruptions – which bugs are after all – in an ad hoc way, and is therefore ideal for a maintenance team.

One of the major success factors here is of course the team itself. All team members were already experienced in agile development and wanted to learn more in a professional context. After about six weeks we were all surprised at how much more effectively and fast we could now go about our daily work.

Please note: The full talk held at the w-jax 2009 in Munich will be published in the next few weeks by w-jax.

The reason: A module we have developed ourselves that serves to load files in a browser once the page itself has already been loaded. This is useful because it means we don’t have to send all functionalities and graphics that might possibly be used through the network at once for every page accessed, which saves you a lot of time waiting for pages to load. If you then decide to use a feature or function that isn’t yet loaded – such as the photo upload in your profile, this small additional feature can then be loaded separately.

The browser feature that our module accesses posed a security loopholes in earlier versions of Internet Explorer. You can read more about this here: Microsoft Internet Explorer onreadystatechange Memory Corruption Vulnerability.

The good news is that Microsoft solved this problem in their own browser some time ago. (It might be worth you visiting windowsupdate.com to make sure your operating system and Internet Explorer are both fully up-to-date.)

If you use an outdated version of the virus scanner F-Secure though, which has not received an update since the removal of the security loophole in Internet Explorer, it will show you a false alarm if you use the Microsoft browser.

Björn Kaiser, one of our software experts, had this to say about the matter: “We did everything in our power here to make sure we avoided any major difficulties here. Even though it wasn’t a security breach at all, we still didn’t want to unsettle our users with nonsensical warning messages from a virus scanner that wasn’t updated. He spent three days trying to pinpoint the exact source of the problem, combing through 60,000 lines of Javascript code to locate the one line that triggers the warning message. One harmless line, lots of work! Thanks to my colleague Ingo as well for all the great debugging he did …”

Doing without onreadystatechange was out of the question. This would have meant that certain modules wouldn’t work at all anymore. The solution our developers came up with was relatively simple in comparison: Thanks to

var handler = ["onr", "eadystatec", "hange"].join(“”);

the virus scanner no longer recognizes the supposedly bad “onreadystatechange“. The string function join enables the components to be brought together and implemented though – without triggering the false alarm.

There was of course no danger to your data or computer at any point in time here. We contacted the manufacturer too to make sure that this was in fact a case of a false alarm.

Having said this you should make it a top priority, in your own interests, to update your virus scanner to the latest standards. At the same time we’ll continue to do everything to ensure the most secure networking possible on our platform, without any unnecessary warning messages.

This works well – you define the requirements for the specific field (such as <input>) and Rails returns the page with an error message, also highlighting the corresponding field in red. Sounds good, but that’s actually where the problem is. Rails surrounds the field with a <div> that is styled via CSS.

This additional <div> may lead to CSS problems especially in pixel-precise layouts such as the XING html forms, it may break the HTML structure – and it will add completely unneeded DOM complexity.

Changing how Rails handles fields with errors

The technical details of how we solved it follow. We were not the first ones to encounter this problem, inquirylabs also talked about (and solved) it in their blog post Highlight background of fields with errors. The basic idea is rather simple: We rewrote the method Rails uses to handle form field errors to create cleaner html. The best solution we can think of is to add a class directly to the error elements, and that class has styling to border the error fields in red. No added DOM elements, no more broken structure, just clean code.

Here is the default rails html output

<div class="fieldWithErrors">
<input />Test</div>

Here is what our changes output

<input class="input-error" />Test

Luckily, Rails already provides a simple entry point for cleaning things up. In active_record_helper.rb in the actionpack gem, there is a class variable defined @@field_error_proc, which can be redefined to apply custom error handling on the html input fields. We’ve uploaded the code to github: http://github.com/xing/classy_field_errors.

It’s a plugin, so just:

• script/plugin install git://github.com/xing/classy_field_errors.git
• Put the css contained in field_error_proc.css in your base css file

The method we call inside the block, does exactly what we want. You pass it an element and a css class. It then applies that css class to input, textarea, or select elements, either adding the class to the existing classes or adding a class attribute to the element.

The method itself just calls the HtmlElement class method add_css_class which does what you’d think it does: It instantiates an HtmlElement object, adds the class passed into the elements and returns the changed html_element (which is really a string).

So, with the added class, we can do the same error highlighting, but without any added DOM complexity and with the intended semantic separation of HTML for content and CSS for styling.

Our solution produces the same basic results as inquirylabs, but also took care of 2 edge cases:

• it only adds the CSS class if the element doesn’t have it already, so in the rare case that an input field has two errors, the code remains clean
• the code also works with self-closing <input/> tags

Thanks to Ladislav Martincik, Sebastian Roebke, Mark Schuette and Hendrik Mans who all contributed to making this code highly efficient and clean.