Normal brandi heroimage whand

iHeartRadio

New York, NY www.iheart.com
   
 
   
 

About iHeartRadio Engineering

iHeartRadio is one of the largest online music/radio app in the US and with over 60 million registered users our engineering team gets to work on challenging problems and build cool features in a distributed and scalable fashion. We are operating as a small startup in a larger organization and our mission is to create the best music experience for our listeners and have fun doing it. We have opportunities across all fields such as big data/data science, backend (scala/nosql), web, mobile and with the reach and scale we have, our engineering work gets to be used and enjoyed by tens of millions of people!

Small 168109 Andy Dirnberger on

Adding Content in Real-time

iHeartRadio ingests hundreds of thousands of products each month. Historically, as a new product delivery was received, a user would manually initiate the ingestion process by entering its file path into a form on a web page, triggering the ingestion application to parse the delivery and update the database. Downstream systems would constantly poll the database, run at regularly scheduled intervals, or be triggered manually. This process, roughly visualized below, was reasonable, with new content arriving in the catalog within a few days of its receipt.

Linear ingestion flow

Small 128247 Adam Denenberg on

Using Scala in Amazon Lambda

Here at iHeartRadio we have made a significant investment in choosing Scala and Akka for our MicroService backend. We have also recently made an investment in moving a lot of our infrastructure over to AWS to give us a lot more freedom and flexibility into how we manage our infrastructure and deployments.


One of the really exciting technologies coming out of AWS is Lambda. Lambda allows you to listen to various “events” in AWS, such as file creation in S3, stream events from Kinesis, messages from SQS and then invoke your custom code to react to those events. Additionally the applications you deploy that react to these events, require no infrastructure and are completely auto-scaled by Amazon (on what seems like a cluster of containers). Currently Lambda supports writing these applications in Python, Node and Java.

Unknown author on

Targeted Marketing with Collaborative Filtering


The data science team at iHeartRadio has been developing collaborative filtering models to drive a wide variety of features, including recommendations and radio personalization. Collaborative filtering is a popular approach in recommendation systems that makes predictive suggestions to users based on the behavior of other users in a service. For example, it’s often used to recommend new artists to users based on what they and similar users are listening to. In this blog post we discuss our initial experiences applying these models to increase user engagement through targeted marketing campaigns.


One of the most successful approaches to collaborative filtering in recent years has been matrix factorization, which decomposes all the activity on a service into compact representations of its users and what they interact with, e.g. artists. At iHeartRadio we use matrix factorization models to represent our users and artists with ~100 numbers each (called their latent vectors) instead of processing the trillions of possible interactions between them. This simplifies our user activity by many orders of magnitude, and allows us to quickly match artists to users by applying a simple scoring function to the user’s and artist’s latent vectors.

Small 83257 Kailuo Wang on

Introducting Kanaloa: make your reactive service more resilient

Announcing a new iHeartRadio open source project Kanaloa. Kanaloa is a set of work dispatchers implemented using Akka actors. These dispatchers sit in front of your service and dispatch received work to them. They make your service more resilient through the following means:


  1. Auto scaling - it dynamically figures out the optimal number of concurrent requests your service can handle, and make sure that at any given time your service handles no more than that number of concurrent requests. This algorithm was also ported and contributed to Akka as Optimal Size Exploring Resizer (although with some caveats).

  2. Back pressure control - this control is Little’s law inspired. It rejects requests when estimated wait time of which exceeds a certain threshold.

  3. Circuit breaker - when error rate from your service goes above a certain threshold, kanaloa dispatcher stops all requests for a short period of time to give your service a chance to “cool down”.

  4. Real-time monitoring - a built-in statsD reporter allows you to monitor a set of critical metrics (throughput, failure rate, queue length, expected wait time, service process time, number of concurrent requests, etc) in real time. It also provides real-time insights into how kanaloa dispatchers are working. An example on Grafana:Dashboard


Unknown author on

Meet the iHeartRadio Engineers: Hua Wang

Earlier this year, we launched a series that profiles our hardworking iHeartRadio engineering and product team. Today, we’re excited to chat with Senior Mobile Developer Hua Wang!


Before joining iHeart, Hua worked on mobile products at Pearson, Barclays, and Apptricity, among others. With a broad range of expertise, Hua has developed mobile technologies from robots to phones. She believes that mobile is impacting our lives like never before, with incredible potential for continued future disruption.



Why did you choose to become an engineer?

Simple: I love problem-solving, and being able to solve challenging problems is critical to being a good engineer. My approach looks something like this:

