Airbnb Engineering http://nerds.airbnb.com Nerds Thu, 26 Feb 2015 15:33:56 +0000 en-US hourly 1 http://wordpress.org/?v=3.8.5 Large Scale Payments Systems and Ruby on Rails http://nerds.airbnb.com/large-scale-payments-systems-ruby-rails/ http://nerds.airbnb.com/large-scale-payments-systems-ruby-rails/#comments Thu, 26 Feb 2015 15:33:56 +0000 http://nerds.airbnb.com/?p=176594743 I’ve been writing code for fun and for work at both small startups and large companies for the past 30 years. Over the years I’ve become fascinated with the payments industry, and I have spent the past decade working in payments related companies. Before coming to work on Payments at Airbnb, I worked for PayPal, […]

The post Large Scale Payments Systems and Ruby on Rails appeared first on Airbnb Engineering.

]]>
I’ve been writing code for fun and for work at both small startups and large companies for the past 30 years.

Over the years I’ve become fascinated with the payments industry, and I have spent the past decade working in payments related companies. Before coming to work on Payments at Airbnb, I worked for PayPal, for a few startups and then was part of the NFC Wallet project at Google.

The payments space is interesting because it combines a strong need for hard core computer science with an industry that is built on an aging foundation. The basic way payments work around the world has essentially stayed the same even as technologies such as location-awareness and strong encryption have become ubiquitous. The industry is ripe for change but extremely resistant to it. It is a fun technical problem and a tough business problem.

Over the years I’ve seen payments systems written in a variety of languages. I’ve noticed that the way payments work translates to requirements that affect the language and framework selection trade offs. For example, payments applications typically require strong transactional integrity, a robust audit trail and very predictable failure behavior.

The Challenge

Ruby on Rails is well known for its quick iteration cycle and the plethora of magical tools that speed up development and simplify prototyping. Those benefits are focused on improving the development process, but in some cases make maintenance of production system more difficult. In terms of the way payments work, some of its shortcomings mean trouble.

Testability

The ActiveRecord pattern favors large, monolithic model classes that contain database access logic and business logic. Testing these classes is difficult. It is not easy to describe their dependencies above and beyond the database table they depend on, and it it is therefore hard to write good, comprehensive unit tests for them. This makes it difficult to reason about their behavior. E.g.: Can you really guarantee that this 3000 line model that touches our transaction table does not contain off-by-one-cent errors if it doesn’t have really good unit tests?

Audit trail

Maintaining a log of ‘who did what when’ for every change involving money or user information is an important part of any payments system. ActiveRecord makes it trivially easy to make database changes, making it hard to ensure that every part of the code that mutates data actually records an audit trail. Furthermore, in some cases (e.g. with mass updates such as update_all), there is no way to enforce that every database change creates an audit trail. The only way to programmatically capture all data mutation is via database triggers.

Predictable Failure Behavior

It is usually a good idea to explicitly check for expected conditions and parameter values at the start of public interface methods. For example, if a parameter can’t be nil, raising an exception if nil is passed. This translates into very loud failure scenarios, but ultimately ensures that problems bubble up and get fixed, and makes bugs easier to track down.

Ruby’s weak typing makes it more difficult to enforce these rules. In strongly typed languages, the compiler complains if you pass in an int where a string is expected.

Furthermore, Ruby has lots of cases where nil is used as a sentinel to signify ‘no value returned’. This is dangerous because nil is also the default value of an uninitialized variable. This makes it difficult to identify bugs where a variable name is mistyped or otherwise not properly initialized.

The Airbnb way

Taking into account those issues, payments might seem more suited for a strongly typed language where the database access model is more restrictive. Yet, at Airbnb we use Rails for our payments stack. Instead of ditching Rails for its drawbacks, we’ve come up with solutions for its main issues, making it work well for payments. This enables us to continue to enjoy the many benefits it provides.

Reducing ActiveRecord’s surface area

A key requirement for proper audit trails is reduced access of code to the raw database data. To achieve this we’re starting to use a layer on top of ActiveRecord we call ProtectedAccess which controls changes to the underlying table and ensures an audit trail is written. It also greatly reduces the ActiveRecord surface area by not exposing all of its data mutation methods by default, and thus forces developers to reason about what methods they call, making it more likely that unwanted data mutations are caught during code reviews.

ProtectedAccess is designed to replace an existing ActiveRecord::Base class. It exposes some of the same interfaces, but actually hides most of the ways to mutate an object. The idea is to disallow most mutations to a Model that can’t easily be audit-trailed, and for those that can, create a shim that transparently creates the audit trail.

