Two weeks ago we were platinum sponsors of the Barcelona Developers Conference 2011, spending three days assisting to developer and entrepeneur talks but also speaking on three different tracks.

The 17th I spoke about how Tuenti release workflow works, both from the development perspective and from a broader devops and testing one. I detailed some of the opensource tools we use, the reasons why and some bottlenecks or problems we’ve run into.

On the 18th our Backend Framework and Security Lead gave a talk about security: Common web attack vectors, how they work, how to prevent them and some specific countermeasures we apply.

And finally, on the 19th our Mobile Core Tech Lead gave an interesting talk about the evolution of Tuenti’s Mobile site, challenges you face when you build for such a broad and varied device segment and how we try to give the best experience on each of them.

More or less at the same time, Pedro Álvarez and Diana López from the Apps Platform team, gave a presentation at the Universidad de Alcalá de Henares, during the first national RITSI event on Agile Methodologies and Cloud Computing. Their talk: Tuenti, from idea to the web, was a great success.

Last week, I had the chance to speak at FICOD – a fantastic event located right here in Madrid. I spoke about the history of Tuenti, the lessons we’ve learned, the opportunity we see in the Mobile/Web ecosystem, and our vision for TU to address that opportunity.

You can find the links to the video and slides below – but there are a few key messages about TU worth highlighting:

• social networking is becoming less about connecting with people, and more about communicating with them.
• TU takes this communication to the next level; keeping you always connected with your friends
• TU’s combines content/experience (namely, Tuenti’s social content and apps) with an operator – and explore what what innovation a social web company can bring to what’s a largely undifferentiated product offering in the Telco market today

TU leverages social context in a couple unique ways:

• the bill (and billing model) is social; through the web, you see who you’re calling and how much it costs; and with most plans, friends on TU are free.
• voicemail arrives instantly to the web interface, where you can see the sender’s profile and play, delete, and reply.

Check out the video at FICOD TV.

Find the deck on Slideshare.

You can check out TU itself at:

http://www.tuenti.com/tu

I’d like to thank the organizers of FICOD for the invitation to speak – and our Communications and TU teams for helping me prepare the presentation.

Finally, the mind map FICOD made during the talk:

Here at Tuenti we were managing our servers in a old-fashioned way for a long time. We used “for” loops in order to replicate changes across different servers, but as we’re grew that became more complex over time and with new people joining the team. Fortunately, now we have an automated deployment system that deploys a basic image to a server based in its server role. Once the node is up we use Puppet for transforming the node to the desired state, ensuring specific versions of the packages are installed, configuration files are in place and services are running.

We have chosen Puppet because it’s easy to understand, it’s straightforward, it’s extensible and it has a very good community around it.

• Easy to understand: Puppet doesn’t have obscure components that are hard to understand. For example, the communication between client and server is made using a REST API over a SSL channel using client certificates issued by the integrated Puppet CA.
• Straightforward: Moving from manual configuration to configuration management system requires a change of mind about how you manage your platform. Nevertheless, you’ll be able to deploy it and write your automated configurations in minutes. People in the team was able to configure new components and modify existing ones after a brief explanation.
• Extensible: At the moment we just created custom facters, but we’ll need to extend puppet with custom types for easily managing our queue system configurations in a more flexible way. Some people have started to share some custom types and modules in the Puppet Module Forge.
• Community: I had the pleasure of attending last PuppetCamp Europe 2011 held in Amsterdam on April 28th. I have met and shared experiences with a lot of developers, people working in systems operations, and even the PuppetLabs engineers. In the open conferences, the strong technical background of the attendees was apparent and you could see how PuppetLabs engineers listened to us about which features we would like to have in Puppet or how to improve them.

Last week, I had the chance to speak at EmTech Spain as part of a panel discussion on “The Future of the Internet”. Our challenge as panelists was to envision what the web would look like in 10 years. I talked mostly about mobile and its implications, which, given the launch of Tu, our MVNO, have occupied a lot of my thinking during the past year.

