Slashdot Mirror

Multiple news agencies are reporting that the Pentagon has demanded the return of WikiLeaks' collection of secret documents relating to the war in Afghanistan. Defense Department spokesman Geoff Morrell said, "The only acceptable course is for WikiLeaks to take steps immediately to return all versions of all of these documents to the US government and permanently delete them from its website, computers and records." According to the BBC, Morrell also "acknowledged the already-leaked documents' viral spread across the internet made it unlikely they could ever be quashed," but hopes to prevent the dissemination of a further 15,000 documents WikiLeaks is reportedly in the process of redacting. "We're looking to have a conversation about how to get these perilous documents off the website as soon as possible, return them to their rightful owners and expunge them from their records." WikiLeaks, predictably, shows no sign of cooperating.

secretrobotron writes "I'm a recent university graduate from a co-op system which has kept me on the move every other semester, so I've never really had a permanent place to live, and I've never had the opportunity (or the capital) to buy expensive things. Now that I'm working, those restrictions on my life are gone and I'm living in an apartment with things I don't want stolen. I would love to build a DIY home security system, but I don't even know where to start since Google searches reveal things like diysecurityforum.com, which help only to an extent for a curious newcomer. Has anybody out there successfully built a home security system on a budget? If so, where did you start?" Related query: When similar questions have come up before, many readers have recommended Linux-based Zoneminder (last updated more than a year ago); is that still the state of the art?

secretrobotron writes "I'm a recent university graduate from a co-op system which has kept me on the move every other semester, so I've never really had a permanent place to live, and I've never had the opportunity (or the capital) to buy expensive things. Now that I'm working, those restrictions on my life are gone and I'm living in an apartment with things I don't want stolen. I would love to build a DIY home security system, but I don't even know where to start since Google searches reveal things like diysecurityforum.com, which help only to an extent for a curious newcomer. Has anybody out there successfully built a home security system on a budget? If so, where did you start?" Related query: When similar questions have come up before, many readers have recommended Linux-based Zoneminder (last updated more than a year ago); is that still the state of the art?

jamie writes "Researchers have turned the biochemical challenge of figuring out protein folding structures into a computer game. The best players can beat a computerized algorithm by rapidly recognizing problems that the computer can't fix. From the article: 'By tracing the actions of the best players, the authors were able to figure out how the humans' excellent pattern recognition abilities gave them an edge over the computer. For example, people were very good about detecting a hydrophobic amino acid when it stuck out from the protein's surface, instead of being buried internally, and they were willing to rearrange the structure's internals in order to tuck the offending amino acid back inside. Those sorts of extensive rearrangements were beyond Rosetta's abilities, since the energy changes involved in the transitions are so large.'"

We've mentioned several times over the past two years Wave, Google's ambitiously multi-channel, perhaps plain overwhelming entry in the social media wars. Now, reader mordejai writes "Google stated in its official blog that they will not continue developing Wave as a standalone product. It's sad, because it had a lot of potential to improve communications, but Google never promoted it well, denying it a chance to replace email and other collaboration tools for many uses."

We've mentioned several times over the past two years Wave, Google's ambitiously multi-channel, perhaps plain overwhelming entry in the social media wars. Now, reader mordejai writes "Google stated in its official blog that they will not continue developing Wave as a standalone product. It's sad, because it had a lot of potential to improve communications, but Google never promoted it well, denying it a chance to replace email and other collaboration tools for many uses."

We've mentioned several times over the past two years Wave, Google's ambitiously multi-channel, perhaps plain overwhelming entry in the social media wars. Now, reader mordejai writes "Google stated in its official blog that they will not continue developing Wave as a standalone product. It's sad, because it had a lot of potential to improve communications, but Google never promoted it well, denying it a chance to replace email and other collaboration tools for many uses."

jamie spotted a fascinating story at The Atlantic about "mysterious and possibly nefarious trading algorithms [that] are operating every minute of every day in" the stock market: "Unknown entities for unknown reasons are sending thousands of orders a second through the electronic stock exchanges with no intent to actually trade. Often, the buy or sell prices that they are offering are so far from the market price that there's no way they'd ever be part of a trade. The bots sketch out odd patterns with their orders, leaving patterns in the data that are largely invisible to market participants." Spotting the behavior of these bots was possible by looking at much finer time slices than casual traders ever see — cool detective work, but as the story points out, discovering it is just the beginning: "[W]e're witnessing a market phenomenon that is not easily explained. And it's really bizarre."

holy_calamity writes "Technology Review looks at how some traditions of computer architecture are up for grabs with the arrival of optical interconnects like Intel's 50Gbps link unveiled last week. The extra speed makes it possible to consider moving a server's RAM a few feet from its CPUs to aid cooling and moving memory and computational power to peripherals like laptop docks and monitors."

eldavojohn writes "Today a decision was handed down (PDF) from the FTC that underlined new guidelines for Intel in the highly anticipated investigation. Biggest result: the practices Intel employed, like bundling prices to get manufacturers like Dell to block sales of competitors' chips, must stop. No word yet on whether or not Intel will face monetary fines from the FTC like they did in Europe over the same monopolistic practices."

eldavojohn writes "Today a decision was handed down (PDF) from the FTC that underlined new guidelines for Intel in the highly anticipated investigation. Biggest result: the practices Intel employed, like bundling prices to get manufacturers like Dell to block sales of competitors' chips, must stop. No word yet on whether or not Intel will face monetary fines from the FTC like they did in Europe over the same monopolistic practices."

astroengine writes "On Tuesday, the Earth was hit by a coronal mass ejection (CME), triggering a 'moderate' geomagnetic storm, igniting aurorae at high latitudes. The CME in question was launched from the sun early on Sunday and space weather scientists predicted its arrival on Aug. 3 — the vast magnetic bubble of solar plasma arrived on schedule."

longacre writes "Erik Sofge trudges through NASA's latest free video game, which he finds tedious, uninspiring and misguided. Quoting: 'Moonbase Alpha is a demo, of sorts, for NASA's more ambitious upcoming game, Astronaut: Moon, Mars & Beyond, which will feature more destinations, and hopefully less welding. The European Space Agency is developing a similar game, set on the Jovian Moon, Europa. But Moonbase Alpha proves that as a recruiting campaign, or even as an educational tool, the astronaut simulation game is a lost cause. Unless NASA plans to veer into science fiction and populate its virtual moons, asteroids and planets with hostile species, it's hard to imagine why anyone would want to suffer through another minute of pretending to weld power cables back into place, while thousands of miles away, the most advanced explorers ever built are hurtling toward asteroids and dwarf planets and into the heart of the sun. Even if it was possible to build an astronaut game that's both exciting and realistic, why bother? It will be more than a decade before humans even attempt another trip outside of Earth's orbit. If NASA wants to inspire the next generation of astronauts and engineers, its games should focus on the real winners of the space race — the robots.'"

GWMAW writes "NASA Astronauts will conduct a spacewalk on Thursday to repair part of the cooling system of the International Space Station. The cooling system is essential for maintaining the temperature inside the station. There are two 'loops' in the system, one that uses water and draws heat from the inside of the station, and one uses ammonia and dumps the heat into space. Ammonia is used because it freezes at a much lower temperature than water. On Saturday the pump that controls the flow of ammonia through the system shut down."

An anonymous reader writes "Recently, video game developers have begun to make games about current conflicts the world over. Many veterans and current military personnel now take an active role in the video game community. Are game companies running the risk of walking into a public relations disaster when making games about current wars? More importantly, how will veterans react to playing games about a conflict in which they have participated? From the article: 'To portray conflict in a way that not only accurately depicts the acts of war, but does so in a manner that takes into account the sacrifices of soldiers within some sort of moral framing is a complicated matter. Now add to this the idea that such depictions are essentially created as entertainment and to make money. It is certainly mind numbing when looked at from a social perspective. ... Now try and apply this dynamic to a more recent conflict such as the Vietnam War or the current conflicts in both Afghanistan and Iraq. Considering that the latter wars are still in progress, the ability for a game developer to accurately gauge the morality of such a conflict is limited at best. To make a game that takes these factors into account while trying to create something that is both entertaining and capable of mass appeal among the gaming community is near impossible.'" We caught a glimpse of this last year with the reactions to Six Days In Fallujah.

Every few years someone asks this community for advice on oscilloscopes. Reader dawning writes "I've just graduated with a degree in Computer Engineering (and did a Comp Sci one while I was at it) and I'm finding myself woefully under-equipped to do some great hardware projects. I'm in major need of a good oscilloscope. I'm willing to put down $2,000 for a decent one, but there are several options and they all seem so archaic and limited. I'm happy to use something that must be controlled through a PC if that gives me more measuring features. What would you, my esteemed Slashdot colleagues, get for yourself?"

Every few years someone asks this community for advice on oscilloscopes. Reader dawning writes "I've just graduated with a degree in Computer Engineering (and did a Comp Sci one while I was at it) and I'm finding myself woefully under-equipped to do some great hardware projects. I'm in major need of a good oscilloscope. I'm willing to put down $2,000 for a decent one, but there are several options and they all seem so archaic and limited. I'm happy to use something that must be controlled through a PC if that gives me more measuring features. What would you, my esteemed Slashdot colleagues, get for yourself?"

Every few years someone asks this community for advice on oscilloscopes. Reader dawning writes "I've just graduated with a degree in Computer Engineering (and did a Comp Sci one while I was at it) and I'm finding myself woefully under-equipped to do some great hardware projects. I'm in major need of a good oscilloscope. I'm willing to put down $2,000 for a decent one, but there are several options and they all seem so archaic and limited. I'm happy to use something that must be controlled through a PC if that gives me more measuring features. What would you, my esteemed Slashdot colleagues, get for yourself?"

adeelarshad82 writes "Latest reports indicate that the website that 'jailbreaks' iPhones, iPads, and iPod Touches does so by means of a PDF-based vulnerability in OS X. PDF parsing and rendering is a core feature of OS X, and there have been several other vulnerabilities in the past in iOS CoreGraphics PDF components." As Gruber points out, the proper term for this is not "jailbreak," but "remote code exploit in the wild."

An anonymous reader writes "Yesterday we discussed the theory that net neutrality might violate the 5th Amendment's 'takings clause.' Over at TechDirt they've explained why the paper making that claim is mistaken. Part of it is due to a misunderstanding of the technology, such as when the author suggests that someone who puts up a server connected to the Internet is 'invading' a broadband provider's private network. And part of it is due to glossing over the fact that broadband networks all have involved massive government subsidies, in the form of rights of way access, local franchise/monopolies, and/or direct subsidies from governments. The paper pretends, instead, that broadband networks are 100% private."

snydeq writes "The former San Francisco network administrator who refused to hand over passwords for one of the city's networks has been denied a new trial and is expected to be sentenced Aug. 6. Terry Childs had been due for sentencing Friday but the court instead heard two defense motions, one requesting a new trial and the other for arrested judgment — essentially to have his original conviction overturned. The motions were both denied but the court then ran out of time before the sentencing phase could be conducted."

bedmison writes "In an op-ed in the Washington Post titled 'WikiLeaks must be stopped,' Marc A. Thiessen writes that 'WikiLeaks represents a clear and present danger to the national security of the United States,' and that the US has the authority to arrest its spokesman, Julian Assange, even if it has to contravene international law to do so. Thiessen also suggests that the new USCYBERCOM be unleashed to destroy WikiLeaks as an internet presence." Reader praps tips an interview with another WikiLeaks spokesman, Daniel Schmitt, who says they have no regrets about releasing the Afghanistan documents, and says WikiLeaks is "changing the game." Several other readers have pointed out that WikiLeaks posted a mysterious, encrypted "insurance" file on Thursday, which sent the media into a speculative frenzy over what it could possibly contain.

Back in January we discussed Intuit's opposition to California's free, convenient software to file tax returns. TechDirt noticed a recent article in the LA Times about Intuit's continued lobbying efforts to get rid of those programs. Quoting: "Most importantly, Intuit is offering nothing that California doesn't already have. The state has arranged with other tax software providers to do exactly what Intuit proposes: Help low-income folks fill in and file state and federal returns for free — although Intuit refuses to participate. It apparently only wants in on this deal if the state knocks out its free programs, thereby creating a larger potential paying customer base for TurboTax. Not surprisingly, Intuit has been greasing the wheels in order to try to sell its scheme in California. Since 2005, public filings indicate that Intuit has spent $1.25 million on lobbyists in the state. Over the same period, it contributed an additional $2.12 million to statewide campaigns, including more than $1 million to state Sen. Tony Strickland (R-Thousand Oaks), a ReadyReturn foe who is running for state controller. In all, Intuit has doled out cash to nearly 120 politicians. The impact has been clear, even if Intuit hasn't gotten its way — yet. As documented in The Times, in 2009 California Republican legislators held back their votes on 20 bills in an attempt to do the corporation's bidding and force the abolition of ReadyReturn and CalFile. They didn't succeed in killing the tax programs, but they did kill funding for domestic violence shelters, police and fire departments, and prevention of swine flu outbreaks."

eldavojohn writes "Beautiful Data: The Stories Behind Elegant Data Solutions is an addition to six or so other books in the 'Beautiful' series that O'Reilly has put out. It is not a comprehensive guide on data but instead a glimpse into success stories about twenty different projects that succeeded in displaying data — oftentimes in areas where others have failed. While this provides, for the most part, disjointed stories, it is a very readable book compared to most technical books. Beautiful Data proves to be quite the cover-to-cover page turner for anyone involved in building interfaces for data or the statistician at a loss for the best way to intuitively and effectively relay knowledge when given voluminous amounts of raw data. That said, it took me almost two months to make it through this book, as each chapter revealed a data repository or tool I had no idea existed. I felt like a child with an attention deficit disorder trying my hand at nearly everything. While the book isn't designed to relay complete theory on data (like Tufte), it is a great series of short success stories revolving around the entire real world practice of consuming, aggregating, realizing and making beautiful data." Keep reading for the rest of eldavojohn's review. Beautiful Data: The Stories Behind Elegant Data Solutions author Edited by Toby Segaran and Jeff Hammerbacher pages 384 publisher O'Reilly Media, Inc. rating 9/10 reviewer eldavojohn ISBN 978-0-596-15711-1 summary A collection of twenty essays and chronicles from the implementers of successful projects revolving around real world data processing and display. Since the individual articles in this book are essentially a series of what to do and what not to do, this review is more like a list of notes that were my personal rewards from each chapter. Given my background, these notes will be very specified to my interests and responsibilities for web development whereas a statistician, academic or researcher might pull a completely different set from the book. The book also has a nice colorized insert that allows the reader to get a better sense of the interfaces discussed throughout the book. One potential problem with these "case studies" is that they will most certainly become dated — and in our world that happens quite quickly. It's very easy for me to think that specific information about colocation facility usage by social networking sites (Chapter Four) will always be useful and relevant. The sad fact of the matter is that because of the unforeseen nature of hardware advancements and language evolution, many of these stories could become irrelevant blasts from the past in one or two decades. I think the audience that stands to benefit this most from this book are low level managers and people in charge of large amounts of data that they don't know what to do with. The reason for this is that while there are a few chapters that deal with low level implementation details it mostly consists of overviews of popular and successful mentalities surrounding data. One other type of audience that might be a target for this book would be young college students with interests in math, statistics or computer science. Had I picked this book up as a freshman in college, no doubt the number of projects I worked late into the night on would have multiplied as would my understanding of how the real world works.

Chapter One deals with two projects done by grad students: Personal Environmental Impact Report (PEIR) and your.flowingdata (YFD). This chapter starts out slow describing how the system harnesses personal GPS devices — a common trend in phone development these days. After clearing the basics, the chapter reveals a lot about the iterative developments the author took to select and include a map interface to effectively and quickly display several routes that a user has driven with intuitive visual queues to indicate which was the most environmentally expensive. Trying to stick with the green means good and red means bad proved difficult and they employed an inverted map of mostly shades of gray to avoid clashing colors with the natural colors on a regular map. The final part of PEIR discussed a Facebook application that simply paired you up against friends also using PEIR. This gave the user a relative value basis of otherwise incomprehensible numbers surrounding their environmental impact. YFD focuses more on an interface for accumulating Twitter data from a user to help them track sleeping and weight loss.