For example, suppose you have a Payment model that has an amount field. By virtue of extending ActiveRecord::Base, it exposes a setter amount=. Any piece of code can call:

  
p = Payment.last
p.amount = 234
p.save
  

which would create an un-audited modification of the payment record.

In comparison, ProtectedAccess creates a shim between the surface area, which still contains amount= and save, and the ActiveRecord model. When save is called it instead creates and saves a new version of the record instead of overwriting the existing version. There is no way for anyone to call the actual model that has access to the Payments table because it does not exist, save for a private member of the class Payment < ProtectedAccess object.

Parameter Validation – Fail Fast (and loud!) and Explicit Dependencies

We use a declarative framework for parameter validation that enables service objects (as well as methods) to check that parameters are of the correct type and value range, ensure mandatory parameters are present and also ensure that no unexpected parameters are passed in. It is loosely inspired by Guava’s Preconditions class.

An example might be an implementation of the validate method of a service object:

  
def validate(options)
  validate_arg(options) do |o|
    o.validate :txn, is_a: Transaction, required: true
    o.validate :buyer, is_a: User, required: true
    o.validate :status, is_a: String, required: true
    o.validate :confirmation_code
  end
end
  

This is not an attempt to make ruby strongly typed (though that might not be such a bad idea…), but rather a way to explicitly declare and enforce the dependencies of an object or a method. It is also not dealing with instantiation, as some dependency injection frameworks do. But it can make it clearer to someone reading a piece of code what its dependencies are.  It also causes faster failures. Without validation a bug would cause an unexpected value to propagate through the code until (hopefully) something blew up or (more likely) a weird result was displayed to a user with no indication as to the source. With validation an exception is thrown, a process crashes, and developers get alerted to the problem. Arguably, it is better to tell the user something went wrong rather than to present something that might be completely off.

Freezing constants is another related method we use, above and beyond the warnings the ruby interpreter issues when modifying a constant.

Parameter validation is very generic, and can be used with any Ruby application. We’re currently evaluating when the right time might be to open source it.

Service Objects

Instead of placing business logic in models, we keep models lean and focused only on data retrieval and storage. All business logic goes in service objects, which are single use business logic objects that are initialized with a clearly defined set of parameters, and then perform an action on them. They tend to be smaller in size and very focused on executing a particular task. Because they have a well defined set of parameters, they are much easier to test, and can be tested primarily using mocking (as opposed to creating test database entries or having test network services).

As an example, suppose you have some code that makes a call to some external gateway for completing a transaction. It might look like

  
def complete_transaction(txn, buyer, status, confirmation_code = "")
  if txn.empty?
    raise Error, "Must call complete transaction with a non null txn"
  end
  # more validations

  response = Net::HTTP.post_form....
  # inspect response and return accordingly
end
  

A service object might look like:

  
class CompleteTransaction < ServiceBase
  def initialize(opts = {})
    validate(opts)
    @txn = opts[:txn]
    @buyer = opts[:buyer]
    @status = opts[:status]
  end

  def validate(opts)
    # use parameter validation to strongly check expected parameter values
  end  

  def perform
    response = Net::HTTP.post_form....
    # inspect response and return accordingly
  end
end
  

Calling this service object would be done like this:

  
CompleteTransaction.new({ txn: txn, buyer: user, status: "Complete" }).call
  

The service object framework will do some pre flight logging and then call perform, following it with post flight logging.

Note that validation, logging and other administrativia are now segregated to their own methods, and the perform method can focus on pure business logic. It can make lots of assumptions on the parameters, as they have been strongly validated. The interesting part of the code is also more easily accessible for someone trying to figure out what it is doing.
Because the o.validate must declare every parameter that can be passed to the service object, it is really clear what it depends on. This is a form of code-documentation that does not go out of date.

Strict Code Style and Code Complexity Filters

To make code easier to understand, we use rubocop and cane in some of our repos. These tools enforce a common style on our code (rubocop) and ensure code is not overly complex (cane).

Rubocop is great for helping teach newcomers the ‘lay of the land’, and also keep everyone in sync as to what is the expected style of code. Cane’s ability to measure ABC code size metric is very useful in forcing the creation of small, easy to read and understand methods. We’ve occasionally seen cases where the cane threshold we chose (15 ABC score) was too restrictive, but generally it has pushed us to remain clear and concise in our code.

