2008年10月27日月曜日

Python 3.0 Interview

Python 3.0 Interview

I was interviewed for the following article on Python 3.0:
http://www.linux.com/feature/150399

While I have no complaints about the way I was quoted, I would have preferred more of the interview to be included, so I'm posting the interview here:

On Sat, Oct 04, 2008, joabjack@comcast.net wrote:
>
> Terrific! Thanks for participating. I'll be sure to put a link in the
> story to your book.

That would be great! Please use http://www.pythonfood.com/

> Could you say approximately how much Python 2.3 or 2.4 code you have
> in your current job? What is this code used for, broadly speaking?

The company I work for is http://www.pagedna.com/ -- it has been in
business for more than ten years and was started with Python 1.4. I've
been working there for more than four years. Our software is a web
application for taking orders and sending EPS/PDF files to printing
plants.

There's more than 200K lines of code, most of it Python. A lot of the
code resides in template files for generating web pages. (There's a
significant amount of JavaScript, much of which is generated by Python
code.) Although EPS/PDF generation is the heart of our application,
there are many ancillary features to meet our customer needs (such as
approval workflow, inventory management, and reporting).

> What are your thoughts about eventually moving that code to 3.0? Would
> this be a big job? At what point, if ever, would it be necessary?

It would be a huge job, made more difficult because many of our bits of
Python code reside in web templates. However, by the time we do the
conversion the tools for automatic conversion should be much improved.
Although both my boss (Tony Lownds) and I are active in the Python
community, we haven't even talked about 3.0 -- it's at least two or
three years away.

> In your opinion, do you think it's a wise move to forgo backward
> compatibility in Python 3.0, given both the user base and current
> limitations of the language?

First of all, I think it overstates the case to talk about "forgoing
compatibility". The base Python language is still the same; the only
difference immediately apparent at the simple scripting level is that the
print command has changed to a function. Python 3.0 is more about
removing mistakes and warts, many of which people have been encouraged to
avoid for years.

In addition, it is the intention to gradually merge the 2.x and 3.x
series; Python 2.6 is already a major step in that direction.

All in all, I think Python 3.0 is the kind of necessary evolution that
software needs. It certainly isn't as big a change as going from DOS to
Windows or from Mac OS 9 to OS X.

> What qualities about Python first attracted you to the language?

Actually, I was forced to learn Python. I was a Perl expert at the time,
and I saw no reason to learn yet another scripting language. Since then,
I have become enamored of Python's readability and how a typical
programmer's pseudocode is trivially translated into running Python.

> Of what you read about Python 3.0, what features do you find most
> intriguing?

The fact that it's getting done at all! For years, Python 3.0 was
referred to as Python 3000 -- the joke being that it would happen in the
year 3000 (meaning, never). Work only started seriously three years ago,
and I think that Python 3.0 has done an excellent job of balancing the
past and the future.

> That's about it, though if you have any other thoughts about Python
> 3.0, I'd love to hear them as well.

That pretty much covers it, I think.



 


Linux.com :: Python 3.0 makes a big break


Typically, each new version of the Python programming language has been gentle on users, more or less maintaining backward compatibility with previous versions. But in 2000, when Python creator Guido van Rossum announced that he was embarking on a new version of Python, he did not sugar coat his plan: Version 3.0 would not be backward-compatible. Now that the first release candidate of Python 3.0 is out, with final release planned for later this month, developers must grapple with the issue of whether to maintain older code or modify it to use the new interpreter.



Developers hate it when a new version of a language doesn't work with the code written for older versions of that language, but for van Rossum, the radical upgrade was necessary. The language was becoming ever more weighed down by multiple ways of doing the same task, and ways of doing tasks no one ever actually did.



"The motivation for 3.0 was to have one specific event where we did as much of the backward incompatibility all at once," van Rossum says. The idea is to "give the language a better foundation for going forward."



Naturally, some stirrings of discontent can be felt across the Python community.



"Python is pretty much determined to remove itself from consideration from various kinds of international projects like the one I work on. We're already catching flak from people due to a few things that were valid in 2.2 that are not valid in 2.3," bemoaned one developer in the comp.lang.python newsgroup.



"For an operating system distributor, Python 3.0 represents a large potential change in their repository of packages for relatively little benefit in terms of resulting functionality," says UK Python developer Paul Boddie.



What changes?


In a way, Python has been a victim of its own success. "The original idea for the language had a much smaller scope. I really hadn't expected it to be so successful and being used in a wide variety of applications, from Web applications to scientific calculations, and everything in between," van Rossum says.



Van Rossum first created Python in 1990, as an open source, extensible, high-level language that he needed to handle some system administration duties. Today, Python is one of the most popular languages used world-wide. In March 2008, Austrian researcher Anton Ertl ranked programming languages in terms of their popularity as gauged by the number of postings in Usenet newsgroups. Python proved to be the third most-discussed language on Usenet, right after C and Java, ahead of such stalwarts as C++ and Perl.



When it comes time to teach someone how to program, often the easiest programming language to use is Python. It is the Basic of today, though more elegant to work with than Basic ever was.



Yet Python's simplicity was being threatened by the unchecked growth of the language, van Rossum says. Throughout the '90s, new functions and features were bolted onto the language, and inconsistencies started popping up across the platform. "We were slowly losing the advantage" of simplicity. "We had to break backward compatibility. The alternative was unchecked bloat of the language definition, which happens very slowly and almost unnoticeable."



Python.org has a list of changes to the language. Some are small, and will go unnoticed by most programmers. Others can be relearned quickly.



"Most of the differences are in the details; the general gist of the language, how people think about the language and the capabilities are pretty much unchanged," van Rossum says.



For instance, the print statement got turned into a print function; you must now put parentheses around what you want to print to the screen. The change allows developers to work with print in a more flexible and uniform way. If someone needs to replace the print function with some other action, it can be done with a universal search and replace, rather than rewriting each print statement by hand.



Another change: The language only has one integer type, instead of the former distinction between long and short integers, which van Rossum characterizes as worthless.



Another tangle of cruft that has been pruned back is something called "classic classes." Python version 2 has two sets of classes, each with its own format. "There was a lot of machinery in the Python virtual machine that was either special-casing classic classes or double implementations with version for classic classes and another version for new-style classes. This was implementation bloat," van Rossum says. So, after six years of campaigning to get people to move to the new classes, the developers of Python 3 have put their collective foot down and are doing away with the classic classes.