The second chapter deals entirely with constructing a very simple survey that has a variable length depending on what answer you give to an earlier question. While this seems to be a very simple task, the chapter does a great job of explaining how you can make it better and why doing this makes it better. A great quote from this chapter is "The key method for collecting data from people online is, of course, through the use of the dreaded form. There is no artifact potentially more valuable to a business, or more boring and tedious to a participant." The chapter points out that for every action you require the user to make, the user may decide the survey is not worth their time. Yes, clicking "Next" on a multi-page form only gives the user another chance to decide this isn't worth it. Furthermore, many pages might cause the user to be unsure of the real length of the survey. So they decided against this and instead made the survey branch from one page so that page would continually get a little larger depending on how you answered the questions. Knowing the targets for the surveys were older made a copy large font mandatory as 72% of Americans report vision impairment by the time they are age 45. This chapter dealt more with collecting the data, respecting the source of data and building trust with the participants than displaying the data they provided.

Chapter Three deals with the recently disabled Phoenix that landed on Mars and how precisely the image collection was done. While it might seem like the wrong place to do it, there was actually pre-processing and compression done on board the lander before transmission to Earth. This article tackles interesting issues that are long thought to be an extinct animal in computer science where resources are constrained and radiation bombarding keeps the CPU modestly lower than your average desktop. Do you process the image in place in memory or make a copy so that the original image can be retained during processing? These are familiar issues to embedded developers but stuff I haven't touched since college. While the author details the situation on all fronts down to the cameras being used, it's largely a blast from the past as far as resource aware computing is concerned. Then again, I doubt any of my code will ever be flight certified by NASA.

Chapter Four has a very interesting analysis and description of Yahoo!'s PNUTS system for serving up data in complex environments like tackling issues with latency across the world when dealing with social networking. The chapter does a decent job of explaining how issues are resolved when replicated servers across the United States become out of sync and the resolution strategy. The chapter ends on an even more interesting note explaining why Yahoo! deviated from Google's BigTable, Amazon's Dynamo, Microsoft's Azure and other existing implementations. This tale of well thought out design is a stark contrast to Chapter Five which centers on a Facebook 'data scientist' that — instead of explaining the solution as a well planned finalized implementation — tells the trial and error approach of a very small team of developers treading into waters unknown with data sets of Sisyphean proportions. It was tempting for me to read this chapter and chastise the author for not foreseeing what numbers could come with making it big in social networking. But the chapter has a lot of value in a "lessons learned" realm. It may even prepare some of you who are writing web applications with a potentially explosive or viral user base. While it's popular to hate Facebook and in turn transfer that hate to the developers, no one can argue against them being one of the most successful social networking sites and any information of their (sometimes flawed) operations certainly proves to be interesting.

Chapter Six was completely unengaging for me. The chapter covers geographing. More specifically the efforts to take pictures of Britain and Ireland and map/display them geographically. The images would aim to cover a large area than users could tag them with what they see (tree, road, hill, etc). Unfortunately it never really registered with me why someone would want to do this and what the end goal was that they were aiming for. Instead they managed to produce some pretty heinous and very difficult to digest heat maps or "spatial tree maps." By embedding coloration and lines into the treemaps the authors hoped to convey intuitive information to the reader. Instead my eyes often glazed over and sometimes I flat out disagreed with their affirmation that this is how to display data beautifully. You're welcome to try to convince me that geographing has some sort of merit other than producing pretty mosaics of large image sets but it took a lot of effort for me to continue reading at points in this chapter.

Chapter Seven sets the book back on track in "Data Finds Data" where the writers cover very important concepts and problems surrounding federated search and instead offer up directories with some semantic metadata or relationship data that makes keyword searching possible over billions of documents. For anyone dealing with large volumes of data, this chapter is a great start to understanding the options you have to processing your data when you first get it (and only once) versus searching for that data just in time and paying for it in delay. While the former incurs much more disk space cost, Google has proven that paradigm shift definitely has merit.

Chapter Eight is about social data APIs and pushes gnip heavily as the de facto social endpoint aggregator for programmers. The chapter mentions WebHooks as an up and coming HTTP Post event transmission project but doesn't offer much more than a wake up call for programmers. The traditional polling has dominated web APIs and has lead to fragile points of failure. This chapter is a much needed call for sanity in the insane world of HTTP transactional polling. Unfortunately, the community seems to be so in love with the simplicity of polling that they use it for everything, even when a slightly more complicated eventing model would save them a large percentage of transactions.

Chapter Nine is a tutorial on harvesting data from the deep web. What they mean by this is that — given proper permission — one can exploit forms on websites to access database data and then index that instead of merely being relegated to static HTML pages. In my opinion, this is a fragile and often frowned upon approach to data collection but as this chapter (and many others) illustrates, sometimes data is locked up due to lack of resources to expose it. This means that if a repository of information is meant to be available to you through a simple submission form, you can tease that information out of "the deep web" and into your system with the tricks mentioned in this chapter.

Chapter Ten is the story of Radiohead's open sourced "data" music video of "House of Cards" and the collection process from the kinds of devices used to the methodology of collecting that data to the attitude they used when treating the data. This chapter is a sort of key for understanding what data you have with Radiohead's offerings and I heavily recommend it for anyone interested in taking a stab at this video. The most interesting things I found in this was their method for collection and, more importantly, their decision to actually degrade the data and opted not to texture when displaying Thom Yorke's face — citing artistic choice. This chapter gave me one very amazing display tool that I am embarrassed to admit I had no knowledge of prior to this book: processing.

Chapter Eleven is the story of a few people that chose to do something about serious crime problems in Oakland. The city was compiling reports of crimes weekly but they weren't opening up the data. You could do a search and get a very minimal display on a map of crimes that had happened. This caused Oakland Crimespotting to arise. At first they were forced to graphically scrape and estimate crime locations so their own system could offer it back to the user in more intuitive and useful ways to the citizens so the citizens could take action. At first they were forced to work around problems but in the end the city government came to its senses and began offering them the data in a far more open format. From browsing the site now, you can get an idea of the tale this chapter tells. The evolution of that end product is chronicled in this chapter.

Chapter Twelve center's on sense.us, a potentially powerful product that aims to empower users to analyze and create notations on graphs that might relay correlations between factors inside US Census data. The only disappointment with this chapter is that sense.us isn't live for us to use. The tool shows powerful abilities in collaboration in analysis of census data but also is a double edged sword. There's nothing that stops this tool from being used for political and monetary ideals instead of purely academic revelations. They used tools like Colorbrewer and prefuse to dynamically generate graphs and charts that were pleasing to the eye. Then they used 'geometric annotation' (a vector graphic approach to recording user's doodling and annotations) in order to facilitate collaboration. The notes the researchers took on the collaboration between their pilot users is probably more intriguing than their actual approach to display good graphics. Each user seemed to take a natural progression from annotation producer to annotation crawler and then bounce between them as other user annotations gave them ideas for more annotations to create. While not exactly ideal collaboration, it's interesting to hear what users do in the wild when left to their own.

Chapter Thirteen "What Data Doesn't Do" is a very short chapter with a set of ten or so rules that are intended to remind you that data doesn't predict, more data isn't always better or easier, probabilities do not explain, data doesn't stand alone, etc. This chapter felt sort of like a pause and remember way point through the book. Just when you've gone through these great stories of success, the book, reels you back into reality with this chapter. In other chapters you'll be reminded to avoid pitfalls like the narrative fallacy but this book just reminds you quite literally what data doesn't do automatically for you. It's an indicator that you need to shore up these things that data doesn't magically do when you present data.

Chapter Fourteen is Peter Norvig's "Natural Language Corpus Data" and does not disappoint. Once the reader is empowered with the code and the data in this chapter, it almost seems like one could solve several problems using ngrams, Bayes' theorem and natural language analysis. As you read this chapter, Norvig lays out how to tackle several problems with ease: decoding encryption levels up to WWII, spelling correction, machine translation and even spam detection. In just 23 pages, Norvig conveys a tiny bit of the power of a corpus of documents coupled with the willingness to be a little dirty (total probabilities summing to more than one, dropping ngrams below a threshold, etc). It's clear why he's employed at Google.

Chapter Fifteen takes a drastic turn into one of Earth's oldest data stores: DNA. As the chapter so coyly notes, programmers can view DNA as a simple string: char(3*10^6) human_genome; The chapter gives you a brief glimpse of DNA analysis but focuses more on the data storage involved in facilities that are currently working to harvest data from many subjects. As of the writing of this chapter, one facility was generating 75 terabits per week in raw data. Most interesting to me from this chapter was ensemble.org, a site to find DNA data, genome data and also collaborate with other researchers on annotating and commenting on certain parts and regions of DNA.

Similar to the previous chapter, Chapter Sixteen focuses briefly on chemistry and describes how data was collected "to predict teh solubility of a wide range of chemicals in non-aqueous solvents such as ethanol, methanol, etc." Having a very minimal chemistry background, it's never really revealed what purpose this data collection has but nonetheless the chapter explains a lot of challenges in this environment that are similar to other chapters. The interesting aspect of this chapter is that the team used open notebook science to collect this data and therefore faced the challenge of cleaning crowd-sourced data. A constantly recurring problem in these chapters is how one represents data and chemistry apparently has many standards — some more open than others. This book makes a very good argument for open standards and selecting open standards when one witnesses the screen scraping, licensing issues and costs researchers face when unifying data even for something as old as the representations of chemicals.

Chapter Seventeen is the case study of FaceStat, a statistically more ambitious Hot-or-Not effort from researchers. The site would allow anyone to upload a photo of a person and then allow users to rate them and tag them. After collecting this data, the researchers used the ubiquitous R statistical language to do some feature extraction on the data. Of course, the chapter first deals with cleaning the data and catching bad user input. While this chapter sounds like vanilla run-of-the-mill feature extraction, it also includes some interesting display examples as well as the very interesting yet controversial stereotype analysis. From taboo topics like attractiveness vs age line fitting to the sexism of tags to using k-means in order to establish stereotype clusters in the data. While other chapters sought offense through possible privacy concerns, this chapter reveals more about the callow stereotypes that internet inflict upon each other.

Chapter Eighteen looks at the San Fransisco Bay Area housing market from a very interesting selection of recent years. What differentiates this chapter from so many of the others (we collect, clean and process the data) is that it needed to break the data down by neighborhood to find the really interesting features of the data. The neighborhoods could then be grouped into six different groups with their increase in house prices to their decline in house prices. Only one group had one neighborhood that showed no decline (Mountain View). Unfortunately for this chapter and the next one, by the time the reader arrives they appear to be straight forward replications of ideas from other chapters. Chapter Nineteen is brief chapter on statistics inside politics. Aside from revealing five or six interesting correlations in voting revealed through data, this chapter merely relays what we already know: politicians implement statistics to a sometimes harmful degree (gerrymandering).

The last chapter is, appropriately, about the many sources of data exposed on the internet and the problems everyone faces in matching entities from one data source to another. The idea of using a URI to describe a movie hasn't really seemed to catch on. And if that wasn't enough, even words like "location" used to describe a column could mean drastically different things between houses and genomes. The chapter lists out a number of sources where data is available to download and tinker with (most already listed in the book) and proceeds to analyze an algorithmic (collective reconciliation) way for a system to differentiate between two movies with the same name. Naturally the author of this chapter worked on freebase which was recently (and predictably) acquired by Google. Although a short chapter, it speaks to problems that all online data communities face and what prohibits mashups from automagically happening between two disparate data sources holding data that is actually related.

With the exception of chapter six, every chapter offered me something that I won't forget. More importantly, most chapters offered a data source or data processing tool that expanded my toolbox of things to use when programming. The only reason this book misses a perfect 10/10 from me is chapter six and a couple of the later chapters feeling like weaker ideas from earlier chapters rehashed into a different domain. A worthwhile book if you work with data — whether you be a consumer or producer.

You can purchase Beautiful Data: The Stories Behind Elegant Data Solutions from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

eldavojohn writes "Beautiful Data: The Stories Behind Elegant Data Solutions is an addition to six or so other books in the 'Beautiful' series that O'Reilly has put out. It is not a comprehensive guide on data but instead a glimpse into success stories about twenty different projects that succeeded in displaying data — oftentimes in areas where others have failed. While this provides, for the most part, disjointed stories, it is a very readable book compared to most technical books. Beautiful Data proves to be quite the cover-to-cover page turner for anyone involved in building interfaces for data or the statistician at a loss for the best way to intuitively and effectively relay knowledge when given voluminous amounts of raw data. That said, it took me almost two months to make it through this book, as each chapter revealed a data repository or tool I had no idea existed. I felt like a child with an attention deficit disorder trying my hand at nearly everything. While the book isn't designed to relay complete theory on data (like Tufte), it is a great series of short success stories revolving around the entire real world practice of consuming, aggregating, realizing and making beautiful data." Keep reading for the rest of eldavojohn's review. Beautiful Data: The Stories Behind Elegant Data Solutions author Edited by Toby Segaran and Jeff Hammerbacher pages 384 publisher O'Reilly Media, Inc. rating 9/10 reviewer eldavojohn ISBN 978-0-596-15711-1 summary A collection of twenty essays and chronicles from the implementers of successful projects revolving around real world data processing and display. Since the individual articles in this book are essentially a series of what to do and what not to do, this review is more like a list of notes that were my personal rewards from each chapter. Given my background, these notes will be very specified to my interests and responsibilities for web development whereas a statistician, academic or researcher might pull a completely different set from the book. The book also has a nice colorized insert that allows the reader to get a better sense of the interfaces discussed throughout the book. One potential problem with these "case studies" is that they will most certainly become dated — and in our world that happens quite quickly. It's very easy for me to think that specific information about colocation facility usage by social networking sites (Chapter Four) will always be useful and relevant. The sad fact of the matter is that because of the unforeseen nature of hardware advancements and language evolution, many of these stories could become irrelevant blasts from the past in one or two decades. I think the audience that stands to benefit this most from this book are low level managers and people in charge of large amounts of data that they don't know what to do with. The reason for this is that while there are a few chapters that deal with low level implementation details it mostly consists of overviews of popular and successful mentalities surrounding data. One other type of audience that might be a target for this book would be young college students with interests in math, statistics or computer science. Had I picked this book up as a freshman in college, no doubt the number of projects I worked late into the night on would have multiplied as would my understanding of how the real world works.

Chapter One deals with two projects done by grad students: Personal Environmental Impact Report (PEIR) and your.flowingdata (YFD). This chapter starts out slow describing how the system harnesses personal GPS devices — a common trend in phone development these days. After clearing the basics, the chapter reveals a lot about the iterative developments the author took to select and include a map interface to effectively and quickly display several routes that a user has driven with intuitive visual queues to indicate which was the most environmentally expensive. Trying to stick with the green means good and red means bad proved difficult and they employed an inverted map of mostly shades of gray to avoid clashing colors with the natural colors on a regular map. The final part of PEIR discussed a Facebook application that simply paired you up against friends also using PEIR. This gave the user a relative value basis of otherwise incomprehensible numbers surrounding their environmental impact. YFD focuses more on an interface for accumulating Twitter data from a user to help them track sleeping and weight loss.

The second chapter deals entirely with constructing a very simple survey that has a variable length depending on what answer you give to an earlier question. While this seems to be a very simple task, the chapter does a great job of explaining how you can make it better and why doing this makes it better. A great quote from this chapter is "The key method for collecting data from people online is, of course, through the use of the dreaded form. There is no artifact potentially more valuable to a business, or more boring and tedious to a participant." The chapter points out that for every action you require the user to make, the user may decide the survey is not worth their time. Yes, clicking "Next" on a multi-page form only gives the user another chance to decide this isn't worth it. Furthermore, many pages might cause the user to be unsure of the real length of the survey. So they decided against this and instead made the survey branch from one page so that page would continually get a little larger depending on how you answered the questions. Knowing the targets for the surveys were older made a copy large font mandatory as 72% of Americans report vision impairment by the time they are age 45. This chapter dealt more with collecting the data, respecting the source of data and building trust with the participants than displaying the data they provided.