Take for example the following condition:

  
if params[:user].messages.last.send_by < Time.now
  params[:user].messages.last.send
else
  job.retry_at(params[:user].messages.last.send_by)
end
  

This has the ABC score of 12.

Compare it with the equivalent:

  
email = params[:user].messages.last
if email.send_by >= Time.now
  return job.retry_at(email.send_by)
end

email.send
  

which has an ABC score of 8.

The differences are simple:

  1. Edge case conditions are evaluated early, and processing is halted instead of having an else clause.
  2. The email parameter is extracted rather than dereferencing through params and messages.

Cane does not propose those changes, it simply alerts you that there is too much complexity. It is up to the team to establish rules of thumb on how to reduce complexity when that happens.

DRY things up – Gems and Modules

The practice of DRY-ing things up is used quite heavily in the way of gems or mixins.
Gems are typically used to extract commonly used functionality that needs to be shared among more than one internal app. Some of our gems are also open source. Aside from those open source examples, we also have internal gems for securely sending credit card information to our credit card processor, for keeping currency information consistent among our various applications and for argument validation.

In cases where functionality needs to be reused within the same application, we sometimes use module mixins – putting functionality in a module and then including it where it is needed.

Disable replica reads

A common scaling strategy in a MySQL environment is to use database replicas for reads, thus reducing the traffic on the master MySQL. This has the disadvantage that your code might sometimes get stale data. For payments, we mostly disable replica reads, trading off load on the main database for data integrity. E.g, it is not acceptable for a new transaction you make to not include the results of the previous one.

Transition

Over the past several years we have learned a lot about building and maintaining large scale payments systems. Some of what we have learned is already implemented in our code base and is part of our daily best practices. Other learnings are still fairly new, and the frameworks they rely on still under construction. As always, our system continues to evolve and we’re constantly looking for ways to make it better and more robust.

If you’re interested in taking a more active part in our journey towards a better, more scalable and robust system, I’d love to hear from you – michel.weksler@airbnb.com

The post Large Scale Payments Systems and Ruby on Rails appeared first on Airbnb Engineering.

]]>
http://nerds.airbnb.com/large-scale-payments-systems-ruby-rails/feed/ 0
Surviving at Scale: Lessons from Airbnb and LinkedIn http://nerds.airbnb.com/surviving-scale-lessons-airbnb-linkedin/ http://nerds.airbnb.com/surviving-scale-lessons-airbnb-linkedin/#comments Thu, 29 Jan 2015 17:45:06 +0000 http://nerds.airbnb.com/?p=176594732 We are super excited to host our first tech talk of 2015! With the new year comes a new schedule of tech talks happening once a month. Each talk will be carefully curated with multiple speakers and a cohesive theme. The theme this month is scaling and infrastructure with Airbnb engineers, Ben Hughes and Jon […]

The post Surviving at Scale: Lessons from Airbnb and LinkedIn appeared first on Airbnb Engineering.

]]>
We are super excited to host our first tech talk of 2015! With the new year comes a new schedule of tech talks happening once a month. Each talk will be carefully curated with multiple speakers and a cohesive theme. The theme this month is scaling and infrastructure with Airbnb engineers, Ben Hughes and Jon Tai and the co-founder and head of engineering at Confluent, Neha Narkhede.

Scaling Things That Don’t Scale: Scalability and Reliability at Airbnb

Paul Graham says to do things that don’t scale, and this advice has served us very well at Airbnb. By 2012, guests had booked more than 10 million nights in 192 countries. Years of exponential growth were great for our business, but hard on our infrastructure.

In early 2013, scaling issues began to affect our user experience. As peak summer travel season ramped up, external services took longer to respond, background tasks overwhelmed our database, and memory usage grew unchecked. We started having downtime several days a week, and responding to incidents was consuming more and more engineers’ time.

A small group of us started on a journey to improve reliability and scalability. We added instrumentation, got scientific about timeouts, fixed bad queries, and threw a lot of hardware at the problem. By the end of the year, not only did we have more users and bookings than ever before, but we had improved our response time and uptime as well. We didn’t accomplish this by doing a major rewrite, removing functionality, or disrupting other teams; we accomplished this by dedicating a small team to work on application reliability, focusing on fundamentals, and working to better understand our systems.

In this talk we will share what we did to improve reliability and scalability, how we shifted from tactics to strategy, and the lessons we learned along the way.

Speaker Bio

