Fun

As seen On Apple TV: A HackWeek Memoir

Last week, to celebrate months of hard work, Rent the Runway hosted HackWeek, a week-long hackathon. This was an opportunity to work with new technologies, hardware, languages, as well as coworkers outside of our usual teams.

So on the Friday before HackWeek, we gathered in the kitchen to hear the pitches and decide what projects to work on. That same Friday, Rent the Runway received the AppleTV Developer Kit (Fun fact: we won it in the AppleTV lottery for just one dollar!) Naturally, the mobile team was itching for an opportunity to tinker with our new toy.

On Monday, our team was formed. Its group members? Billy Tobon - Lead iOS Developer, Sandy Woodruff - Product Designer, and Lea Marolt Sonnenschein - iOS Developer.

We spent the first day reading the Apple tvOS documentation, looking at Apple's human interface guidelines, and learning from their examples. We also spent some time thinking of a clever app name. We ended up with TVGunn (Hint: Project Runway). We realized that building applications for the TV relies heavily on a strong understanding of the user interface to create an application that is:

  1. Simple to use: The user should be able to go through the entire app with just a few taps and flicks of the finger.

  2. Actually usable: Asset placement is important in tvOS. If two assets that can be hovered over are too far from each other, the user won't be able make the transition from one to the other.

  3. Sensible: There's actual value in creating a tvOS app. It complements your existing apps and doesn't just exist for the sake of having your app on all available platforms.

 

With that in mind, we brainstormed, sketched, discussed, failed a lot, and learned from our failures. For example, For example, Apple gives developers two options of developing tvOS apps: native, or using their new Television Markup Language - TVML (along with TVJS and TVMLKit). We spent hours trying to figure out what the best template was for our use case, and trying to work with this new XML and JavaScript. At the end of the day, we decided to scrap the project, and start off fresh with a native implementation the next day.

 

FIRST LESSON LEARNED: If you actually want to build something usable, stick to your guns at a hackathon. If you don't care whether the final product works, feel free to explore.

 

On Tuesday, things got off to a good start. We had a plan. TVGunn would be an app placed in Rent the Runway stores that could help users browse through their shortlists in-store. There would be iBeacons placed in the store to detect the user's shortlists, and automatically pull them up on the screen when the user's credentials were verified. This would help streamline the process of interacting with the stylist.

 

Sandy created fantastic mockups, while Billy and I had a clear division of labor on the tvOS side. I was going to work on the app's frontend, while he would try to make our RTR Foundation Framework work with tvOS, so that TVGunn could easily talk to the backend. In the spirit of HackWeek, we decided to write the app in Swift - the RTR iOS app is completely written in Objective-C. Not only that, but we decided to use Storyboards, something many a mobile team dreads like the plague.

 

SECOND LESSON LEARNED: Betas will be betas - things will break and there's nothing you can do about it.

 

In order to develop for tvOS, we had to download the latest Xcode Beta - 7.1. We quickly learned that the Beta is called a Beta for a reason. For example, using Storyboards resulted in a crash every time I tried to drag a new View Controller on the board. I ended up copying the default View Controller set up in the Storyboard 5 times to achieve the user flow that we wanted - #scrappinessisavirtue.

 

THIRD LESSON LEARNED: Cocoapods don't play nicely with tvOS (yet).

 

Despite the Cocoapods fix for tvOS, released on Wednesday, we couldn't import the frameworks we use in our iOS App as pods, so Billy ended up importing them into our project directly. That resulted in a massive amount of errors that took almost two days to debug. In the meantime, Sandy learned how to create LCR files and make use of Apple's new tools to design parallax icons - ParallaxExporter and ParallaxPreviewer. I, on the other hand, tried to figure out how to best mimic Apple's interface. When the user moves from one element to another, the second element has to expand and cast a shadow to create the feedback needed for the user to know what element they're currently on. While this is done for us in some UI elements, like the UITableViewCells, it's not done in others, like the UICollectionViewCells. In order to achieve the look and feel that the user expects, I had to learn how to use special Focus Engine Controls only available on the tvOS.

We could play with this icon for hours!

We could play with this icon for hours!

 

FOURTH LESSON LEARNED: Parallax icons look and feel fantastic. We played with that app icon just a little too long when we finally got it on the screen.


FIFTH LESSON LEARNED: Don't count on everything you see in examples to be pre-built. I had to put in some muscle in order to get the interface looking and feeling the way Apple does in their examples.

 

SIXTH LESSON LEARNED: Swift 2.1 has evolved-a lot. Make sure to always read the newest documentation carefully, instead of just assuming the old ways work. Otherwise you will experience unnecessary frustration.

 

Swift offers a severely streamlined process of creating apps. Unfortunately, because Swift is still evolving, many of the language's aspects have changed with each iteration. Because of that evolution, learning from older examples proved to be a little difficult, because they didn't work with this new syntax. For example, background tasks and requests now have to be wrapped inside a try/catch block.

 

SEVENTH LESSON LEARNED: Persisting data on tvOS is tricky. We knew from the documentation that there was no local store in the appleTV, and we planned not to persist anything in the device, but when we tried to use a SaaS solution (Parse) as a bridge between iOS and tvOS the app wouldn’t even load, because most of these types of frameworks use local store for caching.


 

In the spirit of HackWeek, we ended up using Parse via REST, and storing user credentials to Parse in plaintext (a definite no, no in production apps) based on data received from the iBeacon. Inside the app, we used a timing function that periodically checked if a new user had appeared on Parse. If there was no user on Parse, the app would play the official RTR promotional video. If the user appeared, however, the app immediately redirected to their shortlists.

 