The biggest change in the mobile web over the last 2-3 years has been the emergence of Apps, driven by the success of the iPhone and its application platform. The signature user experience that the iPhone introduced, with its mass consumer appeal, has earned Apple the market power to control not just the OS and its UX, but to control the App distribution platform as well. This is without precedent; Apple, a device manufacturer, is in a position to gate the individual apps for UX and functionality, as well as control the payments coming from users to download and transact within those apps. Other device manufacturers have followed suit – Android, Blackberry, with Microsoft/Nokia and Amazon soon to follow. This is the biggest shift we’ve seen producing software products shifted from building native applications to building web applications. Now we must build device applications – again native – but with different UX considerations (touch v keyboard, screen resolution, tablet v phone) on each. Cross-platform development is no longer just a technical challenge of trying to build the same product experience on Mac + Windows or on IE + Netscape/Firefox. It’s now a product and design challenge to reframe that experience within the unique bounds of each platform/device – as the signature UX of the device carries through into the product experience.

Consider our case at Tuenti. Tuenti today builds two HTML clients – www.tuenti.com and m.tuenti.com – and mobile clients on 4 platforms (iPhone/iOS, Android, Blackberry, J2ME). Already we have two distributions of the J2ME, built to target lower- and higher-end devices. It’s foreseeable a similar need will emerge for Android, and potentially as the tablet markets for iOS and Android grow, we’ll need to target those with variants targeted towards that specific form factor. That’s 6 different UXes currently (and more coming) built to let users do the same fundamental things: chat, view friend’s content, share photos, etc.

The above is without mentioning an entire class of platforms we don’t build for now, but I expect to be an increasingly relevant way for people to access the Web: video game consoles. Of course, these consoles are increasingly used for a lot more than video games: casual web browsing, video on-demand, etc. It’s something that Tuenti – and anyone planning to deliver products that people use multiple times per day – will need to address.

How this ecosystem evolves in the next few years will dictate what products are brought to market and what types of companies bring them to market (how can start-ups build 6 apps?). I expect some convergence, driven probably as much by the people building products (eg us) as the dynamics of the consumer markets. Apps are a major aspect of the user experience of the phone; consumers will be drawn to the platform that has the apps they want to use. And App makers, particularly start-ups, will need to make tough choices about which platforms they build for. The next generation of innovative apps won’t be available on every device platform. I would also guess that the most innovative apps will be built for the most-open platforms – with the fewest limits on UX and what device functionality the developer can access.

Finally, I want to thank the organizers (MIT Tech Review Spain, Club Malaga Valley) and sponsors of EmTech Spain for the invitation; Ariel Poler for moderating the panel; and the fellow panelists – Geoff Ralston (Co-Founder, Imagine K-12) and Othman Laraki (Director of Growth, Twitter).

On November 24, I’ll be speaking more about the evolution of the mobile web and how Tu fits into that at FICOD.

It’s that time of year again – your family/significant other is dragging you to the beach for a week. It’s a sunny, sandy place that won’t do your laptop any favors. How to make the best of it? My suggestion is to bring along some good books – and I’ve devoted this entry to listing some specific recommendations with relevance to our work.

Dreaming in Code, by Scott Rosenburg, chronicles the Chandler project – an effort led by Mitch Kapor to build a personal organization application that seems to do just about everything (which should tip you off to how that ends up working out). The account reveals a lot of the challenges faced by product dev teams – most of which I’m sure you’ll find familiar. If your team’s ever struggled in the face of shifting requirements and attempts to integrate new technologies, you’ll be happy to learn that you definitely are not alone. (link)

Finding Flow, by Mihaly Csikszentmihalyi, introduces the concept of flow – optimal engagement in the task at hand – and discusses how to structure your experiences to create it. I think you’ll find that most of us are attracted to engineering precisely because it lends itself to engaging us in this way. Most people find such engagement fulfilling (Csikszentmihalyi equates it with happiness and general life satisfaction) – but in an engineering context it’s also quite productive. How can you craft your time, work, and environment to lend themselves to periods of flow? (note – he has several newer books, which I have yet to read)

Talent is Overrated, by Geoff Colvin, debunks a common myth that exceptional performers are blessed with some type of exceptional innate talent for their discipline. It then advances the concept of “deliberate practice” as an alternative explanation – arguing that the capability to perform at an exceptional level is acquired only with lots of hard, structured work – ideally under the guidance of expert teachers. Such work is not fun, not easy, and requires intense concentration and personal drive to pursue. (while the first half of this book is quite interesting, the second diverges into some anecdotes about leadership at GE which I don’t think are very relevant to our field).

The Art of Scalability by Martin L. Abbot and Michael T. Fisher. This book is unbelievably relevant to actual engineering management – it is the closest thing I’ve ever found to guide for doing my job. While it’s focused more on the systems ops/scalability side of things and is occasionally very process heavy, it is a very useful book. (link)

