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.

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.

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.

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.

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:

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

IE7

IE8

Firefox 3.6

Chrome

{0,}

1850,7

1536,2

1575,3

1407,2

*

1817,6

1653,4

1490

1389,1

{1,}

636,9

497,7

275,5

208,4

+

650,9

523,8

269

210,6

{0,1}

1824,6

1650,4

1843,8

1391,6

?

1876,4

1674,4

1842,7

1389,6

{3}

559,8

404,6

346,5

79,5

Repeated

506,5

361,6

122,4

78,5

(?:text)

598,9

430,6

173,9

97,4

text(?:text)*

585,8

435,6

173,3

97,2

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: