When the Kindle Fire was being launched, part of the out-of-the-box experience was that a) it already knew what account it was associated with and b) if you weren't already a Prime member, it phoned home and automatically gave you a non-renewing 1-month free "preview" (not a "trial", since those automatically converted into paid memberships) of Prime so you could watch Prime video, use Kindle lending library, etc. on your brand new device. As secret projects go, the Prime team was brought in very late and given a very short integration window (2-ish weeks, maybe) to determine if that feature would make the cut for launch.
Part of the user experience was getting a "personalized" letter delivered through the Kindle delivery mechanism that included the Prime logo and JeffB's signature. This letter was effectively a Mobi ebook dynamically generated before being pushed to the device. This functionality previously existed and was how notes indicating that lent items had expired were generated, however, those were plaintext and used a custom templating system that the Kindle team (justifiably) didn't want to expose to external teams. The Kindle team wanted us to generate a Mobi that they would pass along, which would have required a bunch of new infrastructure and technology we had no experience with. A former teammate who was now in Kindle made the case for us continuing to use the extensive HTML custom messaging infrastructure we had, but the Kindle team's capability limited them to hitting a single endpoint and we didn't have a nice way to bundle all of our resources (images, content, etc.) into a single file (e.g. zip, tarball). On a call one afternoon I suggested adding data URL support so we could continue to leverage our infrastructure, they could continue to leverage their's and only this small tool they shelled out to would need to change.
Of course, the kindlegen team was not involved in the discussion initially, their code did not use the tools the rest of the company used, for whatever reason they were unwilling to accept code contributions, and they wanted several months to implement the feature.
Being young and without kids at the time, I went home, knocked out a wrapper that would convert data URLs to external resources and replace the references, and then call out to kindlegen to generate the mobi, and had a working tool the next morning. The whole thing went (almost¹) flawlessly, allowed Prime to test and debug with the tools they knew, allowed the Kindle distribution team to swap out one piece transparently, and the Fire launched with that implementation in place. And like most stop-gap solutions, it was in place for several years before kindlegen finally supported data URLs natively.
This was all running on Linux hosts, and that was many many years ago now. It's a good reminder that code is like a sandcastle. It will be gone tomorrow, but the tide will continue.
¹ sure, there may have been a small bug or two, but I stabilized a bunch of their tests in the process, so I consider it a win.
When the Kindle Fire was being launched, part of the out-of-the-box experience was that a) it already knew what account it was associated with and b) if you weren't already a Prime member, it phoned home and automatically gave you a non-renewing 1-month free "preview" (not a "trial", since those automatically converted into paid memberships) of Prime so you could watch Prime video, use Kindle lending library, etc. on your brand new device. As secret projects go, the Prime team was brought in very late and given a very short integration window (2-ish weeks, maybe) to determine if that feature would make the cut for launch.
Part of the user experience was getting a "personalized" letter delivered through the Kindle delivery mechanism that included the Prime logo and JeffB's signature. This letter was effectively a Mobi ebook dynamically generated before being pushed to the device. This functionality previously existed and was how notes indicating that lent items had expired were generated, however, those were plaintext and used a custom templating system that the Kindle team (justifiably) didn't want to expose to external teams. The Kindle team wanted us to generate a Mobi that they would pass along, which would have required a bunch of new infrastructure and technology we had no experience with. A former teammate who was now in Kindle made the case for us continuing to use the extensive HTML custom messaging infrastructure we had, but the Kindle team's capability limited them to hitting a single endpoint and we didn't have a nice way to bundle all of our resources (images, content, etc.) into a single file (e.g. zip, tarball). On a call one afternoon I suggested adding data URL support so we could continue to leverage our infrastructure, they could continue to leverage their's and only this small tool they shelled out to would need to change.
Of course, the kindlegen team was not involved in the discussion initially, their code did not use the tools the rest of the company used, for whatever reason they were unwilling to accept code contributions, and they wanted several months to implement the feature.
Being young and without kids at the time, I went home, knocked out a wrapper that would convert data URLs to external resources and replace the references, and then call out to kindlegen to generate the mobi, and had a working tool the next morning. The whole thing went (almost¹) flawlessly, allowed Prime to test and debug with the tools they knew, allowed the Kindle distribution team to swap out one piece transparently, and the Fire launched with that implementation in place. And like most stop-gap solutions, it was in place for several years before kindlegen finally supported data URLs natively.
This was all running on Linux hosts, and that was many many years ago now. It's a good reminder that code is like a sandcastle. It will be gone tomorrow, but the tide will continue.
¹ sure, there may have been a small bug or two, but I stabilized a bunch of their tests in the process, so I consider it a win.