By Friday, we ended up with a pretty solid working demo, and presented it to the whole company. Billy presented the hack and explained how it works, while Sandy and I did a small roleplaying sketch to make sure everyone understood our use case. Everyone seemed to enjoy it, and we're excited to explore its use. Even though, the demo was a success, we all know that the app has several problems, and is therefore not ready for production. Because this was HackWeek, though, we allowed ourselves to use not-so-stellar coding practices, pass data that shouldn't be passed around willy-nilly, and all in all, hack our ways until we made it work.

 

EIGHTH LESSON LEARNED: Never use the "F*** it, ship it!" method. If you decide to make a hackathon project a production project, scrap the whole thing and start from scratch. This will allow you to follow good development practices, and create a well-maintainable product, instead of having a codebase with so many leaks, you spend more time working on covering up the problems, rather than fixing them and focusing on moving the product forward.

 

All in all, HackWeek was a fantastic experience and a great success. Our team collaborated well and iterated quickly. We learned a lot of new things, and in the end produced a beautiful and exciting app using completely new hardware. I'm extremely proud of my team, and couldn't be happier I worked with them this entire week. We all can't wait to actually create a live Apple TV app, because we believe that the Apple TV has tremendous potential for how our customers can experience Rent the Runway!

Yours in Fashion,

Lea, Sandy & Billy


ChatOps! Or, How I Learned to Stop Worrying and Love the 'Bot

I hope that when future historians look back on October 18th, 2013, they do not identify it as the start of the robot apocalypse.

On that date, I made the initial commit for Fashionator, Rent the Runway's Hubot instance. Until then, most of the communication from machine to human at RTR had been done via e-mail: service alerts, Nagios, Airbrake, and so on. We did have PagerDuty, but rather than having accounts for everyone, we had one shared account tied to a physical on-call iPhone. It was pink. I was led to believe it had been dropped in the toilet at least once. It was so noisy that most people turned off the ringer and just kept an eye on the deluge of e-mail devastating the inbox. I was not a fan.

To be clear: I didn't initially create our robot to solve this problem. Fashionator was born the way all Hubots are born, with community scripts to spam people in your company chat with animated GIFs clipped from '80s cartoons or pictures of put-upon looking pugs donning dollar store Halloween costumes. I figured the robot would be a welcome diversion from our fires rather than a tool to help extinguish them.

I don't remember the first useful script I added—it might have been one that checked Heroku's status, since we used to host some of our Sinatra applications there—but I remember the moment when people began to think of Fashionator as a productivity tool instead of as a distraction. A member of our product team asked one of the engineers to flush caches in the storefront stage environment. I said, "Fashionator can do that," and asked the robot to flush Memcached, which she did.

HipChat exploded. "I had no idea she could do that!" "What else can she do?" Pull requests started coming into the Fashionator repo over the next several days, and at our next hack day, I volunteered to help people hack on Hubot. Over several more hack days, scripts to automatically handle stage orders, query the PagerDuty API, write JIRA tickets, and deploy our WWW site to QA and stage environments appeared. We put her under Puppet's control and gave her her own Jenkins deploy pipeline.

The benefits of maintaining Fashionator have been surprising and tremendous. The centralization of communication afforded by having her in HipChat, where most of us spend our day anyway, means that we see alerts and deploy announcements immediately; if there's an incident, we can gather in our war room and ask if there are problems with GitHub, find out who's on call, search JIRA tickets if we suspect a recent change has broken something, and more. Fashionator also increases transparency and accountability, since everyone can see (or review in HipChat logs) what she's doing and who asked her to do it. Improved communication facilitated by our Hubot has made us better at everything from identifying and fixing bugs to onboarding, and with API integration with GitHub, Jenkins, JIRA, PagerDuty, and more, we're constantly making it faster and easier to share knowledge and get things done.

There are, of course, still times when she's bad:

But Fashionator has become an integral part of our lives at Rent the Runway, and we couldn't imagine working without her.

If you'd like to download your own Hubot, you can find instructions here and a repository of community scripts here.


Gmail I love you, but you’re bringing me down.

Dear Gmail, Why must you not allow more than a dozen fonts into your existence? My designers and I would love to use something different than (sans serif, serif, comic sans ms, courier new, garamound, Georgia, Tahoma, trebuchet ms, verdana). I am forced to embed text into images that never really shows up as clean as we would like.

Why oh why Gmail, do you thread any email with the same subject line? Which isn’t the worst thing in the world but what is, is that you then insist on coloring the duplicate font purple, specifically #500050 . Plus, you impose a class on the text called “im”. I am then forced to declare color value for my font not just in the containing table but also in every cell where font exists.

Why did you not allow style tags in the body nor the head? Then miraculously allow it with out notifying anyone or documenting it, forcing people to stumble upon this by happenstance? What worse is that you strip classes and ids on everything forcing people to chain table+tr+td+table+tr+td+table+tr+td+div on and on and on as deep as their nested tables go, in order to allow some kind of fluid styling to occur. You won’t even allow @import, @media or @font-face among other things that would allow for amazing email designs to occur.

 

P.S. Apple you’re no saint.

Why must you automatically see any date, time, address or any combination there of, and impose an anchor tag around it therefore styling default bright blue and of course adding an underline? This really messes with the design and adds unwanted linking to occur. If I wanted it to link I would code it that way. In order to fix this I have to style for an anchor tag that isn’t there knowing that is will be placed there without my say so. I am not a prognosticator and do not want to start having to be in order to fix things you might do.

 

P.P.S Outlook you suck the most!

Practically nothing renders for you the way it does for either of the above. It doesn’t even look the same between your own versions i.e. 2010, 2011, 2013. You would think that within your own family you’d keep some kind of fluency…nope!

 

Can’t you all play together nicely and have some kind of U.N. type organization that will oversee and perhaps unify this email-coding world into one big happy family?