• Sam Giddins: My Summer at TumblrThis summer, I had the immense pleasure of working on the Tumblr iOS app. From day one, I got to work with an incredible team on an incredible app writing production code. Over the course of nearly 100 pull requests, I managed to get my hands on almost every piece of the app, from design changes to code refactors to some sweet new features.The best part about the summer was working alongside multiple teams at Tumblr (iOS, Creative, API) making real, significant changes to one of the most polished apps on the App Store. When the summer started, I’d never written a custom animation, but after a few weeks I was helping to debug some of the fun things we do with CoreAnimation. Monday of my second week I found a bug in the API and got to spend a day looking through PHP code to help track that down. One Friday, I started work on some new things that will come out soon—at 5 pm, on a whim. By Monday, I was demoing the changes to Peter Vidani. That sort of rapid feedback is incredible, and really made my experience at Tumblr a joy—I got to make a real difference on the app.In addition to the code I wrote (which was a lot!), I got to work with the team on all of the other facets of the app development lifecycle, from the existential frustration of dealing with translations to setting up a CI build server. I review several hundred pull requests, and spent hours discussing code with brilliant collegues who were never hesitant to debate the intricacies of what we were working on.Throughout the summer, I was constantly in awe of the amazing work done at Tumblr every day. I’m proud to say that I got to contribute to the next few updates, and will forever cherish the experiences I had during my time at Tumblr HQ.

    Sam Giddins: My Summer at Tumblr

    This summer, I had the immense pleasure of working on the Tumblr iOS app. From day one, I got to work with an incredible team on an incredible app writing production code. Over the course of nearly 100 pull requests, I managed to get my hands on almost every piece of the app, from design changes to code refactors to some sweet new features.

    The best part about the summer was working alongside multiple teams at Tumblr (iOS, Creative, API) making real, significant changes to one of the most polished apps on the App Store. When the summer started, I’d never written a custom animation, but after a few weeks I was helping to debug some of the fun things we do with CoreAnimation. Monday of my second week I found a bug in the API and got to spend a day looking through PHP code to help track that down. One Friday, I started work on some new things that will come out soon—at 5 pm, on a whim. By Monday, I was demoing the changes to Peter Vidani. That sort of rapid feedback is incredible, and really made my experience at Tumblr a joy—I got to make a real difference on the app.

    In addition to the code I wrote (which was a lot!), I got to work with the team on all of the other facets of the app development lifecycle, from the existential frustration of dealing with translations to setting up a CI build server. I review several hundred pull requests, and spent hours discussing code with brilliant collegues who were never hesitant to debate the intricacies of what we were working on.

    Throughout the summer, I was constantly in awe of the amazing work done at Tumblr every day. I’m proud to say that I got to contribute to the next few updates, and will forever cherish the experiences I had during my time at Tumblr HQ.

  • Megan Belzner: My Summer at TumblrThis summer I got the amazing opportunity to intern as a product engineer on the Creation team. I didn’t really know what to expect when I first stepped in to the office, but whatever hopes and expectations I could have had, the summer far surpassed them.The Creation team is in charge of one of the most important parts of the Tumblr site - posting tools - and most of my summer was spent working with the others on the team to overhaul the code underlying that part of the site. Coming in at the beginning of the summer, I could count the number of times I had worked in an existing codebase on one hand - namely: once, maybe twice. But with the help of the incredible Creation team, I dove right in and started contributing bug fixes, updates, and even entire features. Starting in the very first week I was already writing and deploying code, fixing a bug with note counts and updating Tumblr’s user engagement emails. By the end of the summer, I found myself getting ownership of pretty significant parts of the project. Even better, I had learned how to easily track down the source of a bug, figure out what this or that bit of code actually did, and navigate the figurative jungle of javascript.It was incredibly exciting and rewarding to work on such a central part of the Tumblr site, knowing that people are going to be using some of the code I wrote to make millions of posts a day. I learned a tremendous amount about front-end web development, going from knowing a pretty minimal amount of javascript to knowing all sorts of intricacies about browser implementations and fluently speaking backbone.js and underscore.js.Working at Tumblr really was a dream come true, and though I’m excited to get back to my friends at MIT, I’ve realized that this is absolutely something I could do for the rest of my life (or the foreseeable future, at least). Spending the day bringing ideas to life for Tumblr’s millions of users, surrounded by the most creative, smart, and friendly people I’ve ever met - It almost feels like cheating that I got to call that “work”.

    Megan Belzner: My Summer at Tumblr

    This summer I got the amazing opportunity to intern as a product engineer on the Creation team. I didn’t really know what to expect when I first stepped in to the office, but whatever hopes and expectations I could have had, the summer far surpassed them.

    The Creation team is in charge of one of the most important parts of the Tumblr site - posting tools - and most of my summer was spent working with the others on the team to overhaul the code underlying that part of the site. Coming in at the beginning of the summer, I could count the number of times I had worked in an existing codebase on one hand - namely: once, maybe twice. But with the help of the incredible Creation team, I dove right in and started contributing bug fixes, updates, and even entire features. Starting in the very first week I was already writing and deploying code, fixing a bug with note counts and updating Tumblr’s user engagement emails. By the end of the summer, I found myself getting ownership of pretty significant parts of the project. Even better, I had learned how to easily track down the source of a bug, figure out what this or that bit of code actually did, and navigate the figurative jungle of javascript.

    It was incredibly exciting and rewarding to work on such a central part of the Tumblr site, knowing that people are going to be using some of the code I wrote to make millions of posts a day. I learned a tremendous amount about front-end web development, going from knowing a pretty minimal amount of javascript to knowing all sorts of intricacies about browser implementations and fluently speaking backbone.js and underscore.js.

    Working at Tumblr really was a dream come true, and though I’m excited to get back to my friends at MIT, I’ve realized that this is absolutely something I could do for the rest of my life (or the foreseeable future, at least). Spending the day bringing ideas to life for Tumblr’s millions of users, surrounded by the most creative, smart, and friendly people I’ve ever met - It almost feels like cheating that I got to call that “work”.

  • Brendan Barwick: My Summer at TumblrLast May, I started my internship at Tumblr on the Core Scala team, which writes and maintains the backend Scala services at Tumblr. These backend services do a lot of the high-throughput work involved with communicating between the frontend of the website and the immense amount of data. Tumblr has almost 200 million blogs and over 83 billion posts, with tons of data associated with all of those; therefore, you can imagine that any service that has to deal with retrieving and formatting this information would need to be extremely robust and highly scalable. Before coming to Tumblr, I’d had some experience doing software engineering, but never on a website, nor anything even remotely close to this scale. I had taken courses that taught the concepts behind distributed systems, but applying those ideas to real-world services was an entirely new opportunity. The first thing I worked on at Tumblr was a service that took in requests for unread post counts, unread inbox counts, and toast notifications, and returned the desired data back as properly filtered and formatted JSON. These requests come in at slightly over 7,000/requests/second at normal peaks in traffic. Originally, this functionality was accomplished by a php file (poll.php, named that because the dashboard continually polls for this data) which utilized 36 machines in our datacenter to serve the requests. My project, eventually dubbed the “Pollscala” service since it was written in Scala, started out as a training exercise for me to learn many of the different technologies that come together in building a successful service. Eventually, Pollscala evolved from being just a training exercise into being a production service. Each instance of the new service can serve over 5,000 requests/second, and even assuming I wanted to keep a few extra servers than necessary as backup (which we did, of course), I was able to decommission most of the old machines and shut them down. While the old service was near its threshold handling the peak level of requests, the new Scala service can theoretically handle somewhere around 25,000 requests/second. My work at Tumblr is helping to give the site room to grow with its users.As my work on Pollscala progressed, I learned about Scala, about using tools such as Redis and Memcached, about using JSON, about building RESTful web services, and had the joy of exploring the complex codebase and ecosystem that keeps Tumblr running smoothly (most of the time!) for the gigantic set of users who love to browse Tumblr all day and all night. I took a brief trip into the land of Scala JSON libraries and built a tool to benchmark their performance on different shapes of JSON objects. I even was able to take a day long journey out to the great state of New Jersey (my birthplace and childhood home) to see the Tumblr datacenter, a place that is an impressive feat of engineering and could survive the apocalypse and keep serving data. (A brief aside on Scala: before coming to Tumblr, I didn’t know anything about Scala, besides from being able to recognize that it was a programming language and not a mythical creature from Arthurian legend or something. As the tale goes, Scala was designed by a cool German dude named Martin Odersky who grew so frustrated when working on generics for java that he decided to just build another better language on the JVM. Scala is the beautiful love child of Java and Standard ML, and it has the best parts of both its parents. Scala has a strong static type system, is object oriented, and supports all of the cool shit we love from functional programming languages. And, if you feel like you’re missing that one awesome Java library you used in every project, don’t worry—any Java library can be used in Scala to your heart’s desire. Learning and playing with Scala was one of the highlights of my summer at Tumblr.)The final project that I worked on was a build and deploy tool for Scala services at Tumblr. I contributed to the backend RESTful API portion of the tool (which we wrote in Scala), which controlled actions such as getting and putting things into the database, as well as kicking off builds and deploys and tracking the progress of these processes though statuses and logs. I quickly learned the vital importance of having a good tool for doing builds, deploys, and service control (starts, restarts, stops) on our services.Working at Tumblr has been educational, interesting, and above all, phenomenally fun. Coming in, I was daunted by all the technologies I would have to master in order to successfully contribute to the company, but I now walk away from this summer comfortable with an incredible new skill set. I’m grateful that my team put their faith in me and gave me the opportunity to grow as an engineer, and I’m grateful to have worked in such a high-energy and exciting office. Being a part of Tumblr, and becoming friends with some downright hilarious and chill people here, has been absolutely delightful. Fuck Yeah.

    Brendan Barwick: My Summer at Tumblr

    Last May, I started my internship at Tumblr on the Core Scala team, which writes and maintains the backend Scala services at Tumblr. These backend services do a lot of the high-throughput work involved with communicating between the frontend of the website and the immense amount of data. Tumblr has almost 200 million blogs and over 83 billion posts, with tons of data associated with all of those; therefore, you can imagine that any service that has to deal with retrieving and formatting this information would need to be extremely robust and highly scalable. Before coming to Tumblr, I’d had some experience doing software engineering, but never on a website, nor anything even remotely close to this scale. I had taken courses that taught the concepts behind distributed systems, but applying those ideas to real-world services was an entirely new opportunity. 


    The first thing I worked on at Tumblr was a service that took in requests for unread post counts, unread inbox counts, and toast notifications, and returned the desired data back as properly filtered and formatted JSON. These requests come in at slightly over 7,000/requests/second at normal peaks in traffic. Originally, this functionality was accomplished by a php file (poll.php, named that because the dashboard continually polls for this data) which utilized 36 machines in our datacenter to serve the requests. My project, eventually dubbed the “Pollscala” service since it was written in Scala, started out as a training exercise for me to learn many of the different technologies that come together in building a successful service. Eventually, Pollscala evolved from being just a training exercise into being a production service. Each instance of the new service can serve over 5,000 requests/second, and even assuming I wanted to keep a few extra servers than necessary as backup (which we did, of course), I was able to decommission most of the old machines and shut them down. While the old service was near its threshold handling the peak level of requests, the new Scala service can theoretically handle somewhere around 25,000 requests/second. My work at Tumblr is helping to give the site room to grow with its users.


    As my work on Pollscala progressed, I learned about Scala, about using tools such as Redis and Memcached, about using JSON, about building RESTful web services, and had the joy of exploring the complex codebase and ecosystem that keeps Tumblr running smoothly (most of the time!) for the gigantic set of users who love to browse Tumblr all day and all night. I took a brief trip into the land of Scala JSON libraries and built a tool to benchmark their performance on different shapes of JSON objects. I even was able to take a day long journey out to the great state of New Jersey (my birthplace and childhood home) to see the Tumblr datacenter, a place that is an impressive feat of engineering and could survive the apocalypse and keep serving data. 


    (A brief aside on Scala: before coming to Tumblr, I didn’t know anything about Scala, besides from being able to recognize that it was a programming language and not a mythical creature from Arthurian legend or something. As the tale goes, Scala was designed by a cool German dude named Martin Odersky who grew so frustrated when working on generics for java that he decided to just build another better language on the JVM. Scala is the beautiful love child of Java and Standard ML, and it has the best parts of both its parents. Scala has a strong static type system, is object oriented, and supports all of the cool shit we love from functional programming languages. And, if you feel like you’re missing that one awesome Java library you used in every project, don’t worry—any Java library can be used in Scala to your heart’s desire. Learning and playing with Scala was one of the highlights of my summer at Tumblr.)


    The final project that I worked on was a build and deploy tool for Scala services at Tumblr. I contributed to the backend RESTful API portion of the tool (which we wrote in Scala), which controlled actions such as getting and putting things into the database, as well as kicking off builds and deploys and tracking the progress of these processes though statuses and logs. I quickly learned the vital importance of having a good tool for doing builds, deploys, and service control (starts, restarts, stops) on our services.


    Working at Tumblr has been educational, interesting, and above all, phenomenally fun. Coming in, I was daunted by all the technologies I would have to master in order to successfully contribute to the company, but I now walk away from this summer comfortable with an incredible new skill set. I’m grateful that my team put their faith in me and gave me the opportunity to grow as an engineer, and I’m grateful to have worked in such a high-energy and exciting office. Being a part of Tumblr, and becoming friends with some downright hilarious and chill people here, has been absolutely delightful. Fuck Yeah.

  • What we learned building the Tumblr iOS share extension

    Tumblr share extension icon featured in a banner at Apple’s WWDC 2014 event

    iOS app extensions – launching this Wednesday, as part of iOS 8 – provide an exciting opportunity for developers of all types of apps to integrate with their customers’ devices like never before. Here at Tumblr, we’re thrilled to pull the curtain off of our share extension, which we’ve been working hard on for quite a while now.

    The process of building the Tumblr share extension has been fun, but also really frustrating at times. We’ve hit quite a few problems that we ended up needing to work around, and in the interest of helping you do the same, would like to detail all of the issues that we encountered.

    Of course, your mileage may vary with some or all of these. We’ve talked to other developers who haven’t had the same problems, or have hit some that we haven’t. To make it easy to track updates to these problems and share workarounds, we’ve created an issue in this GitHub repo for each one. Please create pull requests if you’ve got solutions, or issues if you’ve encountered something that we didn’t.

    We couldn’t get background file uploads to work

    Apple’s App Extension Programming Guide contains a section on performing uploads and downloads, complete with sample code indicating how background sessions are to be used to perform uploads that may last longer than your extension process is alive for. Normally, an NSURLSessionUploadTask can be created from a stream, raw data, or a file URL, but only the latter is intended to be used in an extension. This makes sense: communication between extensions and container applications in the same “app group” occurs through a shared container, a special, secure location on disk that both extension and app are able to read and write from. The extension writes a file to the shared container and initiates a task to upload that file. The upload ostensibly occurs in a third process, allowing it to continue even once the extension has been terminated. The container application will then later be woken up and notified as to its success or failure.

    We have not been able to get this to actually work.

    In our experience, while our extension and container application can both access the shared container without issue, the NSURLSessionTask is seemingly unable to. Instead, it spits out errors that you can find in the radar.

    Workaround

    As soon as a user taps the “Post” button, we’d ideally like to dismiss the extension and let them get on with their day, while continuing to upload in the background. Given that we haven’t been able to get this to work, we’ve given our extension a progress bar and are keeping it on screen until the request completes. It’s possible that the user could background the host application, and iOS could kill it in order to reclaim the memory, but this seems like our best option given these limitations. We’ll happily go back to using background sessions if the issue we’re seeing ends up getting fixed.

    The container application must be opened before the share extension can be used

    As mentioned, the shared container is where everything that you need to access from both your app and extension must be located: user defaults, keychains, databases, files that you’re serializing via NSCoding, etc.

    For existing apps, the problem is simple; the data already exists somewhere outside of the shared container, and only the container app can migrate it over. Thus, if the user installs an update that adds an extension, and tries to use the extension before launching the application and giving it a chance to perform the migration, they’re going to have a bad time.

    Workaround

    There’s no great option here. If the user opens our extension first, we just throw up a dialog telling them that they need to launch the application first. Inelegant but necessary.

    We couldn’t get NSFileCoordinator to work

    NSUserDefaults and SQLite are useful for synchronizing data access across both extension and container application, but as per WWDC Session 217, NSFileCoordinator is also supposed to be an option for those of us using NSCoding for custom data persistence. We tried hard, but couldn’t actually get it to reliably work.

    Our use case required both our app and extension to write to the same file, where only the app would read from it. We observed a number of problems while both extension and app processes were running simultaneously. NSFilePresenter methods intended to indicate that the file had been or will be modified (presentedItemDidChange or relinquishPresentedItemToWriter:) would either:

    Workaround

    Rather than trying to keep access to a single file synchronized across processes, we modified our extension to instead atomically write individual files, which are never modified, into a directory that the application reads from.

    This isn’t to say that NSFileCoordinator isn’t currently a viable option if you’ve got a different usage than we do. The New York Times app, for example, is successfully using NSFileCoordinator in a simpler setup, where the container app is write-only and the extension is read-only.

    Share extensions can’t set the status bar color

    The Tumblr share extension – like its container application – has a dark blue background color. White looks great on dark blue. Black, not so much.

    We tried everything, but couldn’t find a way for our share extension (which uses a custom view controller subclass, as opposed to SLComposeServiceViewController) to specify its status bar style. Instead, we always get the status bar style of the host application. Since we’re expecting Photos.app and Safari – both which have black status bars – to be two of the apps that Tumblr users share from the most, this is really disappointing.

    Workaround

    None so far. Neither Info.plist keys nor view controller methods worked, and we couldn’t even get a handle to the keyboard window the way that applications can usually accomplish using private API (Sam Giddins nearly went insane trying. Thanks Sam!). Here’s hoping for a way to do this in iOS 8.1.

    You can’t exclude your own share extension from your application’s activity controllers

    It makes sense that you can’t specifically exclude a specific share extension from an activity view controller. We wouldn’t want Instagram doing something like preventing sharing to Twitter, would we?

    But the one extension that you should be able to remove from your own app’s activity view controllers is your own extension. It’s silly to be able to share to Tumblr from within Tumblr. I mean, it works. It’s OK, I guess. But it’s weird.

    Workaround

    None so far. We tried configuring our activity controllers with an activity item with a custom UTI, and then specifically giving our share extension a predicate that would cause it to not show up when said UTI was present, but it had unintended side effects, which brings us to the next issue…

    By default, share extensions will only show up if they explicitly support all of the provided activity items

    This is a doozy. It’s the most important issue we’ve found, and one that probably deserves a blog post of its own.

    Here’s how applications pass data to share extensions:

    • An application configures a UIActivityViewController with an array of “activity items”
    • The activity controller displays the system activities and share extensions that can operate on the types of items provided

    Here’s how we think this should work, using the Tumblr app as an example:

    • The user long-presses on a photo
    • We put the image data, the posts’s URL, and maybe a text summary of the post, all in the activity items array
    • We’d expect share extensions that support either image data or URLs or text to all show up in the activity controller

    What actually happens is that only share extensions that explicitly support images and URLs and text will show up.

    This is a problem, because the simplest way to specify what your extension supports – and by far the best documented – is by adding NSExtensionActivationRule keys like:

    `NSExtensionActivationSupportsText` : `YES`
    

    This looks like it would mean “show my extension as long as any of the activity items are text,” but it really means “show my extension as long as there is only one activity item, and it is text.”

    Federico Viticci, who at this point has likely used more third-party share extensions than anyone else on the planet, verifies that this is in fact a legitimate problem:

    Workaround

    This negatively affects both app and extension developers. It means that:

    • App developers should only configure their activity controllers with a single activity item. There are a couple of problems with this. First, it’s doable, but a pain if, like in Tumblr.app, you want system activities like copying and saving to the Camera Roll to support multiple different types of data. Secondly, it’s a huge shame to only export one type of data and limit the number of sharing options that your users will be able to perform.

    • Extension developers should use the more complex (and unfortunately, not very thoroughly documented) predicate syntax to specifically specify an OR relationship. This would look something like:

    SUBQUERY(extensionItems, $extensionItem, SUBQUERY($extensionItem.attachments, $attachment, ANY $attachment.registeredTypeIdentifiers UTI-CONFORMS-TO "public.image").@count = 1 OR SUBQUERY(extensionItems, $extensionItem, SUBQUERY($extensionItem.attachments, $attachment, ANY $attachment.registeredTypeIdentifiers UTI-CONFORMS-TO "public.text").@count >= 1).@count >= 1

    Misc.

    Thanks!

    A huge thanks to Matt Bischoff, Paul Rehkugler, Brian Michel, and Sam Giddins for not only helping find these issues and employ these workarounds, but for filing radars, creating sample projects, and helping edit this post as well.

    And of course, to the frameworks and developer evangelist teams at Apple. With extensions, you’ve given us a prime opportunity to delight our users even more. We’ve got lots more ideas and can’t wait to see what everyone else comes up with as well.

  • pipefail:It has been a hot minute since we made the last 1.2.4 release of Collins (actually, its been 270224 hot minutes, give or take), so we figured it was time to cut a new build. So, version 1.3.0 is out. Right now. You can click through to the release page above, but here are some of the highlights:
Play 2.0.8 support
IP allocation improvements
Solr improvements
Official Docker support
Init script de-jankification
Collins_auth gem released
Unit test improvements and cleanups
Asset monitoring plugin
Provisioning knobs and dials added
Restrict provisioning based on asset classification
New AssetType API
Mixed authentication modes
and much more!
Download it and try it out. Or, if you are lazy, it should be as easy as docker run -p 9000:9000 tumblr/collins!
Related: the gif is a glimpse into the development cycle of our beloved Collins.

    pipefail:

    It has been a hot minute since we made the last 1.2.4 release of Collins (actually, its been 270224 hot minutes, give or take), so we figured it was time to cut a new build. So, version 1.3.0 is out. Right now. You can click through to the release page above, but here are some of the highlights:

    • Play 2.0.8 support
    • IP allocation improvements
    • Solr improvements
    • Official Docker support
    • Init script de-jankification
    • Collins_auth gem released
    • Unit test improvements and cleanups
    • Asset monitoring plugin
    • Provisioning knobs and dials added
    • Restrict provisioning based on asset classification
    • New AssetType API
    • Mixed authentication modes
    • and much more!

    Download it and try it out. Or, if you are lazy, it should be as easy as docker run -p 9000:9000 tumblr/collins!

    Related: the gif is a glimpse into the development cycle of our beloved Collins.

  • Kristin Asmus: My Summer at TumblrThis summer I had the time of my life interning at Tumblr with the awesome Android team.  Fun fact:  there are currently only five full-time developers on the team creating one of the top Android apps on the market with tens of millions of downloads!  This meant that even as an intern I got to create interesting front-facing features that really matter to our users.  This involved seeing new features through from their inception through design, implementation, testing, revisions, and ultimately their release to all of our users, which was incredibly rewarding.I worked on a few features this summer, but first, to familiarize myself with our massive code base, I tackled a few bug fixes involving post notes (some were infinitely loading, others appeared with duplicates…not anymore!).  Within a week I’d already begun pushing that code to master and was ready to move on to my first feature.  I was pleasantly surprised at the amount of say I had in choosing my projects, and was really excited to get to work on improving the in-app search experience.My first feature was the addition of search filtering, enabling users to view only posts of a given type within search results.  This was a neat project because it involved modifying our API requests to get the correct results on the back-end, as well as consulting with the design team and building a sleek front-end drawer interface.  This feature was actually released to everyone in an update recently, so maybe you’ve already even used it!  Seeing the update touting my new feature to the world on the Play Store was definitely one of the high points of my summer.Next, I took a break from search stuff to implement a feature to make life easier for our testers and developers.  When we’re testing out big new features, we often rely on a configuration obtained from the server to tell us which new features should be activated and which shouldn’t.  But since we didn’t have any way for a tester to decide which features they’d like to be activated, it could be difficult to tell where bugs were originating.  To address this issue, I created a new settings screen in the beta version of the app for testers to easily see which configuration the server has assigned them, and to change which features are activated at will.  My final big project for the summer was implementing tag search within blogs.  This is a super useful feature that people have been using on the web for a long time, but that couldn’t be done via our app until now - or, until this project is released (stay tuned!).  The design team gave me some pretty ambitious specs for this one, and I’m pleased with how it turned out - it was pretty neat to keep all our new screens and controls consistent with the themes users chose for their blogs.  I’ll be eagerly awaiting word that this has shipped from back at school - hope you guys look forward to it too!I’m leaving Tumblr with many tears to head back to MIT for the fall, but also with a lot of pride in the work I’ve done here, the incredible amount that I’ve learned, and the contributions I’ve made for users of the Android app to enjoy.  I’m so grateful to the Android team for making this experience possible - making me feel like a valuable part of the team, teaching me something new every step of the way, and especially for all the time you put into reviewing my 1000-line pull requests!  Special thanks to Brandon for being so approachable, patient, and infinitely knowledgeable any time I was stuck or needed help.  And a shout out to the rest of the interns too for making this summer in NYC unforgettable!  Working at Tumblr has been everything I could have imagined and more, and it was such a fantastic experience to work with such brilliant, passionate people on a product that we all love to death. 

    Kristin Asmus: My Summer at Tumblr

    This summer I had the time of my life interning at Tumblr with the awesome Android team.  Fun fact:  there are currently only five full-time developers on the team creating one of the top Android apps on the market with tens of millions of downloads!  This meant that even as an intern I got to create interesting front-facing features that really matter to our users.  This involved seeing new features through from their inception through design, implementation, testing, revisions, and ultimately their release to all of our users, which was incredibly rewarding.

    I worked on a few features this summer, but first, to familiarize myself with our massive code base, I tackled a few bug fixes involving post notes (some were infinitely loading, others appeared with duplicates…not anymore!).  Within a week I’d already begun pushing that code to master and was ready to move on to my first feature.  I was pleasantly surprised at the amount of say I had in choosing my projects, and was really excited to get to work on improving the in-app search experience.

    My first feature was the addition of search filtering, enabling users to view only posts of a given type within search results.  This was a neat project because it involved modifying our API requests to get the correct results on the back-end, as well as consulting with the design team and building a sleek front-end drawer interface.  This feature was actually released to everyone in an update recently, so maybe you’ve already even used it!  Seeing the update touting my new feature to the world on the Play Store was definitely one of the high points of my summer.

    Next, I took a break from search stuff to implement a feature to make life easier for our testers and developers.  When we’re testing out big new features, we often rely on a configuration obtained from the server to tell us which new features should be activated and which shouldn’t.  But since we didn’t have any way for a tester to decide which features they’d like to be activated, it could be difficult to tell where bugs were originating.  To address this issue, I created a new settings screen in the beta version of the app for testers to easily see which configuration the server has assigned them, and to change which features are activated at will.  

    My final big project for the summer was implementing tag search within blogs.  This is a super useful feature that people have been using on the web for a long time, but that couldn’t be done via our app until now - or, until this project is released (stay tuned!).  The design team gave me some pretty ambitious specs for this one, and I’m pleased with how it turned out - it was pretty neat to keep all our new screens and controls consistent with the themes users chose for their blogs.  I’ll be eagerly awaiting word that this has shipped from back at school - hope you guys look forward to it too!

    I’m leaving Tumblr with many tears to head back to MIT for the fall, but also with a lot of pride in the work I’ve done here, the incredible amount that I’ve learned, and the contributions I’ve made for users of the Android app to enjoy.  I’m so grateful to the Android team for making this experience possible - making me feel like a valuable part of the team, teaching me something new every step of the way, and especially for all the time you put into reviewing my 1000-line pull requests!  Special thanks to Brandon for being so approachable, patient, and infinitely knowledgeable any time I was stuck or needed help.  And a shout out to the rest of the interns too for making this summer in NYC unforgettable!  Working at Tumblr has been everything I could have imagined and more, and it was such a fantastic experience to work with such brilliant, passionate people on a product that we all love to death. 

  • bryan:

    Had the pleasure of joining Justin Williams on the CocoaRadio podcast to talk about CocoaPods.

    We use CocoaPods to manage our Objective-C dependencies at Tumblr. Learn more about it here.

    Source: bryan

  • Tumblr on Android

    Tumblr on Android is always a hot topic among savvy Tumblr users. It’s easy to get caught up in the hustle and bustle of every day life and forget that this isn’t just a silly app for looking at cool and weird stuff - It’s a complex and robust spectacle of engineering that is under a constant barrage of updates, bug fixes, and new features - all in the sake of helping you look at the cool and weird stuff you love. 

    If you’ve ever daydreamed about the nuts and bolts of Tumblr’s Android app, then this presentation is right up your alley.

  • Tumblr iOS architecture

    Some consider the Tumblr iOS app to be a marvel of modern medicine and science. Others find our custom native HTML rendering to be a telltale sign of our insanity. Other others view our staunch avoidance of Core Data migrations as both prudent and educational. Whichever camp you fall into, you may find something to enjoy in this high-level overview of our iOS application architecture.

  • Tumblr: Hashing Your Way to Handling 23,000 Blog Requests per Second - High Scalability -

    Check out this sweet write up our own Michael Schenck [michael] wrote on scaling Tumblr’s perimeter. 

    At Tumblr, blogs (or Tumblelog) are one of our most highly trafficked faces on the internet.  One of the most convenient aspects of tumblelogs is their highly cacheable nature, which is fantastic because of the high views/post ratio the Tumblr network offers our users.  That said, it’s not entirely trivial to scale out the perimeter proxy tier, let alone the caching tier, necessary for serving all of those requests…