Chapter Three deals with the recently disabled Phoenix that landed on Mars and how precisely the image collection was done. While it might seem like the wrong place to do it, there was actually pre-processing and compression done on board the lander before transmission to Earth. This article tackles interesting issues that are long thought to be an extinct animal in computer science where resources are constrained and radiation bombarding keeps the CPU modestly lower than your average desktop. Do you process the image in place in memory or make a copy so that the original image can be retained during processing? These are familiar issues to embedded developers but stuff I haven't touched since college. While the author details the situation on all fronts down to the cameras being used, it's largely a blast from the past as far as resource aware computing is concerned. Then again, I doubt any of my code will ever be flight certified by NASA.

Chapter Four has a very interesting analysis and description of Yahoo!'s PNUTS system for serving up data in complex environments like tackling issues with latency across the world when dealing with social networking. The chapter does a decent job of explaining how issues are resolved when replicated servers across the United States become out of sync and the resolution strategy. The chapter ends on an even more interesting note explaining why Yahoo! deviated from Google's BigTable, Amazon's Dynamo, Microsoft's Azure and other existing implementations. This tale of well thought out design is a stark contrast to Chapter Five which centers on a Facebook 'data scientist' that — instead of explaining the solution as a well planned finalized implementation — tells the trial and error approach of a very small team of developers treading into waters unknown with data sets of Sisyphean proportions. It was tempting for me to read this chapter and chastise the author for not foreseeing what numbers could come with making it big in social networking. But the chapter has a lot of value in a "lessons learned" realm. It may even prepare some of you who are writing web applications with a potentially explosive or viral user base. While it's popular to hate Facebook and in turn transfer that hate to the developers, no one can argue against them being one of the most successful social networking sites and any information of their (sometimes flawed) operations certainly proves to be interesting.

Chapter Six was completely unengaging for me. The chapter covers geographing. More specifically the efforts to take pictures of Britain and Ireland and map/display them geographically. The images would aim to cover a large area than users could tag them with what they see (tree, road, hill, etc). Unfortunately it never really registered with me why someone would want to do this and what the end goal was that they were aiming for. Instead they managed to produce some pretty heinous and very difficult to digest heat maps or "spatial tree maps." By embedding coloration and lines into the treemaps the authors hoped to convey intuitive information to the reader. Instead my eyes often glazed over and sometimes I flat out disagreed with their affirmation that this is how to display data beautifully. You're welcome to try to convince me that geographing has some sort of merit other than producing pretty mosaics of large image sets but it took a lot of effort for me to continue reading at points in this chapter.

Chapter Seven sets the book back on track in "Data Finds Data" where the writers cover very important concepts and problems surrounding federated search and instead offer up directories with some semantic metadata or relationship data that makes keyword searching possible over billions of documents. For anyone dealing with large volumes of data, this chapter is a great start to understanding the options you have to processing your data when you first get it (and only once) versus searching for that data just in time and paying for it in delay. While the former incurs much more disk space cost, Google has proven that paradigm shift definitely has merit.

Chapter Eight is about social data APIs and pushes gnip heavily as the de facto social endpoint aggregator for programmers. The chapter mentions WebHooks as an up and coming HTTP Post event transmission project but doesn't offer much more than a wake up call for programmers. The traditional polling has dominated web APIs and has lead to fragile points of failure. This chapter is a much needed call for sanity in the insane world of HTTP transactional polling. Unfortunately, the community seems to be so in love with the simplicity of polling that they use it for everything, even when a slightly more complicated eventing model would save them a large percentage of transactions.

Chapter Nine is a tutorial on harvesting data from the deep web. What they mean by this is that — given proper permission — one can exploit forms on websites to access database data and then index that instead of merely being relegated to static HTML pages. In my opinion, this is a fragile and often frowned upon approach to data collection but as this chapter (and many others) illustrates, sometimes data is locked up due to lack of resources to expose it. This means that if a repository of information is meant to be available to you through a simple submission form, you can tease that information out of "the deep web" and into your system with the tricks mentioned in this chapter.

Chapter Ten is the story of Radiohead's open sourced "data" music video of "House of Cards" and the collection process from the kinds of devices used to the methodology of collecting that data to the attitude they used when treating the data. This chapter is a sort of key for understanding what data you have with Radiohead's offerings and I heavily recommend it for anyone interested in taking a stab at this video. The most interesting things I found in this was their method for collection and, more importantly, their decision to actually degrade the data and opted not to texture when displaying Thom Yorke's face — citing artistic choice. This chapter gave me one very amazing display tool that I am embarrassed to admit I had no knowledge of prior to this book: processing.

Chapter Eleven is the story of a few people that chose to do something about serious crime problems in Oakland. The city was compiling reports of crimes weekly but they weren't opening up the data. You could do a search and get a very minimal display on a map of crimes that had happened. This caused Oakland Crimespotting to arise. At first they were forced to graphically scrape and estimate crime locations so their own system could offer it back to the user in more intuitive and useful ways to the citizens so the citizens could take action. At first they were forced to work around problems but in the end the city government came to its senses and began offering them the data in a far more open format. From browsing the site now, you can get an idea of the tale this chapter tells. The evolution of that end product is chronicled in this chapter.

Chapter Twelve center's on sense.us, a potentially powerful product that aims to empower users to analyze and create notations on graphs that might relay correlations between factors inside US Census data. The only disappointment with this chapter is that sense.us isn't live for us to use. The tool shows powerful abilities in collaboration in analysis of census data but also is a double edged sword. There's nothing that stops this tool from being used for political and monetary ideals instead of purely academic revelations. They used tools like Colorbrewer and prefuse to dynamically generate graphs and charts that were pleasing to the eye. Then they used 'geometric annotation' (a vector graphic approach to recording user's doodling and annotations) in order to facilitate collaboration. The notes the researchers took on the collaboration between their pilot users is probably more intriguing than their actual approach to display good graphics. Each user seemed to take a natural progression from annotation producer to annotation crawler and then bounce between them as other user annotations gave them ideas for more annotations to create. While not exactly ideal collaboration, it's interesting to hear what users do in the wild when left to their own.

Chapter Thirteen "What Data Doesn't Do" is a very short chapter with a set of ten or so rules that are intended to remind you that data doesn't predict, more data isn't always better or easier, probabilities do not explain, data doesn't stand alone, etc. This chapter felt sort of like a pause and remember way point through the book. Just when you've gone through these great stories of success, the book, reels you back into reality with this chapter. In other chapters you'll be reminded to avoid pitfalls like the narrative fallacy but this book just reminds you quite literally what data doesn't do automatically for you. It's an indicator that you need to shore up these things that data doesn't magically do when you present data.

Chapter Fourteen is Peter Norvig's "Natural Language Corpus Data" and does not disappoint. Once the reader is empowered with the code and the data in this chapter, it almost seems like one could solve several problems using ngrams, Bayes' theorem and natural language analysis. As you read this chapter, Norvig lays out how to tackle several problems with ease: decoding encryption levels up to WWII, spelling correction, machine translation and even spam detection. In just 23 pages, Norvig conveys a tiny bit of the power of a corpus of documents coupled with the willingness to be a little dirty (total probabilities summing to more than one, dropping ngrams below a threshold, etc). It's clear why he's employed at Google.

Chapter Fifteen takes a drastic turn into one of Earth's oldest data stores: DNA. As the chapter so coyly notes, programmers can view DNA as a simple string: char(3*10^6) human_genome; The chapter gives you a brief glimpse of DNA analysis but focuses more on the data storage involved in facilities that are currently working to harvest data from many subjects. As of the writing of this chapter, one facility was generating 75 terabits per week in raw data. Most interesting to me from this chapter was ensemble.org, a site to find DNA data, genome data and also collaborate with other researchers on annotating and commenting on certain parts and regions of DNA.

Similar to the previous chapter, Chapter Sixteen focuses briefly on chemistry and describes how data was collected "to predict teh solubility of a wide range of chemicals in non-aqueous solvents such as ethanol, methanol, etc." Having a very minimal chemistry background, it's never really revealed what purpose this data collection has but nonetheless the chapter explains a lot of challenges in this environment that are similar to other chapters. The interesting aspect of this chapter is that the team used open notebook science to collect this data and therefore faced the challenge of cleaning crowd-sourced data. A constantly recurring problem in these chapters is how one represents data and chemistry apparently has many standards — some more open than others. This book makes a very good argument for open standards and selecting open standards when one witnesses the screen scraping, licensing issues and costs researchers face when unifying data even for something as old as the representations of chemicals.

Chapter Seventeen is the case study of FaceStat, a statistically more ambitious Hot-or-Not effort from researchers. The site would allow anyone to upload a photo of a person and then allow users to rate them and tag them. After collecting this data, the researchers used the ubiquitous R statistical language to do some feature extraction on the data. Of course, the chapter first deals with cleaning the data and catching bad user input. While this chapter sounds like vanilla run-of-the-mill feature extraction, it also includes some interesting display examples as well as the very interesting yet controversial stereotype analysis. From taboo topics like attractiveness vs age line fitting to the sexism of tags to using k-means in order to establish stereotype clusters in the data. While other chapters sought offense through possible privacy concerns, this chapter reveals more about the callow stereotypes that internet inflict upon each other.

Chapter Eighteen looks at the San Fransisco Bay Area housing market from a very interesting selection of recent years. What differentiates this chapter from so many of the others (we collect, clean and process the data) is that it needed to break the data down by neighborhood to find the really interesting features of the data. The neighborhoods could then be grouped into six different groups with their increase in house prices to their decline in house prices. Only one group had one neighborhood that showed no decline (Mountain View). Unfortunately for this chapter and the next one, by the time the reader arrives they appear to be straight forward replications of ideas from other chapters. Chapter Nineteen is brief chapter on statistics inside politics. Aside from revealing five or six interesting correlations in voting revealed through data, this chapter merely relays what we already know: politicians implement statistics to a sometimes harmful degree (gerrymandering).

The last chapter is, appropriately, about the many sources of data exposed on the internet and the problems everyone faces in matching entities from one data source to another. The idea of using a URI to describe a movie hasn't really seemed to catch on. And if that wasn't enough, even words like "location" used to describe a column could mean drastically different things between houses and genomes. The chapter lists out a number of sources where data is available to download and tinker with (most already listed in the book) and proceeds to analyze an algorithmic (collective reconciliation) way for a system to differentiate between two movies with the same name. Naturally the author of this chapter worked on freebase which was recently (and predictably) acquired by Google. Although a short chapter, it speaks to problems that all online data communities face and what prohibits mashups from automagically happening between two disparate data sources holding data that is actually related.

With the exception of chapter six, every chapter offered me something that I won't forget. More importantly, most chapters offered a data source or data processing tool that expanded my toolbox of things to use when programming. The only reason this book misses a perfect 10/10 from me is chapter six and a couple of the later chapters feeling like weaker ideas from earlier chapters rehashed into a different domain. A worthwhile book if you work with data — whether you be a consumer or producer.

You can purchase Beautiful Data: The Stories Behind Elegant Data Solutions from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

eldavojohn writes "Beautiful Data: The Stories Behind Elegant Data Solutions is an addition to six or so other books in the 'Beautiful' series that O'Reilly has put out. It is not a comprehensive guide on data but instead a glimpse into success stories about twenty different projects that succeeded in displaying data — oftentimes in areas where others have failed. While this provides, for the most part, disjointed stories, it is a very readable book compared to most technical books. Beautiful Data proves to be quite the cover-to-cover page turner for anyone involved in building interfaces for data or the statistician at a loss for the best way to intuitively and effectively relay knowledge when given voluminous amounts of raw data. That said, it took me almost two months to make it through this book, as each chapter revealed a data repository or tool I had no idea existed. I felt like a child with an attention deficit disorder trying my hand at nearly everything. While the book isn't designed to relay complete theory on data (like Tufte), it is a great series of short success stories revolving around the entire real world practice of consuming, aggregating, realizing and making beautiful data." Keep reading for the rest of eldavojohn's review. Beautiful Data: The Stories Behind Elegant Data Solutions author Edited by Toby Segaran and Jeff Hammerbacher pages 384 publisher O'Reilly Media, Inc. rating 9/10 reviewer eldavojohn ISBN 978-0-596-15711-1 summary A collection of twenty essays and chronicles from the implementers of successful projects revolving around real world data processing and display. Since the individual articles in this book are essentially a series of what to do and what not to do, this review is more like a list of notes that were my personal rewards from each chapter. Given my background, these notes will be very specified to my interests and responsibilities for web development whereas a statistician, academic or researcher might pull a completely different set from the book. The book also has a nice colorized insert that allows the reader to get a better sense of the interfaces discussed throughout the book. One potential problem with these "case studies" is that they will most certainly become dated — and in our world that happens quite quickly. It's very easy for me to think that specific information about colocation facility usage by social networking sites (Chapter Four) will always be useful and relevant. The sad fact of the matter is that because of the unforeseen nature of hardware advancements and language evolution, many of these stories could become irrelevant blasts from the past in one or two decades. I think the audience that stands to benefit this most from this book are low level managers and people in charge of large amounts of data that they don't know what to do with. The reason for this is that while there are a few chapters that deal with low level implementation details it mostly consists of overviews of popular and successful mentalities surrounding data. One other type of audience that might be a target for this book would be young college students with interests in math, statistics or computer science. Had I picked this book up as a freshman in college, no doubt the number of projects I worked late into the night on would have multiplied as would my understanding of how the real world works.

Chapter One deals with two projects done by grad students: Personal Environmental Impact Report (PEIR) and your.flowingdata (YFD). This chapter starts out slow describing how the system harnesses personal GPS devices — a common trend in phone development these days. After clearing the basics, the chapter reveals a lot about the iterative developments the author took to select and include a map interface to effectively and quickly display several routes that a user has driven with intuitive visual queues to indicate which was the most environmentally expensive. Trying to stick with the green means good and red means bad proved difficult and they employed an inverted map of mostly shades of gray to avoid clashing colors with the natural colors on a regular map. The final part of PEIR discussed a Facebook application that simply paired you up against friends also using PEIR. This gave the user a relative value basis of otherwise incomprehensible numbers surrounding their environmental impact. YFD focuses more on an interface for accumulating Twitter data from a user to help them track sleeping and weight loss.

The second chapter deals entirely with constructing a very simple survey that has a variable length depending on what answer you give to an earlier question. While this seems to be a very simple task, the chapter does a great job of explaining how you can make it better and why doing this makes it better. A great quote from this chapter is "The key method for collecting data from people online is, of course, through the use of the dreaded form. There is no artifact potentially more valuable to a business, or more boring and tedious to a participant." The chapter points out that for every action you require the user to make, the user may decide the survey is not worth their time. Yes, clicking "Next" on a multi-page form only gives the user another chance to decide this isn't worth it. Furthermore, many pages might cause the user to be unsure of the real length of the survey. So they decided against this and instead made the survey branch from one page so that page would continually get a little larger depending on how you answered the questions. Knowing the targets for the surveys were older made a copy large font mandatory as 72% of Americans report vision impairment by the time they are age 45. This chapter dealt more with collecting the data, respecting the source of data and building trust with the participants than displaying the data they provided.

Chapter Three deals with the recently disabled Phoenix that landed on Mars and how precisely the image collection was done. While it might seem like the wrong place to do it, there was actually pre-processing and compression done on board the lander before transmission to Earth. This article tackles interesting issues that are long thought to be an extinct animal in computer science where resources are constrained and radiation bombarding keeps the CPU modestly lower than your average desktop. Do you process the image in place in memory or make a copy so that the original image can be retained during processing? These are familiar issues to embedded developers but stuff I haven't touched since college. While the author details the situation on all fronts down to the cameras being used, it's largely a blast from the past as far as resource aware computing is concerned. Then again, I doubt any of my code will ever be flight certified by NASA.

