First things first: XWS is not another acronym for an XML-ish thing like XSL or XUL; it stands for XING Web Services. We’re the team that’s currently building the XING API to be rolled out in the near future.
One of the most important things for us when building the native Android App for XING is to give users the best experience possible when interacting with the app. This also means giving the users the feedback they require so they know that the button they clicked on actually worked. What makes things a little more complicated for us is that we “talk” to XING through an API (meaning we make requests and have to wait for responses to be sure that the call worked), and many of the calls from smartphones are effected via 3G networks or even slower ones, meaning that the app doesn’t really know if the call was successful or not until it receives a response with a success message.
“The test plan is dead!”
This was the opening remark that James Whittaker (Engineering Director at Google) started with at a conference we attended last November. Among the audience, most of the people had at some point created test plans, but very few of them still used them even after a short period of time. Read the rest of this entry »
Does frantically hammering away at your keyboard for hours on end sound like a typical day to you? Well, that’s not the case with us developers here at XING as we’re a really creative and professional bunch who like to have fun at work. Read the rest of this entry »
First of all, what is a merge conflict?
When working with a “version control system” (VCS) such as CVS, SVN or GIT, merging is a daily task. Your developer colleagues also work on their features and commit code. To keep your local version up to date you need to “pull” and “merge” their work on a frequent basis.
There can be several reasons for this. Here are the most common:
This is the most trivial one. Let’s look at an example involving a .js file:
796: function foo(){ 797: fooFoo(); 798: } 799: 800:
About a month and a half ago I had the first contact with my boss to be after talking to a friend of mine who already worked for XING. Instead of a phone interview we met in a café and chatted in a nice atmosphere. Two interviews later (another one in a café with my boss to be and the more common interview together with human resources and two of my future teammates and a programming exercise) I got an offer and we settled for me to start in June. I was chuffed to pieces about my new job and couldn’t wait for it to begin! Reflecting on the interview I was amazed about having had the chance to meet my future teammates to see if I’d like to work with them and vice versa. In my opinion it’s essential to fit into a team. And to see that my new employer thought it to be important, too, was a good sign of how XING values their teams and teams’ decisions.
My first day was awesome (a word that would later prove to be one used a lot at XING whenever great things happened). I met a lot of awesome(!) people, got a tour of the two buildings and 8 and a bit floors in sum, the different departments and was introduced to my team (the jobs team) of course. My desk had some flowers welcoming me and my MacBook that I “ordered” beforehand plus all the logins and accounts were all ready for me to get started. I was amazed to have one login fit them all – no delays by having them set up one after the other – awesome, indeed.
Very often while reading the web you’ll come across blog posts and specs that mention all these new JavaScript APIs and elements offered by HTML5. Having said that, such elements are still used rarely due to the fact that specs tend to change or browser vendors only partly implement them.
Graceful degradation is the keyword. By using JavaScript we can offer a pretty similar experience. The first thing we note is that the details / summary functionality only work in Chrome at the moment so all other browsers will fall back to a simple solution.
The main idea we had for network news in the XING Android App was to emulate the platform’s behavior as it is quite robust and includes a lot of information and clickable content, as well as interaction options.
The simplified structure of each of the activities goes something like this: ACTOR performs a VERB with an OBJECT.
The most-common actors (entities which can trigger an activity) are things like XING users, companies, events, etc. Each of these can in turn perform a VERB, which includes things like “add as contact”, “join group”, “share”, etc. Finally there is a “recipient” of these verbs or objects, which can be groups, job ads, other XING users, links, etc.
As you can imagine, a large number of combinations are possible as XING users can join a group, post a job ad, recommend a link, etc. And to add some extra fun, it is possible for an item to have more than one actor as well as more than one object. So, for example, “David Montiel has joined the following groups: Group1, Group2 and Group3”, or something like “David Montiel and Juan Gomez have joined the Group1 group”.
On larger platforms like XING there are many JavaScript modules and helpers which are bundled into a single file for performance reasons. Since you do not necessarily need most of them on every page it would be great to be able to only load such files when they are actually required. The advantage for our users is that they can work faster with the page, less data is loaded initially. We investigated this for quite some time and came up with a mechanism we call Requirer. Normally you load JavaScript files by placing a script tag into the head.
As you can imagine, we use a lot of JavaScript every day so we need it to be easily accessible from anywhere. So let’s have a look at an example:
<head> <!-- bundled file with MyClass and many other classes --> <script src="path_to_all_classes.js"></script> </head> <body> <div id="expand-me">Some hidden content</div> <script> new contentExpander("expand-me"); </script> </body>
Summary
The aim of Absurdity is to give you a simple yet feature-rich way of conducting split testing. It offers multiple variants, multiple metrics, and multiple tracks per user. When writing it I favored explicit over implicit, and pushed any methods you should need to a single external class: Absurdity.
It also comes with a display-only backend interface, available at /absurdities, where you can access the results of any experiments. At the moment it only supports redis, 1.2.6 and higher, for backend storage of the experiments and metrics.
Usage
To get Absurdity set up, please refer to the README at github.There are also examples of usage there, but I consider this one of Absurdity’s strengths, so would like to highlight it here.
In “daily” usage you will only need to use 2 methods: track! and variant. “variant” will return which variant a particular identifier should receive for an experiment. Why is this interesting?
Well, it means you could vary which experiment a user sees based on something besides his or her user ID, such as language.
For example:
Absurdity.variant(:my_experiment, language)
or
Absurdity.variant(:my_other_experiment, current_user_id)
And track! is just as simple:
Absurdity.track!(:my_metric, :my_experiment, current_user_id).
This will automatically determine which variant the current_user_id is assigned, and add the metric to that variant. That’s it. Visit /absurdities and you’ll be able to see the results of your various split tests.
Acknowledgements
Vanity, and its excellent documentation on what A/B testing is, helped me a lot in building absurdity. If you aren’t familiar with the terms used, look here: vanity documentation. You can also check out modesty, which has nearly the same feature set as Absurdity.