Perhaps the biggest change that takes place with Python -- and the one that will require the most rewriting of existing code -- is the new way Python deals with bytes and strings. Originally, Python represented all input and output as strings. When Python was used more in casual settings, most strings that went through the interpreter could easily be represented by the standard ASCII character set. But as the language's use grew to global proportions, more and more users started using Unicode to support a wider array of language characters. To Python, Unicode looked a lot like 8-bit binary byte strings, which could be passed along to the interpreter as part of the output from another program. In some cases, the interpreter would confuse binary data with Unicode-encoded strings, and it would choke, big-time.



The answer? Define a new object class for handling bytes -- a first for Python. Also, redefine strings as Unicode. And then keep the two clear of one another. In other words, the byte type and string type are not compatible in Python 3.0.



"If you ever make the mistake of passing bytes around where you think they are text, your code will raise an exception almost immediately," van Rossum said.



Conversion and converts


van Rossum admits now that he didn't think much of the transition difficulties when he first started thinking about Python 3.0. "In 2000, the community was small enough that I thought that I would just release a new version and people would fix their code and that is that."



In the feedback process with the user community though, the core developers started hearing more clamor for a smooth transition process. They needed tools.



This is the role of the recently released version 2.6 of Python, which will serve as a transition version of the language. Users can easily upgrade their code from earlier versions of Python to version 2.6. The 2.6 interpreter will offer warning messages about aspects of the program that will no longer fly with version 3.0.



"We're encouraging people to upgrade to Python 2.6," van Rossum says. "2.6 can help you find the anachronisms in your code that you will need to change to be prepared for 3.0."



The development team also created a transition tool called 2to3 that converts Python 2.6 code into Python 3.0 code. You can then run your older code in 2.6, rewriting it until all the warning messages have been eliminated, then use 2to3 to convert the code into Python 3.0 specs.



Of course, since Python is a dynamic language, where types are not explicitly declared, there are a lot of cases where a translation tool will not help much, but it should help with the mundane tasks, such as changing print statements into print functions.



Even with this tools in place, van Rossum admits that the migration of the user community will be a slow haul, and not all Python shops will make the transition.



For instance, the printing preparation company Aahz Maruch works for, Page DNA, relies on 200,000 lines of Python code in its core revenue-generating operations. "It would be a huge job" to translate this code into Python 3.0, Maruch says. He says the company will wait for a few years for the automatic translation tools to improve. "We haven't even talked about 3.0 -- it's at least two or three years away."



Others are more skeptical about the necessity of the upgrade.



The "implementation of Python 3.0 gives relatively little attention to [current] issues [modern programming languages face], such as performance, pervasive concurrency, or the provision of a renewed, coherent bundled library," Boddie says.



He says there is a danger that Python 3.0 may not be seen as a necessary upgrade for most developers and, as a result, it could lose its status as the de facto Python in much the same way Windows Vista hasn't become the de facto Windows over its predecessor Windows XP.