Chapter Four has a very interesting analysis and description of Yahoo!'s PNUTS system for serving up data in complex environments like tackling issues with latency across the world when dealing with social networking. The chapter does a decent job of explaining how issues are resolved when replicated servers across the United States become out of sync and the resolution strategy. The chapter ends on an even more interesting note explaining why Yahoo! deviated from Google's BigTable, Amazon's Dynamo, Microsoft's Azure and other existing implementations. This tale of well thought out design is a stark contrast to Chapter Five which centers on a Facebook 'data scientist' that — instead of explaining the solution as a well planned finalized implementation — tells the trial and error approach of a very small team of developers treading into waters unknown with data sets of Sisyphean proportions. It was tempting for me to read this chapter and chastise the author for not foreseeing what numbers could come with making it big in social networking. But the chapter has a lot of value in a "lessons learned" realm. It may even prepare some of you who are writing web applications with a potentially explosive or viral user base. While it's popular to hate Facebook and in turn transfer that hate to the developers, no one can argue against them being one of the most successful social networking sites and any information of their (sometimes flawed) operations certainly proves to be interesting.

Chapter Six was completely unengaging for me. The chapter covers geographing. More specifically the efforts to take pictures of Britain and Ireland and map/display them geographically. The images would aim to cover a large area than users could tag them with what they see (tree, road, hill, etc). Unfortunately it never really registered with me why someone would want to do this and what the end goal was that they were aiming for. Instead they managed to produce some pretty heinous and very difficult to digest heat maps or "spatial tree maps." By embedding coloration and lines into the treemaps the authors hoped to convey intuitive information to the reader. Instead my eyes often glazed over and sometimes I flat out disagreed with their affirmation that this is how to display data beautifully. You're welcome to try to convince me that geographing has some sort of merit other than producing pretty mosaics of large image sets but it took a lot of effort for me to continue reading at points in this chapter.

Chapter Seven sets the book back on track in "Data Finds Data" where the writers cover very important concepts and problems surrounding federated search and instead offer up directories with some semantic metadata or relationship data that makes keyword searching possible over billions of documents. For anyone dealing with large volumes of data, this chapter is a great start to understanding the options you have to processing your data when you first get it (and only once) versus searching for that data just in time and paying for it in delay. While the former incurs much more disk space cost, Google has proven that paradigm shift definitely has merit.

Chapter Eight is about social data APIs and pushes gnip heavily as the de facto social endpoint aggregator for programmers. The chapter mentions WebHooks as an up and coming HTTP Post event transmission project but doesn't offer much more than a wake up call for programmers. The traditional polling has dominated web APIs and has lead to fragile points of failure. This chapter is a much needed call for sanity in the insane world of HTTP transactional polling. Unfortunately, the community seems to be so in love with the simplicity of polling that they use it for everything, even when a slightly more complicated eventing model would save them a large percentage of transactions.

Chapter Nine is a tutorial on harvesting data from the deep web. What they mean by this is that — given proper permission — one can exploit forms on websites to access database data and then index that instead of merely being relegated to static HTML pages. In my opinion, this is a fragile and often frowned upon approach to data collection but as this chapter (and many others) illustrates, sometimes data is locked up due to lack of resources to expose it. This means that if a repository of information is meant to be available to you through a simple submission form, you can tease that information out of "the deep web" and into your system with the tricks mentioned in this chapter.

Chapter Ten is the story of Radiohead's open sourced "data" music video of "House of Cards" and the collection process from the kinds of devices used to the methodology of collecting that data to the attitude they used when treating the data. This chapter is a sort of key for understanding what data you have with Radiohead's offerings and I heavily recommend it for anyone interested in taking a stab at this video. The most interesting things I found in this was their method for collection and, more importantly, their decision to actually degrade the data and opted not to texture when displaying Thom Yorke's face — citing artistic choice. This chapter gave me one very amazing display tool that I am embarrassed to admit I had no knowledge of prior to this book: processing.

Chapter Eleven is the story of a few people that chose to do something about serious crime problems in Oakland. The city was compiling reports of crimes weekly but they weren't opening up the data. You could do a search and get a very minimal display on a map of crimes that had happened. This caused Oakland Crimespotting to arise. At first they were forced to graphically scrape and estimate crime locations so their own system could offer it back to the user in more intuitive and useful ways to the citizens so the citizens could take action. At first they were forced to work around problems but in the end the city government came to its senses and began offering them the data in a far more open format. From browsing the site now, you can get an idea of the tale this chapter tells. The evolution of that end product is chronicled in this chapter.

Chapter Twelve center's on sense.us, a potentially powerful product that aims to empower users to analyze and create notations on graphs that might relay correlations between factors inside US Census data. The only disappointment with this chapter is that sense.us isn't live for us to use. The tool shows powerful abilities in collaboration in analysis of census data but also is a double edged sword. There's nothing that stops this tool from being used for political and monetary ideals instead of purely academic revelations. They used tools like Colorbrewer and prefuse to dynamically generate graphs and charts that were pleasing to the eye. Then they used 'geometric annotation' (a vector graphic approach to recording user's doodling and annotations) in order to facilitate collaboration. The notes the researchers took on the collaboration between their pilot users is probably more intriguing than their actual approach to display good graphics. Each user seemed to take a natural progression from annotation producer to annotation crawler and then bounce between them as other user annotations gave them ideas for more annotations to create. While not exactly ideal collaboration, it's interesting to hear what users do in the wild when left to their own.

Chapter Thirteen "What Data Doesn't Do" is a very short chapter with a set of ten or so rules that are intended to remind you that data doesn't predict, more data isn't always better or easier, probabilities do not explain, data doesn't stand alone, etc. This chapter felt sort of like a pause and remember way point through the book. Just when you've gone through these great stories of success, the book, reels you back into reality with this chapter. In other chapters you'll be reminded to avoid pitfalls like the narrative fallacy but this book just reminds you quite literally what data doesn't do automatically for you. It's an indicator that you need to shore up these things that data doesn't magically do when you present data.

Chapter Fourteen is Peter Norvig's "Natural Language Corpus Data" and does not disappoint. Once the reader is empowered with the code and the data in this chapter, it almost seems like one could solve several problems using ngrams, Bayes' theorem and natural language analysis. As you read this chapter, Norvig lays out how to tackle several problems with ease: decoding encryption levels up to WWII, spelling correction, machine translation and even spam detection. In just 23 pages, Norvig conveys a tiny bit of the power of a corpus of documents coupled with the willingness to be a little dirty (total probabilities summing to more than one, dropping ngrams below a threshold, etc). It's clear why he's employed at Google.

Chapter Fifteen takes a drastic turn into one of Earth's oldest data stores: DNA. As the chapter so coyly notes, programmers can view DNA as a simple string: char(3*10^6) human_genome; The chapter gives you a brief glimpse of DNA analysis but focuses more on the data storage involved in facilities that are currently working to harvest data from many subjects. As of the writing of this chapter, one facility was generating 75 terabits per week in raw data. Most interesting to me from this chapter was ensemble.org, a site to find DNA data, genome data and also collaborate with other researchers on annotating and commenting on certain parts and regions of DNA.

Similar to the previous chapter, Chapter Sixteen focuses briefly on chemistry and describes how data was collected "to predict teh solubility of a wide range of chemicals in non-aqueous solvents such as ethanol, methanol, etc." Having a very minimal chemistry background, it's never really revealed what purpose this data collection has but nonetheless the chapter explains a lot of challenges in this environment that are similar to other chapters. The interesting aspect of this chapter is that the team used open notebook science to collect this data and therefore faced the challenge of cleaning crowd-sourced data. A constantly recurring problem in these chapters is how one represents data and chemistry apparently has many standards — some more open than others. This book makes a very good argument for open standards and selecting open standards when one witnesses the screen scraping, licensing issues and costs researchers face when unifying data even for something as old as the representations of chemicals.

Chapter Seventeen is the case study of FaceStat, a statistically more ambitious Hot-or-Not effort from researchers. The site would allow anyone to upload a photo of a person and then allow users to rate them and tag them. After collecting this data, the researchers used the ubiquitous R statistical language to do some feature extraction on the data. Of course, the chapter first deals with cleaning the data and catching bad user input. While this chapter sounds like vanilla run-of-the-mill feature extraction, it also includes some interesting display examples as well as the very interesting yet controversial stereotype analysis. From taboo topics like attractiveness vs age line fitting to the sexism of tags to using k-means in order to establish stereotype clusters in the data. While other chapters sought offense through possible privacy concerns, this chapter reveals more about the callow stereotypes that internet inflict upon each other.

Chapter Eighteen looks at the San Fransisco Bay Area housing market from a very interesting selection of recent years. What differentiates this chapter from so many of the others (we collect, clean and process the data) is that it needed to break the data down by neighborhood to find the really interesting features of the data. The neighborhoods could then be grouped into six different groups with their increase in house prices to their decline in house prices. Only one group had one neighborhood that showed no decline (Mountain View). Unfortunately for this chapter and the next one, by the time the reader arrives they appear to be straight forward replications of ideas from other chapters. Chapter Nineteen is brief chapter on statistics inside politics. Aside from revealing five or six interesting correlations in voting revealed through data, this chapter merely relays what we already know: politicians implement statistics to a sometimes harmful degree (gerrymandering).

The last chapter is, appropriately, about the many sources of data exposed on the internet and the problems everyone faces in matching entities from one data source to another. The idea of using a URI to describe a movie hasn't really seemed to catch on. And if that wasn't enough, even words like "location" used to describe a column could mean drastically different things between houses and genomes. The chapter lists out a number of sources where data is available to download and tinker with (most already listed in the book) and proceeds to analyze an algorithmic (collective reconciliation) way for a system to differentiate between two movies with the same name. Naturally the author of this chapter worked on freebase which was recently (and predictably) acquired by Google. Although a short chapter, it speaks to problems that all online data communities face and what prohibits mashups from automagically happening between two disparate data sources holding data that is actually related.

With the exception of chapter six, every chapter offered me something that I won't forget. More importantly, most chapters offered a data source or data processing tool that expanded my toolbox of things to use when programming. The only reason this book misses a perfect 10/10 from me is chapter six and a couple of the later chapters feeling like weaker ideas from earlier chapters rehashed into a different domain. A worthwhile book if you work with data — whether you be a consumer or producer.

You can purchase Beautiful Data: The Stories Behind Elegant Data Solutions from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

eldavojohn writes "Beautiful Data: The Stories Behind Elegant Data Solutions is an addition to six or so other books in the 'Beautiful' series that O'Reilly has put out. It is not a comprehensive guide on data but instead a glimpse into success stories about twenty different projects that succeeded in displaying data — oftentimes in areas where others have failed. While this provides, for the most part, disjointed stories, it is a very readable book compared to most technical books. Beautiful Data proves to be quite the cover-to-cover page turner for anyone involved in building interfaces for data or the statistician at a loss for the best way to intuitively and effectively relay knowledge when given voluminous amounts of raw data. That said, it took me almost two months to make it through this book, as each chapter revealed a data repository or tool I had no idea existed. I felt like a child with an attention deficit disorder trying my hand at nearly everything. While the book isn't designed to relay complete theory on data (like Tufte), it is a great series of short success stories revolving around the entire real world practice of consuming, aggregating, realizing and making beautiful data." Keep reading for the rest of eldavojohn's review. Beautiful Data: The Stories Behind Elegant Data Solutions author Edited by Toby Segaran and Jeff Hammerbacher pages 384 publisher O'Reilly Media, Inc. rating 9/10 reviewer eldavojohn ISBN 978-0-596-15711-1 summary A collection of twenty essays and chronicles from the implementers of successful projects revolving around real world data processing and display. Since the individual articles in this book are essentially a series of what to do and what not to do, this review is more like a list of notes that were my personal rewards from each chapter. Given my background, these notes will be very specified to my interests and responsibilities for web development whereas a statistician, academic or researcher might pull a completely different set from the book. The book also has a nice colorized insert that allows the reader to get a better sense of the interfaces discussed throughout the book. One potential problem with these "case studies" is that they will most certainly become dated — and in our world that happens quite quickly. It's very easy for me to think that specific information about colocation facility usage by social networking sites (Chapter Four) will always be useful and relevant. The sad fact of the matter is that because of the unforeseen nature of hardware advancements and language evolution, many of these stories could become irrelevant blasts from the past in one or two decades. I think the audience that stands to benefit this most from this book are low level managers and people in charge of large amounts of data that they don't know what to do with. The reason for this is that while there are a few chapters that deal with low level implementation details it mostly consists of overviews of popular and successful mentalities surrounding data. One other type of audience that might be a target for this book would be young college students with interests in math, statistics or computer science. Had I picked this book up as a freshman in college, no doubt the number of projects I worked late into the night on would have multiplied as would my understanding of how the real world works.

Chapter One deals with two projects done by grad students: Personal Environmental Impact Report (PEIR) and your.flowingdata (YFD). This chapter starts out slow describing how the system harnesses personal GPS devices — a common trend in phone development these days. After clearing the basics, the chapter reveals a lot about the iterative developments the author took to select and include a map interface to effectively and quickly display several routes that a user has driven with intuitive visual queues to indicate which was the most environmentally expensive. Trying to stick with the green means good and red means bad proved difficult and they employed an inverted map of mostly shades of gray to avoid clashing colors with the natural colors on a regular map. The final part of PEIR discussed a Facebook application that simply paired you up against friends also using PEIR. This gave the user a relative value basis of otherwise incomprehensible numbers surrounding their environmental impact. YFD focuses more on an interface for accumulating Twitter data from a user to help them track sleeping and weight loss.

The second chapter deals entirely with constructing a very simple survey that has a variable length depending on what answer you give to an earlier question. While this seems to be a very simple task, the chapter does a great job of explaining how you can make it better and why doing this makes it better. A great quote from this chapter is "The key method for collecting data from people online is, of course, through the use of the dreaded form. There is no artifact potentially more valuable to a business, or more boring and tedious to a participant." The chapter points out that for every action you require the user to make, the user may decide the survey is not worth their time. Yes, clicking "Next" on a multi-page form only gives the user another chance to decide this isn't worth it. Furthermore, many pages might cause the user to be unsure of the real length of the survey. So they decided against this and instead made the survey branch from one page so that page would continually get a little larger depending on how you answered the questions. Knowing the targets for the surveys were older made a copy large font mandatory as 72% of Americans report vision impairment by the time they are age 45. This chapter dealt more with collecting the data, respecting the source of data and building trust with the participants than displaying the data they provided.

Chapter Three deals with the recently disabled Phoenix that landed on Mars and how precisely the image collection was done. While it might seem like the wrong place to do it, there was actually pre-processing and compression done on board the lander before transmission to Earth. This article tackles interesting issues that are long thought to be an extinct animal in computer science where resources are constrained and radiation bombarding keeps the CPU modestly lower than your average desktop. Do you process the image in place in memory or make a copy so that the original image can be retained during processing? These are familiar issues to embedded developers but stuff I haven't touched since college. While the author details the situation on all fronts down to the cameras being used, it's largely a blast from the past as far as resource aware computing is concerned. Then again, I doubt any of my code will ever be flight certified by NASA.

Chapter Four has a very interesting analysis and description of Yahoo!'s PNUTS system for serving up data in complex environments like tackling issues with latency across the world when dealing with social networking. The chapter does a decent job of explaining how issues are resolved when replicated servers across the United States become out of sync and the resolution strategy. The chapter ends on an even more interesting note explaining why Yahoo! deviated from Google's BigTable, Amazon's Dynamo, Microsoft's Azure and other existing implementations. This tale of well thought out design is a stark contrast to Chapter Five which centers on a Facebook 'data scientist' that — instead of explaining the solution as a well planned finalized implementation — tells the trial and error approach of a very small team of developers treading into waters unknown with data sets of Sisyphean proportions. It was tempting for me to read this chapter and chastise the author for not foreseeing what numbers could come with making it big in social networking. But the chapter has a lot of value in a "lessons learned" realm. It may even prepare some of you who are writing web applications with a potentially explosive or viral user base. While it's popular to hate Facebook and in turn transfer that hate to the developers, no one can argue against them being one of the most successful social networking sites and any information of their (sometimes flawed) operations certainly proves to be interesting.