The Innovator’s Dilemma, by Clayton M. Christensen. A classic work analyzing how some companies are able to innovate – and others aren’t. Prevailing wisdom in tech is usually that the bigger a company is, the worse it is at innovating. Christensen illustrates that the size of the company isn’t as important you might think – the type of technological change and the organizational history are also critical determinants of whether a company can successfully innovate and commercialize the technology. Big companies do some things very well; start-ups do other things very well; the question is whether your company is in the right position for what it’s trying to do.

Switch, by Chip and Dan Heath. All this summer reading is only valuable if you can leverage this knowledge to change yourself/your team for the better. So the last book on this list is focused on that: motivating yourself or others to make a change, especially in the face of prevailing attitudes, habits, or organizational inertia.

After reading these books, I hope you’ll return from summer not only well-rested, but also with some new ideas on how to do your work better.

Rule of thumb: your Javascript code might not be the only one executing in your website. Browser extensions and plugins as well as security software might be running their own javascript code before yours and thus, they can potentially break your site. Sadly, that was happening to some of our users with AVG antivirus – the site didn’t work at all for them.

We tried to reproduce the issue installing the AVG antivirus software in some of our machines, but the site worked perfectly for us. So we went back to the investigation and to our own surprise, the issue was only affecting users that had updated the software recently and not to users with fresh installs.

We managed to reproduce the issue and we discovered that AVG injects a script tag as the first child of the head on every single HTML file. The script src looks like this

<script type=”text/javascript” src=”/A2EB891D63C8/avg_ls_dom.js”></script>

This file is always loaded and executed by the browser before than any custom code that the site might want to load and execute. The javascript code in the file is quite aggressive and can potentially trigger some weird, unexpected and hard to debug issues.

That was the case.

Among other code, the file contains these lines:

Chck_Function.prototype = Function.prototype;
Chck_Function.prototype.constructor = Chck_Function;

which basically overwrites Function.prototype.constructor assigning it to Chck_Function because both prototype properties now point to the same object. Our TuJS library does strong type checking to ensure that all the parameters are what they are expected to be and these lines being executed before our library was loaded were messing with them miserably.

Tuenti has contacted AVG regarding this bug and a fix is going to be pushed out very soon. In the meantime, we made a very simple workaround: just redefine Function.prototype.constructor again before our library is loaded.

<head>
<!-- Automatically injected by AVG →
<script type=”text/javascript” src=”/A2EB891D63C8/avg_ls_dom.js”></script>
<script type=”text/javascript”>
        Function.prototype.constructor = Function;
</script>
… Rest of the page

If you are using some external library that does the same kind of type checks, you might be having the same problem.

On Monday last week at 13:37, our first programming contest came to an end. We sincerely hope that you enjoyed the contest during those seven days you’ve had to challenge yourself. On our side, it was more than one week to get this: preparing the contest judge, working to define the problems (and also handing them over to some mates to solve them first!), preparing the submission toolchain, monitoring the contest, … Even if it was lots of hard work, we also had tons of fun.

During those days, an almost neverending stream of comments on our contest official page and mentions to our Tuenti Engineering Twitter account was being received. We tried to solve every issue raised and also gave some small tips. Some really nice write-ups are have been posted already and they are worth taking a look at (for example, Gaspar Fernández has collected a list of them, feel free to add yours in the comments). We will also be linking and/or publishing the outstanding write-ups after the winners are announced.

We have run some basic statistics on the top 75 contestants’ code to see what language has been the most successfully used. Not surprisingly, some have used different languages depending on the problem. Still, the most used language has been Java, closely followed by C++ and Python. Take a look at the following chart:

Remember that the online challenge was just the first round of the Tuenti Programming Contest. We will be contacting every finalist today in order to invite them to our offices next Friday and assist to a one-day workshop about our internal architecture and processes (and some more… but that’s still a secret). We will announce the winners just after that, so keep an eye here!

Our recruiting team has been working really hard to scale out our Engineering teams in Madrid and Barcelona.  This is a major challenge – as we’re committed to maintaining a very high standard of quality in our team as we grow.  A big obstacle our recruiters face is that many candidates who appear to have significant, applicable work experience don’t end up performing very well in our selection process.  We’ve identified that a lot of the skills we look for, while taught at top universities, aren’t used that commonly in work at many European companies.  As such, candidates who have been out of university for a long time often are out of practice in many of these areas. In this article, I’ll briefly describe a number of topics that will be covered throughout the process.

Algorithms and Data Structures - sorting, searching, trees, lists, hash tables, etc.  You should have a basic understanding of each such that you can apply them in solving different problems, and discuss costs/trade-offs imposed.  If you’re interested in working on more low-level stuff, it’s good to be familiar with the implementation of common open source projects that apply these concepts.  Most of the problem-solving type questions we’ll ask will involve applying these concepts to a practical problem to reach an efficient solution.

OOP design - design principles, encapsulation, divisions of responsibility, common patterns, etc. This is one of the big things we look for in the code test – that you know how to structure clean, clear code using inheritance, abstract classes, encapsulation to support your design.  Expect that you’ll be asked to sketch out how you would structure code to implement a particular feature or solve a problem.

Security – common attack vectors against web applications and tactics for combating them.  This probably isn’t something you learned in school; if you’re working at a good web company right now, hopefully they require you to be mindful about these vectors and you know the various pitfalls.  We’re pretty skeptical of pen-testing and audits as a way to prevent security problems, and our release cycle (twice per week) is too quick to allow for exhaustive use of such measures.  Our engineers need to be able to think critically about code written by themselves and others to ensure it does not introduce vulnerabilities into our applications.

Database concepts – concurrency control, indexes, logical-to-physical mappings, query execution.  Tuenti’s a very data intensive application: our users create a ton of content and we present dynamic, unique views of that content to each visitor to the site.  Doing this efficiently requires us to be very careful about how things are stored, cached, and accessed within our systems.  A strong conceptual understanding of information management systems, as well as familiarity with a variety of implementations of such systems (eg MySQL, MemcacheD, Postgres, etc), is extremely helpful in understanding the design decisions we’ve made already and proving to us that you’ll make good decisions once you’re here.

Several points of the above will be evaluated in a code test.  In particular, for a code test you must present an efficient, correct solution implemented with good OOP design in a manner that is readable (using documentation, if needed). To pass, your solution needn’t be bug-free or have perfect style/syntax – but you shouldn’t show unusual carelessness either.  We care mostly about how you think, how you can express that in a well-structured solution, and what you can produce in the allotted time.

If you make it through the code test, you can expect to face questions about each of these in the interviews.  Generally speaking, we try to pose questions that are pretty broad and open-ended – especially as you progress farther in the interview process.  Clearly and concisely explaining your solution is important – don’t be afraid to sketch out something illustrating your solution and, of course, write code.

I hope that gives you an understanding of some of the broad technical areas we’ll cover.  Frequently, to be well-prepared across all of them requires that you are passionate about building web apps and spend a lot of time reading blogs and books related to these.  Such independence and self-motivation is also something we’re looking for throughout the process, as we try to ensure you’ll succeed in our culture.

If you’re ready, submit your CV at jobs.tuenti.com If not, I’ll be posting more articles about the recruiting process here at Tuenti in coming weeks, so check back.

As many of you know, it is not strange these days to see Tuenti engineers attending some of the tech events happening in Madrid (and Barcelona soon). This time, we are doing it the other way around: we will be opening our offices so that you can follow the Google IO event with part of our engineering team and other guests.

This event will take place next Tuesday, May 10th, in our Madrid and Barcelona offices and below is the coordinated agenda between Google and Tuenti:

• 16h30: Check in
• 16h50: Introduction
• 17h00: Presentation from Tuenti Engineering
• 17h30: Presentation of GTUG Madrid
• 18h00: Keynote
• 19h05: Main new announcements discussion
• 19h30: Time for a beer

As can see, we will also be giving a couple of talks If you want to attend (we have only a few slots left), please send an email to googleio (at) tuenti (dot) com. We will then confirm that you got one a nice place in our sofas room and send you over the details. Please remember, registration is REQUIRED and we won’t be able to make exceptions.

See you on Tuesday!

Miguel Jiménez Esún Intern, Frontend Framework

Regular expressions are a sophisticated way to check patterns against strings. In JavaScript, we have five native functions that can use regular expressions as an argument. These are the JS functions for performing operations with strings:

• search, match and replace methods of the String object (regexp is provided as the method’s argument).
• exec and test methods of the RegExp object.

Construction optimization

