This year at the fifth annual Zillow Saltine Challenge we had a number of notable “firsts.” The challenge — eat as many crackers as you can in 1 minute — and the unbridled passion were the same, but the sheer scale and intensity of the competition were unlike anything we have seen before.
The skyrocketing demand for highly skilled software developers in the past few years has created great hiring challenges for the computer science and technology industry. This crunch is compounded by the fact that these fields are predominately male, thus under-representing half of the population. To help battle this gender inequity in software development and to fill the need for developers, the Ada Developers Academy (Ada) has announced a brilliant program: a tuition-free, year-long intensive programming school for women. The program provides six months of full-time classroom instruction and hands-on learning with the Ruby on Rails stack, along with up to six months of internship at a Seattle-area tech company. In order to qualify for Ada, applicants must go through a rigorous interview process, demonstrating their passion for programming and a determination to make the transition to a career in computing.
At Zillow, we like to release code as often as possible, because this lets us iterate quickly and get bugfixes and improvements to our users sooner. Need a landing page because the president of the United States called and your CEO will be moderating a video chat with him in a few days? You’d better be able to ship code quickly. To support our fast releases, we need a testing system that can quickly gauge the quality of any given release. This is easy with a small team, but becomes more difficult as one continues to grow and add developers. More devs means more changes merging together at an ever-increasing pace. To ship safely, we need to be able to quickly determine if all this newly-integrated code is behaving in the way we expect it to.
Automated testing is certainly part of the answer, but we need to compile results from different testing frameworks into a single source that can quickly show us the quality of a piece of code. Enter “Zon.” If you’ve read some other posts on the Zillow Engineering Blog, you’ll know that we like Z names. The name “Zon” comes from Z-On. It tells us when services are up or on. Ideally, all the time! Continue Reading…
My favorite feature of the Google Maps Android API v2 is the ability to quickly and easily add TileOverlays to a map. Google really opened doors for the Android community with this feature. At Zillow, it allowed us to display content on that map that is relevant to a home search such as property lines and school attendance zones. With Google Maps Android API v1 we would have had to implement our own tiling layer perhaps with a Canvas overlay, which gets expensive for those with low-end phones with limited memory resources and could become expensive to maintain.
Having experience with a wide variety of languages and tools can sometimes leave one in a frustrating situation: one knows an easy way to solve a problem using some language or toolset that’s not practical for the target platform. Recently, I was working on an iOS app with a library that generates a stream of data into an NSOutputStream. Seems like a reasonable way to design a library. Without looking closely, one could assume that it would be easy to add some manipulation to the stream of data on its way to a file, resource or memory buffer, perhaps to filter out unnecessary content. The first thing that comes to mind is to create a subclass of NSOutputStream that overrides the write:maxLength: method, but that turns out to be a rather onerous undertaking: it’s easy to overlook the statement in the NSOutputStream documentation: “you may have to implement initializers for the type of stream data supported and suitably reimplement existing initializers.” The compiler doesn’t help, since it sees the initializers declared, so if your subclass (or its client) tries to use any of the initializers other than init, it will compile without any warning but trigger an unrecognized selector exception at runtime. That’s because the subclass of NSOutputStream isn’t “toll-free bridged” to the foundation class that implements those initializers.
One answer to this is to create a subclass that creates a delegate instance of NSOutputStream and implements the desired initializers by implementing all the methods of NSOutputStream as calls to the corresponding method on the delegate. That results in a class with a whole bunch of code (14 overridden methods) with no added value.
So I talked with my colleague, Sanjit Saluja, and he pointed out some code that does message interception. That led us to the idea that instead of creating a true subclass of NSOutputStream, we could create a class that creates objects that contain a delegate instance of NSOutputStream with some short and sweet message forwarding so that these objects act like NSOutputStream. That way, there’s only code to implement the new behavior (as one would expect when specializing a class), plus a couple of methods to tie the new class to delegate.
Mobile app UI test automation is still in its infancy. Whereas web testing had around 20 years to bake some good tools such as Selenium, Watir, and many others, Mobile apps in the current incarnation and popularity have only existed for 6 years since iOS & Android launched in mid-2007. Because Mobile apps are quite young there hasn’t been a lot of time for good test tools to be developed, and most that do exist are developer-centric.
Our team was doing a lot of manual app testing which left us open to missing the occasional important regression. We started looking and evaluating automation test tools about 2.5 years ago. Some of the most popular options we encountered along the way were Robotium for Android, Xcode’s Instruments for iOS, and KIF for iOS, all of which we tried with limited success before we landed on Appium as our framework of choice.
Our Robotium framework died within a month – before we had any test cases running on a regular basis. Additions to our KIF test cases plateaued because they require coding ObjectiveC tied directly to our app code. Our Instruments test cases were working but presented a serious maintenance burden.
Since the dawn of the shell scripting, developers have been using shell scripts and shortcuts to accomplish the quick, tedious things in everyday programming. Everything from starting a server, to creating a properly formatted diff, to navigating and searching directories are quick, small functions that can be encapsulated by shell scripts or functions.
The case was the same at Zillow. There’s no point spending time performing complicated, tedious workflows over and over again. So developers started writing scripts to make some of Zillow’s workflows easier.
Now developers’ workflows were faster, but there was only one problem. Developers were writing the same shell scripts over again! Without a central methodology to share these scripts, multiple developers would implement similar functionality in different ways, and without standard naming conventions, a developer couldn’t work quickly on another’s machine when doing something like pair programming or debugging a problem.
Two times a year, the entire engineering team at Zillow spends a full week working in small teams or individually on fun and interesting projects that are outside the formal backlog of projects. Some teams work on new feature areas and businesses, and some teams work on internal tools and productivity enhancements. We would like to solicit ideas from the community ahead of the next hackweek, which will take place in a few weeks. Email your ideas to us at email@example.com. You can also add them as comments to this blog post for others to see.
Below is a post on our Facebook page describing some past projects and sharing a few photos.
This past Hackweek I had the opportunity to explore a bit of Zillow’s headquarters and find out more about Zillow’s employees. The series of slides below are a collection of what I observed while walking around the office, and of data gathered from an internal survey that was sent out. Enjoy!
You may have heard the saying that the three most important things in real estate are location, location and location. That has been true from the beginning in Zillow Mobile apps for Android and iOS, where our apps start out with a map-based search. We use GPS to zoom in on the user’s current location, and the map will immediately show homes for sale and for rent nearby.
Figure 1 – Zillow Real Estate Android App