Chapter Six was completely unengaging for me. The chapter covers geographing. More specifically the efforts to take pictures of Britain and Ireland and map/display them geographically. The images would aim to cover a large area than users could tag them with what they see (tree, road, hill, etc). Unfortunately it never really registered with me why someone would want to do this and what the end goal was that they were aiming for. Instead they managed to produce some pretty heinous and very difficult to digest heat maps or "spatial tree maps." By embedding coloration and lines into the treemaps the authors hoped to convey intuitive information to the reader. Instead my eyes often glazed over and sometimes I flat out disagreed with their affirmation that this is how to display data beautifully. You're welcome to try to convince me that geographing has some sort of merit other than producing pretty mosaics of large image sets but it took a lot of effort for me to continue reading at points in this chapter.

Chapter Seven sets the book back on track in "Data Finds Data" where the writers cover very important concepts and problems surrounding federated search and instead offer up directories with some semantic metadata or relationship data that makes keyword searching possible over billions of documents. For anyone dealing with large volumes of data, this chapter is a great start to understanding the options you have to processing your data when you first get it (and only once) versus searching for that data just in time and paying for it in delay. While the former incurs much more disk space cost, Google has proven that paradigm shift definitely has merit.

Chapter Eight is about social data APIs and pushes gnip heavily as the de facto social endpoint aggregator for programmers. The chapter mentions WebHooks as an up and coming HTTP Post event transmission project but doesn't offer much more than a wake up call for programmers. The traditional polling has dominated web APIs and has lead to fragile points of failure. This chapter is a much needed call for sanity in the insane world of HTTP transactional polling. Unfortunately, the community seems to be so in love with the simplicity of polling that they use it for everything, even when a slightly more complicated eventing model would save them a large percentage of transactions.

Chapter Nine is a tutorial on harvesting data from the deep web. What they mean by this is that — given proper permission — one can exploit forms on websites to access database data and then index that instead of merely being relegated to static HTML pages. In my opinion, this is a fragile and often frowned upon approach to data collection but as this chapter (and many others) illustrates, sometimes data is locked up due to lack of resources to expose it. This means that if a repository of information is meant to be available to you through a simple submission form, you can tease that information out of "the deep web" and into your system with the tricks mentioned in this chapter.

Chapter Ten is the story of Radiohead's open sourced "data" music video of "House of Cards" and the collection process from the kinds of devices used to the methodology of collecting that data to the attitude they used when treating the data. This chapter is a sort of key for understanding what data you have with Radiohead's offerings and I heavily recommend it for anyone interested in taking a stab at this video. The most interesting things I found in this was their method for collection and, more importantly, their decision to actually degrade the data and opted not to texture when displaying Thom Yorke's face — citing artistic choice. This chapter gave me one very amazing display tool that I am embarrassed to admit I had no knowledge of prior to this book: processing.

Chapter Eleven is the story of a few people that chose to do something about serious crime problems in Oakland. The city was compiling reports of crimes weekly but they weren't opening up the data. You could do a search and get a very minimal display on a map of crimes that had happened. This caused Oakland Crimespotting to arise. At first they were forced to graphically scrape and estimate crime locations so their own system could offer it back to the user in more intuitive and useful ways to the citizens so the citizens could take action. At first they were forced to work around problems but in the end the city government came to its senses and began offering them the data in a far more open format. From browsing the site now, you can get an idea of the tale this chapter tells. The evolution of that end product is chronicled in this chapter.

Chapter Twelve center's on sense.us, a potentially powerful product that aims to empower users to analyze and create notations on graphs that might relay correlations between factors inside US Census data. The only disappointment with this chapter is that sense.us isn't live for us to use. The tool shows powerful abilities in collaboration in analysis of census data but also is a double edged sword. There's nothing that stops this tool from being used for political and monetary ideals instead of purely academic revelations. They used tools like Colorbrewer and prefuse to dynamically generate graphs and charts that were pleasing to the eye. Then they used 'geometric annotation' (a vector graphic approach to recording user's doodling and annotations) in order to facilitate collaboration. The notes the researchers took on the collaboration between their pilot users is probably more intriguing than their actual approach to display good graphics. Each user seemed to take a natural progression from annotation producer to annotation crawler and then bounce between them as other user annotations gave them ideas for more annotations to create. While not exactly ideal collaboration, it's interesting to hear what users do in the wild when left to their own.

Chapter Thirteen "What Data Doesn't Do" is a very short chapter with a set of ten or so rules that are intended to remind you that data doesn't predict, more data isn't always better or easier, probabilities do not explain, data doesn't stand alone, etc. This chapter felt sort of like a pause and remember way point through the book. Just when you've gone through these great stories of success, the book, reels you back into reality with this chapter. In other chapters you'll be reminded to avoid pitfalls like the narrative fallacy but this book just reminds you quite literally what data doesn't do automatically for you. It's an indicator that you need to shore up these things that data doesn't magically do when you present data.

Chapter Fourteen is Peter Norvig's "Natural Language Corpus Data" and does not disappoint. Once the reader is empowered with the code and the data in this chapter, it almost seems like one could solve several problems using ngrams, Bayes' theorem and natural language analysis. As you read this chapter, Norvig lays out how to tackle several problems with ease: decoding encryption levels up to WWII, spelling correction, machine translation and even spam detection. In just 23 pages, Norvig conveys a tiny bit of the power of a corpus of documents coupled with the willingness to be a little dirty (total probabilities summing to more than one, dropping ngrams below a threshold, etc). It's clear why he's employed at Google.

Chapter Fifteen takes a drastic turn into one of Earth's oldest data stores: DNA. As the chapter so coyly notes, programmers can view DNA as a simple string: char(3*10^6) human_genome; The chapter gives you a brief glimpse of DNA analysis but focuses more on the data storage involved in facilities that are currently working to harvest data from many subjects. As of the writing of this chapter, one facility was generating 75 terabits per week in raw data. Most interesting to me from this chapter was ensemble.org, a site to find DNA data, genome data and also collaborate with other researchers on annotating and commenting on certain parts and regions of DNA.

Similar to the previous chapter, Chapter Sixteen focuses briefly on chemistry and describes how data was collected "to predict teh solubility of a wide range of chemicals in non-aqueous solvents such as ethanol, methanol, etc." Having a very minimal chemistry background, it's never really revealed what purpose this data collection has but nonetheless the chapter explains a lot of challenges in this environment that are similar to other chapters. The interesting aspect of this chapter is that the team used open notebook science to collect this data and therefore faced the challenge of cleaning crowd-sourced data. A constantly recurring problem in these chapters is how one represents data and chemistry apparently has many standards — some more open than others. This book makes a very good argument for open standards and selecting open standards when one witnesses the screen scraping, licensing issues and costs researchers face when unifying data even for something as old as the representations of chemicals.

Chapter Seventeen is the case study of FaceStat, a statistically more ambitious Hot-or-Not effort from researchers. The site would allow anyone to upload a photo of a person and then allow users to rate them and tag them. After collecting this data, the researchers used the ubiquitous R statistical language to do some feature extraction on the data. Of course, the chapter first deals with cleaning the data and catching bad user input. While this chapter sounds like vanilla run-of-the-mill feature extraction, it also includes some interesting display examples as well as the very interesting yet controversial stereotype analysis. From taboo topics like attractiveness vs age line fitting to the sexism of tags to using k-means in order to establish stereotype clusters in the data. While other chapters sought offense through possible privacy concerns, this chapter reveals more about the callow stereotypes that internet inflict upon each other.

Chapter Eighteen looks at the San Fransisco Bay Area housing market from a very interesting selection of recent years. What differentiates this chapter from so many of the others (we collect, clean and process the data) is that it needed to break the data down by neighborhood to find the really interesting features of the data. The neighborhoods could then be grouped into six different groups with their increase in house prices to their decline in house prices. Only one group had one neighborhood that showed no decline (Mountain View). Unfortunately for this chapter and the next one, by the time the reader arrives they appear to be straight forward replications of ideas from other chapters. Chapter Nineteen is brief chapter on statistics inside politics. Aside from revealing five or six interesting correlations in voting revealed through data, this chapter merely relays what we already know: politicians implement statistics to a sometimes harmful degree (gerrymandering).

The last chapter is, appropriately, about the many sources of data exposed on the internet and the problems everyone faces in matching entities from one data source to another. The idea of using a URI to describe a movie hasn't really seemed to catch on. And if that wasn't enough, even words like "location" used to describe a column could mean drastically different things between houses and genomes. The chapter lists out a number of sources where data is available to download and tinker with (most already listed in the book) and proceeds to analyze an algorithmic (collective reconciliation) way for a system to differentiate between two movies with the same name. Naturally the author of this chapter worked on freebase which was recently (and predictably) acquired by Google. Although a short chapter, it speaks to problems that all online data communities face and what prohibits mashups from automagically happening between two disparate data sources holding data that is actually related.

With the exception of chapter six, every chapter offered me something that I won't forget. More importantly, most chapters offered a data source or data processing tool that expanded my toolbox of things to use when programming. The only reason this book misses a perfect 10/10 from me is chapter six and a couple of the later chapters feeling like weaker ideas from earlier chapters rehashed into a different domain. A worthwhile book if you work with data — whether you be a consumer or producer.

You can purchase Beautiful Data: The Stories Behind Elegant Data Solutions from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

eldavojohn writes "Beautiful Data: The Stories Behind Elegant Data Solutions is an addition to six or so other books in the 'Beautiful' series that O'Reilly has put out. It is not a comprehensive guide on data but instead a glimpse into success stories about twenty different projects that succeeded in displaying data — oftentimes in areas where others have failed. While this provides, for the most part, disjointed stories, it is a very readable book compared to most technical books. Beautiful Data proves to be quite the cover-to-cover page turner for anyone involved in building interfaces for data or the statistician at a loss for the best way to intuitively and effectively relay knowledge when given voluminous amounts of raw data. That said, it took me almost two months to make it through this book, as each chapter revealed a data repository or tool I had no idea existed. I felt like a child with an attention deficit disorder trying my hand at nearly everything. While the book isn't designed to relay complete theory on data (like Tufte), it is a great series of short success stories revolving around the entire real world practice of consuming, aggregating, realizing and making beautiful data." Keep reading for the rest of eldavojohn's review. Beautiful Data: The Stories Behind Elegant Data Solutions author Edited by Toby Segaran and Jeff Hammerbacher pages 384 publisher O'Reilly Media, Inc. rating 9/10 reviewer eldavojohn ISBN 978-0-596-15711-1 summary A collection of twenty essays and chronicles from the implementers of successful projects revolving around real world data processing and display. Since the individual articles in this book are essentially a series of what to do and what not to do, this review is more like a list of notes that were my personal rewards from each chapter. Given my background, these notes will be very specified to my interests and responsibilities for web development whereas a statistician, academic or researcher might pull a completely different set from the book. The book also has a nice colorized insert that allows the reader to get a better sense of the interfaces discussed throughout the book. One potential problem with these "case studies" is that they will most certainly become dated — and in our world that happens quite quickly. It's very easy for me to think that specific information about colocation facility usage by social networking sites (Chapter Four) will always be useful and relevant. The sad fact of the matter is that because of the unforeseen nature of hardware advancements and language evolution, many of these stories could become irrelevant blasts from the past in one or two decades. I think the audience that stands to benefit this most from this book are low level managers and people in charge of large amounts of data that they don't know what to do with. The reason for this is that while there are a few chapters that deal with low level implementation details it mostly consists of overviews of popular and successful mentalities surrounding data. One other type of audience that might be a target for this book would be young college students with interests in math, statistics or computer science. Had I picked this book up as a freshman in college, no doubt the number of projects I worked late into the night on would have multiplied as would my understanding of how the real world works.

Chapter One deals with two projects done by grad students: Personal Environmental Impact Report (PEIR) and your.flowingdata (YFD). This chapter starts out slow describing how the system harnesses personal GPS devices — a common trend in phone development these days. After clearing the basics, the chapter reveals a lot about the iterative developments the author took to select and include a map interface to effectively and quickly display several routes that a user has driven with intuitive visual queues to indicate which was the most environmentally expensive. Trying to stick with the green means good and red means bad proved difficult and they employed an inverted map of mostly shades of gray to avoid clashing colors with the natural colors on a regular map. The final part of PEIR discussed a Facebook application that simply paired you up against friends also using PEIR. This gave the user a relative value basis of otherwise incomprehensible numbers surrounding their environmental impact. YFD focuses more on an interface for accumulating Twitter data from a user to help them track sleeping and weight loss.

The second chapter deals entirely with constructing a very simple survey that has a variable length depending on what answer you give to an earlier question. While this seems to be a very simple task, the chapter does a great job of explaining how you can make it better and why doing this makes it better. A great quote from this chapter is "The key method for collecting data from people online is, of course, through the use of the dreaded form. There is no artifact potentially more valuable to a business, or more boring and tedious to a participant." The chapter points out that for every action you require the user to make, the user may decide the survey is not worth their time. Yes, clicking "Next" on a multi-page form only gives the user another chance to decide this isn't worth it. Furthermore, many pages might cause the user to be unsure of the real length of the survey. So they decided against this and instead made the survey branch from one page so that page would continually get a little larger depending on how you answered the questions. Knowing the targets for the surveys were older made a copy large font mandatory as 72% of Americans report vision impairment by the time they are age 45. This chapter dealt more with collecting the data, respecting the source of data and building trust with the participants than displaying the data they provided.

Chapter Three deals with the recently disabled Phoenix that landed on Mars and how precisely the image collection was done. While it might seem like the wrong place to do it, there was actually pre-processing and compression done on board the lander before transmission to Earth. This article tackles interesting issues that are long thought to be an extinct animal in computer science where resources are constrained and radiation bombarding keeps the CPU modestly lower than your average desktop. Do you process the image in place in memory or make a copy so that the original image can be retained during processing? These are familiar issues to embedded developers but stuff I haven't touched since college. While the author details the situation on all fronts down to the cameras being used, it's largely a blast from the past as far as resource aware computing is concerned. Then again, I doubt any of my code will ever be flight certified by NASA.

Chapter Four has a very interesting analysis and description of Yahoo!'s PNUTS system for serving up data in complex environments like tackling issues with latency across the world when dealing with social networking. The chapter does a decent job of explaining how issues are resolved when replicated servers across the United States become out of sync and the resolution strategy. The chapter ends on an even more interesting note explaining why Yahoo! deviated from Google's BigTable, Amazon's Dynamo, Microsoft's Azure and other existing implementations. This tale of well thought out design is a stark contrast to Chapter Five which centers on a Facebook 'data scientist' that — instead of explaining the solution as a well planned finalized implementation — tells the trial and error approach of a very small team of developers treading into waters unknown with data sets of Sisyphean proportions. It was tempting for me to read this chapter and chastise the author for not foreseeing what numbers could come with making it big in social networking. But the chapter has a lot of value in a "lessons learned" realm. It may even prepare some of you who are writing web applications with a potentially explosive or viral user base. While it's popular to hate Facebook and in turn transfer that hate to the developers, no one can argue against them being one of the most successful social networking sites and any information of their (sometimes flawed) operations certainly proves to be interesting.

Chapter Six was completely unengaging for me. The chapter covers geographing. More specifically the efforts to take pictures of Britain and Ireland and map/display them geographically. The images would aim to cover a large area than users could tag them with what they see (tree, road, hill, etc). Unfortunately it never really registered with me why someone would want to do this and what the end goal was that they were aiming for. Instead they managed to produce some pretty heinous and very difficult to digest heat maps or "spatial tree maps." By embedding coloration and lines into the treemaps the authors hoped to convey intuitive information to the reader. Instead my eyes often glazed over and sometimes I flat out disagreed with their affirmation that this is how to display data beautifully. You're welcome to try to convince me that geographing has some sort of merit other than producing pretty mosaics of large image sets but it took a lot of effort for me to continue reading at points in this chapter.

Chapter Seven sets the book back on track in "Data Finds Data" where the writers cover very important concepts and problems surrounding federated search and instead offer up directories with some semantic metadata or relationship data that makes keyword searching possible over billions of documents. For anyone dealing with large volumes of data, this chapter is a great start to understanding the options you have to processing your data when you first get it (and only once) versus searching for that data just in time and paying for it in delay. While the former incurs much more disk space cost, Google has proven that paradigm shift definitely has merit.

