Profile cover photo
Profile photo
Gonzalo Maldonado
I make the web rock
I make the web rock

Gonzalo's posts

Post has attachment

Post has attachment

Post has attachment

Post has shared content
Let's talk time scales real quick. Your computer's CPU lives by the nanosecond: most CPUs can get a few things done in each nanosecond – mostly simple math and comparisons. To make this easier to grasp, suppose you're the CPU and instead of nanoseconds, you live and work second by second. For clarity I'll keep this metaphor to a single-core of a single processor.

You can hold a few things in your head (register). Not more than a dozen or two in your active memory, but you can recall any of them pretty much instantly. Information that's important to you you'll often keep close by, either on sheets of loose-leaf paper on your working desk (L1 cache) a couple seconds away, or in a one of a handfull of books in your place (L2 and up cache) which is so well organized that no individual piece of information is more than a dozen or so seconds away.

If you can't find what you're looking for there, you'll have to make a quick stop at the library down the street (RAM, i.e. main memory). Fortunately, it's close enough that you can go down and grab a book and get back to work in only ~8 and a half minutes, and it's enormous, some are thousands of times the size of a typical strip-mall book store. A little inconvenient, until you remember that this library has a free delivery service, so it's really no bother at all so long as you can still find things to work on while you wait.

But the local library mostly just stocks things on demand (which is fair, your bookcases, worksheets, and even the dozen or two facts you hold in your head are mostly the same way). The problem is that when you need something that's not there, it can take a while to get it. How long? Think in the age of exploration. They send out an old wooden boat and it could be a week, could be a month, and it's not unusual to wait 3 years before you hear a response.

Welcome to the world of hard disk storage, where your information is retrieved by making plates of metal spin really fast. Many metric tons of sweat have been spent making this as fast as possible, but it's hard to keep up with electrons flowing through wires.

So when someone says that Solid State Disks are awesome, it's because they're able to turn that slow, unpredictable old sailing ship into a streamlined steam-powered vessel. A good SSD can often make the voyage in less than a week, sometimes in little more than a day. It can also make many thousands more quests for information per year.

(If you're looking for an SSD, I recommend you read , I recently got an OCZ Vertex 3 but it has been brought to my attention that they have unresolved and quite serious bugs.)

[credit inspiration for this post: 1) 2) 3)]

Edited to fix a typo, and add in the third inspiration for this post, which I'd forgotten (click to magnify for it to make sense)
Edited again: Looks like the drive I recommended is problematic, I've withdrawn the recommendation. Linking to the site where I got the information to make my decision is better for folks who might stumble upon this post later.

Post has shared content
Good bye, Google Maps… thanks for all the fish

TL;DR: We at StreetEasy decided to build our own maps using, among other tools, OpenStreetMap, TileMill, MapBox and Leaflet, instead of paying hundreds of thousands of dollars per year to Google. And yes, the money pushed us into doing it, but we're happier with the result because we now control the contents of our maps.