Ben Hughes is a Software Engineer at Airbnb focusing on reliability and scalability. He was previously a cofounder of NabeWise, a neighborhood information startup that was acquired by Airbnb in 2012. Jon Tai is a Software Engineer on the Production Infrastructure team at Airbnb. Beyond scaling software systems, he works to build tooling and evangelize best practices among the engineering team. Prior to Airbnb, Jon was an engineer at IGN Entertainment, where he helped re-architect and scale out IGN’s media platform.

Real-time stream processing at scale using Apache Kafka and Samza

We are enjoying something of a renaissance in data infrastructure. The old workhorses like MySQL and Oracle still exist but they are complemented by new specialized distributed data systems like Cassandra, Redis, Druid, and Hadoop. At the same time what we consider data has changed too–user activity, stock tickers, gaming events, monitoring, logging and other event data are becoming first class citizens for data driven companies. Taking full advantage of all these systems and the relevant data creates a massive data integration problem. This problem is important to solve as these specialized systems are not very useful in the absence of a complete and reliable data flow.

One of the most powerful ways of solving this data integration problem is by restructuring your digital business logic around a centralized firehose of immutable events. Once a company’s data is captured and available as real-time streams, processing this data becomes the next challenge. Stream processing is an essential part of real-time data systems today, and is used for building news feeds, real-time analytics, metrics, alerts and monitoring.

At LinkedIn, we successfully moved virtually all data flow (500 billions events a day) to real-time structured logs using Apache Kafka. This architecture has influenced a lot of companies worldwide in doing the same and Apache Kafka is used in production at hundreds of companies [https://cwiki.apache.org/confluence/display/KAFKA/Powered+By] for similar use cases.

In this talk, I will share our experience of successfully building LinkedIn’s data pipeline infrastructure around real-time streams on top of Apache Kafka and Apache Samza. These lessons are hugely relevant to anyone building a data driven company.

Speaker Bio

Neha Narkhede is co-founder and head of engineering at Confluent. Previously, she was responsible for LinkedIn’s petabyte scale streaming infrastructure supporting hundreds of billions of events per day. She is also one of the initial authors of Apache Kafka and serves as a PMC member and committer for the project. In the past she has worked on search within the database at Oracle and holds a Masters in Computer Science from Georgia Tech.

The post Surviving at Scale: Lessons from Airbnb and LinkedIn appeared first on Airbnb Engineering.

]]>
http://nerds.airbnb.com/surviving-scale-lessons-airbnb-linkedin/feed/ 1
Mapping the World http://nerds.airbnb.com/mapping-world/ http://nerds.airbnb.com/mapping-world/#comments Wed, 07 Jan 2015 19:15:45 +0000 http://nerds.airbnb.com/?p=176594683 People are always surprised when I tell them about Zack Walker, Airbnb’s in-house cartographer, who works on mapping the world. They say, “the world is already mapped! There’s Google Maps, Foursquare, Yelp, Garmin, National Geographic, Zheng He, Isabella Bird, Lewis & Clark & Sacagawea, Leif Erikson, the Planet Earth series narrated by David Attenborough…” Which […]

The post Mapping the World appeared first on Airbnb Engineering.

]]>
People are always surprised when I tell them about Zack Walker, Airbnb’s in-house cartographer, who works on mapping the world.

They say, “the world is already mapped! There’s Google Maps, Foursquare, Yelp, Garmin, National Geographic, Zheng He, Isabella Bird, Lewis & Clark & Sacagawea, Leif Erikson, the Planet Earth series narrated by David Attenborough…”

Which is true, so what’s all this about?

This is all about “AT-AT,” a new internal tool we built to understand locations and their relationships to other locations. It looks like this:

Big questions and hard problems

At Airbnb, the question we want to answer is how do you understand a place without ever having been there?

How do you capture why your friend said you wouldn’t like Fisherman’s Wharf, but you should still go there to get a double double from In N Out?

How do you know where in the world will make for your perfect trip?

Current solutions

We currently tackle this problem in a number of ways:

  • When you’re searching for a place to stay, our location relevance model lets the Airbnb community inform future guests about great places to stay.
  • When you’re exploring new places to experience, Airbnb Neighborhoods combines local editorial content with the handy, need-to-know information alongside professional photos to explore a place without having to leave your chair.
  • Our discovery team is building big things with natural language processing and machine learning algorithms to understand reviews, listing descriptions, and search patterns to recommend the perfect place to stay right from our homepage.
  • Host guidebooks let you find great recommendations from the host.

These products combine to help Airbnb travelers discover all of the wonderful places that make up a city, not just downtown areas where traditional accommodations are normally found.

sf

Airbnb accommodations (red) and traditional accommodations (blue) in San Francisco

Location is a crucial building block for a number of our engineering efforts. Our team needs to help the Airbnb traveler mitigate their number one concern when finding a place to stay: location. On the flipside we want to highlight the million-plus unique listings opened up by Airbnb hosts around  the world.

What’s next

Neighborhoods can only take you so far when trying to match you with the perfect place to stay.

There are culturally significant areas or regions that aren’t drawn on maps. They mostly live in the minds of the local community that calls those areas home. These areas might be a unique part of town along a single road, cutting through 3 neighborhoods. Or they might be a way to describe something in common among multiple neighborhoods.

Finding and mapping these places takes a heroic effort on Zack Walker’s part. He researches historical and current data, talks with folks from the community, and answers emails from hosts to build a clear image of how locals understand their place in the world.

So when you’re looking for a place to stay in “wine country” in Northern California we should be showing you Napa and Sonoma and helping you understand the differences and similarities between the two counties.

While we were very excited to make this happen, this wasn’t possible with our current architecture and existing internal tools. We needed something bigger.

Enter project AT-AT

A small team consisting of Christopher Lin, Alex Blackstock, Daniel Loreto, and myself set out to build the tool to help Zack Walker’s pursuit of mapping the world.

A note on the project code name: Zack wouldn’t let us call it “The Walker System”, so Christopher Lin did the next best thing and used a Star Wars reference (the Imperial Walker or All-Terrain Armored Transport, commonly called “AT-AT”).

AT-AT’s tech stack looks like this:

Our first step was generalizing the existing system so it could handle various geographical polygons (continents, countries, market areas, special regions, towns) and not just cities and neighborhoods.

the bermuda triangle

Relationships

When a polygon is created, the backend calculates the following:

  • Ancestor polygons of the higher type, polygons that contain this polygon (San Francisco => SoMa)
  • Adjacent polygons of the same type, polygons that overlap/border (SoMa => Civic Center)
  • Descendant polygons of a lower type, polygons that this polygon contains (SoMa => Folsom Street Fair)
  • The lat/lng of the centroid of the polygon

Navigation

Navigating a workspace of polygons can be tricky. It took us a few iterations before we landed on interaction patterns that let the UI disappear into the background.

The basic tenents of the system’s UI:

  1. Don’t break the back button
  2. Render only what’s necessary
  3. Reveal information as needed
  4. Get out of the way

We settled on the following interactions: a single click selects a polygon and renders only its adjacent polygons,

and a double-click snaps to the selected polygon.

A tooling culture

Building the future of travel requires a number of special tools working together in the background.

AT-AT is just one of these tools, acting as the foundation for capturing location data for other services and tools to consume — the first step towards answering “Where’s the perfect next trip for me?”

When building tools, remember that you’ll never be able to predict the use cases of the future.

nasa-and-design

And you’ll learn the most from shipping.

Special thanks

Zack Walker, Ben Hughes, Andy Kramolisch, Ann Montgomery.

The post Mapping the World appeared first on Airbnb Engineering.

]]>
http://nerds.airbnb.com/mapping-world/feed/ 8
Payments at Airbnb http://nerds.airbnb.com/payments-airbnb/ http://nerds.airbnb.com/payments-airbnb/#comments Wed, 17 Dec 2014 20:29:18 +0000 http://nerds.airbnb.com/?p=176594675 Talk Abstract Payments at Airbnb is challenging because it operates at the core of a global marketplace to create trust. No single solution exists to meet our needs. Going global involves supporting multiple currencies and payment methods but it also involves nuanced complexities that are unique to local markets. It’s very common for our problems […]

The post Payments at Airbnb appeared first on Airbnb Engineering.

]]>
Talk Abstract

Payments at Airbnb is challenging because it operates at the core of a global marketplace to create trust. No single solution exists to meet our needs. Going global involves supporting multiple currencies and payment methods but it also involves nuanced complexities that are unique to local markets. It’s very common for our problems to cross different domains such as product, compliance, growth, finance, and engineering infrastructure. Airbnb’s two-sided marketplace includes guests and hosts who introduce two different payment problems: collecting and distributing money. Our payments platform also supports other activities in the marketplace such as photographers, translators, trip services, and more in the future.