-Be observant
-Stay grounded in reality with day-to-day problems
-Try to understand issues
-Address them
-Solve them

Unknown author on

How we built Play-swagger, a Swagger spec generator for REST APIs

iHeart/play-swagger is a Swagger spec generator for REST APIs built with Play Framework. It generates swagger specs from play route files and case class reflections without the need for any code annotation.


The main principles we follow when designing this library are:

  1. No code pollution (e.g. annotation)

  2. DRY (extract as much information from the code as possible)

  3. When documenting an endpoint, it should be just swagger specification that you need to write. You shall not need to learn another API or spec format.


Which translate to following features we implemented:

  1. Write your swagger specification in your routes files as comments (json or yml)

  2. Reference your case classes in your swagger spec and play-swagger will generate definitions

  3. Override anything in either the swagger spec in comment or the base swagger spec file.


Here is a simple example that demonstrates how iheart/play-swagger works:

Unknown author on

Meet the iHeartRadio Engineers: Eric Cogan


Several weeks ago, we kicked off a series that profiles our tireless iHeartRadio engineering and product team. Today, we’re excited to chat with Associate Product Manager for Android, Eric Cogan, about his favorite projects, his music tastes and all you need to know about #iHeartLife.


Eric has been at iHeartRadio for two years, and previously spent five years working for iHeartMedia in Washington, D.C. as the Technical Manager for local radio station websites. He enjoys all parts of product management as well as learning new software and website design strategies. When not hacking away, Eric can be found exploring Brooklyn while listening to his favorite podcasts.


So, Eric, why did you choose to work at iHeartRadio?


I wanted to be involved in a company that impacts lives in a positive way. Radio, whether it’s talk or music, does that on a daily basis. iHeartRadio keeps you company on long drives, serves up the perfect soundtrack while getting ready in the morning and provides the most up-to-date news. It’s an essential part of our lives!


How long have you worked here?


I’ve worked at iHeartRadio for a little over two years (and at iHeartMedia for a total of seven). Out of college, I worked for several Washington, D.C. radio stations owned by iHeartMedia, and two years ago I was given the opportunity to come to New York City to help support iHeartMedia’s 850+ radio station websites. Now I’m a Product Manager for our Android app, and it’s been an exciting experience so far!


What’s the most exciting project that you’ve worked on?


It’s hard to pick just one, but I really enjoyed rebuilding our help site for users. By enhancing the design and the tools we used to assist our listeners, we not only made it easier to find information, we also decreased the number of emails received and reduced the number of exchanges needed to resolve issues.


What’s your favorite part of the job?


My favorite part of the job is just knowing that the work I do has a meaningful impact. I try to read all our Android reviews, both positive and negative - it’s always great to see how iHeartRadio has made users’ days just a little bit better.


Do you play an instrument, or have you ever been involved in a music group?


I play the drums, but sadly I had to leave my drum kit behind when I moved to NYC, as city life and drums don’t mesh well. However, I do have a collection of drums from around the world that I’ve acquired over the years—I try to collect new drums that reflect local cultures whenever I visit a new country.

Unknown author on

Making Android applications Null Pointer and Exception free

I am an android developer for iHeartRadio, and my job here is building a beautiful android application for iHeartRadio, which serves millions of android users.

Maintaining a 4.5 star rating is very, very challenging—to do so, your application must have rich contents that users can enjoy, be easy to use, and performant.

As a developer, one of my main focuses is building crash free apps. On a daily basis, I monitor and fix various kinds of application crashes, which can come from hardware limitations as we deal with multiple manufacturers, OS platform level, or developer’s own mistakes. One common class of error causes null pointer exceptions, which is familiar to any experienced java developer.

We spend a lot of effort writing clean code, expanding unit test coverage and performing peer code reviews. Still, it’s not easy to eliminate all null pointer exceptions, as the causes for them are many. They can happen during runtime when the platform API returns a null object, any server response may result in null pointer error, or the developer may simply forget to do null object check in their own code.

You may have written this to avoid null pointer exceptions. So have we!

Screen Shot 2015-08-18 at 11.38.14 AM

The above code is very defensive and prevents null pointer error.

Unknown author on

Interview with an iHeartRadio Engineer: Taichi Matsumoto

Today, we’re excited to kick off a monthly series that will profile the team who works tirelessly behind the scenes to make the iHeartRadio experience we all know and love: our engineers! Once a month, we’ll be sitting down with a member of the iHeartRadio engineering department to talk about how they got here, what they’re working on and their favorite parts of #iHeartLife.

