Sugar and Spice and everything nice about ES6

I recently flew to Nashville, TN to speak at Nodevember 2015 about ECMAScript 6, the new version of JavaScript making its way into the engines of our modern browsers and servers. Some of its features appear to be no more than a little syntax sugar — making development we already do in JavaScript a bit easier. Others add brand new functionality long missing in JavaScript, which allow us to spice up our code without having to include yet another library.

Unfortunately the talk at Nodevember was only 30 minutes long so I couldn’t talk about everything. And even for the features I did talk about, I was only able to give the highlights. So now I will begin a blog series entitled Learning ES6 to go into the nitty gritty details of the various ES6 features. I’m hoping to release a new topic every other week, so check back in regularly to learn all you’ve ever wanted to know about ECMAScript 6.


Search & Recommendation Systems at Eventbrite

On Eventbrite, users can serendipitously discovery events they will love. But making this possible this isn’t easy. Events are short-lived and by the time we can build an adequate collaborative-filtering model, the event is already over. This talk discusses how we’re overcoming technical challenges with a combination of collaborative-filtering and content-based methods.

You’ll learn: The nitty-gritty details of our problem space. Maybe it’s similar to yours! Is a search engine a good technology for serving up recommendations? Our pain points and how we overcame them. What did we try? What failed? How did we scale? How did we determine the quality of our recommendations?

John Berryman is a Senior Software Engineer on Eventbrite’s Search and Discovery team. Working out of Eventbrite’s Nashville office, John implements algorithms to provide personalized recommendations and search to users. John is also the author of Taming Search

A Recipe for Building Better Things

I’m a professional front-end developer and a passionate home cook. I think that building great products is a bit like preparing a 3-course meal. You can follow the recipe, but it’s instinct, experience and personality that take your food from tasty to taste sensation.

One of the things that experience has taught me in my career as a developer, is that it’s the engineers with strong soft-skills (as well as technical ability) that build the best products.

Below are the vital ingredients, which when combined create the perfect recipe for beautiful builds:


This is pretty obvious but listening is a real skill.

I would challenge you to ask yourself the following question:

As a developer when someone is taking you through an idea for a new, slightly unnecessary feature, what are you thinking?

a) You can’t wait to get this project over and done with.
b) You are coming up with a mental list of technical limitations.
c) You are thinking that this person has put their neck out, so the least I can do is engage with what they’re saying.

The correct answer is C. In spite of this, more than a few times in my career, I have found myself thinking A or B, and I know this has come across in my response.

Often a developer will pile on complexity or limit the scope of an idea on the grounds of technical impossibility, when most of us know that truthfully almost anything is possible. It is just a case of time, knowledge and effort.

Ideas are very delicate things; they are all too easy to smother, limit or even extinguish. So when someone is next talking you through an idea you think is bad, take a moment and LISTEN. It might turn out that with a little bit of work it could be the best thing you’ve ever built.


I really enjoy my job at Eventbrite, and this is primarily because I work with a fantastic bunch of people.

I make a point of having discussions over cups of tea with Design, Engineering and Product, before and during every project (yes, I am British!). I find having an informal chat about what we are building and why often reveals nuances that can be missed in formal kick-off meetings.

A set of requirements on paper is great, but you should never take them as gospel. If you think changes will lead to a better project outcome, by all means make them. But don’t go off and do your own thing without talking to the team first.

I have found that on countless occasions talking something through before making tweaks to a spec or design has led to a better end result.


If you’re really trying to make that designer or UX architect in your life happy, this is where you can score major brownie points.

When faced with styling a UI and turning a flat design or prototype into a glossy end product, a lot of developers are filled with a sense of dread. They either leave it right to the last moment after the ‘real coding is complete’ or knock something out quickly to get it out of the way. This often does not end in beautiful results.

The way to build beautiful products is to really care about users’ interactions. Spend the time that a well-crafted design deserves, and focus on executing every small detail.

When approaching the end of development, go back to your designer to discuss what you have produced and ask for feedback. This is also a great opportunity to put forward any UI tweaks that you think would improve the final result.


Being nice is nice! You don’t have to go overboard and buy kittens for all your team mates, but it is a fact that if you are nice to people they are always more willing to go out of their way to help you when you need it. It leads to a better team working environment that encourages new ideas and creative solutions of hard problems.


So my recipe for building better things is as follows:

Line your baking tin.
Listen to an idea and leave it to prove.
Take requirements with a pinch of salt.
Then talk through all ideas until they settle.
Bake at a low heat for the length of development.
Apply icing with a little concentration and attention to detail.
Sprinkle on some nice-ness.

Then serve and enjoy.

Have thoughts? Comment here or find me on Twitter @albybarber

Delightful animation by Joshua Price

Jennifer Wong: I Think I Know What You’re Talking About, But I’m Not Sure

Jennifer Wong took the stage at JS Conf EU this year to talk about the etymology and history of developer-speak and language.

