Hacker News new | past | comments | ask | show | jobs | submit login

Every time static generation rears its head, I'm reminded of Yahoo!'s ... unique... take.

Back in 2006 when I worked for Yahoo!, and they had a CMS / template management system called Jake that statically generated templates for the PHP-based frontend servers to evaluate at request time. The idea was that you put as much of your logic as possible into the template generation layer, leaving the request-time logic to handle the stuff that changed request by request.

Now, that all sounds quite reasonable, but the two layers were written in different languages. The pre-template-generation logic was written as inline Perl (plus a little custom syntax, because why not), while the dynamic frontend logic was written in PHP. Perl was frequently used to generate chunks of PHP code to be executed by the frontend servers, and sometimes this PHP code wrote chunks of inline JavaScript. To say that debugging said JS was fun would be an understatement.




Jake was built for news articles and prerendered all pages. News staff was able to quickly localize templates (10+ lanuages, 20+ products). That was 1999 when we didn't use Javascript or CSS, tested pages on Netscape Navigator 2 and WML (for mobile phones) became hot topic. Later Jake was misused for all kinds of other products mainly because of locali[sz]ation, permission management etc. Yeah, debugging was hard. It was the right tool at that point in time to handle high requests-per-second. Yahoo hired Rasmus Lerdorf and switched to PHP starting 2002.


> Yahoo hired Rasmus Lerdorf and switched to PHP starting 2002.

Well, that's a bit of an exaggeration. When I left Yahoo Europe in 2005, there was still Perl all over the place both in Europe and the US at least. I managed the Yahoo Europe billing system, and that was mostly Perl on the backend, for example.

[small world, btw., courtesy of some minor profile-stalking: I interviewed with Ed about a position a few years back; your service looks interesting - I have a client that might be interested]


Yahoo Europe's progress was from Perl generated static html, to Perl generated PHP.

What Rasmus' hire did was push Yahoo to allow server-side scripting languages on the web server. And that's where PHP was the blindingly obvious choice. (though, I would not be surprised if there was a bun-fight with mod_perl...)


In the teams I worked with, there was thankfully no Perl-generated anything (but I know my boss had to deal with that with a couple of the other teams reporting in to him). We had plenty of Perl on the backend, though, and the US billing team constantly breathing down our neck to do their OneRewriteToBindThemAll in PHP (they had been working on that for a while when I joined in 2003, and were still working on it when I left beginning of 2006; it was a laudable goal - there were something like 8 billing systems worldwide at that point - but it took them a lot of time to figure out how to unify all the international requirements).

The funny thing was that on the instances I heard Rasmus talk, he complained we were taking it too far - he wanted simple PHP templates, not the kind of large PHP applications the US billing team and others were doing. He sounded quite exasperated about it last time I was at one of his talks.


Yup, sounds a bit like a project I did a while back - I had a C/C++ bindings generator that took an XML file and generated the C/C++ code to expose a C/C++ class to Javascript. So of course the logical thing for me to do was write the thing in Ruby.

That said, all code-generation tools - straight up generators, compilers, whatever - are a mindbending experience. Keeping track of whether a variable is available at generation time or runtime is trickier than I initially expected.


My version of that was parsing generated C++ code headers through Doxygen (XML format) and then writing up a Ruby script that would spit out generated C++, C#, and Java to expose the SOAP APIs we needed to do. It was fun, and I think the company is still using it, four years after I left.


FWIW, towards the tail-end of my time at Yahoo! I played a bit part in a team working on a more modern open source PHP-based version of the template localisation system that was at the heart of Jake. Remarkably this still exist on the Internet, though they haven't been touched since 2009 when most of us left.

http://sourceforge.net/projects/rthree/

Looking at the source now, I think we might have been trying to use every pattern in the GoF book in one project.


this is the first story I've heard that explains why Yahoo's navigation is so horrible and why your logged in state on your yahoo account doesn't follow you to different yahoo sites (business, mail, etc.)


That doesn't really explain it. Stuff that really needed to be dynamic would be. But we (I was at Yahoo 2003-2005) took privacy seriously and a lot of seeming quirks of login state etc. were well thought through and had good reasons. E.g. we were regularly reminded not to mingle data that identified browsers (that could "follow" an unlogged in user across sites) with data that identified users (as that would let us tie a userid to data the user explicitly had not knowingly shared with us).

And many particularly personal properties such as mail, or the billing system (my area), would take extra precautions about what information could be made available on other properties (e.g. what info from mail could be shown on the homepage) even if the user was logged in, to prevent leaking information that shouldn't leak. This would lead to extra logins that I'm sure seemed unnecessary, and logins where the user probably thought they were already logged in, but where non-personal information was keyed to the browser rather than their user id.

I'm sure there are bugs and unintentional quirks too - the system was crazy complex already in 2005, but I really hope they've stuck to their guns when it comes to how carefully they treated personal data back then.


Well, stuff like putting the "logged in yahoo account" indicator in the same place on each page, and indicating whether asking for a password was as a secondary verification (since already logged in) or if it was perhaps a different password.

Yes there were such horrible, glaring usability bugs it's quite amazing anyone had the patience to deal with it. I still cringe when I have to navigate anywhere on Yahoo at all, and actively avoid using anything associated with it.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: