No Gravatar

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.

Google Maps V2 with the Property Line Data Overlay

[Continue Reading...]

No Gravatar

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.
[Continue Reading...]

No Gravatar

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.

[Continue Reading...]

No Gravatar

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.
[Continue Reading...]

No Gravatar

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 hackweekideas@zillow.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.

No Gravatar

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!

Information was gathered from observation and an internal survey to learn a bit more about Zillow and what it's like working in our offices.

Information was gathered from observation and an internal survey to learn a bit more about Zillow and what it’s like working in our offices.


[Continue Reading...]

No Gravatar

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.

Figure1-ZillowAndroidRealEstateApp

Figure 1 – Zillow Real Estate Android App

[Continue Reading...]

No Gravatar

Like everyone  at Zillow, I spent our most recent Hack Week trying to test the limit of coolness.  I also gave myself a mission: to show the public, or at least the dev community, the power and potential Zillow data provides.

To access the Zillow data-trove, I used our public APIs. In four days, I built two projects:  one for cloud, and one for desktop. Both earned some laughs and applause at our Hack Week demo day.

The first project is called zTalkBot:  a chatbot backed by Zillow’s brain! It runs on Google App Engine. I’ve found that GAE is an excellent way to build up quick prototypes; it’s also one of the cloud platforms we build on for our production sites. To chat with it, add ztalkbot@appspot.com to your gtalk contacts now!

Here’s a demo:

YouTube Preview Image

[Continue Reading...]

No Gravatar

As mentioned in a previous post on this blog, Zillow holds Hack Week events a few times a year during which teams work on projects of their own choosing.  We put the “own choosing” of this philosophy to the test during our most recent Hack Week by tackling a Zillow Kegerator project.  The tablet-controlled and Web-enabled Kegerator was built with the help of the open-source KegBot Project.  The team consisted of Jarret Falkner and myself.  We are both equipped with an appreciation of beer, but very little electronics experience.  With the help of the KegBot documentation and some tips from other Zillow employees we set off to complete the project in a week.  Read on to see the results.

[Continue Reading...]

No Gravatar

When we built our Premier Agent Websites, we decided at the beginning to base the product on the WordPress core. We knew we wanted to host it ourselves for ultimate control, we wanted to run bare minimal off-the-shelf plugins for security reasons, we needed it to scale it to tens and hundreds of thousands of sites, and we wanted it to be literally faster than any other provider out there. In order to meet these criteria and our high standards, we knew we had to make some smart infrastructure and architecture decisions.

We did things a bit different than what many of the current WordPress best practices recommend and many existing plugins offer, and we feel great about what we ended up with. With that in mind, we’d like to share some of our differentiating secret sauce with the WordPress community.

It All Starts With DNS

Before a user’s browser even hits a server for the initial load, an IP needs to be resolved via DNS. DNS performance is far more important (PDF) than many people realize, and this part of the infrastructure should never be glossed over without any thought.

In our case, we host nearly all of our clients’ DNS records on Amazon’s high-performance and globally-distributed Route 53 service. We allow each of our clients to host the free domain they get through us, or use one they already own, and manage the DNS for that domain on Route 53 via that API and a custom UI. We also host the DNS for our CDN domains (more on that later) on Route 53. The result is that the lookups on our clients’ domains and the CDN domains are incredibly fast!
[Continue Reading...]