Slashdot Mirror

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 "ZDNet blogger Fred Muller notes that a Chinese company called Taobao has become one of the first in the country to participate in open source. After years of Chinese companies using Linux, Taobao has announced they are open sourcing TAIR, and they revealed what is believed by Muller to be the first open source repository hosted by a Chinese corporation. Muller tracked down the originator of this information and was also informed that the Linux kernel can expect contributions soon from Taobao. Several people involved with bringing open source to China have expressed concerns over a cultural divide (PDF) in regards to opening your corporation's source code to potential competition. Some people speculated that the culture created by an open source movement was irreversibly foreign to Chinese culture. Taobao is exhibiting cracks in that assumption — exciting times for open source advocates as code contributions to open source become even more multicultural."

blackbearnh writes "For years, people have been using SETI@Home to help search for signs of extraterrestrial life in radio telescope data. But Jill Tarter, director of the Center for SETI Research at the SETI Institute, wants to take things to the next level. Whereas SETI@Home basically used people's computers as part of a giant distributed network to run a fixed set of filters written by SETI researchers, Tarter thinks someone out there may have even better search algorithms that could be applied. She's teamed with a startup called Cloudant to make large volumes of raw data from the new Allen telescope available, and free Amazon EC2 processing time to crunch the data. According to Tarter: 'SETI@Home came on the scene a decade ago, and it was brilliant and revolutionary. It put distributed computing on the map with such a sexy application. But in the end, it's been service computing. You could execute the SETI searches that were made available to you, but you couldn't make them any better or change them. We'd like to take the next step and invite all of the smart people in the world who don't work for Berkeley or for the SETI Institute to use the new Allen Telescope. To look for signals that nobody's been able to look for before because we haven't had our own telescope; because we haven't had the computing power.'"

blackbearnh writes "The iPhone vs. Android wars are in full swing, but no one talks about the mobile operating system that most of the world uses: Symbian. Part of the reason, perhaps, is that the Symbian developer infrastructure is so different from the Wild West approach that Apple and Google take. Over at O'Reilly Answers, Paul Beusterien, who is the Head of Developer Tools for the Symbian Foundation, talks about why Symbian gets ignored as a platform despite the huge number of handsets it runs on. Quoting: 'Another dimension is the type of developer community. [Historically, Symbian's type of developers] were working for consulting houses or working at phone operator places or specifically doing consulting jobs for enterprise customers who wanted mobile apps. So there's a set of consulting companies around the world that have specialized in creating apps for Symbian devices. It's a different kind of dynamic than where iPhone has really been successful at attracting just the hobbyist, or the one- or two-person company, or the person who just wants to go onto the web and start developing.'"

theodp writes "When it comes to tech academic credentials, Zoho CEO Sridhar Vembu has The Right Stuff: a Ph.D. in EE from Princeton. But Vembu has eschewed Google's Army-of-Ph.D.s approach to software development in favor of tapping into the ranks of high school grads who would not normally go to college for Zoho. Seeing his youngest brother succeed at programming without a college degree convinced Vembu that others could follow that example with the proper training and guidance. And studying the best employees in his own company led to another epiphany: 'What if the college degree itself is not really that useful?' thought Vembu. 'What if we took kids after high school, train them ourselves?'"

miller60 writes "The average web page takes 4.9 seconds to load and includes 320 KB of content, according to Google executive Urs Holzle. In his keynote at the O'Reilly Velocity conference on web performance, Holzle said that competition from Chrome has made Internet Explorer and Firefox faster. He also cited the potential for refinements to TCP, DNS, and SSL/TLS to make the web a much faster place, and cited compressing headers as a powerful performance booster. Holzle also noted that Google's ranking algorithm now includes a penalty for sites that load too slowly."

blackbearnh writes "As more non-traditional programmers start playing around with embedded platforms like the Arduino, the limitations and complications of interrupt-driven event handling can become an annoying barrier to entry. Now a group of academics have ported the parallel-processing language Occam to the Arduino. In an interview on O'Reilly Answers, Matt Jadud of Allegheny College describes how Occam helps artists using the Arduino in their installations, and how the advent of low-cost computing platforms is changing the educational experience for proto-makers in school. 'Basically, an artist or a tinkerer or a hacker has a goal. They don't really care about learning Occam. They don't care about how this language is different from C. They just want to make a cat door that keeps their cat out when the cat comes back with a mouse. Or they want to make some kind of installation piece. Trying to focus as much on the user and the possible goals they might have is what's motivating our work right now.'"

theodp writes "In 2008, Washington, DC, launched one of the hotter trends in public-sector technology: the 'apps contest'. But even as more jurisdictions jump on the bandwagon, the contests are reportedly producing uneven results, and the city that started it all is jumping off the bandwagon. 'I don't think we're going to be running any more Apps for Democracy competitions quite in that way,' says Bryan Sivak, who became the District's CTO in 2009. Sivak calls Apps for Democracy a 'great idea' for getting citizen software developers involved with government, but he also hints that the applications spun up by these contests tend to be more 'cool' than useful to the average city resident. 'If you look at the applications developed in both of the contests we ran, and actually in many of the contests being run in other states and localities,' Sivak says, 'you get a lot of applications that are designed for smartphones, that are designed for devices that aren't necessarily used by the large populations that might need to interact with these services on a regular basis.' Sivak also cited maintenance of the new apps over the long term as a concern."

An anonymous reader points out an 18-month-old interview with the founders of Adobe (and creators of PostScript) Charles Geschke and John Warnock, and highlights three interesting quotes from the book Masterminds of Programming that seem very timely now. "'It is so frustrating that this many years later we're still in an environment where someone says if you really want this to work you have to use Firefox. The whole point of the universality of the Web would be to not have those kind of distinctions, but we're still living with them. It's always fascinating to see how long it takes for certain pieces of historical antiquity to die away. The more you put them in the browsers you've codified them as eternal, and that's stupid. ... With Flash what we're trying to do is both beef it up and make it robust enough so that at least you can get one language that's platform-independent and will move from platform to platform without hitting you every time you turn around with different semantics. ... You can see why, to a certain extent, Apple and Microsoft view that as a challenge because they would like you to buy into their implementation of how the seamless integration with the Web goes. What we're saying is it really shouldn't matter. That cloud ought to be accessible by anybody's computer and through any sort of information sitting out on the Web."

macslocum writes "Amid the uproar over Facebook's privacy maneuvers, Tim O'Reilly offers a contrarian view. He writes: 'The essence of my argument is that there's enormous advantage for users in giving up some privacy online and that we need to be exploring the boundary conditions — asking ourselves when is it good for users, and when is it bad, to reveal their personal information. I'd rather have entrepreneurs making high-profile mistakes about those boundaries, and then correcting them, than silently avoiding controversy while quietly taking advantage of public ignorance of the subject, or avoiding a potentially contentious area of innovation because they are afraid of backlash. It's easy to say that this should always be the user's choice, but entrepreneurs from Steve Jobs to Mark Zuckerberg are in the business of discovering things that users don't already know that they will want, and sometimes we only find the right balance by pushing too far, and then recovering.'" Facebook has confirmed it is working on more changes to its privacy policy in response to feedback from users.

blackbearnh writes "Carmen Medina, until recently, helped run the analysis side of the house at the CIA. She also ran the agency's think tank, the Center for the Study of Intelligence. A self-proclaimed heretic, she has a number of controversial views about how we gather intelligence and how technology is changing the game. She talked to O'Reilly Radar about this and other topics, including the possible ways that intelligence analysis could be crowdsourced, why government technology procurement is so broken, and how the public may need to readjust its views on what things such as privacy mean. Medina said, 'Government is viewed as inefficient and wasteful by American citizens. I would argue that one of the reasons why that view has grown is that they're comparing the inefficiency of government to how they relate to their bank or to their airline. Interestingly enough, for private industry to provide that level of service, there are a lot of legacy privacy barriers that are being broken. Private industry is doing all sorts of analysis of you as a consumer to provide you better service and to let them make more profit. But the same consumer that's okay with private industry doing that is not okay, in a knee-jerk reaction, with government doing that. And yet, if government, because of this dynamic, continues not to be able to adopt modern transactional practices, then it's going to fall further behind the satisfaction curve.'"

Michael J. Ross writes "Like all major programming languages, JavaScript can be extended in functionality through the use of libraries, such as jQuery, which is currently seeing tremendous popularity and enhancement in the Web development community. Designers and developers who want to learn how to use jQuery for creating rich user interfaces through client-side JavaScript are advised to begin their journey to jQuery proficiency by reading one of the many books dedicated to this powerful JavaScript resource — such as jQuery Cookbook: Solutions & Examples for jQuery Developers." Read below for the rest of Michael's review. jQuery Cookbook author Various authors pages 480 pages publisher O'Reilly Media rating 9/10 reviewer Michael J. Ross ISBN 978-0596159771 summary An extensive collection of solutions to jQuery problems. This book was published by O'Reilly Media on 19 November 2009, under the ISBN 978-0596159771, and is authored by no fewer than 19 contributors — all quite knowledgeable of JavaScript and jQuery — and edited by one of those contributors, Cody Lindley. On the publisher's page for the book, visitors can read the book's description, table of contents, and errata, of which there are 22 as of this writing, although none have been confirmed by the authors or publisher. Visitors can also download all of the sample code used in the book, in addition to the eight code demos for Chapter 13. Lastly, prospective buyers can purchase the print version of the book, the electronic one (in PDF, ePub, and Mobi format), or the two combined at a considerable discount — or read the book as part of Safari Books Online.

jQuery Cookbook's 480 pages are organized into 18 chapters, covering a wide range of topics: the basics, element selection, utilities, dimensions, effects, events, forms, plug-ins, user interfaces, theming, Ajax, data formats, and testing. Lindley starts off the first chapter, titled "jQuery Basics," by presenting the advantages, philosophy, and organization of jQuery. Readers will likely chuckle at his suggestion that they memorize the jQuery API outline, which comprises two pages. The many code snippets are quite helpful, but they are needlessly long, partly because most of them contain far more HTML elements than are needed to illustrate the point, and also because each snippet contains the DOCTYPE and head tags, among others — often taking up more lines on the page than does the code pertinent to the topic at hand. This pointless and space-wasting redundancy is seen also in a few of the chapters that follow. As well, some of the passages in the first chapter's narrative are oddly phrased, frequently requiring a rereading of the material, while others could be made more concise. Additionally, some of the sample code contains bugs, which fortunately are detailed on the errata page mentioned earlier. The second chapter, "Selecting Elements with jQuery," presents numerous techniques for specifying elements within the DOM. The only obvious blemish in the material is in section 2.4, where the author refers to animated elements, but with absolutely no explanation as to what that means; countless new readers may assume he is referring to animated GIFs. Nonetheless, these two chapters form a helpful foundation for the rest of the manuscript.

The third chapter, "Beyond the Basics," gets off to a questionable start with the assertion that "jQuery can [] extend jQuery to infinite possibilities," which sounds like a line wisely rejected for the movie Toy Story. Yet the discussion continues on a solid footing, as it covers more advanced techniques for working with selected elements. Some of the discussion overlaps material presented in the previous two chapters, but it is always worthwhile to hear critical concepts explained from a different perspective. However, section 3.8, which briefly introduces jQuery plug-ins, is out of place; that material should be folded into Chapter 12, which focuses on that topic. The fourth chapter may be brief, but it explains several jQuery utility methods. Most of the code snippets use a format of "(function($) (jQuery);" — whose usage and advantages are not explained in this chapter, nor any earlier ones. This points up one of the key downsides of having almost every chapter of a programming book written by separate authors: readers can be confused or misled by disparities in coding practices, especially when the reasoning behind them is not given. The title of the fifth chapter, "Faster, Simpler, More Fun," is a bit misleading, because the authors don't explain how to make one's jQuery programming simpler or more fun, but they do provide a great deal of information on troubleshooting, performance optimization, and jQuery coding practices, including those pertaining to progressive enhancement, accessibility, and unobtrusiveness. Section 5.19 lacks a figure showing the menu being discussed, but that's the only obvious flaw.

The remaining chapters are dedicated to more specific aspects of jQuery programming, including the important topics of page layout as well as element positioning and sizing, discussed in Chapter 6. The subsequent chapter delves into effects, which is one of the more exciting topics in the jQuery realm. Even though a portion of the readers may be put off by the trickiness of the code, the material does demonstrate some of the powerful capabilities of jQuery effects — which in conjunction with HTML5 may easily encroach on areas of client-side programming formerly dominated by Adobe Flash. Throughout Chapter 7, most if not all places where the author refers to the "mouse," he apparently means the "mouse pointer." Events play a critical role in JavaScript software, and even more so for code that is mostly jQuery — thus the value of chapters 8 and 9, which examine basic and advanced event handling. The next pair of chapters discuss a variety of techniques for enhancing HTML forms, from scratch and through the use of jQuery plug-ins. The sample source code is better commented than what is seen elsewhere in the book, and the explanations are quite good. The subsequent chapter focuses on jQuery plug-ins, beyond their usage within HTML forms, and briefly explains how to create your own plug-ins and how to perform unit testing on them.

Because JavaScript is primarily a client-side technology, it should come as no surprise that jQuery can prove an outstanding tool in crafting user interfaces for Web sites and Web-based applications. Chapters 13 through 15 explore such topics as drop-down menus, sliding panels, rotating images, modal windows, tooltips, the jQuery UI, and how to style jQuery UI widgets, a.k.a., theming. No Web interface is an island, and over the years there have emerged a number of data formats and protocols for utilizing those formats for transmitting information between browsers and servers — such as Ajax, XML, JSON, and JSONP — covered in Chapter 16. Finally, the last two chapters of the book are geared more to testing and deployment, and less so to interface design and development. The topics covered include techniques for persisting data in the browser, managing large amounts of code and data for major software projects, automating the unit testing of jQuery code, testing callbacks and user actions, grouping and selecting tests, and more.

Overall, jQuery Cookbook starts off with some basics, and only then moves on to higher-level concepts and related use cases. However, the book is ostensibly aimed at beginners and intermediate JavaScript programmers, but the former group may find the ideas difficult to grasp fully, despite the introductory chapters — because some of the techniques are fairly advanced, they involve terminology unfamiliar to anyone new to jQuery, and some of that terminology is not explained. On the other hand, the recipes are generally well written and clear, supplemented with properly tested and working code. Consequently, anyone who takes the time to work through the examples patiently, should be well rewarded.

Because of its coverage of a wide range of topics, jQuery Cookbook can be used not only as a learning aid, but in some respects also as a reference — and in this regard the book's index will be quite useful. In light of the considerable length of the manuscript, reading it from stem to stern would involve an investment of time — especially if one were to work through all of the examples and try them out in one's own development environment — quite easily, in fact, since all of it can be downloaded from the publisher's site. Most of it, however, is organized as plain text files, and not HTML files; and no reason is provided for this annoying choice.

In terms of the layout and appearance of the text and figures, one flaw is that in countless lines throughout the book, the words are jammed together, making it difficult to read the text rapidly. In fact, some of these lines almost look like single words. This is also seen in the subheads, an excellent example of which can be found on page 149: "Solution2:ChangingthehrefAttributeoftheStylesheetThat'sResponsible." Unfortunately, the same is true for much of the source code, but in a different sense: Operators and variables are jammed together, clearly illustrating the need for whitespace in making code more readable. Some of the code is excessively long (noted earlier), and the authors are inconsistent as to whether their JavaScript is placed at the end of the body element or in the header element. Nonetheless, the sample code is generally of good quality.

There is another aspect related to not only this book but all other computer programming books for which individual chapters are written by different authors: jQuery Cookbook does not seem to be a single book, but instead a collection of books that were bundled together because of a common thread, namely, jQuery. This leads to some of the problems mentioned earlier, such as discrepancies in coding techniques and formatting — from which the beginning reader is supposedly learning best practices. On the other hand, the multi-author approach makes it possible for each major subject area to be handled by one or more writers who are expert in that particular area — which in turn results in a better product overall, even if one or two of the chapters are noticeably weaker than the others.

The book contains a number of copyediting flaws not listed on the aforementioned errata page: "elevated" should instead read "alleviated" (page 12); "or [its] alias" (13); "could change" should read "could be changed" (26); "jQuery('a')removeAttr('title')" is missing a "." (30); "'blue')" is missing a terminating ";" (50); "season in" should read "season" (56); "was contained" should read "is contained" (144); "position: absolute" in the narrative should not be broken between two lines (156); "great[er] than" (157); "equal[-]sized panels" (160); "only running" should read "only runs" (165); "still support[s]" (168), "#source5txt" should read "#source4txt" (217); and at this point I stopped recording errata. Also, in countless places in most of the chapters, semicolons are used where dashes are called for, and vice versa. O'Reilly's copyeditors should have detected and fixed those errors prior to publication.

Yet most of these blemishes are of little significance. What really counts is the overall value provided to the reader: Usable for both learning and reference, jQuery Cookbook delivers a tasty buffet of programming essentials, best practices, illustrative examples, optimization tips, and other information of value to JavaScript developers who wish to spice up their Web creations with jQuery.

Michael J. Ross is a freelance website developer and writer.

You can purchase jQuery Cookbook: Solutions & Examples for jQuery Developers from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

blackbearnh writes "There's an interesting article up on O'Reilly Radar talking about how the US military is reacting to the increasing use of social media by soldiers in hostile territory. In an interview, Price Floyd, Principal Deputy Assistant Secretary of Defense for Public Affairs, talks about the trade-offs between operational security and allowing soldiers and the public to interact, and how social media has changed the way the DoD communicates with the public. 'I think that we need to become much more comfortable with taking risk, much more comfortable with having multiple spokesmen out there, thousands of spokesmen in essence. But, for me, there's nothing more credible than the men and women who are out there on the front lines, fighting the wars that we're in, sending messages back to their family and friends.'"

macslocum writes "Opera's Charles McCathieNevile examines the most significant web browser innovations of the last few years, and he looks ahead to the browser's near-term future."

blackbearnh writes "Usually, Gov 2.0 deals mainly with outward transparency of government to the citizens. But SeeClickFix is trying to drive data in the other direction, letting citizens report and track neighborhood problems as mundane as potholes, and as serious as drug dealers. In a recent interview, co-founder Jeff Blasius talked about how cities such as New Haven and Tucson are using SeeClickFix to involve their citizens in identifying and fixing problems with city infrastructure. 'We have thousands of potholes fixed across the country, thousands of pieces of graffiti repaired, streetlights turned on, catch basins cleared, all of that basic, broken-windows kind of stuff. We've seen neighborhood groups form based around issues reported on the site. We've seen people get new streetlights for their neighborhood, pedestrian improvements in many different cities, and all-terrain vehicles taken off of city streets. There was also one case of an arrest. The New Haven Police Department attributed initial reports on SeeClickFix to a sting operation that led to an arrest of two drug dealers selling heroin in front of a grammar school.'"

blackbearnh writes "Brian Aker, former Sun MySQL guy, and current proponent of the Drizzle MySQL fork, gave O'Reilly Radar an update on where MySQL is at the moment. During the interview, he was asked to speculate on Oracle's original motives for acquiring Sun. 'IBM has been moving their pSeries systems into datacenter after datacenter, replacing Sun-based hardware. I believe that Oracle saw this and asked themselves, "What is the next thing that IBM is going to do?" That's easy. IBM is going to start pushing DB2 and the rest of their software stack into those environments. Now whether or not they'll be successful, I don't know. I suspect once Oracle reflected on their own need for hardware to scale up on, they saw a need to dive into the hardware business. I'm betting that they looked at Apple's margins on hardware, and saw potential in doing the same with Sun's hardware business. I'm sure everything else Sun owned looked nice and scrumptious, but Oracle bought Sun for the hardware.'"

Apple's much-awaited iPad officially launched today, and iFixit has gotten their hands on photos from the FCC teardown. They've done an analysis of the internals and provided directions on doing it yourself, if you're so inclined. Predictably, it's a hot topic in the media. Cory Doctorow wrote about why he won't be getting an iPad, complaining about the closed, hacker-unfriendly design and what he calls the "Wal-martization of the software channel." Daring Fireball's John Gruber disagrees, pointing out that enthusiasts — even kids exercising their curiosity — are still quite capable of playing around with the iPad through app creation, and with much more of a chance to compete with big companies than in the Apple ][ days. Similarly, others are referring to it as the "bedtime computer" — technology that has a reasonable shot at expanding into completely new areas of use, like bedtime reading for kids. Such a device was predicted in 1972 by Alan Kay, the PARC scientist credited with the epigram "The best way to predict the future is to invent it." His hypothetical DynaBook bears striking similarity to what Apple finally came up with. So, those of you who have picked up or received an iPad already: how do you like it?

macslocum writes "Tim O'Reilly: 'I've been talking for years about "the internet operating system," but I realized I've never written an extended post to define what I think it is, where it is going, and the choices we face. This is that missing post. Here you will see the underlying beliefs about the future that are guiding my publishing program as well as the rationale behind conferences I organize.'"

macslocum writes "Nat Torkington begins sketching out an open data process that borrows liberally from open source tools: 'Open source discourages laziness (because everyone can see the corners you've cut), it can get bugs fixed or at least identified much faster (many eyes), it promotes collaboration, and it's a great training ground for skills development. I see no reason why open data shouldn't bring the same opportunities to data projects. And a lot of data projects need these things. From talking to government folks and scientists, it's become obvious that serious problems exist in some datasets. Sometimes corners were cut in gathering the data, or there's a poor chain of provenance for the data so it's impossible to figure out what's trustworthy and what's not. Sometimes the dataset is delivered as a tarball, then immediately forks as all the users add their new records to their own copy and don't share the additions. Sometimes the dataset is delivered as a tarball but nobody has provided a way for users to collaborate even if they want to. So lately I've been asking myself: What if we applied the best thinking and practices from open source to open data? What if we ran an open data project like an open source project? What would this look like?'"

snydeq writes "Peter Wayner provides a developer's comparison of Android and the iPhone and finds Android not only competitive but in fact a better choice than the iPhone for many developers, largely due to its Java foundation. 'While iPhone developers have found that one path to success is playing to our baser instincts (until Apple shuts them down), a number of Android applications are offering practical solutions that unlock the power of a phone that's really a Unix machine you can slip into your pocket,' Wayner writes, pointing out GScript and Remote DB as two powerful tools for developers to make rough but workable custom tools for Android. But the real gem is Java: 'The pure Java foundation of Android will be one of the biggest attractions for many businesses with Java programmers on the staff. Any Java developer familiar with Eclipse should be able to use Google's Android documentation to turn out a very basic application in just a few hours. Not only that, but all of the code from other Java programs will run on your Android phone — although it won't look pretty or run as fast as it does on multicore servers.'"

Brady Forrest writes "Next week, from March 1-5 there will be ~65 Ignite events happening around the world. Ignite is an opportunity for geeks to share their passions and ideas with local peers. Each speaker gets 20 slides that each auto-advance after 15 seconds for a total of just 5 minutes. The result is bite-size chunks of information that inform the crowd on new topics. Most of the Ignites will be streamed on the new Ignite video site."

theodp writes "When it comes to Amazon CEO Jeff Bezos' 1-Click patent, the USPTO is an agency that just can't say no. Or yes. It's now been 4+ years since actor Peter Calveley submitted prior art that triggered a USPTO reexamination of the 1-Click patent. Still no 'final answer' from the USPTO, although an Examiner recently issued yet another Final Rejection of 1-Click related claims (pdf), admonishing Amazon for making him 'sift through hundreds of submitted references to identify what applicant allegedly has already submitted,' which he complained is 'adding an undue burden' to his workload. Looks like Bezos' 2000 pledge of 'less work for the overworked Patent and Trademark Office' isn't working out so well in practice. Not too surprising — after all, Amazon did inform Congress that it 'has modified its specific [patent] reform proposals from the year 2000.'"

Google announced Buzz today, as we anticipated this morning. CNET has a workmanlike description of the social-networking service, which is integrated into gmail. CNET identifies a central obstacle Buzz will have to overcome to gain traction: "The problem, however, will be the increasing backlash Google is seeing from the general public over how much data the company already controls on their online habits." Buzz is being rolled out over the next few days so some people will see a Buzz folder in their gmail, but most won't yet (this Twitter post explains how Safari users can get an early glimpse). A blog posting up at O'Reilly Answers points out some of the distinguishing characteristics of Google Buzz — one interesting one being its ability to post an update either publicly or privately, at the user's option. This design choice places it between the public-by-default Twitter and the private-by-default Facebook. Lauren Weinstein sounds a note of caution about the inherent privacy risks of Google's method of filling out initial friend profiles by automatic friending.

blackbearnh writes "As newspapers struggle to survive and local broadcasts try to find a way to compete with cable news, more and more news outlets are banking on what people want to hear about, rather than what they need to hear. Thoughtful analysis of problems is being pushed out of the way to make room for more celebrity gossip. Electronic news guru Chris Lee thinks that as people get news increasingly tailored to their tastes, the overall knowledge of important issues is plummeting. 'I think one of the observations about how consumers are behaving in the past five years that has surprised me the most is, again, this lack of feeling responsible for knowing the news of their country and their local government of that day. I don't think it's just a technology question. I think if you asked people now versus the same age group 20 years ago, I think they'd be stunningly less informed now about boring news, and tremendously more knowledgeable about bits of news that really interest them.'"

blackbearnh writes "As previously reported on Slashdot, PayPal recently released a series of new APIs that allow developers to embed PayPal into their web sites and applications without requiring the user to go to the PayPal web site to complete the transaction. To encourage developers to use these new APIs, PayPal is offering two prizes totaling $150,000 for interesting new applications. The entry deadline to register ideas is December 16th, and O'Reilly has an interview with the director of the PayPal Developer Network that covers the details of the contest. In it, Naveed Anwar talks about why PayPal is throwing money at developers. 'When Facebook opened up their platform, it allowed people to work in that particular environment, in the Facebook environment. When the iPhone opened up their platform, they allowed people to work in their environment which was build the applications on the iPhone. When PayPal was looking at opening up its platform, we are not limited by one particular area. We go into the enterprises. We go into social networking. We go into all the places where payment as a solution is needed. And if we can actually reduce that barrier of entry — because at the end of the day, when anyone is building out a business and anyone is building out an application, they're looking at ways of monetizing it.'"

blackbearnh writes "The work of making high-volume web sites perform well is an ongoing challenge, and one that continues to evolve as the nature of web content changes. According to Google Performance Guru Steve Souders, fat JavaScript libraries and rich content are creating new problems for web site tuning, but one of the biggest problems lies outside the control of web site administrators — ad servers. In an interview previewing the upcoming Velocity Online conference run by O'Reilly, Souders talks at length about the real causes of poor web performance today, and in particular, the effect that poorly performing ad servers are creating. 'We adopted a framework of inserting ads, of creating ads, that's pretty simple. And because it's pretty simple, it's not highly tuned. That's one reason why we shouldn't be too surprised that we see performance issues in third party ads. The other reason is that ad services are not focused on technology. Certainly companies like Yahoo and Google and Microsoft, we're technology companies. We focus on technology. So it's not surprising that our web developers are on the leading edge of adopting these performance best practices. And it's also not surprising that ad services might lag two, three or four years behind where these web technology companies are.'"

Rubinstien writes "O'Reilly Radar is reporting on an effort to produce Law.gov, 'America's Operating System, Open Source.' The group Public.Resource.Org seeks to 'create a solid business plan, technical specs, and enabling legislation for the federal government to create Law.gov. [They] envision Law.gov as a distributed, open source, authenticated registry and repository of all primary legal materials in the United States.' According to its new website, 'Law.gov would be similar to Data.gov, providing bulk data and feeds to commercial, non-commercial, and governmental organizations wishing to build web sites, operate legal information services, or otherwise use the raw materials of our democracy.'"

stoolpigeon writes "Google's mobile OS Android has received plenty of press. As with a lot of Google products, there was much anticipation before any devices were even available. Now a number of phones are available, with many more coming out world-wide in the near future. Part of the lure of Android is the openness of the platform and the freely available tools for development. The SDK and accompanying Eclipse plug-in give the would be creator of the next great Android application everything they need to make their idea reality. The bar to entry in the official Google Android Marketplace is very low and it doesn't seem to be much of a stretch to predict that the number of developers working on Android is only going to grow. As with any hot technology the number of books will grow as well and O'Reilly's Android Application Development has jumped into the fray, promising to help budding Android developers what they need to get started." Read on for the rest of JR's review. Android Application Development: Programming with the Google SDK author Rick Rogers, John Lombardo, Zigurd Mednieks, Blake Meike pages 332 publisher O'Reilly Media Inc. rating 7/10 reviewer JR Peck ISBN 978-0-596-52147-9 summary Programming with the Google SDK. The book begins with a brief introduction to Android followed by detailed instructions on procuring and installing the Android SDK. Space is given to Windows, Linux and Mac. The install is relatively simple on all three platforms, extra information is provided for Ubuntu users but no others distributions. Extra care is taken to help Windows users with items they may not use regularly, such as environmental variables. This is all pretty basic and gives the book very much of a 'for beginners' feel. Before I had the book I had already installed the SDK and Eclipse plug-in on Windows, Ubuntu and Fedora without any issues beyond getting a current version of Eclipse for the Ubuntu machine. The version I already had from the Ubuntu repositories was not able to run the plug-in. It's a short chapter and if someone really struggles with it, they probably should shift their focus from learning to code to learning how to use their platform of choice. This does set the tone though, that this is a book for those who are very new to development.

Chapter two steps the reader through the ever present "Hello World" and gives an overview of the structure of Android applications. Chapter three introduces the example application that will be used for the rest of the book. There is a lot of repetition here on just what directories and files make up the guts of an Android program. I was quickly worried ( the first four chapters are only fifty-six pages in ) that maybe four authors had been too many. The repetition made it feel as if separate work had been combined without enough editing to remove what was redundant. Fortunately this got better, though there was still a strange proclivity to list files while referring to earlier chapters that explained their purpose. This would be helpful to anyone jumping right into the middle of the book, but the index also serves the same purpose and saves space for more valuable content, as opposed to explaining the purpose of AndroidManifest.xml repeatedly.

Once I moved into the fifth chapter, Debugging Android Applications and the following chapters, things got better. The pace picked up and the repetition dropped off for the most part. The book did not become incredibly difficult, trying to be everything to everyone, but did maintain an introductory style. At the same time the example application makes use of many Android features that are likely to be used by developers. How to set up and use tools was covered step by step. This is very nice but did cause some issues for the authors due to the rapid pace of development on Android. A visit to the book's errata page will show that many readers struggled with changes to the SDK tool set that came out very shortly after the book. The authors say that future editions will fix these issues, but this creates a dilemma for that reader needing introductory level materials. They are more dependent upon the book than a more advanced user and so these issues can be very trying. Based on the responses to the errata posts it became trying for the authors as well. This isn't a knock on the book itself but rather a limitation of the delivery method.

Once the reader is digging down into the example application the team approach to writing the book does become an asset. The authors bring a number of skills to the table that closely resemble the players that would be necessary to a team developing a real-world application. The reader is now being pulled into an example that benefits from the knowledge of each and does a good job of exploring the range of options an Android developer has available. This includes core functionality, UI options and how to best take advantage of the platform while at the same time taking performance and user expectations into account. I felt like I was getting something beyond the excellent documentation provided by Google. This is where I felt the book stood strongest.

Working with a single, large example application was a move that probably helped move things along on writing the book and I think it's an interesting approach. The problem is of course, that means that this example must be right. Right for the task and technically correct. Small issues in the code are inevitable but now their impact is book wide. The changes to the platform just made it just that much more difficult to sort out. On the whole I still found this to be a better approach primarily due to the fact that it gives the features highlighted a better sense of context. Stand-alone examples are often good at highlighting technical features but completely ignore the issues necessary to using the feature in a larger piece of code.

I'm a fan of O'Reilly books. Interestingly enough this doesn't mean that I'll gloss over issues with what they produce. The result is actually the inverse, in that I go into all their titles with a high level of expectation with regards to quality on every level. This may mean that though I strive to be neutral when I look at a book, I'm probably a little tougher on O'Reilly titles. This made my rough start with Android Application Development a bit jarring. The repetition and what felt like sloppy editing are not what I expect. I was quickly given a sense that this book may have been rushed to publication a little sooner than it should have been. As I moved deeper into the book, things improved and while I think there were still editorial issues, things did seem to smooth out to some degree.

There is an interesting tension that exists purely do to the nature of print books. I don't like to bring up print versus electronic in reviews as I don't think it is on topic, but here it is unavoidable. The book is aimed at people that need a little more hand holding and help getting going. It does a good job of providing step by step instructions, the problem is that some of those steps have changed. I don't think anything in the code itself needs to be different, but the tools have changed enough that getting the code to run in a development environment against the new SDK is different. That means that portion of the book is no longer of as much value without going to other sources to find the new steps.

That said, warts and all I found this to be a helpful way to get my feet wet with Android. I really look forward to future versions as I think just a little more time and work will move this from my 'good' list to my 'great' list. Making things a little tighter and cleaning up the few typos and errors would certainly make this an 8 instead of an 7, which is really substantial in my mind. I'm no super developer and I need stuff like this, that can take things a little more slowly and make it all clear. I think this guide is great for those of us in that category as long as the reader is o.k. with hopping to external sources for the information they'll need to get the newer tool set working.

You can purchase Android Application Development: Programming with the Google SDK from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

blackbearnh writes "With the release of the 3.1 iPhone OS, application developers will finally be able to develop augmented reality (AR) apps. In other words, Terminator Vision is right around the corner. O'Reilly Media recently talked to Chetan Damani, one of the founders of Acrossair, about how they developed their new AR application, Nearest Tube, which displays the closest London Tube stations over a live video overlay on an iPhone 3GS. According to Damani, developing AR applications on the 3GS is dead easy, and the real trick will be developing good augmented reality apps. 'It's all about who's going to have the most amount of data and the most valid data. So there's the obvious types of apps which you're going to launch and those are the find me my nearest bar, find me my nearest event, find me the nearest tube stop, find me the nearest ATM. And those sorts of apps are all going to be around. But they're only going to be useful for when you're trying to look for things. So if we want to get users to use augmented reality a little bit more, we have to start introducing other bits of functionality, things like show me the offers available in a particular high street. Show me when I'm walking down a high street if there's a table available at a particular restaurant. And it's that sort of interactivity and providing that real-time data in this augmented reality view which is going to start getting people to use it a lot more rather than just for show me where the nearest area is.'"

blackbearnh writes "With the release of the 3.1 iPhone OS, application developers will finally be able to develop augmented reality (AR) apps. In other words, Terminator Vision is right around the corner. O'Reilly Media recently talked to Chetan Damani, one of the founders of Acrossair, about how they developed their new AR application, Nearest Tube, which displays the closest London Tube stations over a live video overlay on an iPhone 3GS. According to Damani, developing AR applications on the 3GS is dead easy, and the real trick will be developing good augmented reality apps. 'It's all about who's going to have the most amount of data and the most valid data. So there's the obvious types of apps which you're going to launch and those are the find me my nearest bar, find me my nearest event, find me the nearest tube stop, find me the nearest ATM. And those sorts of apps are all going to be around. But they're only going to be useful for when you're trying to look for things. So if we want to get users to use augmented reality a little bit more, we have to start introducing other bits of functionality, things like show me the offers available in a particular high street. Show me when I'm walking down a high street if there's a table available at a particular restaurant. And it's that sort of interactivity and providing that real-time data in this augmented reality view which is going to start getting people to use it a lot more rather than just for show me where the nearest area is.'"

Michael J. Ross writes "Slow Web page loading can discourage visitors to a site more than any other problem, regardless of how attractive or feature-rich the given site might be. Consequently, many Web developers hope to achieve faster response times using AJAX (Asynchronous JavaScript and XML), since only portion(s) of an AJAX page need to be reloaded. But for many rich Internet applications (RIAs), such potential performance gains can be lost as a result of non-optimized JavaScript, graphics, and CSS files. Steve Souders — a Web performance expert previously at Yahoo and now with Google — addresses these topics in his second book, Even Faster Web Sites: Performance Best Practices for Web Developers." Read on for the rest of Michael's review. Even Faster Web Sites author Steve Souders pages 254 pages publisher O'Reilly Media rating 8/10 reviewer Michael J. Ross ISBN 978-0596522308 summary Advanced techniques for improving website performance. The book was published by O'Reilly Media on 18 June 2009, under the ISBN 978-0596522308. The publisher makes available a Web page, where visitors can purchase the print and electronic versions of the book (as well as a bundle of the two), read the book online as part of the Safari library service, and check the reported errata — comprising those confirmed by the author (of which there are currently two) and any unconfirmed errors (all six of which are valid, though the fifth one may be a coincidence). In a break with traditional practice among technical publishers nowadays, there is no sample chapter available, as of this writing.

In many ways, this second book is similar to Steve's previous one, High Performance Web Sites: It presents methods of enhancing the performance of websites, with a focus on client-side factors. It is fairly slender (this one is 254 pages), relative to most programming books nowadays, and the material is organized into 14 chapters. However, unlike its predecessor, Even Faster Web Sites emphasizes generally more advanced topics, such as script splitting, coupling, blocking, and chunking (which to non-developers may sound like a list of the more nefarious techniques in professional hockey). This second book also has employed a team approach to authorship, such that six of the chapters are written by contributing authors. In his preface, Steve notes that the 14 chapters are grouped into three broad areas: JavaScript performance (Chapters 1-7), network performance (Chapters 8-12), and browser performance (Chapters 13-14). The book concludes with an appendix in which he presents his favorite tools for performance analysis, organized into four types of applications: packet sniffers, Web development tools, performance analyzers, and some miscellaneous applications.

In the first chapter, "Understanding Ajax Performance," guest author Douglas Crockford briefly describe some of the key trade-offs and principles of optimizing applications, and how JavaScript now plays a pivotal role in that equation — as websites nowadays are designed to operate increasingly like desktop programs. On pages 2 and 3, he uses some figures to illustrate fixed versus variable overhead, and the dangers of attempting to optimize the wrong portions of one's code. By the way, the so-called "axes" are not axes, or even Cartesian grid lines, but simply levels. Aside from its choppy narrative style and a pointless religious reference in the first paragraph, the material serves as a thought-provoking springboard for what follows. Chapter 2, titled "Creating Responsive Web Applications," was written by Ben Galbraith and Dion Almaer, who discuss response times, user perception of them, techniques for measuring latency, browser threads, Web Workers, Google Gears, timers, and memory issues. The material is neatly explained, although Figure 2-2 is quite confusing; moreover, both of the figures on that page should not have been made Mac- and Firefox-specific.

In the subsequent four chapters, Steve dives into the critical topic of how to optimize the performance of JavaScript-heavy pages through better script content and organization — specifically, how and when to split up large scripts into smaller ones, how to load scripts without blocking one another or breaking dependencies within the code, and how to best in-line scripts, when called for. Each of the four chapters follows an effective methodology: The first author delineates a particular performance mistake made by even some of the most popular websites, with the statistics to back it up. He presents one or more solutions, including any relevant tools, again with waterfall charts illustrating how well the solutions work. Lastly, he explains any browser-specific issues, oftentimes with a handy chart showing which possible method would likely be optimal for the reader's given situation, such as expected browser choices in the site's target audience. When there are potential pitfalls, Steve points them out, with helpful workarounds. He generally provides enough example source code to allow any experienced developer to implement the proposed solutions. Unfortunately, the example code does not appear to be available for download from O'Reilly's website.

The discussion of JavaScript optimization is capped off by the seventh chapter, written by Nicholas C. Zakas, who explains variable scope within JavaScript code, the advantages of choosing local variables as much as possible, scope chain augmentation, the performance ramifications of the four major data types (literal values, variables, arrays, and objects), optimizing flow control statements, and string concatenation. He outlines what sorts of problems can cause the user's Web browser to freeze up, and the differing responses she would see depending upon her chosen browser. Nicholas concludes his chapter by explaining how to utilize timer code to force long-running scripts to yield, in order to avoid these problems. By the way, in Figures 7-2 and 7-3, the data point symbols need to be enlarged so as to be distinguishable; as it is, they are quite difficult to read. More importantly, on page 93, the sentence beginning "This makes array lookup ideal..." is either misworded or mistaken, since array lookup cannot be used for testing inclusion in ranges.

With the eighth chapter, the book shifts gears to focus on network considerations — namely, how to improve the site visitor's experience by optimizing the number of bytes that must be pushed down the wire. In "Scaling with Comet," Dylan Schiemann introduces an emerging set of techniques that Steve Souders describes as "an architecture that goes beyond Ajax to provide high-volume, low-latency communication for real-time applications such as chat and document collaboration" — specifically, by reducing the server-side resources per connection. In Chapter 9, Tony Gentilcore discusses a rather involved problem with using gzip compression — one that negatively impacts at least 15% of Internet users. Even though videos, podcasts, and other audiovisual files consume a lot of the Internet's bandwidth, images are still far more common on websites, and this alone is reason enough for Chapter 10, in which Stoyan Stefanov and Nicole Sullivan explain how to reduce the size of image files without degrading visible quality. They compare the most popular image formats, and also explain alpha transparency and the use of sprites. The only clear improvement that could be made to their presentation is on page 157, where the phrase "named /favicon.ico that sits in the web root" should instead read something like "usually named favicon.ico," since a favicon can have any filename, and can be located anywhere in a site's directory structure.

The lead author returns in Chapter 11, in which he explains how to best divide resources among multiple domains (termed "sharding"). In the subsequent chapter, "Flushing the Document Early," Steve explores the approach of utilizing chunked encoding in order to begin rendering the Web page before its full contents have been downloaded to the browser. The third and final section of the book, devoted to Web browser performance, consists of two chapters, both of whose titles neatly summarize their contents: "Using Iframes Sparingly" and "Simplifying CSS Selectors." That last chapter contains some performance tips that even some of the most experienced CSS wizards may have never heard of before. As with most of the earlier chapters, the narrative tends to be stronger than the illustrations. For instance, Figure 14-5, a multiline chart, is quite misleading, because it appears to depict three values varying over time, when actually each of the ten x-axis coordinates represents a separate major website. A bar chart would obviously have been a much better choice.

Like any first edition of a technical book, this one contains a number of errata (aside from those mentioned earlier): In Figure 1-1, "iteration" is misspelled. On page 23, in the sentence beginning "Thus, if...," the term "was" should instead read "were." In Figures 7-1 and 7-4, the "Global object" box should not contain "num2." On page 95, in the phrase "the terminal condition evaluates to true," that instead should read "false." On page 147, in the sentence beginning "However, the same icon...," the "was" should instead read "were." On page 214, "Web-Pagetest. AOL" should instead read "Web-Pagetest, then AOL," because the first sentence is one long absolute phrase (i.e., lacking a finite noun and verb).

All of these defects can be easily corrected in future printings. What will probably need to wait for a second edition, are improvements to the figures that are in need of replacement or clarification. What the publisher can rectify immediately — should the author and O'Reilly choose to do so — would be to make all of the example source code available for download.

Even though this book is decidedly longer than High Performance Web Sites, and has many more contributing authors, it does not appear to contain as much actionable information as his predecessor — at least for small- to medium-sized websites, which probably make up the majority of all sites on the Web. Even though such methodologies as Comet, Doloto, and Web Workers appear impressive, one has to wonder just how many real-world websites can justify the development and maintenance costs of implementing them, and whether their overhead could easily outweigh any possible benefits. Naturally, these are the sorts of questions that are best answered through equally hard-nosed experimentation — as exemplified by Steve Souders's admirable emphasis upon proving what techniques really work.

Fortunately, none of this detracts from the application development and optimization knowledge presented in the book. With its no-nonsense analysis of Internet performance hurdles, and balanced recommendations of the most promising solutions, Even Faster Web Sites truly delivers on its title's promise to help Web developers wring even more speed out of their websites.

Michael J. Ross is a freelance Web developer and writer.

You can purchase Even Faster Web Sites from amazon.com. Slashdot welcomes readers' book reviews — to see your own review here, read the book review guidelines, then visit the submission page.

blackbearnh writes "Everybody knows what the best programming language is, it's whatever one you like the most. But is there a best language overall? Or even a best language for a given purpose? This question has been debated since the first time there were two languages to choose from. The argument is still going on, of course, but maybe a little light will be shed on the issue this week at OSCON. On Wednesday night at 7PM Pacific, representatives of the 5 major open source languages (perl, PHP, Python, Java and Ruby), as arbitrarily decided by O'Reilly, will meet to debate the merits of their various languages. If you're not going to be at OSCON, you can watch it live on a webcast and pose questions or comments to the participants. The representatives are: Python: Alex Martelli, Google; Ruby: Brian Ford, Engine Yard; PHP: Laura Thomson, Mozilla; Perl: Jim Brandt, Perl Foundation; Java: Rod Johnson, SpringSource."

An anonymous reader writes "Linux distributions track upstream projects, releasing a particular version with each official release. But how far behind the latest versions do these releases linger? Scott Shawcroft did an interesting new study into this relationship between distributions and upstream projects. Shawcroft says: 'Over the last 10 months I've been working on Linux evolution research. Similar to distrowatch, I track the current versions of packages in a number of distributions and the current upstream version. Based on that data I then graph a number of metrics to understand the relationship between upstream and downstream.' His presentation on the topic scheduled for [this] week's open source convention, OSCON, should provide an interesting insight into that relationship. Currently he is tracking 20 projects including the Linux kernel, Firefox, GCC, OpenSSH and GNOME on Arch, Debian, Fedora, Gentoo, openSUSE, Sabayon, Slackware, and Ubuntu."

blackbearnh writes "The Human Genome Project took 13 years to sequence a single human's genetic information in full. At Washington University's Genome Center, they can now do one in a week. But when you're generating that much data, just keeping track of it can become a major challenge. David Dooling is in charge of managing the massive output of the Center's herd of gene sequencing machines, and making it available to researchers inside the Center and around the world. He'll be talking about his work at OSCON, and gave O'Reilly Radar a sense of where the state of the art in genome sequencing is heading. 'Now we can run these instruments. We can generate a lot of data. We can align it to the human reference. We can detect the variance. We can determine which variance exists in one genome versus another genome. Those variances that are cancerous, specific to the cancer genome, we can annotate those and say these are in genes. ... Now the difficulty is following up on all of those and figuring out what they mean for the cancer. ... We know that they exist in the cancer genome, but which ones are drivers and which ones are passengers? ... [F]inding which ones are actually causative is becoming more and more the challenge now.'"

stoolpigeon writes "At the end of last year, I made a move from an IT shop focused on supporting the US side of our business to a department that provides support to our operations outside the US. This was the first time I've worked in an international context and found myself, on a regular basis, running into long-time assumptions that were no longer true. My first project was implementing a third-party, web-based HR system for medium-sized offices. I found myself constantly missing important issues because I had such a narrow approach to the problem space. Sure, I've built applications and databases that supported Unicode, but I've never actually implemented anything with them but the same types of systems I'd built in the past with ASCII. But a large portion of the world's population is in Asia, and ASCII is certainly not going to cut it there. Fortunately, a new edition of Ken Lunde's classic CJKV Information Processing has become available, and it has really opened my eyes." Keep reading for the rest of JR's review. CJKV Information Processing 2nd ed. author Ken Lunde pages 898 publisher O'Reilly Media, Inc. rating 10/10 reviewer JR Peck ISBN 978-0-596-51447-1 summary Chinese, Japanese, Korean and Vietnamese computing. CJKV Information Processing has a long history that actually goes back into the 1980s. It began as a simple text document JAPAN.INF, available via FTP on a number of servers. This document was excerpted and refined and published as Lunde's first book in 1993, Understanding Japanese Information Processing. Shortly after JAPAN.INF became CJK.INF and the foundation for the first edition of CJKV Information Processing was born. The first edition was published in 1999, and it is safe to say that a number of important things have changed over the last 10 years. Lunde states four major developments that prompted this second edition in the preface. They are the emergence of Unicode, OpenType and the Portable Document Format (PDF) as preferred tools and lastly the maturity of the web in general to use Unicode and deal with a wider range of languages and their character sets.

Lunde sets out not to create an exhaustive reference on the languages themselves, but rather an exhaustive guide to the considerations that come into play when processing CJKV information. As Lunde states, "..this book focuses heavily on how CJKV text is handled on computer systems in a very platform-independent way..." Taking into account the complexity of the topic, the breadth of the work and the degree to which it is independent of any specific technology, outside a heavy bias for Unicode, is extremely impressive. A glance over the table of contents show just how true this is. Chapter 9, Information Processing Techniques has sections touching on C/C++, Java, Perl, Python, Ruby, Tcl and others. These are brief, with most examples in Java but that they are all directly addressed shows a great awareness of the options out there. The sections that deal with operating system issues have the same breadth. Chapter 10, OSes, Text Editors, and Word Processors doesn't just hit the top Mac and Windows items. It looks at FreeBSD, Linux, Mac OS X, MS Vista, MS-DOS, Plan 9, OpenSolaris, Unix and more. There are also sections for what Lunde calls hybrid environments such as Boot Camp, CrossOver Mac, Gnome, KDE, VMware Fusion, Wine and the X Window System. Interestingly the Word Processor system covers AbiWord and KWord but not OpenOffice.org The point stands that anyone looking to support CJKV, this book will probably cover your platform and give you at the very least a starting point with your chosen tool set.

That said, an extremely specific implementation is not what Lunde is out to offer up. This is the very opposite of a 'cook book' approach. This also makes the book extremely useful to anyone dealing with internationalization, globalization or localization issues regardless of character set or language. Lunde teaches the underlying principles of how writing systems and scripts work. He then moves to how computer systems deal with these various writing systems and scripts. The focus is always on CJKV but the principles will hold true in any setting. This continues to be the case as Lunde talks about character sets, encoding, code conversion and a host of other issues that surround handling characters. Typography is included, as well as input and output methods. In each case Lunde covers the basics as well as pointing out areas of concern and where exceptions may cause issues. The author is nothing if not thorough in this regard. His knowledge of the problem space is at times down right staggering. Lunde also touches on dictionaries as well as publishing in print and on the web.

The first three chapters set the table for the rest of the book with an overview of the issues that will be addressed, information on the history and usage of the writing systems and scripts covered and the character set standards that exist. This was a fascinating glimpse, once again into CJKV languages and how other languages are dealt with as well. I think there is even a lot here that would be extremely informative to a person who wants to learn more about CJKV, even if they are not a developer that will be working with one of the languages. That's only the first quarter of the book, so I don't know that it would be worth it from just that perspective, but it is definitely a nice benefit of Lunde's approach.

The style is very readable, but I wouldn't just hand this to someone who didn't have some familiarity with text processing issues on computer systems. While there is no requirement to know or understand one of the CJKV languages, understanding how computer systems process data and information is important. I did not know anything about CJKV languages prior to reading the book and have learned quite a bit. What I learned was not limited to the CJKV arena. The experience I had was very similar to when I studied ancient Greek in school. Learning Greek I learned much more about English grammar than I had ever picked up prior. Reading CJKV Information Processing I learned quite a bit more about the issues involved in things like character encoding and typography for every language, not just these four. But in dealing with CJKV specifically I've found that Lunde's work is indispensable. It is not just my go to reference, it's essentially my only reference. If any other works do come my way, this is the standard against which they will be judged.

There are thirteen indexes including a nice glossary. Nine of them are character sets, which were printed out in the longer first edition. In this second edition, there is a note on each, with a url pointing to a PDF with the information. It seemed odd, but each URL gets it's own page. This means there are nine pages with nothing but the title of the index and a url. Fortunately they are all in the same directory, which can be reached directly from the books page at the O'Reilly site. It seems it would have made sense to just list them all on a single page, but maybe it was necessary for some reason. It's a minute flaw in what is a great book."

You can purchase CJKV Information Processing 2nd ed. from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

blackbearnh writes with this excerpt from O'Reilly Radar "Think about Wikipedia, what some consider the most complete general survey of human knowledge we have at the moment. Now imagine squeezing it down to fit comfortably on an 8GB iPhone. Sound daunting? Well, that's just what Patrick Collison's Encyclopedia iPhone application does. App Store purchasers of Collison's open source application can browse and search the full text of Wikipedia when stuck in a plane, or trapped in the middle of nowhere (or, as defined by AT&T coverage...)"

blackbearnh writes with this excerpt from O'Reilly Radar "Think about Wikipedia, what some consider the most complete general survey of human knowledge we have at the moment. Now imagine squeezing it down to fit comfortably on an 8GB iPhone. Sound daunting? Well, that's just what Patrick Collison's Encyclopedia iPhone application does. App Store purchasers of Collison's open source application can browse and search the full text of Wikipedia when stuck in a plane, or trapped in the middle of nowhere (or, as defined by AT&T coverage...)"

blackbearnh writes "Google just released Google Squared into the Google Labs playground. Google Squared lets you get results back in row and column format, and then add more columns to the result set. There's a brief tour of the features over on O'Reilly Radar, where the judgement is that there's lots of rough edges, but a huge amount of potential, especially for quick and dirty table generation for reports."

blackbearnh writes "Google just released Google Squared into the Google Labs playground. Google Squared lets you get results back in row and column format, and then add more columns to the result set. There's a brief tour of the features over on O'Reilly Radar, where the judgement is that there's lots of rough edges, but a huge amount of potential, especially for quick and dirty table generation for reports."

blackbearnh writes "We all know that slow Web pages drive users crazy, but where is the boundary between too slow and too simple? As Microsoft's Eric Schurman points out, the fastest-loading page of all is a blank one, but it's also the most useless. In an interview with O'Reilly Radar leading up to his appearance at the Velocity Conference, Schurman talks about his experiences working on some of Microsoft's highest-volume sites, including the home page and Live Search. In particular, he discusses how Microsoft will selectively degrade the performance of pages to small sets of users so that they can see how various amounts of delay at different times and places affect user behavior. 'In cases where we were giving what was a significantly degraded experience, the data moved to significance extremely quickly. We were able to tell when we delayed people's pages by more than half a second, and it was very obvious that this had a significant impact on users very quickly. We were able to turn off that experiment. The reasoning... was it helps us make a strong argument for how we can prioritize work on performance against work on other aspects of the site.' He also talks about what it's like to be one of the most often-targeted DDoS sites on the planet."

blackbearnh writes "We all know that slow Web pages drive users crazy, but where is the boundary between too slow and too simple? As Microsoft's Eric Schurman points out, the fastest-loading page of all is a blank one, but it's also the most useless. In an interview with O'Reilly Radar leading up to his appearance at the Velocity Conference, Schurman talks about his experiences working on some of Microsoft's highest-volume sites, including the home page and Live Search. In particular, he discusses how Microsoft will selectively degrade the performance of pages to small sets of users so that they can see how various amounts of delay at different times and places affect user behavior. 'In cases where we were giving what was a significantly degraded experience, the data moved to significance extremely quickly. We were able to tell when we delayed people's pages by more than half a second, and it was very obvious that this had a significant impact on users very quickly. We were able to turn off that experiment. The reasoning... was it helps us make a strong argument for how we can prioritize work on performance against work on other aspects of the site.' He also talks about what it's like to be one of the most often-targeted DDoS sites on the planet."

blackbearnh writes "We all know that slow Web pages drive users crazy, but where is the boundary between too slow and too simple? As Microsoft's Eric Schurman points out, the fastest-loading page of all is a blank one, but it's also the most useless. In an interview with O'Reilly Radar leading up to his appearance at the Velocity Conference, Schurman talks about his experiences working on some of Microsoft's highest-volume sites, including the home page and Live Search. In particular, he discusses how Microsoft will selectively degrade the performance of pages to small sets of users so that they can see how various amounts of delay at different times and places affect user behavior. 'In cases where we were giving what was a significantly degraded experience, the data moved to significance extremely quickly. We were able to tell when we delayed people's pages by more than half a second, and it was very obvious that this had a significant impact on users very quickly. We were able to turn off that experiment. The reasoning... was it helps us make a strong argument for how we can prioritize work on performance against work on other aspects of the site.' He also talks about what it's like to be one of the most often-targeted DDoS sites on the planet."

Michael J. Ross writes "Two decades ago, Web usage was limited to a single individual (Sir Tim Berners-Lee) using the only browser in existence (WorldWideWeb) running on a single platform (a NeXT Computer). Nowadays, billions of people access the Web daily, with the ability to choose from over a dozen browsers running on desktop computers, laptops, and a variety of mobile devices, such as cell phones. The number of possible combinations is growing rapidly, and makes it increasingly difficult for Web designers and developers to craft their sites so as to be universally accessible. This is particularly true when accounting for Web users with physical and cognitive disabilities — especially if they do not have access to assistive technologies. The challenges and solutions for anyone creating an accessible website are addressed in Universal Design for Web Applications, authored by Wendy Chisholm and Matt May." Keep reading for the rest of Michael and Laura's review. Universal Design for Web Applications author Wendy Chisholm and Matt May pages 198 publisher O'Reilly Media rating 5/10 reviewer Michael J. Ross with Laura Andres ISBN 9780596518738 summary An introduction to accessible Web design. The book was published by O'Reilly Media on 26 November 2008, under the ISBN 9780596518738, and weighs in at a slender 198 pages. The publisher offers a Web page for the book, where visitors will find a detailed description, a customer review, errata (there are none listed, as of this writing), a sample chapter (the 11th one, "The Process") in PDF format, and other items that may be of interest to the prospective reader. The authors as well have a website for the book, which offers the 20 accessibility checklist questions from Chapter 11, as well as slides from the authors' presentation at the Web 2.0 Expo on 17 September 2008 in New York City.

In the preface to their book, the authors explain that the purpose of universal Web design is to make Web content "work as efficiently as possible across the range of capabilities exhibited by both people and their chosen browsing technologies." While it has little to do with efficiency per se, maximum Web usability is a laudable goal for every designer and developer of a website or Web-based application. The consensus in the Web design community is that the most effective way to achieve this goal is through adherence to accepted usability standards and design practices, and those are the topics that the authors explore in the eleven chapters that compose this book: an introduction; selling universal design; metadata; structure and design; forms; tabular data; video and audio; scripting; AJAX and WAI-ARIA; Rich Internet applications; and the universal design process.

The first chapter serves as a brief introduction to the concept and overall purpose of universal design (UD), which the authors consider to be "the design of products and environments to be usable by all people, to the greatest extent possible, without the need for adaptation or specialized design" (as defined by architect Ron Mace). In view of the brevity and preliminary nature of this chapter's material, it should have been labeled as an introduction, and not a chapter. More importantly, the discussion is rather choppy, jumping among topics such as architecture, grocery stores, unemployment rates among the blind, and mobile phones. Readers will likely be confused by the authors' statement that "mobile and accessible design are also at opposite ends of the spectrum when it comes to meeting our stated goal," as that suggests that the more mobile the device, the least accessible platform it can ever be. Yet the gist of the discussion is clear: The need for maximally accessible websites is quite important — critical to those with various disabilities — and will become more so with the proliferation of Web-enabled mobile devices.

If any chapter in this book is going to raise hackles, it is surely the second one. It focuses on how to sell Web accessibility to decision-makers, such as convincing management that compliance with universal design standards — in creating a new site or re-creating an existing one — is worth the investment. This position could easily be supported with a thoroughly positive mindset, such as showing how enhanced accessibility for some is beneficial to all. Instead, the authors initially take a more negative approach, and begin the chapter with somewhat hostile descriptions of what it is like to not understand a movie, and the resistance the authors have encountered in selling accessibility to clients. The authors clearly want the reader to empathize with such people, but the methods employed are questionable — such as asserting that all of us can face a handicap at some point, and thus we can all be lumped together as "disabled." While the authors' passion for online resources being made available to everyone, is certainly laudable, there is nothing to be gained from making sweeping generalizations or lecturing the reader. (Overstating one's arguments tends to turn off listeners, and provides fodder for counterarguments.) The authors go on to define the four major categories of physical and situational disabilities, as they relate to website usage. They cite statistics for deafness and hard of hearing, but neglect to include tinnitus, which apparently has more sufferers than those first two conditions combined. Next, the authors provide selling points for employing universal design to increase a site's potential audience — humans and search engines — thereby increasing financial results and adhering to legal restrictions. Readers are referred to a number of pertinent resources, including the Web Content Accessibility Guidelines (WCAG), the Authoring Tool Accessibility Guidelines (ATAG), the User Agent Accessibility Guidelines (UAAG), the Accessible Rich Internet Applications Suite (WAI-ARIA), and the Mobile Web Best Practices (MWBP). Nearing the end of the chapter, the authors return to the minefield of how to convince the "prejudiced developer" and manager that they should learn and utilize accessibility best practices in creating websites for which they are responsible, especially when they see no value or need for it. Lastly, excellent arguments for the product benefits of continuous accessible design are briefly presented.

By the third chapter, Web designers and developers who purchased this book to learn specific accessibility techniques, may become a bit impatient, since nothing concrete has been presented up to that point (despite the claim later in the chapter that "We've devoted three chapters to making web applications accessible."). Fortunately, this chapter gets things going by addressing metadata and how it can be leveraged to increase content accessibility. The specific techniques discussed include the alt, height, and width attributes for image tags; document-level metadata, including title tags; and link text. The guidelines are definitely worthwhile, but the presentation could have been better edited. For example, the authors state that the alt text for a linked image is "a verb and represents where the link will take you" (page 27), but a destination is not a verb, and neither is the example provided ("next page").

Chapter 4 addresses the structuring and design of Web pages, and covers important topics of semantic markup, headings, links, lists, forms, tables, colors, layout choices, text sizing, fonts, and images. For some reason not explained to the reader, forms are discussed first, even before semantics, which is odd. Nonetheless, all of the suggestions provided are well worth learning and incorporating into one's own repertoire of Web coding and design principles. The authors rightly teach the maxim "separate structure and presentation," and demonstrate how to do this throughout the discussion of the aforesaid topics. Also addressed are flickering images — and one of the dangers thereof, photoepilepsy — and HTML e-mail messages.

Web forms possibly compose the most problematic type of page element, especially in terms of usability and accessibility, because they involve for more user input than any other. This is especially true with forms that use CAPTCHAs in an attempt to defeat form spam. Chapter 5 encompasses a useful discussion, with illustrative sample code, covering the key considerations for coding accessible forms — including labels, fieldsets and their legends, accesskey attributes, and tab order among elements. The authors state that a block of sample form code (page 54) is available on their website, but, as of this writing, it could not be found. Yet readers may not want to use that code anyway, since all of the labels and all of the input fields are separated, into two divs; no explanation is given as to why this nonstandard structure was chosen. Error handling is a subject that stymies countless inexperienced Web programmers, as evidenced by the oftentimes useless messages displayed on the sites that they have created, and the authors provide solid advice, with emphasis on client-side error handling. The chapter concludes with a somewhat short discussion of what they consider "Public Enemy #1 for blind, low-vision, and dyslexic people," the dreaded CAPTCHA, with links to two publications that propose alternatives.

Accessibility abuses are especially prevalent with three types of Web content: HTML tables and multimedia. These are the topics of chapters 6 and 7, respectively. Semantic use of HTML tables for tabular data is seeing a resurgence with the growing interest in accessible design, and Chapter 6 explains how to implement them properly. However, Figure 6-3 purportedly contains blue shading, but it is effectively invisible on the black-and-white printed page. Chapter 7 explains how to add captions and audio descriptions to audiovisual files, or outsource the work. But first the reader slogs through a detailed history of Web-based video that is unneeded, despite the authors' claims that knowledge of the history is important.

The next two chapters discuss the use of JavaScript and AJAX as they pertain to site accessibility, and could be combined into a single chapter. The first one briefly addresses a number of related topics: progressive enhancement, Unobtrusive JavaScript (again with an unnecessary history), keyboard activation of pop-up menus, limitations of :hover pseudoselectors, two recommended drop-down menu scripts, and tabbing order. One of the scripts is an open-source script that the authors claim can be downloaded from their website; but, like the form sample code mentioned above, the promised script is missing from their site. The authors later declare (page 107) that in this chapter they show "you how to add JavaScript to your HTML and CSS to make a web application," when in fact they do nothing of the sort. Entire books explain how to make Web applications — not something accomplished in a 15-page chapter. Chapter 9 focuses on AJAX and WAI-ARIA — specifically, the ways that the AJAX paradigm clashes with the current state of assistive technologies, and how ARIA may prove the best solution — resolving the keyboard activation problem covered in the previous chapter, and handling tab ordering in a more elegant manner — though still not ubiquitously implemented. The narrative's flow is interrupted with almost three pages of JavaScript that the reader is apparently not expected to implement as-is or even use as sample code to learn from, and thus looks suspiciously like padding.

In Chapter 10, the authors discuss the unfortunate lack of Web accessibility guidelines for Rich Internet applications (RIAs) developed using technologies such as Java, Flex, and Silverlight. To remedy this, the authors promise "a crash course in software accessibility as applied to Flex and Silverlight," but only deliver on the second half of that promise. For illustrating Silverlight development, they provide some of the code for creating a custom Digg button (although the term "buttons" is also confusingly used). The chapter concludes with mention of some tools from Microsoft for testing RIAs that utilize Microsoft Active Accessibility (MSAA).

The last chapter begins with a brief high-level perspective on the importance of baking accessibility into any new application or site from the start, and then explores numerous development and testing tools and other resources. Perhaps the material that will be most referenced in the future by readers, are the 20 key questions that a designer can use as a valuable checklist for evaluating a site she has created. The chapter concludes with some thoughts on strategies for successful universal design, for four different team sizes. The book's sole appendix consists of a table relisting the 20 key usability questions, and for each one, the specifications of the WCAG 2.0 Proposed Recommendation, the MWBP 1.0, and the UD4WA. This is followed by an index that proved quite disappointing, as it contains almost none of the entries that I attempted to look up.

Universal Design for Web Applications has numerous relatively minor flaws that could be fixed in a future edition: Some of the chapter summaries comprise only one or two sentences, and add no value to the book, since the chapters themselves are so short. Other chapter summaries contain new material not even mentioned in the respective chapters, and should be renamed as final sections. Many of the URLs are wisely presented as footnotes — instead of embedded in the text, as is done in many other technical books, which impedes reading flow. Unfortunately, this practice was not followed consistently throughout the book. In some passages, the writing style is rather unpolished; for instance, "mobile and accessibility as our criteria" (page 2), mixes adjective and noun. In other passages, the statements are hyperbolic; for instance, a reporter "found himself a hair's breadth from being eviscerated" (page 4). Some unexplained phrases will prove cryptic to many readers; for instance, "content adaptation" (page 24), "lolcats" (page 26), and "antipattern" (page 37). The use of a shortened URL (page 23) is inadvisable, since it depends upon the longevity of the particular service provider and the short URL that the service generated. Some of the terminology is inconsistent, e.g., the Enter key referred to as a "Return" key. The book contains a couple erratum: "to to" (page 12), and a sentence missing a verb (page 111, beginning with "Layering").

A visually annoying problem with this book is the manner in which, on far too many lines in the text, there is an inadequate amount of space between the words. Consequently, distinguishing individual words — particularly when trying to read at a fast pace — is made much more difficult. While skimming, each line begins to look like one extremely long word. There is no excuse for this, since there is plenty of space in the outer margins to have expanded the lines, and the number of pages is far less than in a typical computer book. This is not the first of the most recently published O'Reilly books to exhibit this problem, but I certainly hope it is the last. It is rather ironic to see this readability mistake in a book devoted to usability and accessibility. (Note that production decisions such as whitespace are not decided by the authors.)

Perhaps the most exasperating defect of all is that both instances of code that supposedly can be downloaded from the authors' website, are nowhere to be found, as of this writing — nor is the code available on the O'Reilly page for the book. In fact, a reader comment on that O'Reilly page indicates that the script code wasn't available on 30 December 2008, just weeks after the book's publication. This is quite unlike the level of follow-through typically seen with O'Reilly authors.

In some respects, the book could have been far better than the final product. It gets off to a weak start with a non-chapter, and then in several sections spends pages discussing the history of various technologies, but then fails to go into enough detail so the reader could use the current state of those technologies to implement what is promised in the book. It also could have been improved with much more detailed and usable discussions of such topics as scrolling, bypassing blocks of content, session time limits on forms, site maps, breadcrumb trails, usable CAPTCHA alternatives, typography, text case, paragraph justification, sign language, text direction, and techniques for providing text for image-heavy websites — as well as more complete code examples.