Chapter Eight is about social data APIs and pushes gnip heavily as the de facto social endpoint aggregator for programmers. The chapter mentions WebHooks as an up and coming HTTP Post event transmission project but doesn't offer much more than a wake up call for programmers. The traditional polling has dominated web APIs and has lead to fragile points of failure. This chapter is a much needed call for sanity in the insane world of HTTP transactional polling. Unfortunately, the community seems to be so in love with the simplicity of polling that they use it for everything, even when a slightly more complicated eventing model would save them a large percentage of transactions.

Chapter Nine is a tutorial on harvesting data from the deep web. What they mean by this is that — given proper permission — one can exploit forms on websites to access database data and then index that instead of merely being relegated to static HTML pages. In my opinion, this is a fragile and often frowned upon approach to data collection but as this chapter (and many others) illustrates, sometimes data is locked up due to lack of resources to expose it. This means that if a repository of information is meant to be available to you through a simple submission form, you can tease that information out of "the deep web" and into your system with the tricks mentioned in this chapter.

Chapter Ten is the story of Radiohead's open sourced "data" music video of "House of Cards" and the collection process from the kinds of devices used to the methodology of collecting that data to the attitude they used when treating the data. This chapter is a sort of key for understanding what data you have with Radiohead's offerings and I heavily recommend it for anyone interested in taking a stab at this video. The most interesting things I found in this was their method for collection and, more importantly, their decision to actually degrade the data and opted not to texture when displaying Thom Yorke's face — citing artistic choice. This chapter gave me one very amazing display tool that I am embarrassed to admit I had no knowledge of prior to this book: processing.

Chapter Eleven is the story of a few people that chose to do something about serious crime problems in Oakland. The city was compiling reports of crimes weekly but they weren't opening up the data. You could do a search and get a very minimal display on a map of crimes that had happened. This caused Oakland Crimespotting to arise. At first they were forced to graphically scrape and estimate crime locations so their own system could offer it back to the user in more intuitive and useful ways to the citizens so the citizens could take action. At first they were forced to work around problems but in the end the city government came to its senses and began offering them the data in a far more open format. From browsing the site now, you can get an idea of the tale this chapter tells. The evolution of that end product is chronicled in this chapter.

Chapter Twelve center's on sense.us, a potentially powerful product that aims to empower users to analyze and create notations on graphs that might relay correlations between factors inside US Census data. The only disappointment with this chapter is that sense.us isn't live for us to use. The tool shows powerful abilities in collaboration in analysis of census data but also is a double edged sword. There's nothing that stops this tool from being used for political and monetary ideals instead of purely academic revelations. They used tools like Colorbrewer and prefuse to dynamically generate graphs and charts that were pleasing to the eye. Then they used 'geometric annotation' (a vector graphic approach to recording user's doodling and annotations) in order to facilitate collaboration. The notes the researchers took on the collaboration between their pilot users is probably more intriguing than their actual approach to display good graphics. Each user seemed to take a natural progression from annotation producer to annotation crawler and then bounce between them as other user annotations gave them ideas for more annotations to create. While not exactly ideal collaboration, it's interesting to hear what users do in the wild when left to their own.

Chapter Thirteen "What Data Doesn't Do" is a very short chapter with a set of ten or so rules that are intended to remind you that data doesn't predict, more data isn't always better or easier, probabilities do not explain, data doesn't stand alone, etc. This chapter felt sort of like a pause and remember way point through the book. Just when you've gone through these great stories of success, the book, reels you back into reality with this chapter. In other chapters you'll be reminded to avoid pitfalls like the narrative fallacy but this book just reminds you quite literally what data doesn't do automatically for you. It's an indicator that you need to shore up these things that data doesn't magically do when you present data.

Chapter Fourteen is Peter Norvig's "Natural Language Corpus Data" and does not disappoint. Once the reader is empowered with the code and the data in this chapter, it almost seems like one could solve several problems using ngrams, Bayes' theorem and natural language analysis. As you read this chapter, Norvig lays out how to tackle several problems with ease: decoding encryption levels up to WWII, spelling correction, machine translation and even spam detection. In just 23 pages, Norvig conveys a tiny bit of the power of a corpus of documents coupled with the willingness to be a little dirty (total probabilities summing to more than one, dropping ngrams below a threshold, etc). It's clear why he's employed at Google.

Chapter Fifteen takes a drastic turn into one of Earth's oldest data stores: DNA. As the chapter so coyly notes, programmers can view DNA as a simple string: char(3*10^6) human_genome; The chapter gives you a brief glimpse of DNA analysis but focuses more on the data storage involved in facilities that are currently working to harvest data from many subjects. As of the writing of this chapter, one facility was generating 75 terabits per week in raw data. Most interesting to me from this chapter was ensemble.org, a site to find DNA data, genome data and also collaborate with other researchers on annotating and commenting on certain parts and regions of DNA.

Similar to the previous chapter, Chapter Sixteen focuses briefly on chemistry and describes how data was collected "to predict teh solubility of a wide range of chemicals in non-aqueous solvents such as ethanol, methanol, etc." Having a very minimal chemistry background, it's never really revealed what purpose this data collection has but nonetheless the chapter explains a lot of challenges in this environment that are similar to other chapters. The interesting aspect of this chapter is that the team used open notebook science to collect this data and therefore faced the challenge of cleaning crowd-sourced data. A constantly recurring problem in these chapters is how one represents data and chemistry apparently has many standards — some more open than others. This book makes a very good argument for open standards and selecting open standards when one witnesses the screen scraping, licensing issues and costs researchers face when unifying data even for something as old as the representations of chemicals.

Chapter Seventeen is the case study of FaceStat, a statistically more ambitious Hot-or-Not effort from researchers. The site would allow anyone to upload a photo of a person and then allow users to rate them and tag them. After collecting this data, the researchers used the ubiquitous R statistical language to do some feature extraction on the data. Of course, the chapter first deals with cleaning the data and catching bad user input. While this chapter sounds like vanilla run-of-the-mill feature extraction, it also includes some interesting display examples as well as the very interesting yet controversial stereotype analysis. From taboo topics like attractiveness vs age line fitting to the sexism of tags to using k-means in order to establish stereotype clusters in the data. While other chapters sought offense through possible privacy concerns, this chapter reveals more about the callow stereotypes that internet inflict upon each other.

Chapter Eighteen looks at the San Fransisco Bay Area housing market from a very interesting selection of recent years. What differentiates this chapter from so many of the others (we collect, clean and process the data) is that it needed to break the data down by neighborhood to find the really interesting features of the data. The neighborhoods could then be grouped into six different groups with their increase in house prices to their decline in house prices. Only one group had one neighborhood that showed no decline (Mountain View). Unfortunately for this chapter and the next one, by the time the reader arrives they appear to be straight forward replications of ideas from other chapters. Chapter Nineteen is brief chapter on statistics inside politics. Aside from revealing five or six interesting correlations in voting revealed through data, this chapter merely relays what we already know: politicians implement statistics to a sometimes harmful degree (gerrymandering).

The last chapter is, appropriately, about the many sources of data exposed on the internet and the problems everyone faces in matching entities from one data source to another. The idea of using a URI to describe a movie hasn't really seemed to catch on. And if that wasn't enough, even words like "location" used to describe a column could mean drastically different things between houses and genomes. The chapter lists out a number of sources where data is available to download and tinker with (most already listed in the book) and proceeds to analyze an algorithmic (collective reconciliation) way for a system to differentiate between two movies with the same name. Naturally the author of this chapter worked on freebase which was recently (and predictably) acquired by Google. Although a short chapter, it speaks to problems that all online data communities face and what prohibits mashups from automagically happening between two disparate data sources holding data that is actually related.

With the exception of chapter six, every chapter offered me something that I won't forget. More importantly, most chapters offered a data source or data processing tool that expanded my toolbox of things to use when programming. The only reason this book misses a perfect 10/10 from me is chapter six and a couple of the later chapters feeling like weaker ideas from earlier chapters rehashed into a different domain. A worthwhile book if you work with data — whether you be a consumer or producer.

You can purchase Beautiful Data: The Stories Behind Elegant Data Solutions from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

eldavojohn writes "Beautiful Data: The Stories Behind Elegant Data Solutions is an addition to six or so other books in the 'Beautiful' series that O'Reilly has put out. It is not a comprehensive guide on data but instead a glimpse into success stories about twenty different projects that succeeded in displaying data — oftentimes in areas where others have failed. While this provides, for the most part, disjointed stories, it is a very readable book compared to most technical books. Beautiful Data proves to be quite the cover-to-cover page turner for anyone involved in building interfaces for data or the statistician at a loss for the best way to intuitively and effectively relay knowledge when given voluminous amounts of raw data. That said, it took me almost two months to make it through this book, as each chapter revealed a data repository or tool I had no idea existed. I felt like a child with an attention deficit disorder trying my hand at nearly everything. While the book isn't designed to relay complete theory on data (like Tufte), it is a great series of short success stories revolving around the entire real world practice of consuming, aggregating, realizing and making beautiful data." Keep reading for the rest of eldavojohn's review. Beautiful Data: The Stories Behind Elegant Data Solutions author Edited by Toby Segaran and Jeff Hammerbacher pages 384 publisher O'Reilly Media, Inc. rating 9/10 reviewer eldavojohn ISBN 978-0-596-15711-1 summary A collection of twenty essays and chronicles from the implementers of successful projects revolving around real world data processing and display. Since the individual articles in this book are essentially a series of what to do and what not to do, this review is more like a list of notes that were my personal rewards from each chapter. Given my background, these notes will be very specified to my interests and responsibilities for web development whereas a statistician, academic or researcher might pull a completely different set from the book. The book also has a nice colorized insert that allows the reader to get a better sense of the interfaces discussed throughout the book. One potential problem with these "case studies" is that they will most certainly become dated — and in our world that happens quite quickly. It's very easy for me to think that specific information about colocation facility usage by social networking sites (Chapter Four) will always be useful and relevant. The sad fact of the matter is that because of the unforeseen nature of hardware advancements and language evolution, many of these stories could become irrelevant blasts from the past in one or two decades. I think the audience that stands to benefit this most from this book are low level managers and people in charge of large amounts of data that they don't know what to do with. The reason for this is that while there are a few chapters that deal with low level implementation details it mostly consists of overviews of popular and successful mentalities surrounding data. One other type of audience that might be a target for this book would be young college students with interests in math, statistics or computer science. Had I picked this book up as a freshman in college, no doubt the number of projects I worked late into the night on would have multiplied as would my understanding of how the real world works.

Chapter One deals with two projects done by grad students: Personal Environmental Impact Report (PEIR) and your.flowingdata (YFD). This chapter starts out slow describing how the system harnesses personal GPS devices — a common trend in phone development these days. After clearing the basics, the chapter reveals a lot about the iterative developments the author took to select and include a map interface to effectively and quickly display several routes that a user has driven with intuitive visual queues to indicate which was the most environmentally expensive. Trying to stick with the green means good and red means bad proved difficult and they employed an inverted map of mostly shades of gray to avoid clashing colors with the natural colors on a regular map. The final part of PEIR discussed a Facebook application that simply paired you up against friends also using PEIR. This gave the user a relative value basis of otherwise incomprehensible numbers surrounding their environmental impact. YFD focuses more on an interface for accumulating Twitter data from a user to help them track sleeping and weight loss.

The second chapter deals entirely with constructing a very simple survey that has a variable length depending on what answer you give to an earlier question. While this seems to be a very simple task, the chapter does a great job of explaining how you can make it better and why doing this makes it better. A great quote from this chapter is "The key method for collecting data from people online is, of course, through the use of the dreaded form. There is no artifact potentially more valuable to a business, or more boring and tedious to a participant." The chapter points out that for every action you require the user to make, the user may decide the survey is not worth their time. Yes, clicking "Next" on a multi-page form only gives the user another chance to decide this isn't worth it. Furthermore, many pages might cause the user to be unsure of the real length of the survey. So they decided against this and instead made the survey branch from one page so that page would continually get a little larger depending on how you answered the questions. Knowing the targets for the surveys were older made a copy large font mandatory as 72% of Americans report vision impairment by the time they are age 45. This chapter dealt more with collecting the data, respecting the source of data and building trust with the participants than displaying the data they provided.

Chapter Three deals with the recently disabled Phoenix that landed on Mars and how precisely the image collection was done. While it might seem like the wrong place to do it, there was actually pre-processing and compression done on board the lander before transmission to Earth. This article tackles interesting issues that are long thought to be an extinct animal in computer science where resources are constrained and radiation bombarding keeps the CPU modestly lower than your average desktop. Do you process the image in place in memory or make a copy so that the original image can be retained during processing? These are familiar issues to embedded developers but stuff I haven't touched since college. While the author details the situation on all fronts down to the cameras being used, it's largely a blast from the past as far as resource aware computing is concerned. Then again, I doubt any of my code will ever be flight certified by NASA.

Chapter Four has a very interesting analysis and description of Yahoo!'s PNUTS system for serving up data in complex environments like tackling issues with latency across the world when dealing with social networking. The chapter does a decent job of explaining how issues are resolved when replicated servers across the United States become out of sync and the resolution strategy. The chapter ends on an even more interesting note explaining why Yahoo! deviated from Google's BigTable, Amazon's Dynamo, Microsoft's Azure and other existing implementations. This tale of well thought out design is a stark contrast to Chapter Five which centers on a Facebook 'data scientist' that — instead of explaining the solution as a well planned finalized implementation — tells the trial and error approach of a very small team of developers treading into waters unknown with data sets of Sisyphean proportions. It was tempting for me to read this chapter and chastise the author for not foreseeing what numbers could come with making it big in social networking. But the chapter has a lot of value in a "lessons learned" realm. It may even prepare some of you who are writing web applications with a potentially explosive or viral user base. While it's popular to hate Facebook and in turn transfer that hate to the developers, no one can argue against them being one of the most successful social networking sites and any information of their (sometimes flawed) operations certainly proves to be interesting.

Chapter Six was completely unengaging for me. The chapter covers geographing. More specifically the efforts to take pictures of Britain and Ireland and map/display them geographically. The images would aim to cover a large area than users could tag them with what they see (tree, road, hill, etc). Unfortunately it never really registered with me why someone would want to do this and what the end goal was that they were aiming for. Instead they managed to produce some pretty heinous and very difficult to digest heat maps or "spatial tree maps." By embedding coloration and lines into the treemaps the authors hoped to convey intuitive information to the reader. Instead my eyes often glazed over and sometimes I flat out disagreed with their affirmation that this is how to display data beautifully. You're welcome to try to convince me that geographing has some sort of merit other than producing pretty mosaics of large image sets but it took a lot of effort for me to continue reading at points in this chapter.

Chapter Seven sets the book back on track in "Data Finds Data" where the writers cover very important concepts and problems surrounding federated search and instead offer up directories with some semantic metadata or relationship data that makes keyword searching possible over billions of documents. For anyone dealing with large volumes of data, this chapter is a great start to understanding the options you have to processing your data when you first get it (and only once) versus searching for that data just in time and paying for it in delay. While the former incurs much more disk space cost, Google has proven that paradigm shift definitely has merit.

Chapter Eight is about social data APIs and pushes gnip heavily as the de facto social endpoint aggregator for programmers. The chapter mentions WebHooks as an up and coming HTTP Post event transmission project but doesn't offer much more than a wake up call for programmers. The traditional polling has dominated web APIs and has lead to fragile points of failure. This chapter is a much needed call for sanity in the insane world of HTTP transactional polling. Unfortunately, the community seems to be so in love with the simplicity of polling that they use it for everything, even when a slightly more complicated eventing model would save them a large percentage of transactions.

Chapter Nine is a tutorial on harvesting data from the deep web. What they mean by this is that — given proper permission — one can exploit forms on websites to access database data and then index that instead of merely being relegated to static HTML pages. In my opinion, this is a fragile and often frowned upon approach to data collection but as this chapter (and many others) illustrates, sometimes data is locked up due to lack of resources to expose it. This means that if a repository of information is meant to be available to you through a simple submission form, you can tease that information out of "the deep web" and into your system with the tricks mentioned in this chapter.