We’ll talk about building end-to-end systems (upstream and downstream) that process billions of dollars in a reliable and scalable way. Want to know how to change tires while driving in a production environment that has significant money flow? Want to know how to confidently sprint instead of walk with code on a frequent basis? As a result of Airbnb’s rapid growth, its Payments platform has evolved quite a bit and we’d like to talk about it while also providing concrete tips based on our experience.

Speaker Bio

Ian Logan is an Engineering Manager at Airbnb. He joined Airbnb over 3 and a half years ago as the first payments engineer, bringing his experience working in investment banking at BlackRock, Barclays Global Investors, and Morgan Stanley to a new problem of payments in the sharing economy. During his time at Airbnb, Ian worked on all aspects of core payments technology and built its original foundation. Currently, Ian leads the engineering teams responsible for Payments, Trust & Safety, and Internal Products at Airbnb.

The post Payments at Airbnb appeared first on Airbnb Engineering.

]]>
http://nerds.airbnb.com/payments-airbnb/feed/ 0
Meet the Nerds: Eric Levine http://nerds.airbnb.com/meet-nerds-eric-levine/ http://nerds.airbnb.com/meet-nerds-eric-levine/#comments Wed, 17 Dec 2014 15:32:28 +0000 http://nerds.airbnb.com/?p=176594660 Howdy, Eric Levine! Eric is an engineering manager on our Trust and Safety team. Eric tells us about keeping bad guys at bay and going for swims in a Turkish bay (okay, just a pool, but sounded better to say bay). How did you get started in Computer Science? My path toward computer science started […]

The post Meet the Nerds: Eric Levine appeared first on Airbnb Engineering.

]]>

Howdy, Eric Levine! Eric is an engineering manager on our Trust and Safety team. Eric tells us about keeping bad guys at bay and going for swims in a Turkish bay (okay, just a pool, but sounded better to say bay).

How did you get started in Computer Science?

My path toward computer science started when my brother and mentor Matthew came home from university and decided that he wanted to teach his kid brother how to write some code. He taught me the basics and helped me pick out a book to continue my development. I just ran with it from there, and by the time I finished high school I was running an online game with about a dozen regular users.

What was your path to Airbnb?

My path to Airbnb was a long one, starting in 2008. I received an email from a recruiter who worked at YouTube at the time who asked if I was interested in an internship. That internship definitely changed the course of my professional career in a very positive way. Fast forward four years, and that same recruiter from my YouTube days, reached out to me about a position at Airbnb. Due to the previous encounter, I knew I could trust her, and Airbnb seemed pretty amazing from the outside. I was working at Google at the time and decided that I didn’t think the skills I was accruing were as portable as I was hoping they’d be. You don’t take a lot of Google’s infrastructure with you when you leave and I wanted to be more versatile in my skill set. Airbnb was the perfect fit and it has been one of the best decisions I’ve made.

What’s the most interesting technical challenge you’ve worked on since joining?

The most interesting technical challenge that I’ve worked on since joining has definitely been our machine learning-based risk detection systems. My colleagues Naseem Hakim and Aaron Keys wrote up a great blog post describing some of the systems that I’ve worked on, and the next iterations are definitely taking it to the next level.

What do you want to work on next?

We’re hoping to start thinking more about Verified ID and how we can do even more with that. While it’s been a great start, we can start to apply our learnings from other areas and try to apply it to identity to better understand the users of the platform. Further, we have a ton of awesome work planned to improve our systems to further help protect the community.

What is your favorite core value, and how do you live it?

My favorite core value is Embrace the Adventure. The way I interpret this core value is a recognition that perfection is an impossible ideal and that one should try to “roll with the punches” when faced with undefined situations. We try to apply that in our engineering culture by encouraging people to fix things that are broken and to really take ownership of our product. It’s this core value and the way we apply it that makes Airbnb so unique.

What’s your favorite Airbnb experience?

My favorite Airbnb experience was with a couple in a Kirazli, a small village in Turkey. The space itself was absolutely stunning, beautifully designed and the perfect fit for our stay. Every morning I’d wake up to the village’s morning call to prayer. After lazily awakening, I’d go for a quick swim before the hosts would treat me to a traditional Turkish breakfast. The hosts would then take me for a walk through the hills to pick fresh figs off the trees. The whole experience was just extraordinarily pleasant and inspiring.

 

The post Meet the Nerds: Eric Levine appeared first on Airbnb Engineering.

]]>
http://nerds.airbnb.com/meet-nerds-eric-levine/feed/ 0
Decentralized Payments with Bitcoin http://nerds.airbnb.com/decentralized-payments-bitcoin/ http://nerds.airbnb.com/decentralized-payments-bitcoin/#comments Wed, 10 Dec 2014 18:54:33 +0000 http://nerds.airbnb.com/?p=176594641 Talk Abstract So you’ve heard of Bitcoin, a global digital currency with an avid following, and a wildly fluctuating price. But the real power of Bitcoin stems from its underlying decentralized ledger, the blockchain. In this talk, Adrian will take a deep dive into the blockchain, and look at how transactions are generated and broadcast […]

The post Decentralized Payments with Bitcoin appeared first on Airbnb Engineering.

]]>
Talk Abstract

So you’ve heard of Bitcoin, a global digital currency with an avid following, and a wildly fluctuating price. But the real power of Bitcoin stems from its underlying decentralized ledger, the blockchain.

In this talk, Adrian will take a deep dive into the blockchain, and look at how transactions are generated and broadcast in a completely trustless peer-to-peer network. He will discuss what role miners play in this network, and whether the blockchain network could exist independent of the Bitcoin currency. Finally, he will look at some of the potential future applications of Bitcoin and the blockchain, including sidechains and decentralized asset tracking.

Speaker Bio

Adrian Macneil is Director of Engineering at Coinbase, the largest bitcoin company in the world. Originally from New Zealand, Adrian has previously been involved with several e-commerce and payments startups, and has seen first hand the difficulties faced by companies looking to innovate using the current financial networks. Adrian moved to the US in early 2014, and has since helped Coinbase grow from 5 to 20 engineers, and launch in 19 countries and 22 languages. In his spare time, Adrian can be found traveling, snowboarding, and spreading the word of bitcoin.

The post Decentralized Payments with Bitcoin appeared first on Airbnb Engineering.

]]>
http://nerds.airbnb.com/decentralized-payments-bitcoin/feed/ 1
Randomness and Fraud http://nerds.airbnb.com/randomness-fraud-2/ http://nerds.airbnb.com/randomness-fraud-2/#comments Wed, 03 Dec 2014 23:25:49 +0000 http://nerds.airbnb.com/?p=176594604 Talk Abstract Over the course of three years, we’ve built Stripe from scratch and scaled it to process billions of dollars a year in transaction volume by making it easy for merchants to get set up and start accepting payments. While the vast majority of the transactions we process are legitimate, Stripe does need to […]

The post Randomness and Fraud appeared first on Airbnb Engineering.

]]>
Talk Abstract

Over the course of three years, we’ve built Stripe from scratch and scaled it to process billions of dollars a year in transaction volume by making it easy for merchants to get set up and start accepting payments. While the vast majority of the transactions we process are legitimate, Stripe does need to protect its merchants and itself from rogue individuals and groups seeking to “test” or “cash” stolen credit cards. In this talk, I’ll discuss the two types of fraud Stripe faces—merchant fraud and transaction fraud—and how our approach to both has evolved over time. I’ll then demonstrate how “randomness” helps us combat fraud in the three stages of the model-building process. Specifically, I’ll focus on how fraud often appears less random than legitimate behavior (feature generation), how our in-house, distributed random forest learner allows us to build models on huge data sets with more control over how the random splits are made (model training), and how the introduction of randomness in the production scoring environment allows us to reason about counterfactuals (“what would have happened if we hadn’t intervened?”) and evaluate candidate models without production experiments (model evaluation).

Speaker Bio

Michael Manapat is a Software Engineer on Stripe’s Machine Learning team. He was previously a Software Engineer at Google, a Postdoctoral Fellow in and Lecturer on Applied Mathematics at Harvard, and a graduate student in mathematics at MIT.

The post Randomness and Fraud appeared first on Airbnb Engineering.

]]>
http://nerds.airbnb.com/randomness-fraud-2/feed/ 1
SDK Mindset http://nerds.airbnb.com/sdk-mindset/ http://nerds.airbnb.com/sdk-mindset/#comments Wed, 03 Dec 2014 23:25:30 +0000 http://nerds.airbnb.com/?p=176594599 Talk Abstract Writing software is difficult. Bugs happen. Users find weakness and hit them with their mallets repeatedly. Complexity hides and exponentiates with every new feature. When developing SDKs—that is, code we write to run in others’ systems—these problems are critical and acute. We will talk about a number of scenarios we’ve encountered to highlight […]

The post SDK Mindset appeared first on Airbnb Engineering.

]]>
Talk Abstract