Nonetheless, Universal Design for Web Applications provides some valuable recommendations and pointers on how website designers, developers, and owners can greatly increase the accessibility of their sites to the growing variety of human and search engine visitors on the Internet.

Michael J. Ross is a freelance Web developer and writer. Laura Andres is a Unix administrator, Oracle DBA, and programmer.

You can purchase Universal Design for Web Applications: Web Applications That Reach Everyone from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

BillyG noted an RMS interview where he says "'Software as a service' means that you think of a particular server as doing your computing for you. If that's what the server does, you must not use it! If you do your computing on someone else's server, you hand over control of your computing to whoever controls the server. It is like running binary-only software, only worse: it's even harder for you to patch the program that's running on someone else's server than it is to patch a binary copy of a program running on your own computer. Just like non-free software, 'software as a service' is incompatible with your freedom."

blackbearnh writes "One of the biggest problem that a platoon on the ground in Iraq or Afghanistan faces is that when a new unit cycles in, all the street-sense and experience of the old unit is lost. Knowing where insurgents like to plant IEDs, or even which families have a lot of domestic disputes, can spell the difference between living and dying. In response to this, DARPA created TIGR, the Tactical Ground Reporting System. Developed as much on the ground in active warzones as in a lab, TIGR lets platoons access the latest satellite and drone imagery in an easy-to-use map based interface, as well as recording their experiences in the field and accessing the reports of other troops. In this O'Reilly Radar interview, two of the people responsible for the development of TIGR talk about the intel issues that troops face in hostile territory, the challenges of deploying new technology meant for combat areas, the specific tricks that they had to employ to make TIGR work over less-than-robust military networking, and how TIGR is impacting platoons in their day to day operations"

blackbearnh writes "One of the biggest problem that a platoon on the ground in Iraq or Afghanistan faces is that when a new unit cycles in, all the street-sense and experience of the old unit is lost. Knowing where insurgents like to plant IEDs, or even which families have a lot of domestic disputes, can spell the difference between living and dying. In response to this, DARPA created TIGR, the Tactical Ground Reporting System. Developed as much on the ground in active warzones as in a lab, TIGR lets platoons access the latest satellite and drone imagery in an easy-to-use map based interface, as well as recording their experiences in the field and accessing the reports of other troops. In this O'Reilly Radar interview, two of the people responsible for the development of TIGR talk about the intel issues that troops face in hostile territory, the challenges of deploying new technology meant for combat areas, the specific tricks that they had to employ to make TIGR work over less-than-robust military networking, and how TIGR is impacting platoons in their day to day operations"

NewYorkCountryLawyer writes "President Barack Obama has named his chief technology officer, and the appointee is not a Silicon Valley name like so many predicted. He is Aneesh Chopra. As the Secretary of Technology for the Commonwealth of Virginia, his job has been to 'leverage technology in government reform, promote Virginia's innovation agenda, and foster technology-related economic development with a special emphasis on entrepreneurship.' But Chopra's not a tech guy. Before he got his secretary job in 2005, he was a managing director at the Advisory Board Company, a public-market health care think tank, as well as an angel investor." O'Reilly Radar is running an article discussing why Chopra is a good choice for federal CTO.

blackbearnh writes "Yahoo! has been working for a while to promote a unified system for referring to places, through their Where On Earth IDs. Using a WOEID, you can query Yahoo's publicly available APIs to find out things like what cities are in a county, or what counties border each other. In an interview for O'Reilly Radar, Tyler Bell, the product lead for the Yahoo Geo Technology Group, talks about their Open Location program (not to be confused with openlocation.org, a different group altogether). He also talks about how privacy concerns interact with the increasing use of personal geotracking, and the troublesome problem of what to call places. 'I'm not even going to tell you about the problems we had when we accidentally called Constantinople Byzantium, just slipping back about 800 years there accidentally. That's a very sensitive issue. Any company dealing with geography is going to have to address it somehow. So I'll be very candid in how Yahoo addresses this. I mean first, our stated goal is to capture the world's geography as it is used by the world's people. We don't see ourselves as the definitive authority on how a place should be called.'"

blackbearnh writes "Yahoo! has been working for a while to promote a unified system for referring to places, through their Where On Earth IDs. Using a WOEID, you can query Yahoo's publicly available APIs to find out things like what cities are in a county, or what counties border each other. In an interview for O'Reilly Radar, Tyler Bell, the product lead for the Yahoo Geo Technology Group, talks about their Open Location program (not to be confused with openlocation.org, a different group altogether). He also talks about how privacy concerns interact with the increasing use of personal geotracking, and the troublesome problem of what to call places. 'I'm not even going to tell you about the problems we had when we accidentally called Constantinople Byzantium, just slipping back about 800 years there accidentally. That's a very sensitive issue. Any company dealing with geography is going to have to address it somehow. So I'll be very candid in how Yahoo addresses this. I mean first, our stated goal is to capture the world's geography as it is used by the world's people. We don't see ourselves as the definitive authority on how a place should be called.'"

blackbearnh writes "Jeff Holden spent a decade at Amazon, where he was involved as Senior Vice President of Consumer Websites with the recommendation engine, Amazon Prime, and the product review system. He's left now, and has started Pelago, a company that wants to help mobile users turn their lives into stories they can share on the web. Among the interesting effects he discusses in this interview for O'Reilly Radar is that users of their product, Whrrl, have talked about changing their lives to make more interesting stories. Holden also talks about some of the work he did at Amazon, privacy issues that arise when social networking starts to become ubiquitous, and why he thinks the Apple App Store review system is seriously broken. 'One of the things that happens with an iPhone is when you uninstall an app, it asks you to rate it. And it defaults to one-star. ... The problem is ... there's no kind of qualification. Anybody just downloads it and checks it out or doesn't check it out, right? And I think a number of people run it and they see that you have to sign in and they just delete it. And you get a one-star rating out of those experiences.'"