1. Apertus -- open source cinema camera. (via joshua on Delicious)
2. A Survey of Collaborative Filtering Techniques -- From basic techniques to the state-of-the-art, we attempt to present a comprehensive survey for CF techniques, which can be served as a roadmap for research and practice in this area. (via bos on Delicious)
3. Drizzle Replication using RabbitMQ as Transport -- we're watching the growing use of message queues in web software, and here's an interesting application. (via sogrady on Delicious)
4. Facebook Data Team: Distributed Data Analysis at Facebook -- job ad from Facebook gives numbers on company use of their Hive data warehouse tool built on top of Hadoop: Today, Facebook counts 29% of its employees (and growing!) as Hive users. More than half (51%) of those users are outside of Engineering. They come from distinct groups like User Operations, Sales, Human Resources, and Finance. Many of them had never used a database before working here. Thanks to Hive, they are now all data ninjas who are able to move fast and make great decisions with data. (via Simon Willison)

The 8th Ignite Seattle is this Tuesday, 12/1. We've got an amazing set of speakers and fun opening activity. We are once again at the King Cat Theatre in Downtown Seattle.

Doors open at 7PM. The contest will start at 7:30 and the talks will begin at 8:30. You can track Ignite Seattle updates at http://igniteseattle.com.

Here is our list of awesome speakers:

Benjamin Franklin – Intellect: without an outlet in the world