Chapter Ten is the story of Radiohead's open sourced "data" music video of "House of Cards" and the collection process from the kinds of devices used to the methodology of collecting that data to the attitude they used when treating the data. This chapter is a sort of key for understanding what data you have with Radiohead's offerings and I heavily recommend it for anyone interested in taking a stab at this video. The most interesting things I found in this was their method for collection and, more importantly, their decision to actually degrade the data and opted not to texture when displaying Thom Yorke's face — citing artistic choice. This chapter gave me one very amazing display tool that I am embarrassed to admit I had no knowledge of prior to this book: processing.

Chapter Eleven is the story of a few people that chose to do something about serious crime problems in Oakland. The city was compiling reports of crimes weekly but they weren't opening up the data. You could do a search and get a very minimal display on a map of crimes that had happened. This caused Oakland Crimespotting to arise. At first they were forced to graphically scrape and estimate crime locations so their own system could offer it back to the user in more intuitive and useful ways to the citizens so the citizens could take action. At first they were forced to work around problems but in the end the city government came to its senses and began offering them the data in a far more open format. From browsing the site now, you can get an idea of the tale this chapter tells. The evolution of that end product is chronicled in this chapter.

Chapter Twelve center's on sense.us, a potentially powerful product that aims to empower users to analyze and create notations on graphs that might relay correlations between factors inside US Census data. The only disappointment with this chapter is that sense.us isn't live for us to use. The tool shows powerful abilities in collaboration in analysis of census data but also is a double edged sword. There's nothing that stops this tool from being used for political and monetary ideals instead of purely academic revelations. They used tools like Colorbrewer and prefuse to dynamically generate graphs and charts that were pleasing to the eye. Then they used 'geometric annotation' (a vector graphic approach to recording user's doodling and annotations) in order to facilitate collaboration. The notes the researchers took on the collaboration between their pilot users is probably more intriguing than their actual approach to display good graphics. Each user seemed to take a natural progression from annotation producer to annotation crawler and then bounce between them as other user annotations gave them ideas for more annotations to create. While not exactly ideal collaboration, it's interesting to hear what users do in the wild when left to their own.

Chapter Thirteen "What Data Doesn't Do" is a very short chapter with a set of ten or so rules that are intended to remind you that data doesn't predict, more data isn't always better or easier, probabilities do not explain, data doesn't stand alone, etc. This chapter felt sort of like a pause and remember way point through the book. Just when you've gone through these great stories of success, the book, reels you back into reality with this chapter. In other chapters you'll be reminded to avoid pitfalls like the narrative fallacy but this book just reminds you quite literally what data doesn't do automatically for you. It's an indicator that you need to shore up these things that data doesn't magically do when you present data.

Chapter Fourteen is Peter Norvig's "Natural Language Corpus Data" and does not disappoint. Once the reader is empowered with the code and the data in this chapter, it almost seems like one could solve several problems using ngrams, Bayes' theorem and natural language analysis. As you read this chapter, Norvig lays out how to tackle several problems with ease: decoding encryption levels up to WWII, spelling correction, machine translation and even spam detection. In just 23 pages, Norvig conveys a tiny bit of the power of a corpus of documents coupled with the willingness to be a little dirty (total probabilities summing to more than one, dropping ngrams below a threshold, etc). It's clear why he's employed at Google.

Chapter Fifteen takes a drastic turn into one of Earth's oldest data stores: DNA. As the chapter so coyly notes, programmers can view DNA as a simple string: char(3*10^6) human_genome; The chapter gives you a brief glimpse of DNA analysis but focuses more on the data storage involved in facilities that are currently working to harvest data from many subjects. As of the writing of this chapter, one facility was generating 75 terabits per week in raw data. Most interesting to me from this chapter was ensemble.org, a site to find DNA data, genome data and also collaborate with other researchers on annotating and commenting on certain parts and regions of DNA.

Similar to the previous chapter, Chapter Sixteen focuses briefly on chemistry and describes how data was collected "to predict teh solubility of a wide range of chemicals in non-aqueous solvents such as ethanol, methanol, etc." Having a very minimal chemistry background, it's never really revealed what purpose this data collection has but nonetheless the chapter explains a lot of challenges in this environment that are similar to other chapters. The interesting aspect of this chapter is that the team used open notebook science to collect this data and therefore faced the challenge of cleaning crowd-sourced data. A constantly recurring problem in these chapters is how one represents data and chemistry apparently has many standards — some more open than others. This book makes a very good argument for open standards and selecting open standards when one witnesses the screen scraping, licensing issues and costs researchers face when unifying data even for something as old as the representations of chemicals.

Chapter Seventeen is the case study of FaceStat, a statistically more ambitious Hot-or-Not effort from researchers. The site would allow anyone to upload a photo of a person and then allow users to rate them and tag them. After collecting this data, the researchers used the ubiquitous R statistical language to do some feature extraction on the data. Of course, the chapter first deals with cleaning the data and catching bad user input. While this chapter sounds like vanilla run-of-the-mill feature extraction, it also includes some interesting display examples as well as the very interesting yet controversial stereotype analysis. From taboo topics like attractiveness vs age line fitting to the sexism of tags to using k-means in order to establish stereotype clusters in the data. While other chapters sought offense through possible privacy concerns, this chapter reveals more about the callow stereotypes that internet inflict upon each other.

Chapter Eighteen looks at the San Fransisco Bay Area housing market from a very interesting selection of recent years. What differentiates this chapter from so many of the others (we collect, clean and process the data) is that it needed to break the data down by neighborhood to find the really interesting features of the data. The neighborhoods could then be grouped into six different groups with their increase in house prices to their decline in house prices. Only one group had one neighborhood that showed no decline (Mountain View). Unfortunately for this chapter and the next one, by the time the reader arrives they appear to be straight forward replications of ideas from other chapters. Chapter Nineteen is brief chapter on statistics inside politics. Aside from revealing five or six interesting correlations in voting revealed through data, this chapter merely relays what we already know: politicians implement statistics to a sometimes harmful degree (gerrymandering).

The last chapter is, appropriately, about the many sources of data exposed on the internet and the problems everyone faces in matching entities from one data source to another. The idea of using a URI to describe a movie hasn't really seemed to catch on. And if that wasn't enough, even words like "location" used to describe a column could mean drastically different things between houses and genomes. The chapter lists out a number of sources where data is available to download and tinker with (most already listed in the book) and proceeds to analyze an algorithmic (collective reconciliation) way for a system to differentiate between two movies with the same name. Naturally the author of this chapter worked on freebase which was recently (and predictably) acquired by Google. Although a short chapter, it speaks to problems that all online data communities face and what prohibits mashups from automagically happening between two disparate data sources holding data that is actually related.

With the exception of chapter six, every chapter offered me something that I won't forget. More importantly, most chapters offered a data source or data processing tool that expanded my toolbox of things to use when programming. The only reason this book misses a perfect 10/10 from me is chapter six and a couple of the later chapters feeling like weaker ideas from earlier chapters rehashed into a different domain. A worthwhile book if you work with data — whether you be a consumer or producer.

You can purchase Beautiful Data: The Stories Behind Elegant Data Solutions from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

eldavojohn writes "Beautiful Data: The Stories Behind Elegant Data Solutions is an addition to six or so other books in the 'Beautiful' series that O'Reilly has put out. It is not a comprehensive guide on data but instead a glimpse into success stories about twenty different projects that succeeded in displaying data — oftentimes in areas where others have failed. While this provides, for the most part, disjointed stories, it is a very readable book compared to most technical books. Beautiful Data proves to be quite the cover-to-cover page turner for anyone involved in building interfaces for data or the statistician at a loss for the best way to intuitively and effectively relay knowledge when given voluminous amounts of raw data. That said, it took me almost two months to make it through this book, as each chapter revealed a data repository or tool I had no idea existed. I felt like a child with an attention deficit disorder trying my hand at nearly everything. While the book isn't designed to relay complete theory on data (like Tufte), it is a great series of short success stories revolving around the entire real world practice of consuming, aggregating, realizing and making beautiful data." Keep reading for the rest of eldavojohn's review. Beautiful Data: The Stories Behind Elegant Data Solutions author Edited by Toby Segaran and Jeff Hammerbacher pages 384 publisher O'Reilly Media, Inc. rating 9/10 reviewer eldavojohn ISBN 978-0-596-15711-1 summary A collection of twenty essays and chronicles from the implementers of successful projects revolving around real world data processing and display. Since the individual articles in this book are essentially a series of what to do and what not to do, this review is more like a list of notes that were my personal rewards from each chapter. Given my background, these notes will be very specified to my interests and responsibilities for web development whereas a statistician, academic or researcher might pull a completely different set from the book. The book also has a nice colorized insert that allows the reader to get a better sense of the interfaces discussed throughout the book. One potential problem with these "case studies" is that they will most certainly become dated — and in our world that happens quite quickly. It's very easy for me to think that specific information about colocation facility usage by social networking sites (Chapter Four) will always be useful and relevant. The sad fact of the matter is that because of the unforeseen nature of hardware advancements and language evolution, many of these stories could become irrelevant blasts from the past in one or two decades. I think the audience that stands to benefit this most from this book are low level managers and people in charge of large amounts of data that they don't know what to do with. The reason for this is that while there are a few chapters that deal with low level implementation details it mostly consists of overviews of popular and successful mentalities surrounding data. One other type of audience that might be a target for this book would be young college students with interests in math, statistics or computer science. Had I picked this book up as a freshman in college, no doubt the number of projects I worked late into the night on would have multiplied as would my understanding of how the real world works.

Chapter One deals with two projects done by grad students: Personal Environmental Impact Report (PEIR) and your.flowingdata (YFD). This chapter starts out slow describing how the system harnesses personal GPS devices — a common trend in phone development these days. After clearing the basics, the chapter reveals a lot about the iterative developments the author took to select and include a map interface to effectively and quickly display several routes that a user has driven with intuitive visual queues to indicate which was the most environmentally expensive. Trying to stick with the green means good and red means bad proved difficult and they employed an inverted map of mostly shades of gray to avoid clashing colors with the natural colors on a regular map. The final part of PEIR discussed a Facebook application that simply paired you up against friends also using PEIR. This gave the user a relative value basis of otherwise incomprehensible numbers surrounding their environmental impact. YFD focuses more on an interface for accumulating Twitter data from a user to help them track sleeping and weight loss.

The second chapter deals entirely with constructing a very simple survey that has a variable length depending on what answer you give to an earlier question. While this seems to be a very simple task, the chapter does a great job of explaining how you can make it better and why doing this makes it better. A great quote from this chapter is "The key method for collecting data from people online is, of course, through the use of the dreaded form. There is no artifact potentially more valuable to a business, or more boring and tedious to a participant." The chapter points out that for every action you require the user to make, the user may decide the survey is not worth their time. Yes, clicking "Next" on a multi-page form only gives the user another chance to decide this isn't worth it. Furthermore, many pages might cause the user to be unsure of the real length of the survey. So they decided against this and instead made the survey branch from one page so that page would continually get a little larger depending on how you answered the questions. Knowing the targets for the surveys were older made a copy large font mandatory as 72% of Americans report vision impairment by the time they are age 45. This chapter dealt more with collecting the data, respecting the source of data and building trust with the participants than displaying the data they provided.

Chapter Three deals with the recently disabled Phoenix that landed on Mars and how precisely the image collection was done. While it might seem like the wrong place to do it, there was actually pre-processing and compression done on board the lander before transmission to Earth. This article tackles interesting issues that are long thought to be an extinct animal in computer science where resources are constrained and radiation bombarding keeps the CPU modestly lower than your average desktop. Do you process the image in place in memory or make a copy so that the original image can be retained during processing? These are familiar issues to embedded developers but stuff I haven't touched since college. While the author details the situation on all fronts down to the cameras being used, it's largely a blast from the past as far as resource aware computing is concerned. Then again, I doubt any of my code will ever be flight certified by NASA.

Chapter Four has a very interesting analysis and description of Yahoo!'s PNUTS system for serving up data in complex environments like tackling issues with latency across the world when dealing with social networking. The chapter does a decent job of explaining how issues are resolved when replicated servers across the United States become out of sync and the resolution strategy. The chapter ends on an even more interesting note explaining why Yahoo! deviated from Google's BigTable, Amazon's Dynamo, Microsoft's Azure and other existing implementations. This tale of well thought out design is a stark contrast to Chapter Five which centers on a Facebook 'data scientist' that — instead of explaining the solution as a well planned finalized implementation — tells the trial and error approach of a very small team of developers treading into waters unknown with data sets of Sisyphean proportions. It was tempting for me to read this chapter and chastise the author for not foreseeing what numbers could come with making it big in social networking. But the chapter has a lot of value in a "lessons learned" realm. It may even prepare some of you who are writing web applications with a potentially explosive or viral user base. While it's popular to hate Facebook and in turn transfer that hate to the developers, no one can argue against them being one of the most successful social networking sites and any information of their (sometimes flawed) operations certainly proves to be interesting.

Chapter Six was completely unengaging for me. The chapter covers geographing. More specifically the efforts to take pictures of Britain and Ireland and map/display them geographically. The images would aim to cover a large area than users could tag them with what they see (tree, road, hill, etc). Unfortunately it never really registered with me why someone would want to do this and what the end goal was that they were aiming for. Instead they managed to produce some pretty heinous and very difficult to digest heat maps or "spatial tree maps." By embedding coloration and lines into the treemaps the authors hoped to convey intuitive information to the reader. Instead my eyes often glazed over and sometimes I flat out disagreed with their affirmation that this is how to display data beautifully. You're welcome to try to convince me that geographing has some sort of merit other than producing pretty mosaics of large image sets but it took a lot of effort for me to continue reading at points in this chapter.

Chapter Seven sets the book back on track in "Data Finds Data" where the writers cover very important concepts and problems surrounding federated search and instead offer up directories with some semantic metadata or relationship data that makes keyword searching possible over billions of documents. For anyone dealing with large volumes of data, this chapter is a great start to understanding the options you have to processing your data when you first get it (and only once) versus searching for that data just in time and paying for it in delay. While the former incurs much more disk space cost, Google has proven that paradigm shift definitely has merit.

Chapter Eight is about social data APIs and pushes gnip heavily as the de facto social endpoint aggregator for programmers. The chapter mentions WebHooks as an up and coming HTTP Post event transmission project but doesn't offer much more than a wake up call for programmers. The traditional polling has dominated web APIs and has lead to fragile points of failure. This chapter is a much needed call for sanity in the insane world of HTTP transactional polling. Unfortunately, the community seems to be so in love with the simplicity of polling that they use it for everything, even when a slightly more complicated eventing model would save them a large percentage of transactions.

Chapter Nine is a tutorial on harvesting data from the deep web. What they mean by this is that — given proper permission — one can exploit forms on websites to access database data and then index that instead of merely being relegated to static HTML pages. In my opinion, this is a fragile and often frowned upon approach to data collection but as this chapter (and many others) illustrates, sometimes data is locked up due to lack of resources to expose it. This means that if a repository of information is meant to be available to you through a simple submission form, you can tease that information out of "the deep web" and into your system with the tricks mentioned in this chapter.

Chapter Ten is the story of Radiohead's open sourced "data" music video of "House of Cards" and the collection process from the kinds of devices used to the methodology of collecting that data to the attitude they used when treating the data. This chapter is a sort of key for understanding what data you have with Radiohead's offerings and I heavily recommend it for anyone interested in taking a stab at this video. The most interesting things I found in this was their method for collection and, more importantly, their decision to actually degrade the data and opted not to texture when displaying Thom Yorke's face — citing artistic choice. This chapter gave me one very amazing display tool that I am embarrassed to admit I had no knowledge of prior to this book: processing.

Chapter Eleven is the story of a few people that chose to do something about serious crime problems in Oakland. The city was compiling reports of crimes weekly but they weren't opening up the data. You could do a search and get a very minimal display on a map of crimes that had happened. This caused Oakland Crimespotting to arise. At first they were forced to graphically scrape and estimate crime locations so their own system could offer it back to the user in more intuitive and useful ways to the citizens so the citizens could take action. At first they were forced to work around problems but in the end the city government came to its senses and began offering them the data in a far more open format. From browsing the site now, you can get an idea of the tale this chapter tells. The evolution of that end product is chronicled in this chapter.