Today, the chief implementation of Python is CPython, which is a Python interpreter written in C. However, Boddie notes that other implementations exist, such as JPython (Python in Java), IronPython (Python written in Microsoft .Net's Common Runtime Language), and PyPy (a Python interpreter written in Python).



"I think that Python 3.0 may actually focus attention on other Python implementations, particularly if these do not pursue Python 3.0 compatibility as a priority," Boddie suggests.



Nonetheless, the core development team is confident the tide will turn their way, eventually. "I expect that most people will be using 2.6 a year from now. Only bleeding edge people will be using 3.0," van Rossum says. However, "if you're starting a brand new thing, you should use 3.0."

2008年10月24日金曜日

Brian "Krow" Aker's Idle Thoughts - Assumptions, Drizzle

Brian "Krow" Aker's Idle Thoughts - Assumptions, Drizzle

What is the future of Drizzle? What sort of assumptions are you making?

  • Hardware
    On the hardware front I get a lot of distance saying "the future is 64bit, multi-core, and runs on SSD". This is a pretty shallow answer, and is pretty obvious to most everyone. It suits a sound bite but it is not really that revolutionary of a thought. To me the real question is "how do we use them".
    64bit means you have to change the way you code. Memory is now flat for the foreseeable future. Never focus on how to map around 32bit issues and always assume you have a large, flat, memory space available. Spend zero time thinking about 32bit.
    If you are thinking "multi-core" then think about it massively. Right now adoption is at the 16 core point, which means that if you are developing software today, you need to be thinking about multiples of 16. I keep asking myself "how will this work with 256 cores". Yesterday someone came to me with a solution to a feature we have removed in drizzle. "Look we removed all the locks!". Problem was? The developer had used a compare and swap, CAS, operation to solve the problem. Here is the thing, CAS does not scale with this number of cores/chips that will be in machines. The good thing is the engineer got this, and has a new design :) We won't adopt short term solutions that just kneecap us in the near future.
    SSD is here, but it is not here in the sizes needed. What I expect us to do is make use of SSD as a secondary cache, and not look at it as the primary at rest storage. I see a lot of databases sitting in the 20gig to 100gig range. The Library of Congress is 26 terabytes. I expect more scale up so systems will be growing faster in size. SSD is the new hard drive, and fixed disks are tape.
    The piece that I have commented least on is the nature of our micro-kernel. We can push pieces of our design out to other nodes. I do not assume Drizzle will live on a single machine. Network speed keeps going up, and we need to be able to tier the database out across multiple computers.
    One final thought about Hardware, we need 128bit ints. IPV6, UUID, etc, all of these types mean that we need single instruction operator for 16byte types.
  • Community Development
    Today 2/3 of our development comes from outside of the developers Sun pays to work on Drizzle. Even if we add more developers, I expect our total percentage to decrease and not increase. I believe we will see forks and that we have to find ways to help people maintain their forks. One very central piece of what we have to do is move code to the Edge, aka plugins. Thinking about the Edge, has to be a share value.
    I see forks as a positive development, they show potential ways we can evolve. Not all evolutionary paths are successful, but it makes us stronger to see where they go. I expect long term for groups to make distributions around Drizzle, I don't know that we will ever do that.
    Code drives decisions, and those who provide developers drive those decisions.
    While I started out focusing Drizzle on web technologies, we are seeing groups showing up to reuse our kernel in data warehousing and handsets (which is something I never predicted). By keeping the core small we invite groups to use us as a piece to build around.
    Drizzle is not all about my vision, it is about where the collective vision takes us.
  • Directions in Database Technology
    Map/Reduce will kill every traditional data warehousing vendor in the market. Those who adapt to it as a design/deployment pattern will survive, the rest won't. Database systems that have no concept of being multiple node are pretty much dead. If there is no scale out story, then there is not future going forward.
    The way we store data will continue to evolve and diversify. Compression has gotten cheap and processor time has become massive. Column stores will continue to evolve, but they are not a "solves everything" sort of solution. One of the gambles we continue to make is to allow for storage via multiple methods (we refer to this as engines). We will be adding a column store in the near the future, it is an import piece for us to have. Multiple engines cost us in code complexity, but we continue to see value in it. We though will raise the bar on engine design in order to force the complexity of this down to the engine (which will give us online capabilities).
    Stored procedures are the dodos for database technology. The languages vendors have designed are limited. On the same token though, putting processing near the data is key to performance for many applications. We need a new model badly, and this model will be a pushdown from two different directions. One direction is obvious, map/reduce, the other direction is the asynchronous queues we see in most web shops. There is little talk about this right now in the blogosphere, but there is a movement toward queueing systems. Queueing systems are a very popular topic in the hallway tracks of conferences.
    Databases need to learn how to live in the cloud. We cannot have databases be silos of authentication, processing, and expect only to provide data. We must make our data dictionaries available in the cloud, we need to take our authentication from the cloud, etc...
    We need to live in the cloud.

    Tags: database, drizzle, mysql

  • Link | Leave a comment

    | Add to Memories | Tell a Friend

    Comments {8}

    awfief

    (no subject)

    from: [info]awfief
    date: Oct. 22nd, 2008 06:08 pm (UTC)
    Link

    the good thing about things like planning for multiple cores, lots of memory, and many different physical machines...
    is that it will all work on one behemoth machine if you want it to. Not planning this way right now makes no sense -- obviously we can't predict the future. The most difficult area will likely be disk, since historically that's what's actually changed. RAM hasn't changed (AFAIK), though amounts and speeds have. Disk has changed -- different OS's use different filesystem types, which is essentially different disks, due to usage (and is relevant for issues like fsync). SSD's are one way disks may or may not change in the future....but in the time of records, who envisioned tapes or CD's or mp3 files?
    We can try to figure that stuff out....but historically, RAM really hasn't changed, CPU's have changed a bit (layout wise w/multiple cores), and disks have changed the most. This boils down to "make use of everything we know about today, and give the most flexibility to the disk stuff".
    perhaps via drizzle plugins? *shrug*

    Reply | Thread

    Tanjent

    (no subject)

    from: [info]tanjent
    date: Oct. 22nd, 2008 06:12 pm (UTC)
    Link

    Don't know about Sun's chips, but all modern intel/amd/ppc chips have 128-bit vector registers and a good complement of integer ops (though I don't think any can treat the entire register as one enormous 128-bit int). Windows under x64 actually bypasses the old x87 FPU entirely and does all float math using vector registers - it lets the compiler extract a nice bit of extra parallelism in certain cases.

    Reply | Thread

    Brian

    (no subject)

    from: [info]krow
    date: Oct. 22nd, 2008 06:18 pm (UTC)
    Link

    I want a single instruction comparison for 128bit ints :)
    (Really... a 16byte comparison operation).
    I'm not trusting compilers to really optimize for me around this just yet.

    Reply | Parent | Thread

    Tanjent

    (no subject)

    from: [info]tanjent
    date: Oct. 22nd, 2008 06:32 pm (UTC)
    Link

    Altivec has vcmp(eq/gt)(s/u)(b/h/w) - vector compare equal/greater signed/unsigned byte/half/word, and docs say it sets the comparison flags appropriately. Don't remember SSE's off the top of my head but they have an equivalent.

    Reply | Parent | Thread

    axehind

    (no subject)

    from: [info]axehind
    date: Oct. 22nd, 2008 06:25 pm (UTC)
    Link

    Totally agree about moving code to the edge. plugins/modules are the way to go if the interface is easy enough to use. This will spawn lots of sub projects which is a good thing I think!
    Not sure I agree with you in regards to SSD. I think using it as a secondary cache could be beneficial right now but I dont see that phase lasting long. I think the jump to all SSD will happen pretty fast.

    Reply | Thread

    mutantgarage

    (no subject)

    from: [info]mutantgarage
    date: Oct. 25th, 2008 04:55 pm (UTC)
    Link

    NAND Flash SSDs are good for reads, but write performance sucks. They also wear out with a lot of writes, stick a big RAM writeback cache in front of the SSD. This can be hardware or implemented in your application.

    Reply | Parent | Thread

    Eric

    Cloud Application Framework

    from: [info]oddity80
    date: Oct. 22nd, 2008 06:37 pm (UTC)
    Link

    Very well put (on all topics). In terms or pushing application logic out to where the data lives, we need a dynamic application framework that integrates well into existing web shops while leveraging the power of the cloud. Google and Amazon had the right idea, but they've missed the mark (keep it open, people want more control). There are some solutions that work well for specific purposes (Hadoop), but we still need something more general-purpose. I have a feeling a flexible, open source, language-independent, application framework is right around the corner... or is it already here but just not well known? ;)

    Reply | Thread

    Kevin Allen Burton

    Agreed on 128 bits.

    from: [info]burtonator
    date: Oct. 22nd, 2008 07:03 pm (UTC)
    Link

    I agree on having 128 bits.... I've needed them before.......
    Kevin

    Reply | Thread

    2008年10月22日水曜日

    いま開いているページを簡単に携帯で読むためのブックマークレット(はてなMobileGateway+ポップアップウィンドウバージョン)

    以下のエントリに乗っからせていただきます。 違いは以下の2点です。
    • はてなMobileGatewayを使用
    • ポップアップにてgmail送信ウィンドウが開く
    いま開いているページを簡単に携帯で読むためのブックマークレット - 頭ん中

    ブックマークレットの作り方

    1. ↓ここに自分の携帯メールアドレスを入れて


      (ブラウザ上で処理されるため、入力内容は当サービスに送信されません。)

    2. と、↓ここに [携帯で読む] というリンクが表示されるので

       

    3. できたリンクを右クリックして
      ブックマークなりお気に入りなりに追加する。
      (「このリンクは安全でない可能性が」などと出ても気にしない。) なお、動作確認FireFox3でのみ行っています。

      Technorati タグ: ,,

    Opera 9.6 Launches, Now Includes Magazine-Style RSS...Sort Of - ReadWriteWeb

    Opera 9.6 Launches, Now Includes Magazine-Style RSS...Sort Of - ReadWriteWeb

    Today, Opera revealed the newest version of their web browser, Opera 9.6. As always, the latest update includes speed and performance increases, but the update delivers several new features, too. The one new feature that we were really excited to try out is how Opera 9.6 deals with RSS feeds. In this latest version of the browser, you can preview your feeds in an attractive magazine-style layout. But what we really wanted to know is could read your feeds like this once subscribed?

    Magazine-Style Feeds

    In Opera 9.6, a new feed preview feature has been introduced that turns any RSS feed into a magazine-style page where the articles in an feed appear as columns. (See image below). With the feeds laid out in this manner, suddenly RSS reading becomes accessible, understandable, and far less geeky than its acronym implies. Although heavy RSS users and techie folks will probably continue to use an RSS reader like Google Reader, a magazine-style layout is a great option for a light reader or someone new to RSS.

    Previewing RWW's Feed

    In a way, Opera's new magazine-style feature reminds us very much of how the Firefox extension, Feedly, operates. With Feedly installed, you can view your Google Reader feeds in an easy-to-read format while still being able to hop into your different folders. Of course, Feedly does so much more than just change the layout of Google Reader, but that's a whole other topic.

    The difference between Feedly's magazine interface and what Opera does is that Opera only displays feeds in this manner when you preview them while deciding whether or not to subscribe. That's disappointing. We were hoping that Opera would include this as a new option under the "Display -> View" settings in Opera's built-in RSS reader, too. Unfortunately, those view settings have remained the same. Feed reading there is still an inbox-like experience, with feeds titles in one window and the articles in a second window. This familiar Outlook format works for some people, we're sure, but to have the magazine-style option here as well would have been a nice treat.

    Other New Features

    In addition to the preview feeds feature, Opera 9.6 also adds other updates, including the following:

    • Expanded Opera Link: Opera Link is one of the browser's best features. With it, you have access to your data from any computer or mobile device. It synchronizes your bookmarks, Speed Dial, notes taken in your Opera browser, and personal bar. With the update to Opera 9.6, Opera Link now lets you take your favorite search engines and browser history with you, too.
    • Optimized Opera Mail: Opera's built-in e-mail client, Opera Mail, now includes "low-bandwidth mode" to retrieve mails even faster when bandwidth is limited. This is great for when you're on the road and trying to use your air card in a bad spot where the signal isn't very strong.
    • Prioritized e-mail: Opera Mail has two new ways to manage e-mail conversations. Keep an eye on important threads and contacts by following them, or ignore less important threads and contacts with a single click. Looks like you can start to manage your information overload with this.
    • Increased speed: Opera 9.6 improves the quick responsiveness and page loading of Opera 9.5.
    • Improved fluency: Opera added support for Indonesian, Ukrainian, Estonian, Hindi, Telugu, and Tamil languages.

    Wall Street Staggers

    Wall Street Staggers

    In times of high stress, many in the financial world seek solace in watery metaphors. We hear of vast irresistible forces converging in "perfect storms" and unforeseeable events contributing to "100-year floods."

    How could we have expected, let alone prevented, this?

    Count on Warren E. Buffett to cut to the truth. Years ago, referring to reckless corporate debt, Buffett noted (or so the story goes): "You never know who is swimming naked until the tide goes out."

    The tide's moving, and we're starting to get the full, not-so-pretty view. Along with the bare swimmers emerging from the soggy murk, we're being reminded of some of the dumb ideas and reckless choices that helped deliver us to our current debacle. As stunning as the scene seems, we've actually had plenty of experience with this sort of thing. But like some stubborn residents of hurricane zones, we swiftly choose to forget the last tempest and reassure ourselves that things will be different from now on. Why don't we learn the obvious lesson to the contrary? Answers: the timeless power of hubris during periods when profits seem easy, and a set of foolish financial notions that have become prevalent over the past three decades.

    One of those beliefs is the indiscriminate antiregulatory ideology one hears preached on Wall Street with tent-revival fervor. What makes this thinking so perplexing is that many of the free-market true believers also assume the federal government will save them if they flop. Consider the extraordinary taxpayer-backed rescues of insurance titan American International Group (AIG), housing financiers Fannie Mae (FNM) and Freddie Mac (FRE), and, before those, the Treasury-guided merger of Bear Stearns into JPMorgan Chase (JPM). It brings to mind the homeowner who rants about getting Washington off his back but wants federally guaranteed flood insurance no matter how close to the Gulf Coast he builds his house.

    Other by-now-familiar attitudes have helped put us in the drink: In good times, there's no such thing as too much leverage. (Remember Michael Milken?) Derivatives don't require oversight, even though almost no one understands them. (How now, Long-Term Capital Management?) And, don't worry, the quantitative geniuses have devised models to eliminate extreme risk. (Enron, anyone?)

    "Now, again, the banks and the Bush Administration and [Treasury Secretary Henry] Paulson and [Federal Reserve Chairman Ben] Bernanke would like you to think these crises are like floods or hurricanes," says Michael Greenberger, a senior official at the Commodity Futures Trading Commission (CFTC) during the Clinton Administration. An advocate of more aggressive regulation of investment banks, he was shot down in the late 1990s by Democratic colleagues, not just GOP foes. Most financial calamities aren't like natural forces beyond control, Greenberger says. "These are predictable events." Predictable events, of course, are more likely to be prevented with sound rules and stiff enforcement.

    Different Animals

    Alfred E. Kahn offers the long view—a very long view. As the Carter Administration's aviation czar, he unshackled airline routes and fares in the late 1970s, reshaping that industry (for better and worse) and helping spur a lengthy era of economic deregulation. Still sharp at 91, the retired Cornell University economist and part-time consultant recalls that almost as soon as the free-market spirits were set loose, a furious stampede ensued. Lenders, for one, demanded lots more freedom. But they "were a different kind of animal" from airlines and trucking firms, which the Carterites also deregulated, Kahn says. "They were animals that had a direct effect on the macroeconomy. That is very different from the regulation of industries that provided goods and services.…I never supported any type of deregulation of banking."

    During the Reagan years, Kahn's cautious industry-by-industry analysis was replaced by the all-encompassing antiregulatory ideology of the University of Chicago. One result: the liberation of an armada of savings and loan pirates, abetted by congressional Democrats as well as Republicans, many of them drunk on S&L campaign largesse. (Wall Street lobbyists with open wallets have since perfected the practice of neutralizing Congress on a bipartisan basis.) Hundreds of thrifts ultimately collapsed in the late 1980s and 1990s amid greedy and, in some cases, fraudulent real estate deals.

    As early as 2000, William J. Brennan, a prominent consumer attorney who has represented mortgage borrowers since the S&L catastrophe, warned in testimony before the House Financial Services Committee that real estate finance would return in new guises to haunt us. Few listened. Behind every burst of ill-advised lending lurk financial innovators creating new mechanisms to entice ever-more-sketchy borrowers, says Brennan, the director of Atlanta Legal Aid Society's Home Defense Program. In the 1980s, Michael Milken and his comrades at the now-defunct Drexel Burnham Lambert investment bank exacerbated the S&L fiasco by hawking their thrift clients' high-risk junk bonds. More recently the likes of soon-to-be-defunct Lehman Brothers and Bear Stearns engineered the securitization of mortgages, encouraging home lenders to spew wildly unwise loans. "Lending without regard [for] the ability to pay back started with the S&L scandal," says Brennan. In the 1980s the borrowers were reckless shopping-mall developers; in the recent boom, unsophisticated and sometimes cavalier homeowners.

    Wall Street transformed dicey subprime mortgages into the toxic securities that have required hundreds of billions in writedowns and that drove once-mighty Merrill Lynch (MER) to sell itself to Bank of America (BAC). One of the most striking aspects of the current turbulence is the degree to which banks invested in the noxious fare themselves, notes Emanuel Derman, who heads risk management at Prisma Capital Partners, a hedge fund in Jersey City, N.J. "These guys ate their own cooking; they didn't just pass it on to clients."

    The outsize appetite on Wall Street for hazardous mortgage-backed securities and even more obscure derivatives has had a lot to do with the people in the kitchen failing to understand fully what was in their recipes. All of this is painfully familiar to anyone who paid attention to past adventures with wizards who claimed their esoteric models had magically eliminated risk and uncertainty. Hedge fund Long-Term Capital Management (LTCM) couldn't imagine Russia defaulting on its debt, much as Lehman apparently couldn't conceive of housing prices across the country deteriorating simultaneously, followed by a paralyzing credit crunch.

    For four years in the mid-1990s, LTCM boasted extraordinary profits based on supposedly flawless computer formulas devised by a team that included two Nobel laureates. But in the summer of 1998, Russian credit disintegrated, one of several concurrent global shocks that the LTCM crew had failed to factor into their algorithms. After losing more than $4 billion in a few months—in retrospect, the amount seems almost quaint—the hedge fund received a federally organized rescue, although it later shut down altogether.

    Financial "rocket scientists," says Henry T. Hu, a corporate law professor at the University of Texas in Austin, have a knack for neglecting low-probability, catastrophic events. The smartest guys in the room at Enron similarly assumed away risks they didn't want to confront. "These models…work in normal circumstances but not during times of market stress, when it really matters," Hu says. "It is almost like a safety belt that only fails in a serious car crash."

    One of the things that dismayed outsiders about LTCM after it came apart was the size and complexity of its derivatives portfolio. Some in the Clinton Administration pushed for more oversight of the unregulated, privately traded instruments whose value derives from price shifts in currencies, securities, or other assets. Then-Fed Chairman Alan Greenspan, allied with Robert E. Rubin, Clinton's Treasury Secretary (and now a director and senior counselor at Citigroup (C), opposed tougher policing of derivatives. Banks could watch over each other more effectively than regulators could, Greenspan argued. This turned out to be shortsighted.

    In an interview, Greenspan doesn't back down, even after all we've seen lately. "The majority of lawyers, in my experience, seek to regulate—that is, to contain certain activities with little weight given to the lost benefits of such activities," he says. "The question is: What do you lose? In this case, a very valuable instrument [credit default swaps, the derivatives at the core of the current mess] for the diminution of systemic risk. You can stop the system dead and eliminate speculative losses. But you will also get significantly reduced economic activity and ultimately lower standards of living."

    Greenspan adds: "I've been extraordinarily distressed by how badly the most sophisticated people in the business handled risk management. But the question is: If, protecting their own resources, they can't do it, who's going to do it better?" (Well, maybe regulators who don't have big bonuses at stake would be less likely to get carried away by the euphoria.)

    Rubin says separately that he didn't oppose the general idea of scrutinizing derivatives, but instead argued against particular proposals in the late '90s to expand CFTC authority. "I have always been concerned about derivatives," he says.

    Michael Greenberger served as the CFTC's director of trading and markets at the time. A proponent of tougher oversight, he recalls the Greenspan-Rubin resistance as being fierce and across-the-board. "If we had prevailed, the [subprime-securitization] party would never have gotten started; the wildness wouldn't have happened," he says. "There would have been auditing requirements, capital requirements, transparency. No more operating in the shadows. Bear Stearns, Lehman, Enron, and AIG would be thriving, and spending every waking hour complaining about regulatory restraints imposed upon them." Now a law professor at the University of Maryland, Greenberger adds: "In a booming economy, people couldn't be convinced that without corrections, LTCM would happen again—bigger and with more ramifications." Today, Bear, Lehman, and AIG have untold amounts of outlandish derivatives on their books. It could be years before anyone untangles what they're worth.

    One other legacy of LTCM is "moral hazard": the prospect that other financial actors would take greater risks because at some level they'd assume that they, too, would be considered "too big to fail." Surely one can surmise that Fannie Mae and Freddie Mac overstepped in part because of an implied federal safety net that turned out to be a very real one.

    Edward S. Lampert, the hedge fund tycoon who controls Sears Holdings (SHLD), worries about yet another twist. He says the current wave of federal intervention sends the opposite signal from what's intended: that officials are panicking because of broader instability. "As an investor, that was my immediate reaction" to the Fannie and Freddie moves, he says. "They completely destroyed confidence in any financial institution."

    Lampert frets that with investment banks failing and merging, the resulting consolidation will concentrate risk and invite more rescues. "You are going to have Citi, JPMorgan, and Bank of America with $2 trillion-plus in assets each," he notes. "That's three times the size of Fannie and Freddie. Now if they end up with problems, what do you think is going to happen? They are too big to fail."

    2008年10月21日火曜日

    BSDCan 2008: ZFS Internals | KernelTrap

    BSDCan 2008: ZFS Internals | KernelTrap

    Pawel Dawidek first ported ZFS to FreeBSD from OpenSolaris in April of 2007. He continues to actively port new ZFS features from OpenSolaris, and focuses on improving overall ZFS stability. During the introduction to his talk at BSDCan, he explained that his goal was to offer an accessible view of ZFS internals. His discussion was broken into three sections, a review of the layers ZFS is built from and how they work together, a look at unique features found in ZFS and how they work internally, and a report on the current status of ZFS in FreeBSD.

    The BSDCan website notes that Pawel is a FreeBSD committer, adding:

    "In the FreeBSD project, he works mostly in the storage subsystems area (GEOM, file systems), security (disk encryption, opencrypto framework, IPsec, jails), but his code is also in many other parts of the system. Pawel currently lives in Warsaw, Poland, running his small company."


    Derived from notes taken at a one-hour BSDCan talk by Pawel Dawidek, titled, A closer look at the ZFS file system. Simple administration, transactional semantics, end-to-end data integrity.

    ZFS Layers

    In a series of slides titled "ZFS, the internals", Pawel started with a diagram illustrating the many layers of ZFS, offering a quick overview of how it all fits together, and how it fits into FreeBSD. He then quickly moved from layer to layer.

    • SPA: Storage Pool Allocator
      Pawel explained that The Storage Pool Allocator is responsible for managing all pools, creating pools, attaching disks, replacing disks, and related tasks. The 'zpool' command communicates directly with this layer, and maintains an environment history allowing you to review what's happened with these pools. SPA is also responsible for logging persistent data errors, accessible with the command zpool status -v which shows all errors as well and lists all files affected by these errors. An example use of this Pawel pointed out was that's it's easy to quickly determine exactly which files need to be restored from a backup.
    • VDEV: Virtual Devices
      This layer provides a unified method of arranging and accessing devices. Pawel suggested that it looks like a mini, less flexible GEOM built inside of ZFS. It creates mirrors, RAID-Z volumes, additional caching devices, and real vdevs (disks and files). It is also responsible for handling I/O requests and laying out the blocks. Pawel's slides included a diagram showing the vdev tree.
    • ZIO: ZFS I/O Pipeline
      This layer is responsible for compression, checksum verification, encryption, and decryption. It is also responsible for managing I/O request priority. Pawel went on to explain that regular I/O requests are considered more important than those used to sync both halves of a mirror, so the act of synchronizing doesn't saturate I/O bandwidth and significantly slow down regular activities.
    • ARC: Adjustable Replacement Cache
      ZFS follows a copy on write model which is very fast for writing data, but is not necessarily fast for reading data as it may be scattered all around the disk as data is modified over time. The ARC layer tries to cache as much as possible to make reads fast.

      A feature found in the latest ZFS release, which Pawel is actively porting to FreeBSD, is the ability to use an entire device for caching, which he noted was similar to an L2 cache.

    • DMU: Data Management Unit
      Pawel described this as the heart of ZFS, explaining that all operations are transactional. Any change to the filesystem is done as a transaction, and all transactions are handled by the DMU. Every 5 seconds ZFS syncs the transaction log to the disk, assuring atomicity and removing the needs for utilities like fsck. When data is modified, the change version is written to a new place on the disk rather than overwriting the old copy of the data. Once written, the pointers are updated to point to the new data. If there's a crash in the middle of an operation, the old pointers will still lead to the old data which will remain consistent and unmodified.
    • DSL: Dataset and Snapshot Layer
      This layer is responsible for snapshots and datasets, and can inherent various properties for parent filesystems. It also is where quota reservations are enforced.
    • ZIL: ZFS Intent Log
      ZFS provides consistency on disk through transactions, rather than through a journal. It does provide an internal journaling layer called ZIL which is used so that applications using fsync() and O_FSYNC (such as databases like MySQL and PostgreSQL) behave as expected. Writes go into the ZIL for the 5 seconds between transaction writes, but the log is never used except in the event of a crash, in which case the log will be replayed.
    • ZAP: ZFS Attribute Processor
      File and directory names are stored using ZAP layer functionality. There are two types of ZAP, micro ZAP for small entries, and fat ZAP for large directories and files with long names. The layer utilizes scalable hash algorithms to create arbitrary associations within an object set.

      Traversing the live filesystem is not easy when you have multiple datasets mounted, a feature provided by this layer. This allows you to synchronize mirrors, and is used when verifying all checksums in your pool.

    • ZVOL: ZFS Emulated Volumes
      In FreeBSD, this layer exports GEOM providers, allowing access to storage pool data via /dev/zvol/<dataset>
    • ZPL: ZFS Posix Layer
      Pawel noted that this was the most difficult layer to port from OpenSolaris. This layer provides all filesystem operations, such as open, read, chmod, etc. Pawel noted that the POSIX API is quite limiting. This layer also provides /dev/zfs, the communication gate between userland tools such as zfs(8) and zpool(8) and ZFS, used to configure the kernel and modify ZFS pools.

    ZFS Features

    • RAID-5 versus RAID-Z
      Pawel started by talking about RAID-5, noting that RAID is supposed to stand for Redundant Array of Inexpensive Disks, then suggesting that this isn't really true as to make it work properly you use memory, and either have to take a big performance hit synchronizing data to all disk whenever a write happens in case there's a crash, or you have to use very expensive RAID controllers with sufficient RAM and battery backups. He went on to describe the write-hole-problem, in which following a power failure you can have valid data on your disk, but the parity hasn't been updated yet and thus suggest that the data is invalid. This requires either very expensive controllers to avoid, or a lengthy synchronization process after every crash.

      Pawel described RAID-Z as "similar to RAID-5, and yet so much different". RAID-Z gains from the fact that ZFS uses copy on write, and never overwrites data, avoiding the above limitations with RAID-5.

      RAID-Z is also self healing, because a checksum is written when data is written with RAID-Z, and then each time data is read the checksum is always validated. If the checksum doesn't validate, ZFS automatically attempts to reconstruct the data from the parity information, then validates this reconstructed data - if valid, it writes the corrected data back to the disk.

      Another advantage to RAID-Z is that when a disk is replaced, it doesn't blindly copy the entire disk. Instead, it only copies actual data, so if a pool is almost empty synchronization can happen very quickly.

    • End-to-end data integrity
      Pawel noted that other filesystem don't check if the data written to a disk is the same data you get back when you read from the disk, allowing silent data corruption. This data corruption can come from many different places, including a bad cable, a controller driver bug, or even a disk silently corrupting the data. He then provided an analogy to a a mail carrier such as UPS who would be saying something like: "Here's your package: it may be broken, and it may not even be yours, but we don't care."

      He then discussed hardware that does checksumming in the controller. For example, disks might be formatted with 520 byte sectors rather than 512 byte sectors, and the extra 8 bytes is then used to store checksum data. Pawel pointed out that this still does not provide end to end integrity, and can still be corrupted by a bad cable, in memory, or even by a buggy driver. Returning to the mail carrier analogy, he suggested they'd be saying something like: "We can only guarantee that when the package left our office, it was okay."

      Other filesystems offer checksums providing block consistency verification, checking the block itself but not guaranteeing that the block is in the right place. Thus, a controller bug could mistakingly send writes to the wrong place, or phantom writes can happen when you think you wrote data but you didn't. Continuing the the mail carrier analogy, he offered: "Here is a package. It's not broken, but it may not be yours."

      And then finally he looked at how every block is verified against an independent checksum in ZFS. Pointers are stored to the block in another block along with a checksum. When data is read, it can verify the data and that it really is the block being asked for. Stepping back, he noted that as data is stored in a tree, you have checksums going all the way up to the topmost block which offers a single checksum of all blocks in the filesystem. He described this global checksum as a cryptographically strong signature of the entire pool.

    • Snapshots
      ZFS does not impost any limits on the number of snapshots that can be taken, and snapshots creation is a constant time operation that doesn't slow down other filesystem operations. Only removing snapshots takes time, as it has to check to see if it needs to free blocks that were in the snapshot but are no longer in the filesystem.

      To maintain snapshots, ZFS tracks when a block was stored using a counter incremented each time an operation is written to disk, as well as a pointer to the block and a checksum. Every snapshot maintains its own dead block list, which is reviewed when a snapshot is destroyed, freeing blocks that meet the following conditions: they were born after the previous snapshot, born before the destroyed snapshot, they died after this snapshot was created, and they died before the next snapshot was created.

    • Resilvering
      When mirroring drives, it would be possible to simply copy one entire disk to another one. In RAID-Z it's not that simple, as it has to know where the block boundaries are. ZFS first traverses the metadata when synchronizing and when mirroring, giving several benefits: data integrity verification happens before the data is copied, only live data is copied so you don't waste time copying areas of the disk not containing live data, and it's possible to only copy the differences in data between two disks (similar to rsync).

      This synchronization happens from the top of the tree and works its way down, so if it is stopped mid-process by a crash, it is possible to pick up where it left off, or to obtain at least some of the data from the partially synchronized disk.

    ZFS Status in FreeBSD
    Pawel explained that he has already ported the most recent version of ZFS from OpenSolaris, and that it currently lives in his private Perforce source code repository. He noted that this port is completed code wise and everything works, but that he's working on writing regression tests. He's already written 2,000 tests, but these only cover half of ZFS functionality -- an illustration of just how many features ZFS has. The new code will not be comitted until he completes the writing of his regression tests, so he suggests "be patient".

    Cool New Features in the Latest Port

    • Delegated administration
      This makes it possible to delegate administrative rights to a non-privileged user, allowing them to create their filesystems, to create snapshots of their filesystems, and so on.
    • L2ARC
      L2ARC, or Level 2 caching in ARC makes it possible to use a disk in addition to RAM for caching reads. This improves read performance, which can otherwise be slow because of the fragmentation caused by the copy-on-write model used by ZFS.
    • Additional device for ZIL
      Useful for applications such as databases that heavily use fsync operations, allowing a small fast disk to be dedicated for ZIL entries.
    • Can access a corrupted file list
    • Stability improvements
      Pawel noted that he has been unable to duplicate the kmem_map panics reported with the earlier version of ZFS that was committed to FreeBSD, though he's not fully convinced yet the problem is solved.
    • ZFSboot
      In the latest code, it's possible to boot directly from ZFS, no longer requiring a small non-ZFS boot partition. "No you can use only ZFS and just enjoy it," he stated.
    • zpool properties
    • failure modes
      The current version of ZFS in FreeBSD will panic if it's unable to write. The upcoming version that Pawel recently ported from OpenSolaris has two other modes: wait mode is useful if a disk disappears for a short moment, ZFS will wait and then continue to work when the disk returns; continue mode denies all further writes, but allows you to continue reading data from the disk.

    When Will ZFS Be Production Ready?
    Pawel notes that he's heard this question a lot. "The experimental status is very inconvenient," he commented to lots of laughter from the crowded room. He noted that he's currently the only maintainer, and suggested until someone comes along to co-maintain the code to help debug things when the filesystem gains more users he wouldn't be marking the code as production ready. He also commented that nobody has stepped up yet to co-maintain the code, so he expect is will be a while yet.

    He went on to note that he's personally used ZFS on FreeBSD in production for 2 years, and on his laptop for more than 1 year, "it just works, and it doesn't lose data. It doesn't corrupt data, and you don't have to wait for fsck."

    Questions and Answers
    With this, Pawel opened the floor to questions.

    Q: Is the latest port available?
    A: Not yet. The regression tests are being written first, then the patch will be published, then it wil go into CVS.

    Q: Will the new version of ZFS be able to talk to partitions created with the old version of ZFS?.
    A: Yes, but you will need to use a command to update the volume if you want to access the new ZFS features.

    Q: How does ZFS handle bad sectors on the disk
    A: This can be handled by mirror disks or using RAID-Z. In addition, ZFS always replicates its metadata, and it's possible to configure it to also replicate data on a single disk.

    Q: Does it support ACLs?
    A: The new version does. In OpenSolaris they use filesystem attributres. In FreeBSD we use extended attributes. In the new version the two can be translated. It's also possible to implement POSIX ACLs, but this isn't likely to happen as it would make ZFS on FreeBSD incompatible with ZFS on OpenSolaris. There's also a Google Summer of Code project related to this.

    Q: How does ZFS work with 64-bit architectures?
    A: Another nice ZFS feature is that it has no endian dependencies. ZFS always writes in the architecture's endianness, and doesn't slow down writes by translating. When reading, it simply checks the order in which data was stored, then feeds bytes appropriately.

    Q: Can you dynamically expand filesystems?
    A: Yes.
    Pawel then popped up a terminal and offered a live demonstration of how it works.

    Q: How much space is allocated for snapshots?
    A: No space is allocated for a snapshot until you start modifying it, then it allocates space as the filesystem changes.

    Twitter, SearchMonkey, and Caching (Yahoo! Developer Network Blog)

    Twitter, SearchMonkey, and Caching (Yahoo! Developer Network Blog)

    Intrepid coder Bart Teeuwisse has written up an excellent technical account of creating "Tweet", a beautifully designed SearchMonkey app for Twitter. From a performance standpoint, writing a Twitter SearchMonkey app is particularly challenging, as Bart explains:

    It turns out that execution speed of a SearchMonkey is key. To make the SearchMonkey Gallery a presentation monkey such as Tweet has to complete within a fraction of a second. Any call to fetch 3rd party takes too long to satisfy this requirement. Certainly calling Twitter's API whose fluctuating response times are all over the map.

    Secondly, Twitter's profile API call takes a user ID, which first has to be extracted from Yahoo!'s indexed data. An additional data SearchMonkey can do that and whose output is the input to Tweet's profile feching data monkey. However, this chaining of data monkeys makes Tweet only slower.

    Fortunately, Bart hit on a really clever solution: a mashup with Google App Engine, which acts as a simple proxy cache for Twitter data, which SearchMonkey can then consume. The result (after also adding Bart's own FriendNet infobar app):

    Example Twitter application from Bart Teeuwisse; shows profile picture, tweets, followers, and more.

    Not only is the caching a nifty way to smooth out the API response times, but it also helps reduce the number of (rate-limited) API calls required. Read more about it at Bart's place.

    Yahoo! 360?? - Dawn Patrol - Tweet, a Yahoo! SearchMonkey application to enhance Twitter user profiles

    Preamble

    Tweet is a plugin for Yahoo! Search. Such plugins are called SearchMonkeys in honor of Greasemonkey for FireFox browser. Like Greasemonkey, SearchMonkey allows developers to enhance the experience, the search experience in this case. SearchMonkeys can enhance presentation with images and additional links or by combining Yahoo!'s Search index with other structured data.

    Yahoo! Search users can add SearchMonkey applications to their profile on an opt-in basis. Add Tweet to yours if you like to get much improved search results for Twitter user profiles.

    Current Twitter search results

    While Twitter user profiles are being indexed by all major Search engines, their summary is extremely poor. Google and Yahoo's results are nearly identical. Yahoo!'s summary of my profile (below) doesn't even include my full name (Bart Teeuwisse), which is on the page.

    Standard Yahoo! Search summary of my Twitter user profile

    SearchMonkey to the rescue1

    Luckily with SearchMonkey you can replace standard summaries with enhanced summaries. To improve Yahoo!'s Twitter user profile search results I wrote a SearchMonkey application called tweet that is triggered for all URLs matching *.twitter.com/*. Tweet calls Twitter's API to fetch user profile information not in the Yahoo! Search index. The result is a rich overview of a Twitter user, including last message (aka. tweet).

    Enhanced summary of my Twitter user profile by Tweet

    Tweet's challenges

    Sounds simple doesn't it? Contact Twitter's API, get profile, present profile. The SearchMonkey's architecture splits this into 2 monkeys:

    • A data monkey to contact Twitter's API to get the profile, and
    • A presentation monkey (Tweet) to present said profile.

    Well, not quite.

    Speed, speed, speed

    It turns out that execution speed of a SearchMonkey is key. To make the SearchMonkey Gallery a presentation monkey such as Tweet has to complete within a fraction of a second. Any call to fetch 3rd party takes too long to satisfy this requirement. Certainly calling Twitter's API whose fluctuating response times are all over the map.

    Secondly, Twitter's profile API call takes a user ID, which first has to be extracted from Yahoo!'s indexed data. An additional data SearchMonkey can do that and whose output is the input to Tweet's profile feching data monkey. However, this chaining of data monkeys makes Tweet only slower.

    Thirdly -as I mentioned earlier- Twitter's API has wildly varying response times. And is by no means predictable enough to guarantee a prompt response. Furthermore Twitter is having scaling issues already. Adding a SearchMonkey that calls Twitter's API for up to 10 search results for each query could make things should Tweet gain many opt-in users.

    Perhaps caching can help? The SearchMonkey platform does has some caching. Unfortunately SearchMonkey developers have no control over SearchMonkey's cache. Emperical data suggests that SearchMonkeys are cached for only a few minutes. Tweet could be cached much longer without sacrificing functionality.

    SearchMonkey + AppEngine = Fast Data Monkey

    To mitigate these challenges I decided to use a proxy of my own in between SearchMonkey & Twitter.

    • A proxy that could scale, should Tweet become popular.
    • A proxy where I could control my own cache.
    • And a proxy that eliminates the need for an additional data Monkey to extract the Twitter user ID from the search result.
    • And lastly a proxy that returns DataRSS to minimize (XSLT) transformations in SearchMonkey.

    Why not Yahoo! Pipes?

    I first turned to Yahoo! Pipes, but Pipes doesn't give me caching control and the only XML output format is RSS not DataRSS. So I turned to Google's App Engine instead, which satisfies all my requirements. It offers Memcache caching, is build to scale, allows me to extract the Twitter user ID, make the Twitter API call and transform its response to DataRSS.

    Developing for Google App Engine

    Even though this is my 1st Python application worth mentioning, I didn't have too much trouble writing it. App Engine's documentation combined with Python's tutorials were sufficient to answer my questions. The biggest obstacle I encountered is the lack of good XML/XLT libraries for Python. There isn't a clear winner to begin with and App Engine's restriction to pure Python libraries eliminates all candidates, as I learned the hard way.

    I really like the Googel App Engine SDK. No hassle configuring a web server or data base. No need to be online even. I developped about half the proxy while vanpooling to and from work!

    How the proxy works

    My proxy takes the URL of the search result as input from SearchMonkey. Given the trigger URL pattern these are all URLs to *.twitter.com. E.g. twitter.com, explore.twitter.com or m.twitter.com. The proxy first extracts the Twitter user ID, if any. In Twitter's URL schema, user IDs are the 1st part of the URLs path. E.g. bartt in twitter.com/bartt or twitter.com/bartt/friends

    It then checks the Memcache for a profile for this ID. If it has one it composes the DataRSS response and exits. If it doesn't it calls Twitter's API. Succesfull API calls are parsed and stored in Memcache for -currently- 2 hours, before composing a DataRSS response. Failed calls return an empty DatRSS response.

    Fast enough?

    My proxy speeds up cached profiles by a factor 3x to 10x. Most of the time, that is. Despite App Engine's claim to scale, it does have performance issues from time to time. App Engine had an outage for a day while I tested my proxy for example.

    Odly enough, Twitter's API holds the record of the fastest response time, yet its average is many times App Engine's average response time (for cached profiles). App Engine's response time is very stable - about 200 milliseconds round trip from a west coast data center.

    This doesn't make Tweet fast enough to be included into the SearchMonkey Gallery though. Not only is the proxy not fast enough, to that you'll have to add the XSLT process and 'render' times by SearchMonkey. Still, Tweet is now eminently more usable and shields Twitter from API overload.

    Tweet & FriendNet combined

    Combine Tweet with FriendNet, one of my other monkeys for an even richer search result. FrienNet displays profiles and contacts embedded in the page. It combines hCard profiles with XFN links embedded on the page to present a social graph.

    Enhanced summary of my Twitter user profile by Tweet with FriendNet below

    In collapsed mode -the default- FriendNet shows the number of profiles, cards and contacts found on the page by Yahoo! Search.

    Enhanced summary of my Twitter user profile by Tweet & social network by FriendNet

    Expanded, FriendNet shows details of Twitter friends.

    Create your own SearchMonkeys

    Got your own ideas for improving Yahoo! Search? Start monkeying around! You find everything you need at SearchMonkey on the Yahoo Developer Network.

    Check out the SearchMonkey Gallery for more monkeys you can use. Or take my Better Amazon monkey for a spin.