When we first developed our mobile apps in 2014, we decided to use a third-party service to deliver push notifications. It was fast, easy and at the time we did not have enough engineers to implement sending push notifications ourselves. However, as we have grown, both in number of engineers and in mobile app users, that company no longer gives us the level of control, data analysis, and stability that we desire. (Plus, it charges us per push notification.) Therefore, we decided to implement our own way of sending push notifications.
Thumbtack, like any marketplace, has two sides: consumers looking for services and pros offering services. As a result, we have two iOS apps: one for consumers and one for pros. To manage dependencies in both apps we use CocoaPods, not only for 3rd party libraries but also for our internal library called TTKit.
There are two main reasons to migrate to frameworks: first and foremost, supporting Swift code in our dependencies; second, better code organization. With frameworks, each library is contained in its own module as opposed to having every static library compiled and linked into one binary.
By: Ben Anderson & Xin Liu
When a customer posts a request on Thumbtack, we want to match them with the right professional for the job. When the marketplace was small, this was easy—just blast the request out to all of the pros in the request’s category and location. Today, with millions of requests a year and hundreds of thousands of active pros, we can’t rely on that simple algorithm anymore. The definition of “right” is no longer obvious—the pro and the customer each have their own preferences, and we need to balance how we benefit customers and pros to grow a healthy marketplace in the long run.
At Thumbtack, one of our core values is to Make Each Other Better. We do this by giving and receiving feedback, mentoring new engineers, and finding ways to mindfully educate and empower one another. There is something in our culture that brings out the best in people. However, much like other rapidly growing companies, it’s important that we continually look for ways to improve.
The women on our team wanted a way to seek mentorship without having to invest their time finding and attending local female-focused events, with varied success and relevance. So, in an effort to live our values,
Part ll: How we run Spark/Sqoop in production
In the last post, we described our legacy infrastructure and event processing code, along with the key design decisions we made as we architected our new data infrastructure. In this post, we’ll discuss some of the operational details involved with deploying these systems in production and some lessons that we’ve learned along the way. Here, we’ll cover two topics:
- Running Spark jobs
- Running Sqoop imports
Spark in Production
As we described in our last post, we elected to run our own Spark + CDH installation on top of EC2 nodes.