Regular expressions have two sections: the regexp itself, and the modifiers. According to this scheme, they can be generated in two different ways:

• With a ‘/’ starter: the regexp is between two slashes; after the second we place the modifiers.
• With the RegExp constructor: the regexp is passed as a string as the first parameter, and the modifiers as the second parameter also as a string. This method allows building it from any data type  (strings, numbers, etc). However it does have a performance cost. For example, you can make a regexp to change a string in to another one by using a predefined regexp:

  var str = "Hello, John! Today is Monday.";
  var regexp = /John/g;
  var user = str.match(regexp, 'Mark');

  This will return "Hello, Mark! Today is Monday.". However in some cases this approach may not possible, i.e. you may need to provide the string to be replaced through a parameter:

  function myReplace(name) {
      var str = "Hello, John! Today is Monday.";
      var regexp = new RegExp(name, "g");
      return user = str.match(regexp, 'Mark');
  }

  This will slow down your code by several orders of magnitude. Be extra careful specially if you are running it inside a loop. Here we can see the performance impact across different browsers (less is better):

  

  Table 1. Different ways of building a regexp

Global modifiers optimization

There are 3 different global modifiers in Javascript, which are described after the regexp closing slash. These can be g, i, and m.

• g: only used in replace, match and exec methods. It performs a global replace instead of returning just the first occurrence only one.
• i: case insensitive when making searches or replacements. For example, /a/gi will find A and a. Use this modifier instead of a regular expression, because it will be up to 10% faster. E.g. using /a/gi is faster than /[Aa]/g. You must take in account that the i modifier is prepared to handle any unicode character, regardless of what code it has.

  

  Table 2. Differences between using the /i modifier against double match

• m: multiline modifier, allows ^ and $ modifiers to match against a \n character and a \r character, instead of just checking at the start or at the end of the string. This is a very useful and fast modifier so it is recommended to apply it whenever possible instead of an alternative regular expression. As seen below it can be almost 3x faster. For example, when parsing code, it is better to use /^for (.*);/gm, rather than /(\nfor\s*(.*);)|(^for\s*(.*);)/g.

  

  Table 3. Differences between using the /m modifier against compound patterns

Quantity modifiers

• Using {} notation when trying to find a repeated pattern can be marginally slower than using special characters, because the regexp parser engine must evaluate what is inside them. In general, you can substitute them by:
  • {0,} with a .
  • {1,} with a +.
  • {0,1} with a ?.
  • {x} with the repeated pattern manually.
  • {1} with nothing (this is the default for everything).
• The “+” modifier is slightly slower than using the *. It makes the regular expression a bit redundant as you have to repeat the pattern, but it gives you a tiny bit of a performance improvement . This gives the backtracking algorithm a fixed pattern that must be present in the string. Not all browsers implement this performance improvement.

In the chart below we see the metrics comparing these:

Table 4. Quantity modifiers

Back-references

Back-references are a method to use parts of the regexp matches in a different part of the regexp within the same regexp, or else within the replaced string. They can be used also in the callback method. JavaScript has a maximum number of 9 back-references, and they are stored in the same order as the opening parenthesis appear in the expression.

• Try to avoid using parentheses when it is not needed to create a backreference; and if needed, append  “?:” modifier to the parentheses; this will mark the pattern as non capturing, preventing it to be stored in memory, and thus, making the regexp faster.
• When using backreferences in the same regexp, you can do so by using the backslash followed by the number; but this process has a performance cost. Do not use it to match strings that can be done without them (e.g.: /"[^"]*"/g instead of (")[^"]*(\1)/g).
• Backreferences can be used in the replace string in JavaScript by using the symbol $, followed by the number. This notation allows making a lot of replacements:
  • $$ returns the $ symbol.
  • $n returns the back-reference labeled with number “n”.
  • $` returns everything before the matched string.
  • $' returns everything after the matched string.
  • $& returns the entire matched string.

  For example, to delete quotes from strings, you can use the following: str.replace(/"([^"])*"/g, "$1");. This will be a *lot* faster than doing a function where you make the replacement:

  str.replace(/"([^"])*"/g, function(match) {
      return match.slice(1,-1);
  });

• There are other $ sequences not covered here as they are not fully supported in some browsers such as Opera or IE.

Table 5. Backreferences performance against function substitution

Note: All the charts shown in this article were generated by executing the code 100,000 times, in a page containing a single test.