Here at XING we’ve been working on implementing OpenSocial since 2007. In May 2009 we launched the first XING applications on our platform, and have also hosted apps from third-party providers as part of the XING Partner Ecosystem since July 22. Our partner applications add a number of business-relevant functions to the XING platform such as online conferences, project management, calendars and presentations.
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. (more…)
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…
Agile development processes like SCRUM (confer Scrum @ XING – a case study) raise the bar for quality assurance professionals. The biggest challenge we need to overcome is getting used to release cycles of two to four weeks.
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. (more…)
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. (more…)
Susanne Reppin on 13.11.2009 at 17:46h CET
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. (more…)
Christian Burtchen on 13.11.2009 at 10:24h CET
Just to make it perfectly clear from the outset: There is no virus on the XING platform, nor is there any code that might be damaging to your computer. Under certain – very specific – circumstances, you might find though that your virus scanner sets off a false alarm if it hasn’t been updated for a long time.
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. (more…)
There are many html forms on XING – when you sign up, when you write a message, or when you discuss in a group. We do most of our form validations on the server side. This allows us to apply complex validations, prevents code duplication, and apply security checks.
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. (more…)
Sebastian Röbke on 31.08.2009 at 13:42h CET
As you probably know, boolean values in software systems represent the states “true” or “false”. For some use cases in a software application, you may need a lot of them.
To give you a very simplified example, imagine a form where the user can check which languages he or she speaks:
XING´s official twitter account