This week we talked with Taichi Matsumoto, a Lead Software Engineer for Mobile at iHeartRadio, who has been working here since 2013. Previously, Taichi lived in Japan and worked as an iOS and software engineer at Fenrir and Zero-Sum, Ltd. Taichi is fluent in Python, Linux, Cocoa and C++ programming languages, as well as Japanese. He graduated from Kyoto University’s Department of Technology in 2007, where he studied Computer Science.

1. So, Taichi, why did you choose to work at iHeartRadio?​
I like working on products that people actually use; it’s rewarding to me when my work has a large day-to-day impact. iHeartRadio’s huge user base was impressive to me, and I knew working here would give me the opportunity to engineer products that people love and use every day.

2. What’s the most exciting project that you’ve worked on at iHeartRadio?
Everything is exciting! Just knowing that the code I’m writing for iHeartRadio is being used by our millions of app users is thrilling. But if I have to choose a specific project...the most exciting one I’ve worked on so far has been the Mac App we designed. Together with a few colleagues at our company-wide Hack Day, I proposed the idea to create a brand new product that hadn’t been done before—and thus, the Mac App was born. It was coded, developed and brought to market all within a few months and I’m really proud of the final product. Being involved in nearly all of the large decisions regarding the app, from start to finish, was a really rewarding experience.

3. What’s your favorite part of the job?
The opportunities to iterate on iHeartRadio’s code and make small improvements that have a large-scale impact are endless. There’s always something to be done, and when I’m looking for a change in my daily routine, I work on identifying areas where we can continue to improve and better the code and listener experience.

For example, last year I fixed several small crash bugs in the system, which propelled our crash-free rate from 97 percent to 99.5 percent. These improvements helped those who experienced app crashes use iHeartRadio more smoothly.

Also, a few months ago, I cleaned up our code and resources, reducing our app size by 2MB. It might sound small, but this reduction helps new users download our app more quickly.

4. Do you play an instrument or have you ever been involved in a music group? If not, is there a band you love that you would like to be a part of?
It’s funny: I’m surrounded by musicians, but I actually don’t play any instruments. I love Train, and my favorite song by them is “Save Me, San Francisco.” I saw Train perform at the iHeartRadio Music Festival​ ​last year, and it was a very memorable performance—just one of the perks of working here!

Small 1526025 Tom Drapeau on

Hacker Culture at iHeart Radio


image
iHeartRadio has a thriving culture of self motivated, driven, and brilliant makers. We channel this energy in a number of ways, including our “Hack” event series. We have multiple Hack Days per year, and Hack Week each summer. Hack Day is an onsite 24-hour hackathon: a few months before the event, teams begin to organically form and share ideas. During the event, teams collaborate and in many cases pull an all nighter on an idea they came up with and are passionate to solve.

image
All ideas share a common basic theme that they improve an aspect of  iHeartRadio’s product offering. Projects range from productivity enhancing internal tools to data dashboards for greater user insights to new features or even whole new product lines. Hack Day ends with a demo session to show fellow hackers and iHeartRadio senior management what has been accomplished, followed by a vote for the grand prize winning demo.

See here for information on our Mac App, a brand new product for us and the grand prize winner from the March 2015 Hack Day. Check out the Hack Day demo of Mac App:

HackDay Mac App from iHeartMedia on Vimeo.

Hack Week shares the same organic idea and team formation philosophy from Hack Day, but takes place offsite. With an entire week, teams complete more ambitious projects, are bigger and have a more cross functional team makeup. Hack Week is a great bonding experience, providing an opportunity for people to meet and spend quality time with people they seldom come in contact with during the normal workday.

HACKERS 2015 from iHeartMedia on Vimeo.

This year’s Hack Week produced a number of wide ranging new innovations in social, station building, accessibility, analytics insights, our product process, infrastructure, international expansion, data science and visualizations, and search. In addition, several brand new products to be announced in the near future.

The Hack Week grand prize winner, Eric Cogan (Android product manager) designed an iHeartRadio chrome extension from scratch on the first day, then spent the rest of the week adding new features and customizations to it. Here he is, fresh off his demo victory!

image
Also at the Hack Week house, our heads of engineering, operations and product took part in the inaugural Hack Week Grill-Off. First prize honors went to our Manager of Data Engineering, Neil Gallagher, who slow cooked award-winning BBQ ribs for a very appreciative crowd and took home the honors!

image

Join Us