We were all happy...
Our site, StreetEasy (, has been using Google Maps embedded in our pages for the last 6 years. We're a real estate portal, so most of our pages have maps in them. So when Google announced they new usage limits (see , we were a little worried.

25,000 free map views per day, and $4 per CPM (1,000 views) beyond that. On Christmas day, when everybody was opening their presents, we did ten times that. On a good day, we do 600K-700K pageviews (

We did the math and came up with numbers that reminded me of Oracle licensing in 1999. Six, seven, eight hundred thousand dollars. We met with Google salespeople, expecting to negotiate better terms, and they were nice, and they offered us discounts, but only to about half of what we've calculated.

In our opinion, their price was off by an order of magnitude. It's very, very hard to work out a $2 CPM cost in any site's business model, when most of the time, if you're lucky, you're making $1 CPM off your pages. And yes, StreetEasy does much better than that, and it would not have bankrupted us, but it would have also meant giving away a significant chunk of our profits.

It was not just the money!
$200,000 to $300,000 a year is, at the very least, the same as hiring a very good engineer for a year (and paying all the taxes and benefits and costs and still having a lot of money left). It was enough money to finally push us into doing our own maps.

Because despite Google Maps being such an awesome product, it had it's downsides. One is that your site looks just like every other site with maps on the Internet (and I know you can customize their colors now, but that costs even more!). Another is that you have no control over your maps, so when you're trying to point out the location of this wonderful apartment, Google might thing it's a good idea to cutter the map with random local businesses (and yes, they've gotten better at it, but often it's just noise). Or they might have bad data, and there's very little you can do about it except report it and wait. (I've always been annoyed at "Classon Pointe" being shown in the middle of Harlem, probably a mistake by some mapping data company decades ago, again, something that has been corrected, but that highlights the problem)

I've always wanted to have our own maps, but thought it would be impossible, or at the very least, a huge amount of work. Something not worth considering, given the rest of a long list of things we also wanted to build on StreetEasy. But with a potential invoice for a third of a million dollars hanging over our heads, we had enough "carrot" (or is it "stick"?) to revisit our priorities. At the very least, we should do more research and see what our options were.

Looking beyond GMaps
Our first option was, of course, Bing Maps. I'm sure Microsoft is having a great time helping all the Google Maps Refugees, and I have no doubt they would have offered us a very cheap licensing deal, but it still meant using someone else's maps, and leave us with license renegotiation risks a year or two down the road. But it was an option.

Then, my coworker +Jordan Anderson, sitting quietly across my desk, pointed out that his "other job", the site he had built with a friend before joining StreetEasy, the fabulous Ride The City (, did not use Google Maps, but their own tiles, and an open source JS library to display them.

A couple of days later, at a NYC Big Apps hackathon where we were showing off our public APIs, I met +Javier de la Torre (from and he showed me his awesome product, CartoDB ( and gave me a few more pointers. And I saw what +Alastair Coote was doing for his taxi app and got excited with the possibilities.

I spent the next week reading and browsing and searching, discovering the wonderful world of digital cartography, and being amazed at how far the open source tools had advanced in the last few years.

The world of Open Source Cartography
We now had a great tile renderer, Mapnik (, that was at the core of pretty much every mapping tool out there. Great "geo" and "gis" functionality for Postgres, in the form of PostGIS ( A few javascript libraries to present the results inside web browsers, such as Leaflet (, Open Layers ( and Modest Maps (, and other libraries to abstract your mapping backend behind a common API, such as Wax ( or Mapstraction (

But then I discovered the "second generation" of tools, built on top of what I just listed on the previous paragraph, and it blew my mind. Things like CartoDB or TileMill ( or Web Map Studio (

TileMill, in particular, was just amazing, and Carto CSS ( made map design look like something I could actually do!

And of course, OpenStreetMap (, the Wikipedia of mapping. An open source (well, technically, Creative Commons) data set, covering the entire globe, with lots of details (sometimes too much detail, like the voltage and gauge of a subway line!). It has a few errors here and there, but you can go and fix them yourself (as I've done

The path we took
I settled on Leaflet for the front end, mostly because it was small, fast, clean code with a good API that resembled Google Maps v2. It's a good thing that when we first implemented maps on StreetEasy, we did it through ruby that generated the JS code, so all I had to do was "implement an new backend". If I were to do it today, I might use Wax or Mapstraction instead, to ensure I could change map APIs if I had to.

It was fairly easy to implement most basic features. Showing a map, adding markers, adding polygons, info popups (we had our own code for that, just had to hook it on the right events). I spent a couple of days getting our "polygon editor" to work (something I plan to contribute back to Leaflet as soon as I have time to clean up the code). And of course, the dreaded "does it run on IE?" time (I ran into some issues with onload events on script tags, but that was all).

I installed Postgres and PostGIS, downloaded OSM extracts from, because there is no point in downloading gigs and gigs of worldwide data when all I care about is the area around NYC. Imported it using osm2pgsql ( and started playing with TileMill.

I discovered the work of Mike at Stamen (for example and was inspired by it. Found a couple of TileMill projects ( and to better understand how to organize them. Ran into High Road (, a set of queries that makes OSM roads much more manageable and stylable.

And I spent days and days tweaking maps. Just to get to a point where we were not unhappy with our maps. Something that was good enough to flip the switch.

We added building outlines from NYC Open Data (, and our own neighborhood boundaries to decide where to put the labels (and trust me, we have the best boundaries for NYC).

As soon as I had something that didn't cause my coworkers to vomit, I uploaded the tiles to S3 and started testing it on our site. A few days later, and a lot more map tweaks, we started using the new maps for some of our users. And as of Jan 10th, we flipped the switch for all pageviews on our site.

We decided to host our tileset with MapBox (, from the great guys at Development Seed.. We could have unpack the mbtiles file produced by TileMill and just upload them to S3 (see, but we went ahead and paid for MapBox, in part because it means less servers to worry about, in part because we want to support the guys that brought us TileMill, and in part because of the promise of more cool features down the road. And most importantly, because they promised to help us make our maps look nicer, and they know about nice maps.

Take a look at the results:

Where to now?
If I haven't made it clear, we're not completely happy with how our maps look, but we were happy enough to go ahead. We want to make them look great, with more data (such as subway stations) and better labels and lots of other little things. Development Seed will help us with that, and we've been learning a lot ourselves.

We'd also like to have a "live mapnik server", producing tiles on demand (and caching the results, duh) to make it easier to tweak our maps. Right now it takes a couple of days to go from OSM import to tile rendering to uploading multi-gigabyte files and finally showing them on the site. A live server would let us change a stylesheet and see the results right away.

We will try to contribute back to all these open source projects as much as we can. I already have some code for Leaflet for polygon editing and encoding, for example, and we've started doing edits on OSM.

What about geocoding?
You'd probably noticed I didn't talk about geocoding (the "art" of converting a street address into a set of coordinates in a map, in case you didn't know). That's part of what Google offers as part of their Maps APIs.

Well, at StreetEasy we built our own geocoder for NYC, using the City's database of streets and buildings. So it's not something we had to worry about as part of this transition.

But in case you need to do some geocoding, there are plenty of tools (for example that use OSM data.

The Year of the Open Map
I think that someone at Google got their pricing wrong by an order of magnitude. Large companies might be willing to pay that kind of licenses, but this is not the CMS market in 1998, where people would pay half a million for a Vignette license and another million for Oracle. There are so many open source options out there that the value of proprietary solutions has come down dramatically.

And if Google keeps pushing companies into experimenting with these open source solutions, it's only going to get better. I think 2012 is going to be the year of the Open Map. And I'm happy to be part of the front lines.

Post has shared content
Follow up to “Android graphics true facts”, or The Reason Android is Laggy

Yesterday +Dianne Hackborn posted to Google+ an article that dismissed the common accusation that Android is laggy because UI rendering wasn’t hardware accelerated until Honeycomb:

It’s an insightful post that illuminates many of the complex issues with smooth Android rendering. Unfortunately, it doesn’t answer the fundamental question asked by both technical and nontechnical android users:

Why is Android laggy, while iOS, Windows Phone 7, QNX, and WebOS are fluid?

This post will attempt to answer that question.

However before I jump in, a couple disclaimers. First, I am a 3rd year undergraduate software engineering student. I interned on the Android team, and +Romain Guy who was responsible for much of the hardware acceleration work in Honeycomb, reviewed some of my code, but I was not on the framework team and I never read the Android rendering source code. I do not have any authoritative Android knowledge and I cannot guarantee what I say here is necessarily 100% accurate, but I have done my best to do my homework.

Second, I’m interning with the Windows Phone team starting in January, so it’s possible that this post will be unconsciously biased against Android, but if you ask any of my friends, it’s really hard to shut me up about Android. I have more Android t-shirts than days of the week and I’d rather give away my Macbook than my Nexus S. The Googlplex is like a second home - I’ve slept there on more than a few occasions to the dismay of startled janitors (and if you ever get a chance to visit, the banana french toast at Big Table Cafe is to die for). If anything, I’m probably biased in Android’s favor.

Finally, any opinions expressed in this article are solely my own and do not represent those of any past or future employers.

With that out of the way, lets dive right in.

Dianne starts off her post with a surprising revelation:

“Looking at drawing inside of a window, you don’t necessarily need to do this in hardware to achieve full 60fps rendering. This depends very much on the number of pixels in your display and the speed of your CPU. For example, Nexus S has no trouble doing 60fps rendering of all the normal stuff you see in the Android UI like scrolling lists on its 800x480 screen.”

Hun? How can this be the case? Anybody who’s used a Nexus S knows it slows down in all but the simplest of ListViews. And forget any semblance of decent performance if a background task is occurring, like installing an app or updating the UI from disk. On the other hand, iOS is 100% smooth even when installing apps. But we know Dianne isn’t lying about the potential CPU performance, so what’s going on?

The Root Cause

It’s not GC pauses. It’s not because Android runs bytecode and iOS runs native code. It’s because on iOS all UI rendering occurs in a dedicated UI thread with real-time priority. On the other hand, Android follows the traditional PC model of rendering occurring on the main thread with normal priority.

This is a not an abstract or academic difference. You can see it for yourself. Grab your closest iPad or iPhone and open Safari. Start loading a complex web page like Facebook. Half way through loading, put your finger on the screen and move it around. All rendering instantly stops. The website will literally never load until you remove your finger. This is because the UI thread is intercepting all events and rendering the UI at real-time priority.

If you repeat this exercise on Android, you’ll notice that the browser will attempt to both animate the page and render the HTML, and do an ‘ok’ job at both. On Android, this a case where an efficient dual core processor really helps, which is why the Galaxy S II is famous for its smoothness.

On iOS when an app is installing from the app store and you put your finger on the screen, the installation instantly pauses until all rendering is finished. Android tries to do both at the same priority, so the frame rate suffers. Once you notice this happening, you’ll see it everywhere on an Android phone. Why is scrolling in the Movies app slow? Because movie cover thumbnails are dynamically added to the movie list as you scroll down, while on iOS they are lazily added after all scrolling stops.

Other Reasons

The fundamental reason Android is laggy is UI rendering threading and priority, but it’s not the only reason. First, hardware acceleration, despite Dianna’s reservations, does help. My Nexus S has never been snappier since upgrading to ICS. Hardware acceleration makes a huge difference in apps like the home screen and Android market. Offloading rendering to the GPU also increases battery life, because GPUs are fixed-function hardware, so they operate at a lower power envelope.

Second, contrary to what I claimed earlier, garbage collection is still a problem, even with the work on concurrent GC in Dalvik. For example, if you’ve ever used the photo gallery app in Honeycomb or ICS you may wonder why the frame rate is low. It turns out the frame rate is capped at 30 FPS because without the cap, swiping through photos proceeds at 60 FPS most of the time, but occasionally a GC pause causes a noticeable “hiccup”. Capping the frame rate at 30 fixes the hiccup problem at the expense of buttery smooth animations at all times.

Third, there are the hardware problems that Dianne discussed. The Tegra 2, despite Nvidia’s grandiose marketing claims, is hurt by low memory bandwidth and no NEON instruction set support (NEON instructions are the ARM equivalent of Intel’s SSE, which allow for faster matrix math on CPUs). Honeycomb tablets would be better off with a different GPU, even if it was theoretically less powerful in some respects than the Tegra 2. For example, the Samsung Hummingbird in the Nexus S or Apple A4. It’s telling that the fastest released Honeycomb tablet, the Galaxy Tab 7.7, is running the Exynos CPU from the Galaxy S II.

Fourth, Android has a ways to go toward more efficient UI compositing. On iOS, each UI view is rendered separately and stored in memory, so many animations only require the GPU to recomposite UI views. GPUs are extremely good at this. Unfortunately, on Android, the UI hierarchy is flattened before rendering, so animations require every animating section of the screen to be redrawn.

Fifth, the Dalvik VM is not as mature as a desktop class JVM. Java is notorious for terrible GUI performance on desktop. However, many of the issues don’t carry over to the Dalvik implementation. Swing was terrible because it was a cross platform layer on top of native APIs. It is interesting to note that Windows Phone 7’s core UI is built in native code, even though the original plan was to base it entirely on Silverlight. Microsoft ultimately decided that to get the kind of UI performance required, the code would have to be native. It’s easy to see the difference between native and bytecode on Windows Phone 7, because third party apps are written in Silverlight and have inferior performance (NoDo and Mango have alleviated this problem and the Silverlight UIs are generally very smooth now).

Thankfully, each of the five issues listed above is solvable without radical changes to Android. Hardware acceleration will be on all Android phones running ICS, Dalvik continues to improve GC efficiency, the Tegra 2 is finally obsolete, there are existing workarounds for the UI compositing problems, and Dalvik becomes a faster VM with every release. I recently asked +Jason Kincaid of +TechCrunch if his Galaxy Nexus was smooth, and he had this to say:

“In general I've found ICS on the Galaxy Nexus to be quite smooth. There are occasional stutters — the one place where I can consistently get jitters on the Galaxy Nexus is when I hit the multitasking button, where it often will pause for a quarter second. That said, I find that the iPhone 4S also jitters more than I had expected, especially when I go to access the systemwide search (where you swipe left from the home screen).”

So there you go, the Android lag problem is mostly solved, right? Not so fast.

Going Forward

Android UI will never be completely smooth because of the design constraints I discussed at the beginning:

- UI rendering occurs on the main thread of an app
- UI rendering has normal priority

Even with a Galaxy Nexus, or the quad-core EeePad Transformer Prime, there is no way to guarantee a smooth frame rate if these two design constraints remain true. It’s telling that it takes the power of a Galaxy Nexus to approach the smoothness of a three year old iPhone. So why did the Android team design the rendering framework like this?

Work on Android started before the release of the iPhone, and at the time Android was designed to be a competitor to the Blackberry. The original Android prototype wasn’t a touch screen device. Android’s rendering trade-offs make sense for a keyboard and trackball device. When the iPhone came out, the Android team rushed to release a competitor product, but unfortunately it was too late to rewrite the UI framework.

This is the same reason why Windows Mobile 6.5, Blackberry OS, and Symbian have terrible touch screen performance. Like Android, they were not designed to prioritise UI rendering. Since the iPhone’s release, RIM, Microsoft, and Nokia have abandoned their mobile OS’s and started from scratch. Android is the only mobile OS left that existed pre-iPhone.

So, why doesn’t the Android team rewrite the rendering framework? I’ll let Romain Guy explain:

“...a lot of the work we have to do today is because of certain choices made years ago... ...having the UI thread handle animations is the biggest problem. We are working on other solutions to try to improve this (schedule drawing on vsync instead of block on vsync after drawing, possible use a separate rendering thread, etc.) An easy solution would of course to create a new UI toolkit but there are many downsides to this also.”

Romain doesn’t elaborate on what the downsides are, but it’s not difficult to speculate:

- All Apps would have to be re-written to support the new framework
- Android would need a legacy support mode for old apps
- Work on other Android features would be stalled while the new framework is developed

However, I believe the rewrite must happen, despite the downsides. As an aspiring product manager, I find Android’s lagginess absolutely unacceptable. It should be priority #1 for the Android team.

When the topic of Android comes up with both technical and nontechnical friends, I hear over and over that Android is laggy and slow. The reality is that Android can open apps and render web pages as fast or faster than iOS, but perception is everything. Fixing the UI lag will go a long way to repairing Android’s image.

Beyond the perception issue, lag is a violation of one of Google’s core philosophies. Google believes that things should be fast. That’s a driving philosophy behind Google Search, Gmail, and Chrome. It’s why Google created SPDY to improve on HTTP. It’s why Google builds tools to help websites optimize their site. It’s why Google runs it’s own CDN. It’s why Google Maps is rendered in WebGL. It’s why buffering on Youtube is something most of us remember, but rarely see anymore.

But perhaps the most salient reason why UI lag in Android is unacceptable comes from the field of Human-Computer Interaction (HCI). Modern touch screens imply an affordance language of 1 to 1 mapping between your finger and animations on the screen. This is why the iOS over-scroll (elastic band) effect is so cool, fun, and intuitive. And this is why the touch screens on Virgin America Flights are so frustrating: they are incredibly laggy, unresponsive, and imprecise.

A laggy UI breaks the core affordance language of a touch screen. The device no longer feels natural. It loses the magic. The user is pulled out of their interaction and must implicitly acknowledge they are using an imperfect computer simulation. I often get “lost” in an iPad, but I cringe when a Xoom stutters between home screens. The 200 million users of Android deserve better.

And I know they will have it eventually. The Android team is one of the most dedicated and talented development teams in the world. With stars like +Dianne Hackborn and +Romain Guy around, the Android rendering framework is in good hands.

I hope this post has reduced confusion surrounding Android lag. With some luck, Android 5.0 will bring the buttery-smooth Android we’ve all dreamed about since we first held an HTC G1. In the mean time, I’ll be in Redmond working my butt off trying to get a beautiful and smooth mobile OS some of the recognition it deserves.


Parts of this post was inspired by this reddit comment by ddtro who explained the UI thread and real-time issue:

This explanation of Android versus iOS UI compositing on Hacker News by Corun was illuminating:

Information about Android’s historical roots taken from In the Plex by +Steven Levy and Steve Jobs by Walter Isaacson

Post has shared content
#geeky and #OMG
QUOTE: [Craig S Wright ] says: I was contracted to test the systems on a Boeing 747. They had added a new video system that ran over IP. They segregated this from the control systems using layer 2 - VLANs. We managed to break the VLANs and access other systems and with source routing could access the Engine management systems.

The response, "the engine management system is out of scope."

For those who do not know, 747's are big flying Unix hosts. At the time, the engine management system on this particular airline was Solaris based. The patching was well behind and they used telnet as SSH broke the menus and the budget did not extend to fixing this. The engineers could actually access the engine management system of a 747 in route. If issues are noted, they can re-tune the engine in air.

The issue here is that all that separated the engine control systems and the open network was NAT based filters. There were (and as far as I know this is true today), no extrusion controls. They filter incoming traffic, but all outgoing traffic is allowed. For those who engage in Pen Testing and know what a shoveled shell is... I need not say more.

Post has shared content
I am very, very sad to hear the news about Steve. He was a great man with incredible achievements and amazing brilliance. He always seemed to be able to say in very few words what you actually should have been thinking before you thought it. His focus on the user experience above all else has always been an inspiration to me. He was very kind to reach out to me as I became CEO of Google and spend time offering his advice and knowledge even though he was not at all well. My thoughts and Google's are with his family and the whole Apple family.

Post has shared content
From the earliest days of Google, whenever Larry and I sought inspiration for vision and leadership, we needed to look no farther than Cupertino. Steve, your passion for excellence is felt by anyone who has ever touched an Apple product (including the macbook I am writing this on right now). And I have witnessed it in person the few times we have met.

On behalf of all of us at Google and more broadly in technology, you will be missed very much. My condolences to family, friends, and colleagues at Apple.

Post has attachment
Wait while more posts are being loaded