Do we remain in awe of Ben Franklin’s capacity and accomplishments or do we take on his mantle of “Doing the best with what we have” and look at our issues and do something about them? Better yet, WWBFD? [Brady's note: This is going to be a presentation by someone done as Benjamin Franklin. You can learn more on his site.

Wendy Chisholm (wendyabc) Challenge your assumptions. Innovate. Change the world.

Most designers are taught to design for the average user and as a society we hold many assumptions about the characteristics of those users. However, products are used in unexpected ways and by unexpected audiences.

Sarah Schacht (sarahschacht) Overcoming Cacophony: Making Gov 2.0 Work for You

What can you do, as an individual to make your voice heard in the lawmaking process and what tools do you use? Learn how to make your email float to the top of a pile of thousands, how to stand out from the crowd, and how to do so without losing your sanity.

Eugene Lin – iPhoning my way to retirement, $.70 at a time

I want to be rich. Steve Jobs promised it. App after app, the Apple gods got angry with me. Until finally, with nothing but an accelerometer, two dozen naked women, and the nation of Japan, I had a story to tell.

Scott Berkun (berkun) Everything you need to know about philosophy in 5 minutes

I’m the sad owner of a philosophy degree. I’m convinced i can give people a better education in philosophy (and make them realize how much they already know and love philosophy) in 5 minutes than I got in 4 years.

Jason Carmel (defenestrate99) Defamation and Twitter - A Practical Guide to Covering Your Ass

I will provide a few practical ways that might protect your right as an American to roast the bejeezus out of the people of the world, without getting sued into oblivion.

Jeremy Bingham (captain_tenille) An Astronomical Viewing Shelter on the Cheap

Using your telescope in the city can be frustrating with all the stray light all over the place. You can’t do much about the skyglow, but you can shield yourself from stray light sources nearby.

Richard Bailey – More blink in less time? Manufacturing electronics for art projects.

The Groovik Cube required a custom surface mount circuit board for each of the 56 facets. Early estimates showed that this would require well over 150 hours of time to accomplish. The Groovik electronics team created an assembly line and produced 90 boards in one day.

Mike Tyka – Cubes in the Sky

We went through about 10 designs each trying to achieve the same goal of somehow raising the 15×15x15ft Groovik’s Cube, weighing near 4000 lbs 10 feet in the air within a fairly tight budget.

Arianna O’Dell (arianna) How to Sneak into Bars

I am a 19 year old student at the University of Washington. Most people don’t know this because they never ask. I’ve been attending networking events all summer and most people think I’m out of school and already graduated.

Greg Dunlap (heyrocker) How to not suck at pinball

Pinball is hard. Luckily, getting better at pinball, not great but respectable, is actually pretty easy.

p>Jon Bell (jonbell) Usability Beyond the Classroom

It wasn’t until I spent a year at frog design as a developer that I realized everything I learned in art school was either wrong, outdated, or only told half the story.

Norman Guadagno (thinktone) Amazon Archaeology OR Swimming In Our Own Clickstream

Every time we buy from Amazon, we give their algorithms a little more information about ourselves (or at least the things we buy). But, do we have our own algorithms to help us make sense of purchase after purchase across time? What can we learn about ourselves through the things we buy?

Peter Wilson (peterwil) Google vs. Microsoft: An Insiders Guide

Google vs. Microsoft: where will the battles be fought, how will each companies strategies and blind-spots impact the outcomes, and who will win? The speaker spent 9 years at Microsoft and 4 at Google, and so thinks he knows something about this…

Ron Burk (ronburk) Three Strange Definitions of Computer Programming Legendary computer scientist Edsger Dijkstra once said: “Computer Science is no more about computers than astronomy is about telescopes.” But if programming is not about the computers, what IS it about?

Veronica Sopher (Shih_Wei) Jewelry: It’s What Geeks Know!

Elizabeth Taylor and Ivanka Trump may have their own jewelry lines, but it’s geeks like you/us who are the experts in jewelry. Yes, it takes a real geek to know jewelry, cut through the salesperson’s bs, and shop like a pro. Let me show you why.

Dylan Wilbanks (dylanw) Everyone Core Dumps: Death and Loss For The Geek

We are all going to die. But handling loss is something geeks struggle with. Learn three things you should do when a friend dies, three things you shouldn’t do, and ways you can preserve your existence online.

After the recent Web 2.0 Expo NY--a sprawling, week-long conference and exhibition--I ducked into the Morgan Library to catch "A Woman's Wit: Jane Austen's Life and Legacy." A one-room show about an 18th century novelist seemed like the perfect antidote to a week of tech talk in the Death Star Javits Center.

As I'd hoped, the Morgan focuses on a handful of objects from Austen's life, and the commentary is thoughtful. I was surprised, though, to find myself thinking that had Twitter been around in Austen's time (1775-1817), she would likely have been a fan.

Austen wrote more than 3,000 letters, many to her sister Cassandra. They corresponded constantly, starting new letters to each other the minute they finished the last one and sharing the minutia of their lives. From reading Austen's novels, I'd always assumed that people in her era spent a long time waiting for the mail. But the show mentions that during Austen's life, mail in London and environs was delivered six times a day. Sometimes, a letter sent in the morning was delivered the same evening. Which makes snail mail sound a lot more like email or twitttering.

The speed of mail at the time and the content of the Austen sisters' letters suggest that the desires to communicate instantly and to let other people know what you ate for breakfast aren't modern phenomenon. Of course, Twitter lets you share your soy milk-to-cereal ratio with strangers and thus adds a layer of publishing to our updates. But people today often assume that email, Twitter and other relatively instant communication media have created a slew of brand new communication behaviors. The Jane Austen show at the Morgan suggests just the opposite: our human patterns are surprisingly consistent, and technology evolves to meet us.

Incidentally, the show doesn't say when multi-daily snail mail faded, and I wonder if it passed out of fashion with the rise of the telegraph in the mid-1800s. Anyone know?

As much as anything else, a user's impression of a web site has to do with how fast the site loads. But modern Web 2.0 websites aren't your father's Oldsmobile. Chocked full of rich Flash content and massive JavaScript libraries, they present a new set of challenges to engineers trying to maximized the performance of their sites. You need to design your sites to be Fast by Default. That's the theme of the upcoming Velocity Online Conference, co-chaired by Google performance guru Steve Souders. Souders is the author of High Performance Web Sites and Even Faster Web Sites, and spent some time discussing the new world of web site performance with me.

James Turner: There's been an evolution of the whole area of web performance, from the old days when it was all about having a bunch of servers and then doing round robin or just spreading the load out. How is web performance today different than it was, say, ten years ago?

Steve Souders: Well, what's happened in the last five years or so is that Web 2.0 and DHTML and AJAX has really taken off. And that's really been in the last two years. Five years ago, we started seeing a lot of flash and bigger images. So basically what's happened is our web pages have gotten much richer, and that also means heavier. There's more content being downloaded, more bytes. And then in the last two years, with the explosion of Web 2.0, we're seeing not only a lot more bytes being downloaded into web pages, but we're seeing that that involves a lot of complex interaction with JavaScript and CSS. And so whereas maybe five or ten years ago, the main focus was to build back-end architectures that would support these websites, we're seeing today that we need a lot more focus on the front-end architecture of our websites and web applications.

So that's where Velocity comes in, and my work comes in. Whereas ten or twenty years ago, you had people looking at collecting and evangelizing best practices for back-end architectures like databases and web servers, Velocity and my work is about identifying and evangelizing best practices for building really fast high-performance front-end architectures.

James Turner: I know, as someone who's been doing AJAX development, AJAX is a very different kind of paradigm for how you're interacting with the server. It's a lot more chatty. Are the current generations of web servers really designed for that kind of interaction?

Steve Souders: I think that the chattiness of AJAX applications isn't really the issue with regard to performance. I mean, anything can become an issue, but looking across the top 1,000 websites in the world, that's not the issue. The issue is that these web applications that do AJAX require a lot of JavaScript to set up that framework on the client, inside the browser. And to set that up, to download all of that JavaScript and parse it and execute it just takes a lot of time. A user is downloading complex photos or mail or calendaring application, and before they've even done any chatty AJAX request, they're just waiting for the application to actually load and start up. That's the frustrating period, you just want to get in and start working on your slides or reading your mail, and you're waiting for this start up to happen. Typically, once these AJAX frameworks have loaded, the AJAX work that we're doing in the background is not that big of a problem either from a back-end perspective or from the client side perspective.

James Turner: One of the things we see a lot these days is people using libraries like YUI or Google's libraries or JQuery . They have compressed versions, but they're still pretty large. To what extent do you think there's a need to really go in and pick and choose out of those libraries?

Steve Souders: Well, myself personally, I do that frequently because I only need usually one small feature, like I need a carousel or I need a drop-down menu or something like that. And I'll go to the work of pulling out just the code that I need. But I'm working small website projects. If you're building a whole web application, you're probably using many parts of these JavaScript frameworks. There still might be some benefit in pulling out just the pieces that you need. But that's extra work. And when you need to upgrade, that's the likelihood of introducing bugs or other problems. So certainly, I wouldn't avoid doing that. It should be evaluated, pulling out just the JavaScript that you need from the frameworks so long as the licensing even supports that.

But something else that helps address that problem is the Google AJAX Libraries API. This is where Google is actually hosting versions of JQuery and Dojo and YUI and Google's Closure JavaScript framework and Scriptactulous and EXT and others. What happens is you can have multiple websites that don't have any interaction with each other, Sears.com and WholeFoods.com, but they both might be using JQuery 1.3.2. And if they're both downloading that library from the Google AJAX Libraries API, then the URL is exactly the same. So a user that visits multiple of these websites only has to download that JavaScript once during their entire cache session. That further mitigates the need or motivation or benefit of pulling out just the parts that you need.

At first, I didn't think there would be that much of a critical mass around these people that would adopt the Google AJAX Library CDN and the actual version numbers of these JavaScript frameworks, but it's actually taken off really well, a lot of websites are using them. Users are actually getting this critical mass benefit where when they go to some website, Sears.com, that's using JQuery, they already have that in their cache from a visit they made a previous day to a different website. So I think in general, I would recommend to developers that they not change the JavaScript frameworks they're using. And if they're using a framework that's hosted on Google, download it from there. It's hosted on Google's infrastructure, so it's going to be fast, reliable, and users will actually get the benefit of having a greater probability of the framework being in their cache, because multiple websites are taking advantage of loading it from there.

James Turner: I have to put my security hat on for a second and ask, when you get into a situation like that, the flag that comes up for me is if someone managed, by some kind of an injection fake, delivery a version of a library that had vulnerabilities so that it appeared to be coming from Google, you could get into a situation where someone would be using a poison library. Do you think that's at all a realistic concern?

Steve Souders: Well, I think it depends on who's doing that. I work at Google so I don't want to come off as sounding like a fan boy who's only going to say great things about what Google is doing. I'm as cautious as the next person with what passwords I use and what information I give to any web company. But when it comes to something like this, I've built stuff that's running on Google App Engine or Amazon AWS. It's always possible that these big companies, these big web hosting providers are going to go down. But there's probably a greater chance that my website is going to go down than Google or Amazon. And the same thing with security. There's probably a greater chance that my website is going to be hacked than Google or Amazon. So I think it is a possibility. But I think the odds are pretty small of that happening. And that would not be a concern that would stop me from taking advantage of these services because of the performance benefits I get from them.

James Turner: Staying a little bit on security, there's certainly been more of an emphasis over the last, pick your unit of years, about making sure that data stays secure. You see things like Open ID now and everything pretty much is SSH'd. How much of a balance do you have to keep between performance and security or can they work in concert?

Steve Souders: I don't think there is that much tension between performance and security. The things that are making websites slow are not being done in a slow way because people are striving to have greater security. In most of the places where improvement could be made, the improved way, the higher performance way of doing things, doesn't change your security exposure to any degree.

There are some situations where protecting the users' data could make a website slower. For example, suppose I'm a mail application and I want to not cache the user's address book. You want to protect the user's data. That's a higher priority than performance. And so you make that address book response non-cacheable. Now that will make the website slower, the web mail application slower the next time the user goes there, but that one request for the user's inbox and the user's address book, those small number of requests are insignificant compared to all of the other JavaScript and CSS and images that are being downloaded. So whether you cache that or not, whether you load it over SSL or not, that is not what's making websites slower. The things that are making websites slower are large amounts of JavaScript, much of which is not used in the initial loading of the page, images that are not being optimized and these other performance best practices that are being evangelized by tools like YSlow and Page Speed.

James Turner: You've been focusing a lot on the front-end. I have to say as someone who works largely on the back-end, one of the trends I've seen is more and more tiers being layered on, of more and more complexity. Maybe not now, but certainly a few years ago, everything was going to be SOAP over web services with Enterprise Service Buses and all of this very complex multi-tier architecture. Wasn't that just latency waiting to happen there?

Steve Souders: Well, if you look at most websites, you'll see that for almost all websites, less than 10 to 20 percent of the page load time is spent getting the HTML document. And that's largely where this back-end potential for latency lies that you're talking about. It lies behind generating that HTML document. That HTML document might generate a page that has a few more hits on the back-end for some AJAX responses or some dynamically generated JavaScript, but by and large, that's where you're going to have the biggest latency impact from the back-end, from these tiers that you've described, it's generating the HTML document. And yet we see across almost all websites that the HTML document, not just the generation of it, but the request going up to the web server and the response coming back, all of that is less than 10 to 20 percent of the page load time. So it's certainly not the long pole in the tent. And, in fact, if you could drop the HTML document time to zero, most users wouldn't notice. It's that front-end part that is the long pole in the tent.

That's not true of all websites. It's probably true of 95 percent of the websites out there. There are certainly a number of websites where the back-end is taking a long time. It's taking 30 to 50 percent of the overall page load time. The first thing I recommend website owners do is get a handle, get an idea of the overall page load time. And then the second thing I say is break that into two parts: the back-end and the front-end. And if you find that like most websites, your back-end time is less than 10 or 20 percent, then you're correct in focusing on these front-end best practices. If your back-end time is 30 to 50 percent or more, then you should really start on looking at your back-end architecture.

Perhaps there are some latency delays injected there because of multiple tiers or other web services that you're using. But there are even some best practices in that situation. For example, flushing the document early is a situation where if you do have a lot of web service requests that are required to generate your HTML document, you can still send back some of your HTML page to the browser early before you start those slow web service calls and give the user some content and some feedback and start the browser doing some work while you continue on with your other back-end requests in processing.

James Turner: One place that I see a lot of slowdown in pages has nothing to do with the site I'm actually visiting, but a lot of times, it appears the ads being served on the page. What's the state of that right now? It seems like the people who are doing the least to optimize their performance are the ad servers.

Steve Souders: Yeah. Ads being served, third party ads being served inside of web pages, is becoming more of a problem. It's not that it's getting worse; it's that everything else is getting better. When I started this work about five years ago, the percentage of problems that could be associated with ads was pretty small. Maybe 20 percent of the improvements you could make to a page had to do with ads. That's because most websites weren't focusing on these other best practices of spriting and ETags and caching. Well, in the last five years, we've seen a lot of the major websites adopting these front-end performance best practices. So it's not that ads have gotten worse; it's that the actual website content has gotten so much better. Now, of the bad performance practices that you see inside of popular web pages, a much higher percentage, maybe 40 or 50 percent of the problems are introduced because of third party ads.

And it's not too surprising that that's happening for two reasons. One is that it's amazing that this system of serving third party ads works. Here you have two companies that have never spoken to each other. You have two sets of web developers who have never met and never exchanged any plans for how to integrate content. And yet, this third party ad service can serve up content that almost 100 percent of the time loads correctly in some publisher's page. That's just an amazing infrastructure that has worked for as long as it has and it continues to work, especially when you consider all of the cross browser compatibility issues that can arise.

So how is it that we were able to achieve that? Well, it's because we adopted a framework of inserting ads, of creating ads, that's pretty simple. And because it's pretty simple, it's not highly tuned. That's one reason why we shouldn't be too surprised that we see performance issues in third party ads. The other reason is that ad services are not focused on technology. Certainly companies like Yahoo and Google and Microsoft, we're technology companies. We focus on technology. So it's not surprising that our web developers are on the leading edge of adopting these performance best practices. And it's also not surprising that ad services might lag two, three or four years behind where these web technology companies are.

I think that's where we are. We've seen a lot of adoption of these performance best practices in these web companies over the last three years and now it's time for the ad services to catch up. I don't know what the answer is there. It's going to require changing this huge infrastructure for serving third party ads, and that's not something that's easy to do. Certainly we know things that we can do to make ads serve better, to make them faster, to reduce the impact they have. But getting that to propagate across this huge ecosystem of ads is going to take a long time, a lot of evangelism, a lot of monitoring and a lot of organizational changes. It's not something that's going to happen overnight. But hopefully in the next few years, we'll see progress there.

I know in the last two years, the IAB has established a performance working group and has published some guidelines for how to make ads higher performance. I think we'll continue to see progress there. And just as we're seeing with web companies, where companies that have faster web pages are more successful, have greater revenue, reduced operating expenses, the ad services are going to realize that too, that when it comes to ads, faster ads are going to have a competitive advantage. I think, in part, the ecosystem will take care of itself. These ad services will realize that to remain competitive, they need to be fast.

James Turner: Okay. I'm going to wrap up with one last, kind of geeky, question. What is the state-of-the-art in small good-looking images these days?

Steve Souders: Well, when it comes to images, the two experts in the industry are Stoyan Stefanov and Nicole Sullivan. I worked with both of them over in the Yahoo Exceptional Performance Group. And they, in fact, contributed a chapter to my most recent book on optimizing images. So they're really the experts, but I think I can summarize what they would say. If you have small images with a very few number of colors, GIF is probably going to be the optimal format to use. All of these formats are supported across all browsers. In most cases though, PNG is going to be the format to choose, you can choose PNG 8 for images that are less than 255 colors or PNG 24 for images that are over 255 colors. And if you have a very high resolution image, like a photograph, JPEG is still the optimal format. So your question was about small high-quality images. PNG is going to be the format of choice, most likely, for those types of images.

Planning to attend the O'Reilly Velocity Online Conference on December 8, 2009? Register using code velfall09d25 and receive 25% off the registration price!

1. Paywall Performance for News -- the National Business Review (NBR) in New Zealand went to a paywall in mid-July, and Foo Camper Lance Wiggs says their visitor numbers reveal a grim picture. As a commenter says, of course, visitor numbers go down but NBR makes money directly from the visitors that stay. I'm curious to see the effect on advertisers now the site's incentives are not to spray their load far and wide to land on as many eyeballs as possible. An interesting canary in the mine for Rupert's paywall plans at Fox.
2. Real Time, Real Discussion, Real Reporting: Choose Two (CrunchGear) -- a long post about the Internet's effects on journalism, but the headline will stick with me the longest.
3. Sony Still Subsidizing US Supercomputer Efforts -- US military buying PS3s as a cheap source of cell CPUs. The PS3's retail price is subsidized by Sony, driving game sales in a razor-blades model. It's like you could melt down razors and get more in scrap metal than they cost to buy at the supermarket ... (via BoingBoing)
4. Open Source Proves Elusive as Business Model (NYTimes) -- To Ms. Kroes’s point, there is an open-source alternative, and usually a pretty good one, to just about every major commercial software product. In the last decade, these open-source wares have put tremendous pricing pressure on their proprietary rivals. Governments and corporations have welcomed this competition. Whether open-source firms are practical as long-term businesses, however, is a much murkier question. On the contra side, Mozilla makes millions from referred searches and must be counted as a win for open source even though it's not a company.

My Parka pinched tightly, I plunged into the sleet that
battered the pavements of Washington DC in a flash storm and tread
down 6th Street. I wasn't about to turn back now. There was no other
time for me to take the assortment of extended family members to the
Newseum,
the exhibit hall about journalism that has garnered so much buzz since
its recent move from humble beginnings over the horizon in Virginia to
a swank neomodern block with a balcony over looking the Capitol
building that generates so much of its subject matter.

The Newseum is an experience worth the entrance fee, and a capacious
view into the profession that it honors. The history exhibit boasts
history-making front pages throughout the life of our country, and the
First Amendment exhibit brought tears to my eyes. But a lot was
missing from the Newseum too, and I didn't think the omissions were
just something they'll get to later.

The focus of the museum is on the journalist as individual hero,
extending to interviews with Pulitzer-winning photographers and an
obligatory homage to Edward Morrow. Hard on the heels of the
First Amendment exhibit was a memorial to journalists who died in the
line of duty, including even an automobile destroyed by a car bomb to
underline the dangers they face.

This is all appropriate, but left nothing for the business of
journalism, which is key to understanding where it stands today. I
tried to count the references to the economics of the field and found
about enough to be covered by a two-fingered typist. A panel about
William Randolph Hearst mentioned media consolidation, with one
sentence criticizing it and another defending it. The history and
digital media exhibits mentioned the wave of recent newspaper
bankruptcies. Particular ironic was the application of the label
"Global Media Diversity" to a panel listing five of the world's
largest organizations in an ever-consolidating industry.

It's hard to suppress a hypothesis as to why so little is said here
about industry finances and their editorial influence: the museum was
largely funded by the very organizations that it would otherwise have
to put under its microscope. I issue a challenge, therefore, to the
Newseum: exercise the uncompromising investigatory dedication you
celebrate in your subjects, and add an exhibit about the changing
economics of journalism and the scissors crisis in which it traps its
practitioners.

Another understated theme in the Newseum is the effect of journalists
on events subsequent to their coverage. Repeatedly, exhibits play up
journalists' insight and courage in responding to the urgent issues of
their times, but any influence in the other direction is only hinted
at. The clearest connection made was Nellie Bly's ground-breaking
nineteenth-century exposé of conditions in a New York insane
asylum, an assignment that required her to be committed and live the
life of an inmate.

Although the history exhibit celebrates African-American journalism in
the last decades of slavery and during the post-war Civil Rights
movement, it does not bring home to the viewer how the relentless
parade of facts and images brought a white American public less jaded
than we are today to a conviction that it was time for change. And a
lavish Woodstock exhibit fails to point out that coverage of this
massive gathering propelled the youth counterculture into the
mainstream.

Finally, the museum glosses over the roles of various technologies in
changing journalism. It offers live interviews in a TV studio, but only
for the vicarious tingle it gives would-be participants. Exhibits on the
contributions of Internet technologies, typewriters, and helicopters
are skimpy.

Despite my wish that it would go farther, I highly recommend a visit to the
Newseum. It offers many issues of our day their due, such as the
journalistic rights of bloggers. On the whole, it's the fullest survey
I've seen of the state of journalism in our time. If we want
journalism to continue to exist outside the museum, we can all line
up there to gain a better understanding of the field.

My Parka pinched tightly, I plunged into the sleet
battering the pavements of Washington DC in a flash storm and tread
down 6th Street. I wasn't about to turn back now. There was no other
time for me to take the assortment of extended family members to the
Newseum,
the exhibit hall about journalism that has garnered so much buzz since
its recent move from humble beginnings over the horizon in Virginia to
a swank neomodern block with a balcony over looking the Capitol
building that generates so much of its subject matter.

The Newseum is an experience worth the entrance fee, and a capacious
view into the profession that it honors. The history exhibit boasts
history-making front pages throughout the life of our country, and the
First Amendment exhibit brought tears to my eyes. But a lot was
missing from the Newseum too, and I didn't think the omissions were
just something they'll get to later.

The focus of the museum is on the journalist as individual hero,
extending to interviews with Pulitzer-winning photographers and an
obligatory homage to Edward Morrow. Hard on the heels of the
First Amendment exhibit was a memorial to journalists who died in the
line of duty, including even an autmobile destroyed by a car bomb to
underline the dangers they face.

This is all appropriate, but left nothing for the business of
journalism, which is key to understanding where it stands today. I
tried to count the references to the economics of the field and found
about enough to be covered by a two-fingered typist. A panel about
William Randolph Hearst mentioned media consolidation, with one
sentence criticizing it and another defending it. The history and
digital media exhibits mentioned the wave of recent newspaper
bankruptcies. Particular ironic was the application of the label
"Global Media Diversity" to a panel listing five of the world's
largest organizations in an ever-consolidating industry.

It's hard to suppress a hypothesis as to why so little is said here
about industry finances and their editorial influence: the museum was
largely funded by the very organizations that it would otherwise have
to put under its microscope. I issue a challenge, therefore, to the
Newseum: exercise the uncompromising investigatory dedication you
celebrate in your subjects, and add an exhibit about the changing
economics of journalism and the scissors crisis in which it traps its
practitioners.

Another understated theme in the Newseum is the effect of journalists
on events subsequent to their coverage. Repeatedly, exhibits play up
journalists' insight and courage in responding to the urgent issues of
their times, but any influence in the other direction is only hinted
at. The clearest connection made was Nellie Bly's ground-breaking
nineteenth-century exposé of conditions in a New York insane
asylum, an assignment that required her to be committed and live the
life of an inmate.

Although the history exhibit celebrates African-American journalism in
the last decades of slavery and during the post-war Civil Rights
movement, it does not bring home to the viewer how the relentless
parade of facts and images brought a white American public less jaded
than we are today to a conviction that it was time for change. And a
lavish Woodstock exhibit fails to point out that coverage of this
massive gathering propelled the youth counterculture into the
mainstream.

Finally, the museum glosses over the roles of various technologies in
changing journalism. It offers live interviews in a TV studio, but only
for the vicarious tingle it gives would-be participants. Exhibits on the
contributions of Internet technologies, typewriters, and helicopters
are skimpy.

Despite my wish that it would go farther, I highly recommend a visit to the
Newseum. It offers many issues of our day their due, such as the
journalistic rights of bloggers. On the whole, it's the fullest survey
I've seen of the state of journalism in our time. If we want
journalism to continue to exist outside the museum, we can all line
up there to gain a better understanding of the field.

1. ProFORMA -- software which builds a 3D model as you rotate an object in front of your webcam. Check out the video below. (via Wired)
2. BiwaScheme -- a Scheme interpreter written in Javascript. (via Hacker News)
3. YMacs -- in-browser EMACS written in Javascript. Emacs, for those of you who were left in any doubt, is the only editor ever created by software engineers worth a damn (where "worth a damn" == "has possibly already achieved sentience") with the possible exception of teco.
4. Historic Documents in Computer Science -- my eye was caught by John Backus's first FORTRAN manual, Niklaus Wirth's original Pascal paper, the BCPL reference manual (the C programming language got its name from the C in BCPL), and Eckert and Mauchly's ENIAC patent. (via Hacker News)

1. ProFORMA -- software which builds a 3D model as you rotate an object in front of your webcam. Check out the video below. (via Wired)
2. BiwaScheme -- a Scheme interpreter written in Javascript. (via Hacker News)
3. YMacs -- in-browser EMACS written in Javascript. Emacs, for those of you who were left in any doubt, is the only editor ever created by software engineers worth a damn (where "worth a damn" == "has possibly already achieved sentience") with the possible exception of teco.
4. Historic Documents in Computer Science -- my eye was caught by John Backus's first FORTRAN manual, Niklaus Wirth's original Pascal paper, the BCPL reference manual (the C programming language got its name from the C in BCPL), and Eckert and Mauchly's ENIAC patent. (via Hacker News)

1. 1 in 3 Schools -- visual exploration of education data is the latest BERG project, and they've found a new application for a cute visualization and they're calling the result Chernoff Schools. Recommended reading for those interested in visualization or education.
2. The Robots Podcast -- self-explanatory. (via So Where's My Robot?)
3. Dive Into HTML 5 (Mark Pilgrim) -- absolutely gorgeous layout. The first thing I've seen that makes me want HTML 5. (Apparently O'Reilly will be publishing it when it's finished. Yay, us!)
4. Copyright Watch -- a repository of national copyright laws.