Writing software is difficult. Bugs happen. Users find weakness and hit them with their mallets repeatedly. Complexity hides and exponentiates with every new feature. When developing SDKs—that is, code we write to run in others’ systems—these problems are critical and acute. We will talk about a number of scenarios we’ve encountered to highlight the difficulties of building and shipping SDKs: backwards compatibility, flexibility, abstraction, understandability, shippability, adoption, beta partners, communication, etc.

Speaker Bios

Ben Mills is a software developer who works on the Braintree SDKs primarialy on the back-end.

Mickey Reiss is an iOS developer who works on Braintree’s iOS SDK. Braintree is a payments company who’s goal is to provide developers with a foundation to build applications on.

The post SDK Mindset appeared first on Airbnb Engineering.

]]>
http://nerds.airbnb.com/sdk-mindset/feed/ 0
The Future of App Deployment http://nerds.airbnb.com/future-app-deployment/ http://nerds.airbnb.com/future-app-deployment/#comments Wed, 03 Dec 2014 23:25:07 +0000 http://nerds.airbnb.com/?p=176594596 Talk Abstract Writing an app is one thing, deploying it to a production ready environment and keeping it online in the face of countless potential scenarios of adversity is an entirely different beast. Not only does it currently still involve a fair bit of expertise when it comes to unix-fu, it also involves keeping an […]

The post The Future of App Deployment appeared first on Airbnb Engineering.

]]>
Talk Abstract

Writing an app is one thing, deploying it to a production ready environment and keeping it online in the face of countless potential scenarios of adversity is an entirely different beast. Not only does it currently still involve a fair bit of expertise when it comes to unix-fu, it also involves keeping an eye out on the latest software and configure them properly to combat things like security breaches. This is all generally considered tedious and cumbersome work, and often outside the domain of knowledge of developers. Wouldn’t it be great if we didn’t need to go through as many hoops as we need to do today and make it more developer friendly?

This talk will go over the most important steps currently involved in setting up a production environment for your a web app and will propose alternative approaches as well in the form of new software solutions developed by Phusion. This talk will focus on app deployment, monitoring and server provisioning, but will also touch upon topics such as UI design and UX as the latter plays an important part in making things more accessible. More specifically, we’ll discuss Docker, Polymer, Node, Rails, Phusion Passenger, Union Station and much more.

Speaker Bios

Hongli Lai is the co-founder and CTO of Phusion. His work involves all layers of an application stack. Be it from Phusion Passenger for deployment, to tinkering on Docker baseimage, his work has helped deploy hundreds of thousands of sites.

Tinco Andringa is a full stack software engineer at Phusion. During his time at Phusion he has built Ruby on Rails applications for clients and he is now leading development work on Phusion’s new monitoring solution Union Station. When he is not building Ruby web apps he works on open source software and tinkers on video games.

Goffert van Gool is a Full-Stack Engineer at Phusion, where he works on modern web applications, and high-availability services. He is often experimenting with new technology and how it can be used to improve application architecture.

The post The Future of App Deployment appeared first on Airbnb Engineering.

]]>
http://nerds.airbnb.com/future-app-deployment/feed/ 0
Feature Engineering for Real-Time Fraud Detection http://nerds.airbnb.com/feature-engineering-real-time-fraud-detection/ http://nerds.airbnb.com/feature-engineering-real-time-fraud-detection/#comments Wed, 03 Dec 2014 23:24:44 +0000 http://nerds.airbnb.com/?p=176594588 Talk Abstract This talk will explore some of the joys and pitfalls of applying machine learning to Internet activity. It’ll focus on the process that Sift Science uses to develop features for its realtime fraud detection service, covering some of the specific evaluation and modeling problems that are unique to this kind of data. Speaker […]

The post Feature Engineering for Real-Time Fraud Detection appeared first on Airbnb Engineering.

]]>
Talk Abstract

This talk will explore some of the joys and pitfalls of applying machine learning to Internet activity. It’ll focus on the process that Sift Science uses to develop features for its realtime fraud detection service, covering some of the specific evaluation and modeling problems that are unique to this kind of data.

Speaker Bio

Doug Beeferman is a software engineer at Sift Science, formerly at Google and Lycos. His focus throughout his career has been applications that analyze logs of user activity such as search and web logs. He is also interested in text and speech processing.

View the slides here.

The post Feature Engineering for Real-Time Fraud Detection appeared first on Airbnb Engineering.

]]>
http://nerds.airbnb.com/feature-engineering-real-time-fraud-detection/feed/ 0