Recursion, instantiate, lexical scope – where do these words come from?! If you’ve ever been in conversation with other developers and thought, “I think I know what they’re talking about, but I’m not sure…”, you’re not alone. Let’s delve into the weird and wonderful parlance that computer scientists and developers have created for themselves. Whether the words are borrowed or just plain made up, I’ll uncover how they made their way into the vocabulary of the modern programmer.

In this session, you’ll learn everything from etymology to history to broader definitions, all of which can help you understand what the heck that person’s rambling about. So, the next time you’re in conversation, you’ll be the one discussing dependency injection versus inversion of control with ease.

Cookies Can be Costly: How Separate Domains Can Save Big Bucks

At Eventbrite, we use separate domains for our static assets. Instead of having something like, or, we use completely different domains for hosting things like CSS, JavaScript, and Images. There are lots of reasons why we do this, but one of the big ones is saving our customers money and time. We’ll go into the details of what we do, but we need to go over some background first.

To start, remember that the full set of cookies that match the domain and path are sent with every web request, provided the cookie is valid (i.e., not expired, not secure on a non-secure connection, etc). For various reasons, most of the cookies Eventbrite sets are tied just to domain (*, and a survey of other top sites shows this is a pretty common practice. This means that, for most sites, having 50 requests to * will result in a complete copy of the matching cookies being sent 50 times.

If you work on a site that gets a large amount of traffic (>1M pageviews/day), you might see why this can be a problem, but let’s break it down further.

Let’s pretend gets 10 million pageviews per day. This is not our real pageview number, just an example for this post. Let’s further say that that the homepage has about 60 static assets, and those assets are hosted at

10 million x 60 requests = 600 million requests

For instance, say Eventbrite has about 1kB of cookies on it’s homepage, and all of those cookies get sent on every request to *

600 million requests x 1kB = 600,000,000 kB

600,000,000 / 1024≈ 585,937 MB

585,937 / 1024 ≈ 572 GB

So our customers in this hypothetical example are sending out over half a terabyte of cookies per day. This isn’t good, and it’s expensive. How expensive? Well, that’s a bit tricky to calculate, and depends a lot on locale. So let’s make some assumptions that will get us an order-of-magnitude calculation. Assumption 1: All these page views are in the US. Assumption 2: Half of our traffic is mobile. With these assumptions, we can use the findings in the Open Technology Institute’s Cost of Connectivity report to see how much we’re costing our mobile users.

572 GB / 2 = 286 GB ≈ Cookies sent over Mobile in US for our example

According to the report, 3GB of data costs about US$30, which makes a nice easy US$10/GB.

286 GB x US$10 = US$2860

So, if we were to have all our static assets hosted at a subdomain of our primary URL, we would be costing these hypothetical mobile users around US$2,860 per day. Another way of looking at this is we would be costing these example users US$1,043,900 per year.

Thankfully, this is not how is set up. We don’t pay the “cookie cost” because we have our static assets hosted on a separate domain that is linked to from our pages. Since that static asset domain doesn’t set cookies, our users don’t have to send those cookies when they ask for an image or css file.

If your site is in a position where you’re making your users pay the cookie cost, I’d highly suggest creating a new domain for static content and switching the URLs in your codebase to that domain. As an added bonus, if you make that domain available over HTTPS, you can update all your URLs to only request assets over HTTPS, and provide a more secure experience for your users.

If you’re interested in helping make Eventbrite even more performant and better for our users, we are hiring. Thanks for reading!

How I learned Django While Working at Eventbrite

We all are constantly learning new technologies and strategies to be more effective at our jobs, or just because they interest us. How do you balance the need to stay on top of the latest and greatest changes in our industry with making a product? How do you take a new hire with amazing potential and help them learn everything they need to know, while shipping at the same time? Shipping code as soon as possible isn’t a cutthroat business decision. It helps people learn faster, be more effective, feel more valued, and keeps them centered on the right goals. How do you balance learning with shipping code? Is there any reason they have to be separate? When Alli joined Eventbrite, she knew Java and Ruby. She’ll give some tips and strategies while saying what worked — and didn’t — when she was learning Django at Eventbrite.

Alli Lacker is a Senior Software Engineer who joined the team at the start of 2013 after spending two years in the Peace Corps. Her recent hits include building the Eventbrite Styleguide, a living centralized styleguide for the entire company, and working tirelessly to make our entire Event + Ticket Creation process responsive during Project Ubiquity. She works on the Discovery Team, which focuses on helping consumers find great events to attend through newsletters, search, and recommendations.

Ashwini Oruganti on Open Source Technology & Building Listing Pages at Eventbrite

Ashwini is a Software Engineer on Eventbrite’s Listings Team. Recently elected to the Python Software Foundation Board, Ashwini is an active open source contributor and working with the team to help OS more projects at Eventbrite.

First, welcome! You have been at Eventbrite for just a few months, why did you choose to join the team?

I got to know some of the engineers in 2013 when I was presenting at PyCon, and we kept in touch while I finished my degree. Ultimately, it was really the people that drew me to Eventbrite. Diving into a new product is never easy, but there is a support system here where I’m not scared to ask questions, and I feel above all else that the team has my back. This is a place where I can learn a lot and contribute a lot.

What is the Listing Team at Eventbrite responsible for?

When someone creates an event on Eventbrite, the listing page is where people learn about the event and register. These pages drive a large majority of our traffic, and are where the magic (the transactions) happen. We processed $1.5B in tickets last year alone.

We recently launched a redesign for free, single-ticket events and the feedback has been overwhelmingly positive. I’m now working on building the backend for the redesign of paid ticket listing pages. Listing

How did you first get involved with Python? What drew you to it?

I learned the language early on in school, and stuck with it because it has a great community that provides a lot of mentorship. I was really lucky to be involved with a community where you can go to people with the dumbest questions and they are welcoming and patient.

What kind of open source work does Eventbrite do?

Last year Eventbrite open sourced Dorsal, a client-side, platform agnostic JavaScript boilerplate automation system that allows you to register your handcrafted plugins.

We’re also working on a tool called Tiki Bar that is used to instrument pages within Eventbrite that we plan to open source. It counts how long each query is taking and reports on the speed and flags the load times to help improve performance.

Another project is our service oriented architecture that is being built to open source.

What were you working on prior to joining Eventbrite?

I was working on TLS, a cryptographic protocol implementation in Python, as part of Stripe’s Open Source Retreat program. Prior to that, I worked on a project called Twisted as part of Google’s Summer of Code.

Twisted is an asynchronous event-driven networking framework, it has a higher level of abstraction, meaning the flow doesn’t work in a straight line which makes it different from the normal programing paradigm. It’s a really efficient framework when you know how to get started with it, but people have stayed away because it’s different from what they’re used to. By the end of the summer I really wanted to break down those barriers and help people get involved with the project, so I started giving talks on why people shouldn’t be scared of Twisted.

Working on Twisted was really my entry point to the open source community.

After Twisted, what got you excited about continuing to be involved with open source work?

I had amazing mentors who kept pushing me to solve more challenging problems. As soon as I got comfortable, they would throw even harder ones my way, pushing me to learn. At some point I got used to being continuously challenged, and when you add that with a great community and support system, “continuing to work on open source software” stopped being a conscious decision, and started being just something you end up doing, because I couldn’t think of anything else I would rather do with my time.

Tell me about Python Software Foundation and how you got involved with the organization.

The Python Software Foundation leads the development of Python and supports user groups, communities, and people who are working on projects that use Python. The Board of Directors meets every two weeks to vote on resolutions on issues affecting the Python community and the future of Python, grants, and awards. We also organize and fund conferences and the global Python communities that support diversity and help get more people involved with Python.

I was elected in June 2015 to the Board of 11, it’s already been a great experience. I’ve learned a lot about helping to maintain a transparent and welcoming international community.

What kind of impact do you want to have at Eventbrite?

Converting all listing pages to the new design will be a really impactful change for Eventbrite and I’m really excited to be working on it as my first project.

There are really knowledgeable engineers working on interesting challenges, and I’m looking forward to learning and working alongside them.

What I’m Reading: 13 of My Favorite Web Development Newsletters

Keeping up to date with the ever-changing world of web development is tricky. You can either get overwhelmed by the amount of JavaScript frameworks and new shiny projects that promise you 10x productivity or you can just say, to hell with it and pray to not be left behind on the web development world.

I’ve consolidated my favorite sources of development related newsletters to share.

Continue reading

It’s 2015 and drawing text is still hard (WebGL, ThreeJS)

Preface (TL; DR):

  • After reading this blog post you should know about some techniques and performance optimizations around rendering text in WebGL/OpenGL ES. (Signed Distance Fields) SDF + Mesh Merging + Texture Mapping are the answer, and are the correct set of compromises in terms of performance and quality *for us*. Our “String Texture” method was the most performant way to render text that we found as long as an application didn’t have “canvas zooming” needs.
  • Here are links to all the demos in this post.
  • We have open sourced our rendering engine Cartogram. It provides a nice abstraction on top of ThreeJS, and a lot of tools in a world where “mesh merging” is the default. Feel free to play around with it and use it in production. Docs, more optimizations and interface changes are coming soon!

Continue reading

Readable JavaScript Tests with Object Builders

Building objects purely for testing purposes is often tedious. Let’s walk through the wondrous world of using design patterns to improve your JavaScript tests.

Over the past weeks we’ve been porting features to our new Event pages. Events are complicated, and the front end of the event page that supports them is feature-rich and has to deal with all sorts of different states an event can be in, in addition to all the types of ticket an event can have. As you can imagine, writing tests to cater for all these different scenarios can get tricky fast.

Continue reading