Chapter Twelve center's on sense.us, a potentially powerful product that aims to empower users to analyze and create notations on graphs that might relay correlations between factors inside US Census data. The only disappointment with this chapter is that sense.us isn't live for us to use. The tool shows powerful abilities in collaboration in analysis of census data but also is a double edged sword. There's nothing that stops this tool from being used for political and monetary ideals instead of purely academic revelations. They used tools like Colorbrewer and prefuse to dynamically generate graphs and charts that were pleasing to the eye. Then they used 'geometric annotation' (a vector graphic approach to recording user's doodling and annotations) in order to facilitate collaboration. The notes the researchers took on the collaboration between their pilot users is probably more intriguing than their actual approach to display good graphics. Each user seemed to take a natural progression from annotation producer to annotation crawler and then bounce between them as other user annotations gave them ideas for more annotations to create. While not exactly ideal collaboration, it's interesting to hear what users do in the wild when left to their own.

Chapter Thirteen "What Data Doesn't Do" is a very short chapter with a set of ten or so rules that are intended to remind you that data doesn't predict, more data isn't always better or easier, probabilities do not explain, data doesn't stand alone, etc. This chapter felt sort of like a pause and remember way point through the book. Just when you've gone through these great stories of success, the book, reels you back into reality with this chapter. In other chapters you'll be reminded to avoid pitfalls like the narrative fallacy but this book just reminds you quite literally what data doesn't do automatically for you. It's an indicator that you need to shore up these things that data doesn't magically do when you present data.

Chapter Fourteen is Peter Norvig's "Natural Language Corpus Data" and does not disappoint. Once the reader is empowered with the code and the data in this chapter, it almost seems like one could solve several problems using ngrams, Bayes' theorem and natural language analysis. As you read this chapter, Norvig lays out how to tackle several problems with ease: decoding encryption levels up to WWII, spelling correction, machine translation and even spam detection. In just 23 pages, Norvig conveys a tiny bit of the power of a corpus of documents coupled with the willingness to be a little dirty (total probabilities summing to more than one, dropping ngrams below a threshold, etc). It's clear why he's employed at Google.

Chapter Fifteen takes a drastic turn into one of Earth's oldest data stores: DNA. As the chapter so coyly notes, programmers can view DNA as a simple string: char(3*10^6) human_genome; The chapter gives you a brief glimpse of DNA analysis but focuses more on the data storage involved in facilities that are currently working to harvest data from many subjects. As of the writing of this chapter, one facility was generating 75 terabits per week in raw data. Most interesting to me from this chapter was ensemble.org, a site to find DNA data, genome data and also collaborate with other researchers on annotating and commenting on certain parts and regions of DNA.

Similar to the previous chapter, Chapter Sixteen focuses briefly on chemistry and describes how data was collected "to predict teh solubility of a wide range of chemicals in non-aqueous solvents such as ethanol, methanol, etc." Having a very minimal chemistry background, it's never really revealed what purpose this data collection has but nonetheless the chapter explains a lot of challenges in this environment that are similar to other chapters. The interesting aspect of this chapter is that the team used open notebook science to collect this data and therefore faced the challenge of cleaning crowd-sourced data. A constantly recurring problem in these chapters is how one represents data and chemistry apparently has many standards — some more open than others. This book makes a very good argument for open standards and selecting open standards when one witnesses the screen scraping, licensing issues and costs researchers face when unifying data even for something as old as the representations of chemicals.

Chapter Seventeen is the case study of FaceStat, a statistically more ambitious Hot-or-Not effort from researchers. The site would allow anyone to upload a photo of a person and then allow users to rate them and tag them. After collecting this data, the researchers used the ubiquitous R statistical language to do some feature extraction on the data. Of course, the chapter first deals with cleaning the data and catching bad user input. While this chapter sounds like vanilla run-of-the-mill feature extraction, it also includes some interesting display examples as well as the very interesting yet controversial stereotype analysis. From taboo topics like attractiveness vs age line fitting to the sexism of tags to using k-means in order to establish stereotype clusters in the data. While other chapters sought offense through possible privacy concerns, this chapter reveals more about the callow stereotypes that internet inflict upon each other.

Chapter Eighteen looks at the San Fransisco Bay Area housing market from a very interesting selection of recent years. What differentiates this chapter from so many of the others (we collect, clean and process the data) is that it needed to break the data down by neighborhood to find the really interesting features of the data. The neighborhoods could then be grouped into six different groups with their increase in house prices to their decline in house prices. Only one group had one neighborhood that showed no decline (Mountain View). Unfortunately for this chapter and the next one, by the time the reader arrives they appear to be straight forward replications of ideas from other chapters. Chapter Nineteen is brief chapter on statistics inside politics. Aside from revealing five or six interesting correlations in voting revealed through data, this chapter merely relays what we already know: politicians implement statistics to a sometimes harmful degree (gerrymandering).

The last chapter is, appropriately, about the many sources of data exposed on the internet and the problems everyone faces in matching entities from one data source to another. The idea of using a URI to describe a movie hasn't really seemed to catch on. And if that wasn't enough, even words like "location" used to describe a column could mean drastically different things between houses and genomes. The chapter lists out a number of sources where data is available to download and tinker with (most already listed in the book) and proceeds to analyze an algorithmic (collective reconciliation) way for a system to differentiate between two movies with the same name. Naturally the author of this chapter worked on freebase which was recently (and predictably) acquired by Google. Although a short chapter, it speaks to problems that all online data communities face and what prohibits mashups from automagically happening between two disparate data sources holding data that is actually related.

With the exception of chapter six, every chapter offered me something that I won't forget. More importantly, most chapters offered a data source or data processing tool that expanded my toolbox of things to use when programming. The only reason this book misses a perfect 10/10 from me is chapter six and a couple of the later chapters feeling like weaker ideas from earlier chapters rehashed into a different domain. A worthwhile book if you work with data — whether you be a consumer or producer.

You can purchase Beautiful Data: The Stories Behind Elegant Data Solutions from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

eldavojohn writes "President Barack Obama has announced that on August 31st the United States will cease all combat operations in Iraq, although 50,000 troops will remain until the end of 2011. It's been a long seven-and-a-half years, with no guarantee of this announcement actually signifying the end of violence. Pundits are already speculating on whether or not this withdrawal speech is 'Mission Accomplished 2.' It's possibly the most significant confirmation of and commitment to a withdrawal the world will hear from the United States in Iraq."

eldavojohn writes "As we strive closer and closer to quantum computing, physics may need to be improved. A paper released in Nature Physics suggests that the limit defined by Heisenberg's Uncertainty Principle can be beaten with quantum memory. From the article, 'The cadre of scientists behind the current paper realized that, by using the process of entanglement, it would be possible to essentially use two particles to figure out the complete state of one. They might even be able to measure incompatible variables like position and momentum. The measurements might not be perfectly precise, but the process could allow them to beat the limit of the uncertainty principle.' Will we find out that Heisenberg was shortsighted in limiting the power of quantum physics or will the scientists be surprised to find that such a theoretical scenario — once conducted — performs unexpectedly in Heisenberg's favor?"

angry tapir writes "One Laptop Per Child wants to join forces to help develop the Indian government's planned $35 tablet. In a congratulatory note to the government, OLPC Chairman Nicholas Negroponte said the world needs the $35 tablet, and he offered the country full access to OLPC hardware and software technology."

eldavojohn writes "Linus has announced the release of 2.6.35 for people to download and test after he found not a lot of changes between this week and last. The big features to look out for include: 'Transparent spreading of incoming network traffic load across CPUs, Btrfs improvements, KDB kernel debugger frontend, Memory compaction and Support for multiple multicast route tables' as well as various performance and graphics improvements. Linus also praised the community saying that 'regression changes only' after rc1 improved this time around and gave numbers to back it up saying 'in the 2.6.34 release, there were 3800 commits after -rc1, but in the current 35 release cycle we had less than 2000.' Good to see the process is becoming more refined and controlled after the first release candidate — hopefully there's no impending burnout."

eldavojohn writes "Linus has announced the release of 2.6.35 for people to download and test after he found not a lot of changes between this week and last. The big features to look out for include: 'Transparent spreading of incoming network traffic load across CPUs, Btrfs improvements, KDB kernel debugger frontend, Memory compaction and Support for multiple multicast route tables' as well as various performance and graphics improvements. Linus also praised the community saying that 'regression changes only' after rc1 improved this time around and gave numbers to back it up saying 'in the 2.6.34 release, there were 3800 commits after -rc1, but in the current 35 release cycle we had less than 2000.' Good to see the process is becoming more refined and controlled after the first release candidate — hopefully there's no impending burnout."

ninguna writes "The largest wildlife census of its kind conducted in Chernobyl has revealed that mammals are declining in the exclusion zone surrounding the nuclear power plant. While some stories seem to indicate nature is recovering, the actual picture isn't quite so great."

ninguna writes "The largest wildlife census of its kind conducted in Chernobyl has revealed that mammals are declining in the exclusion zone surrounding the nuclear power plant. While some stories seem to indicate nature is recovering, the actual picture isn't quite so great."

Kohenkatz writes "I have Verizon FIOS at home and my Verizon-supplied Actiontec router had the password 'password1' that the tech assigned to it when he set it up three years ago. I received an email from Verizon that said 'we have identified that your router still had a password of either password1 or admin1 and we have changed it to your serial number.' I checked and it actually had been changed. I believe this to be in response to the Black Hat presentation about the hackability of home routers. I am upset about this because Verizon should not have any way to get into my router and change the settings, especially because I own the router, not them! I looked in the router's settings and I see port 4567 goes to the router and is labeled 'Verizon FIOS Service.' Is this port for anything useful other than Verizon changing settings on my router? What security measures does Verizon have to protect that port from unauthorized access?"

We previously discussed security researcher Chris Paget's plans to demonstrate practical cell phone interception at DefCon. Paget completed his talk yesterday, and reader suraj.sun points out coverage from Wired. Quoting: "A security researcher created a $1,500 cell phone base station kit (including a laptop and two RF antennas) that tricks cell phones into routing their outbound calls through his device, allowing someone to intercept even encrypted calls in the clear. Most of the price is for the laptop he used to operate the system. The device tricks the phones into disabling encryption and records call details and content before they are routed on their proper way through voice-over-IP. The low-cost, home-brewed device ... mimics more expensive devices already used by intelligence and law enforcement agencies — called IMSI catchers — that can capture phone ID data and content. The devices essentially spoof a legitimate GSM tower and entice cell phones to send them data by emitting a signal that's stronger than legitimate towers in the area. Encrypted calls are not protected from interception because the rogue tower can simply turn it off. Although the GSM specifications say that a phone should pop up a warning when it connects to a station that does not have encryption, SIM cards disable that setting so that alerts are not displayed. Even though the GSM spec requires it, this is a deliberate choice of the cell phone makers, Paget said."

pitchpipe writes "A puzzling pattern in the cosmic rays bombarding Earth from space has been discovered by an experiment buried deep under the ice of Antarctica. ... It turns out these particles are not arriving uniformly from all directions. The new study detected an overabundance of cosmic rays coming from one part of the sky, and a lack of cosmic rays coming from another." The map of this uneven distribution comes from the IceCube neutrino observatory last mentioned several days ago.

josath writes "Texas Instruments' flagship calculator, the Nspire, was hacked to allow user-written programs earlier this year. Earlier this month, TI released an update to the OS that runs on the calculator, providing no new features, but only blocking the previous hack. Now, just a few weeks later, Nleash has been released, which defeats this protection. The battle rages on as users fight for the right to run their own software on their own hardware."

josath writes "Texas Instruments' flagship calculator, the Nspire, was hacked to allow user-written programs earlier this year. Earlier this month, TI released an update to the OS that runs on the calculator, providing no new features, but only blocking the previous hack. Now, just a few weeks later, Nleash has been released, which defeats this protection. The battle rages on as users fight for the right to run their own software on their own hardware."

eldavojohn writes "Gizmodo's got an interesting scoop on a list of IPs acquired from Peer Block revealing who is downloading the Facebook user data torrented this week: Apple, the Church of Scientology, Disney, Intel, IBM and several major government contractors just to name a few. The article notes that this doesn't mean it's sanctioned by these companies or even known to be happening, but the IP addresses of requests coming to one of the users' machines match to lists of IP blocks for each company."

Trailrunner7 writes "Microsoft will issue an out-of-band patch on Monday for a critical vulnerability in all of the current versions of Windows. The company didn't identify which flaw it will be patching, but the description of the vulnerability is a close match to the LNK flaw that attackers have been exploiting for several weeks now, most notably with the Stuxnet malware. The advance notification from Microsoft on Friday said that the company is patching a critical vulnerability that is being actively exploited in the wild and affects all supported Windows platforms. The LNK flaw in the Windows shell was first identified earlier this month when researchers discovered the Stuxnet worm spreading from infected USB drives to PCs. Stuxnet has turned out to be a rather interesting piece of malware as it not only uses the LNK zero day vulnerability to spread, but it had components that were signed using a legitimate digital certificate belonging to Realtek, a Taiwanese hardware manufacturer."

suraj.sun writes with news that the US Department of Justice has joined a lawsuit alleging Oracle of overcharging the federal government for its software products. Quoting: "In a nutshell, the lawsuit argues that Oracle's government customers — a wide array of agencies, including the State Department, the Energy Department, and the Justice Department itself — got deals 'far inferior' to those the enterprise software giant gave to its commercial clients. The allegations stem from a software deal between Oracle and the federal General Services Administration that the Justice Department says involved 'hundreds of millions of dollars in sales' and that ran from 1998 to 2006. Under the contract, Oracle was required to inform the GSA when commercial discounts improved and to offer those same discounts to government buyers. Oracle misrepresented its true commercial sales practices and thus defrauded the US, the lawsuit contends.

omarlittle writes "The US Copyright Group — a company owned by intellectual property lawyers, which has been in the news for threatening downloaders of the movie Hurt Locker — has apparently stolen their site from a competitor. At one point, even the competitor's phone number and copyright statement were copied word for word on USCG's 'settlement' website. The competitor is reportedly going to send a Cease & Desist."

Perl 6 may have been "finally coming within reach" in 2004, but now it's even closer. Reader rnddim writes "The Perl 6 implementation Rakudo Star has been released today for 'early adopters.' This release of Rakudo is different from the normal monthly compiler releases in that it is bundled with a draft of a Perl 6 book, and several modules. It's not complete, and it's not as fast as it should be, but Rakudo in its current state is proving to be usable and useful. Rakudo Star releases will come monthly or as major features or bugfixes are made. It is available for download at github.com."

Bruce Perens writes "Japan's IKAROS satellite, which earlier performed the first successful demonstration of a solar sail, has broken more new ground. Liquid-crystal displays — yes, like in your video monitor — were fabricated into strips on the edges of the solar sail. By energizing some of the LCDs and changing the reflective characteristics of parts of the sail from specular to diffuse, JAXA scientists successfully generated attitude control torque in the sail, changing the spacecraft's orientation."

mehemiah writes "The writer of the Mariposa Botnet has been arrested through international effort. The FBI said this arrest and the arrests of three alleged operators in February were the result of a two-year joint investigation into the Mariposa Botnet, which may have infected as many as eight million to 12 million computers around the world."

An anonymous reader writes "Back in June ASCAP oddly declared war on free culture, specifically calling out Creative Commons, EFF and Public Knowledge, making a number of false statements about all three. The war of words continued as the three groups responded politely, pointing out the errors in the statement from ASCAP's Paul Williams. Larry Lessig wrote a blog post where he asked Williams to debate these topics, saying that it might help if they could get away from making false statements. Williams has now publicly declined to debate saying that it's not worth his time, and once again attacking these groups for trying to 'silence' him. It's difficult to see how a request for a public discussion and debate is an attempt to silence, but that's ASCAP's position and they're sticking to it."