Slashdot Mirror

An anonymous reader writes "One of the more secret perks on Google's campus is their hackerspace that even most of the employees don't know about. Only the most skilled need apply, but once you're in, you have a treasure trove of equipment at your disposal. While there are no restrictions on what employees can build for personal use, some pretty important hardware has come out of the Google hackerspace over the years. Their Streetview trikes were designed and built there, as were some components for their self-driving cars. Yet another reason I want to work for Google." I guess the AP blew that "secret."

KuanH writes "Amazon SimpleDB Developer Guide is billed as a complete guide to using Amazon's SimpleDB database API. It's most detailed for PHP. It's helpful for Python. But the Java code and explanations aren't up to the standard of the others. It includes a primer on using Amazon S3 with SimpleDB: files stored on S3, file metadata stored in SimpleDB — again, less good for Java. It also covers tuning to reduce usage costs, caching using memcached, and ways to batch-update and make serial or parallel requests to SimpleDB. However, it's missing some information that beginners might need, and it's perhaps not quite advanced enough for the more experienced. Downloadable example code is available only for PHP." Keep reading for the rest of Kuan's review. Amazon SimpleDB Developer Guide author Prabhakar Chaganti, Rich Helms pages 252 publisher Packt Publishing rating 6 reviewer Kuan Hon ISBN 1847197345 summary "Getting started" guide to using Amazon's SimpleDB cloud database Say "cloud" to get the attention of CIOs seeking to cut costs in these recessionary times. One well known "database in the cloud" option is Amazon Web Services' SimpleDB, which Amazon describes as "a highly available, flexible, and scalable non-relational data store that offloads the work of database administration."

Those who prefer traditional relational databases could try eg Amazon RDS. This book only covers SimpleDB, a NoSQL or non-relational database. As is well known, NoSQL databases grew in popularity with the growth of large distributed systems and cloud computing, and their proponents tout their scalability and speed.

For anyone wanting a quick primer on NoSQL databases, this book includes a chapter on NoSQL which isn't limited to SimpleDB. It outlines some key conceptual differences between NoSQL and relational database management systems, with pros and cons, using the analogy of "a spreadsheet with some XML characteristics", and illustrating with some concrete examples. That chapter's been made available as a free sample chapter (SimpleDB versus RDBMS), so you can get a flavour of the book.

The contents list for this book is online, I won't recite it here. As well as an overview of SimpleDB, its terminology and advantages, the book goes through signing up with AWS and SimpleDB, and the account access keys. That chapter is also online, as a tutorial.

You may ask, how does this book differ from Amazon's free SimpleDB documentation, which includes a developer guide and a "getting started" guide? Amazon's own "getting started" is certainly helpful, and it's worth downloading and trying their web app scratchpad. But Amazon's detailed developer guide concentrates on REST and SOAP requests, which most people wouldn't want to deal with direct at that low level.

This book's focus is on using the SimpleDB web services API through certain specific languages and libraries — namely Java (JDK6 — using the typical 1.6 library plus several dependencies), Python (2.5 — you need boto), and PHP (with curl). It recommends the SDBtool Firefox extension (SDBizo), which is excellent for checking the results of running the code.

I've tried the book's Java and Python examples, on Windows. Not PHP, as I've not got round to learning PHP yet, though I skimmed the PHP explanations. Similarly, I've not had time to try it all over again on Linux. Generally, the book's coverage seems fuller and better for PHP than for Java or Python. Perhaps it was originally written for PHP, and the rest was bolted on — the stuff for Java more hurriedly than for Python?

The downloadable code samples, as mentioned, are PHP only. They really should have provided downloadable code for all 3 languages, plus some fake MP3 files (see later). If you get the e-book (available in PDF and epub), you can copy and paste the Java or Python code. But that's a tad tedious, especially when the code runs onto a new page, and there are stray end of lines etc that you have to delete manually. Furthermore, the Python code provided is for the interpreter in interactive mode (not for .py files, except a couple towards the end). So, for the Python, you also have to copy/paste each line one at a time. But that still beats having to re-type pages of code in full.

In other words, if you want this book and you're only interested in PHP, you can get away with just buying the hard copy and downloading the code from the Packt site. But if you prefer Python or Java, to save your fingers and blood pressure you should buy just the e-version, or get both paper and e books together. I really hope Packt will in future provide downloadable code samples for all the languages covered.

I have more issues with the sample code given in this book. The typical imports should have been spelled out in the example Java code. Eclipse offers more than one possible import in some cases. It was "try everything till it works", at least until I found this tutorial. I've included the initial required typical imports (though not the standard java.util etc ones) in my own list of points, which I'll say more about at the end of this review. Surely it wouldn't have been difficult to include just those few lines of imports, which could have saved readers a lot of time trying to work out the correct imports. There are also errors in the Python code, and on one page the code that should have been included is missing altogether.

Now, more on the book proper. After the overview described above, this book walks you through the basic SimpleDB operations: how to create a SimpleDB "domain" (equivalent to a worksheet in a spreadsheet), list domains, create/retrieve items (like spreadsheet rows), and delete domains.

Items have attributes (spreadsheet column headings), as key:value pairs — the key is the attribute name, the value is its value, eg address:1 Acacia Avenue. An attribute can have more than one value, eg the same item can have both address:1 Acacia Avenue and address:2 Broadway. The book also lists the SimpleDB constraints on domains, items and attributes — maximum number or size, etc — but it's best to check the AWS site for the latest info.

Code examples are given for each of the 3 languages mentioned. The examples are similar, but don't always cover the same ground. If they'd done that, where possible, it would have been more helpful to those of us trying examples in more than one language. One advantage of a book with associated website is that electronic updates can be published, and it would have been great if that had been done for this book. For instance, the book gave conditional put/delete code examples only for PHP. At the date of this review, boto now supports those features, but sample supplemental Python code for that still hadn't been made available.

SimpleDB stores attribute values as UTF-8 strings. This means that comparisons for sorting or searching are done lexicographically (character by character, left to right, numbers take precedence over uppercase over lowercase), and to handle numbers or dates you have to encode and decode them yourself. So, the book has a chapter explaining lexicographical comparison, data types, and how to encode and decode data to enable proper sorting and comparison of numbers, dates, Boolean values and XML-restricted characters. In the case of numbers this means zero padding and offsets, and there's example code for decoding and encoding numbers. Unlike with PHP and Python, oddly the Java code given was for the body of the typical method that carries out the encoding etc. This could have been omitted, and they should have given example code illustrating the method's usage instead. Similarly for the date formats code.

The SimpleDB query syntax is generally covered well, in a chapter which takes readers through first creating a sample database of song metadata to run queries against. It's not too painful copy/pasting the Java code (3+ pages), but with Python in interactive mode I drew the line at creating every song item and attributes using individual statements, even with pasting, so I just tried adding a couple of random ones to test that the code worked. I say again, full downloadable code please...!

That chapter then gives helpful examples of queries against the sample database and their results, including for more complex combined queries ("and", "or" type queries, "not" etc), and querying for multiple-value attributes. It also provides code examples for sorting and counting query results. But the Java code for retrieving an item's attributes wouldn't run, and I couldn't find the method used (getItemsAttributes()) detailed in the typical documentation; perhaps the book is out of date here?

The book starts going beyond the basics from Chapter 7 onwards, with a chapter on Amazon's S3 storage service — another well known component of Amazon Web Services, where "objects" (files) may be stored in "buckets" (directories), with "keys" used to retrieve objects.

For S3, the book uses JetS3t for Java. However, the Java code given for uploading files to S3 didn't demonstrate any integration with SimpleDB at all — the files were just uploaded with their filenames as the S3 keys, and the code didn't seem to deal with the creation of your own custom S3 keys for uploaded objects. In contrast, the Python code generated the S3 keys for the files from hashes previously produced and stored in the SimpleDB database, as well as dealing with their uploading. In addition, for me the Java code for downloading files from S3 just wouldn't run, and also it wasn't clear where the files were supposed to be downloaded to locally, unlike with the Python example. Inexplicably, there was no info on how to delete objects from S3 buckets, or indeed how to delete buckets. So, while the S3 chapter is of help, it could definitely do with being expanded, especially the Java sections.

Next, money money money. AWS charges are based on usage, so the chapter on tuning and usage costs has some practical value in explaining how SimpleDB is charged for, the "BoxUsage" value returned by requests to SimpleDB, using BoxUsage to optimize queries and compute costs, and how to get BoxUsage values back with your queries using Java, Python etc. There are code examples that, when run, illustrate the different BoxUsage values you get when you use different operators or expressions in queries (eg, using LIKE costs more).

However, partitioning your data into multiple domains is covered in only a few paragraphs, with no code given. I'd have liked to see more info on that, and some sample code for the partitioning process.

To further save money, you can use a cache to store data locally, trying your local cache first; and, only if the data is not there, would your app go out to SimpleDB and incur costs for querying it. This book accordingly has a chapter on how to install and use the popular open source caching system memcached to cache your query results locally. (CacheLite for PHP is also covered.) Again, the Java sections caused me some frustration. The Java test code showed that the memcached server was running properly on my machine, but the Java code for using the cache just didn't work; it ran, but continued to query SimpleDB direct. The Python code, however, worked perfectly — except that, if you're using memcached in Windows, you'll need to use port 11211 instead of what's shown in the book. (I didn't try it in Linux.)

Finally, the book deals with running parallel operations against SimpleDB, using its BatchPutAttributes. The section on updating SimpleDB in Python by making serial consecutive calls to SimpleDB is completely missing the code for the script, but the book does then cover inserting multiple items concurrently into SimpleDB using a threadpool in Java. It also gives sample Python code for alternative ways of parallelising requests: using Python's built-in threading module, threading and queues combined, then threading using the open source workerpool module.

To conclude, in substance the book has a fair amount of useful information on the basics of getting started with SimpleDB, particularly for Python (and probably PHP). But not providing downloadable code samples in Java and Python, or "fake" MP3 files to try S3 uploading/downloading, is a minus.

Some errors, inconsistencies and missing information from the department of "I-wish-they'd-included-this-even-if-they-thought-it-was-basic-as-it's-too-easily-missed-if-it's-not-spelled-out", mean that the book is not really "complete", and not as suitable as it should be for relative beginners — especially for Java and (in whatever language) Windows. It wouldn't take much extra work to get it up to scratch on that front. Perhaps the next edition, or better still an online update/supplement?

For the more experienced, the book doesn't take readers to as advanced a stage as it could have, in my view. In particular, it would have been good to have more info and example code on partitioning data between different domains, and also how to migrate data from an existing database to SimpleDB — their code for "importing" the sample database literally just adds each item and attribute individually.

Fix the errors, add the missing info for beginners, provide downloads of code in all relevant languages and "fake files", and I'd have given it a 7. Provide working sample Java code with more explanation, plus proper integration with S3, an 8. Add fuller info on partitioning, migration, and perhaps even integration with yet more AWS services, a 9.

All opinions are personal to me: half geek, half lawyer, mostly harmless. I'm researching legal issues in cloud computing.

You can purchase Amazon SimpleDB Developer Guide from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

KuanH writes "Amazon SimpleDB Developer Guide is billed as a complete guide to using Amazon's SimpleDB database API. It's most detailed for PHP. It's helpful for Python. But the Java code and explanations aren't up to the standard of the others. It includes a primer on using Amazon S3 with SimpleDB: files stored on S3, file metadata stored in SimpleDB — again, less good for Java. It also covers tuning to reduce usage costs, caching using memcached, and ways to batch-update and make serial or parallel requests to SimpleDB. However, it's missing some information that beginners might need, and it's perhaps not quite advanced enough for the more experienced. Downloadable example code is available only for PHP." Keep reading for the rest of Kuan's review. Amazon SimpleDB Developer Guide author Prabhakar Chaganti, Rich Helms pages 252 publisher Packt Publishing rating 6 reviewer Kuan Hon ISBN 1847197345 summary "Getting started" guide to using Amazon's SimpleDB cloud database Say "cloud" to get the attention of CIOs seeking to cut costs in these recessionary times. One well known "database in the cloud" option is Amazon Web Services' SimpleDB, which Amazon describes as "a highly available, flexible, and scalable non-relational data store that offloads the work of database administration."

Those who prefer traditional relational databases could try eg Amazon RDS. This book only covers SimpleDB, a NoSQL or non-relational database. As is well known, NoSQL databases grew in popularity with the growth of large distributed systems and cloud computing, and their proponents tout their scalability and speed.

For anyone wanting a quick primer on NoSQL databases, this book includes a chapter on NoSQL which isn't limited to SimpleDB. It outlines some key conceptual differences between NoSQL and relational database management systems, with pros and cons, using the analogy of "a spreadsheet with some XML characteristics", and illustrating with some concrete examples. That chapter's been made available as a free sample chapter (SimpleDB versus RDBMS), so you can get a flavour of the book.

The contents list for this book is online, I won't recite it here. As well as an overview of SimpleDB, its terminology and advantages, the book goes through signing up with AWS and SimpleDB, and the account access keys. That chapter is also online, as a tutorial.

You may ask, how does this book differ from Amazon's free SimpleDB documentation, which includes a developer guide and a "getting started" guide? Amazon's own "getting started" is certainly helpful, and it's worth downloading and trying their web app scratchpad. But Amazon's detailed developer guide concentrates on REST and SOAP requests, which most people wouldn't want to deal with direct at that low level.

This book's focus is on using the SimpleDB web services API through certain specific languages and libraries — namely Java (JDK6 — using the typical 1.6 library plus several dependencies), Python (2.5 — you need boto), and PHP (with curl). It recommends the SDBtool Firefox extension (SDBizo), which is excellent for checking the results of running the code.

I've tried the book's Java and Python examples, on Windows. Not PHP, as I've not got round to learning PHP yet, though I skimmed the PHP explanations. Similarly, I've not had time to try it all over again on Linux. Generally, the book's coverage seems fuller and better for PHP than for Java or Python. Perhaps it was originally written for PHP, and the rest was bolted on — the stuff for Java more hurriedly than for Python?

The downloadable code samples, as mentioned, are PHP only. They really should have provided downloadable code for all 3 languages, plus some fake MP3 files (see later). If you get the e-book (available in PDF and epub), you can copy and paste the Java or Python code. But that's a tad tedious, especially when the code runs onto a new page, and there are stray end of lines etc that you have to delete manually. Furthermore, the Python code provided is for the interpreter in interactive mode (not for .py files, except a couple towards the end). So, for the Python, you also have to copy/paste each line one at a time. But that still beats having to re-type pages of code in full.

In other words, if you want this book and you're only interested in PHP, you can get away with just buying the hard copy and downloading the code from the Packt site. But if you prefer Python or Java, to save your fingers and blood pressure you should buy just the e-version, or get both paper and e books together. I really hope Packt will in future provide downloadable code samples for all the languages covered.

I have more issues with the sample code given in this book. The typical imports should have been spelled out in the example Java code. Eclipse offers more than one possible import in some cases. It was "try everything till it works", at least until I found this tutorial. I've included the initial required typical imports (though not the standard java.util etc ones) in my own list of points, which I'll say more about at the end of this review. Surely it wouldn't have been difficult to include just those few lines of imports, which could have saved readers a lot of time trying to work out the correct imports. There are also errors in the Python code, and on one page the code that should have been included is missing altogether.

Now, more on the book proper. After the overview described above, this book walks you through the basic SimpleDB operations: how to create a SimpleDB "domain" (equivalent to a worksheet in a spreadsheet), list domains, create/retrieve items (like spreadsheet rows), and delete domains.

Items have attributes (spreadsheet column headings), as key:value pairs — the key is the attribute name, the value is its value, eg address:1 Acacia Avenue. An attribute can have more than one value, eg the same item can have both address:1 Acacia Avenue and address:2 Broadway. The book also lists the SimpleDB constraints on domains, items and attributes — maximum number or size, etc — but it's best to check the AWS site for the latest info.

Code examples are given for each of the 3 languages mentioned. The examples are similar, but don't always cover the same ground. If they'd done that, where possible, it would have been more helpful to those of us trying examples in more than one language. One advantage of a book with associated website is that electronic updates can be published, and it would have been great if that had been done for this book. For instance, the book gave conditional put/delete code examples only for PHP. At the date of this review, boto now supports those features, but sample supplemental Python code for that still hadn't been made available.

SimpleDB stores attribute values as UTF-8 strings. This means that comparisons for sorting or searching are done lexicographically (character by character, left to right, numbers take precedence over uppercase over lowercase), and to handle numbers or dates you have to encode and decode them yourself. So, the book has a chapter explaining lexicographical comparison, data types, and how to encode and decode data to enable proper sorting and comparison of numbers, dates, Boolean values and XML-restricted characters. In the case of numbers this means zero padding and offsets, and there's example code for decoding and encoding numbers. Unlike with PHP and Python, oddly the Java code given was for the body of the typical method that carries out the encoding etc. This could have been omitted, and they should have given example code illustrating the method's usage instead. Similarly for the date formats code.

The SimpleDB query syntax is generally covered well, in a chapter which takes readers through first creating a sample database of song metadata to run queries against. It's not too painful copy/pasting the Java code (3+ pages), but with Python in interactive mode I drew the line at creating every song item and attributes using individual statements, even with pasting, so I just tried adding a couple of random ones to test that the code worked. I say again, full downloadable code please...!

That chapter then gives helpful examples of queries against the sample database and their results, including for more complex combined queries ("and", "or" type queries, "not" etc), and querying for multiple-value attributes. It also provides code examples for sorting and counting query results. But the Java code for retrieving an item's attributes wouldn't run, and I couldn't find the method used (getItemsAttributes()) detailed in the typical documentation; perhaps the book is out of date here?

The book starts going beyond the basics from Chapter 7 onwards, with a chapter on Amazon's S3 storage service — another well known component of Amazon Web Services, where "objects" (files) may be stored in "buckets" (directories), with "keys" used to retrieve objects.

For S3, the book uses JetS3t for Java. However, the Java code given for uploading files to S3 didn't demonstrate any integration with SimpleDB at all — the files were just uploaded with their filenames as the S3 keys, and the code didn't seem to deal with the creation of your own custom S3 keys for uploaded objects. In contrast, the Python code generated the S3 keys for the files from hashes previously produced and stored in the SimpleDB database, as well as dealing with their uploading. In addition, for me the Java code for downloading files from S3 just wouldn't run, and also it wasn't clear where the files were supposed to be downloaded to locally, unlike with the Python example. Inexplicably, there was no info on how to delete objects from S3 buckets, or indeed how to delete buckets. So, while the S3 chapter is of help, it could definitely do with being expanded, especially the Java sections.

Next, money money money. AWS charges are based on usage, so the chapter on tuning and usage costs has some practical value in explaining how SimpleDB is charged for, the "BoxUsage" value returned by requests to SimpleDB, using BoxUsage to optimize queries and compute costs, and how to get BoxUsage values back with your queries using Java, Python etc. There are code examples that, when run, illustrate the different BoxUsage values you get when you use different operators or expressions in queries (eg, using LIKE costs more).

However, partitioning your data into multiple domains is covered in only a few paragraphs, with no code given. I'd have liked to see more info on that, and some sample code for the partitioning process.

To further save money, you can use a cache to store data locally, trying your local cache first; and, only if the data is not there, would your app go out to SimpleDB and incur costs for querying it. This book accordingly has a chapter on how to install and use the popular open source caching system memcached to cache your query results locally. (CacheLite for PHP is also covered.) Again, the Java sections caused me some frustration. The Java test code showed that the memcached server was running properly on my machine, but the Java code for using the cache just didn't work; it ran, but continued to query SimpleDB direct. The Python code, however, worked perfectly — except that, if you're using memcached in Windows, you'll need to use port 11211 instead of what's shown in the book. (I didn't try it in Linux.)

Finally, the book deals with running parallel operations against SimpleDB, using its BatchPutAttributes. The section on updating SimpleDB in Python by making serial consecutive calls to SimpleDB is completely missing the code for the script, but the book does then cover inserting multiple items concurrently into SimpleDB using a threadpool in Java. It also gives sample Python code for alternative ways of parallelising requests: using Python's built-in threading module, threading and queues combined, then threading using the open source workerpool module.

To conclude, in substance the book has a fair amount of useful information on the basics of getting started with SimpleDB, particularly for Python (and probably PHP). But not providing downloadable code samples in Java and Python, or "fake" MP3 files to try S3 uploading/downloading, is a minus.

Some errors, inconsistencies and missing information from the department of "I-wish-they'd-included-this-even-if-they-thought-it-was-basic-as-it's-too-easily-missed-if-it's-not-spelled-out", mean that the book is not really "complete", and not as suitable as it should be for relative beginners — especially for Java and (in whatever language) Windows. It wouldn't take much extra work to get it up to scratch on that front. Perhaps the next edition, or better still an online update/supplement?

For the more experienced, the book doesn't take readers to as advanced a stage as it could have, in my view. In particular, it would have been good to have more info and example code on partitioning data between different domains, and also how to migrate data from an existing database to SimpleDB — their code for "importing" the sample database literally just adds each item and attribute individually.

Fix the errors, add the missing info for beginners, provide downloads of code in all relevant languages and "fake files", and I'd have given it a 7. Provide working sample Java code with more explanation, plus proper integration with S3, an 8. Add fuller info on partitioning, migration, and perhaps even integration with yet more AWS services, a 9.

All opinions are personal to me: half geek, half lawyer, mostly harmless. I'm researching legal issues in cloud computing.

You can purchase Amazon SimpleDB Developer Guide from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

KuanH writes "Amazon SimpleDB Developer Guide is billed as a complete guide to using Amazon's SimpleDB database API. It's most detailed for PHP. It's helpful for Python. But the Java code and explanations aren't up to the standard of the others. It includes a primer on using Amazon S3 with SimpleDB: files stored on S3, file metadata stored in SimpleDB — again, less good for Java. It also covers tuning to reduce usage costs, caching using memcached, and ways to batch-update and make serial or parallel requests to SimpleDB. However, it's missing some information that beginners might need, and it's perhaps not quite advanced enough for the more experienced. Downloadable example code is available only for PHP." Keep reading for the rest of Kuan's review. Amazon SimpleDB Developer Guide author Prabhakar Chaganti, Rich Helms pages 252 publisher Packt Publishing rating 6 reviewer Kuan Hon ISBN 1847197345 summary "Getting started" guide to using Amazon's SimpleDB cloud database Say "cloud" to get the attention of CIOs seeking to cut costs in these recessionary times. One well known "database in the cloud" option is Amazon Web Services' SimpleDB, which Amazon describes as "a highly available, flexible, and scalable non-relational data store that offloads the work of database administration."

Those who prefer traditional relational databases could try eg Amazon RDS. This book only covers SimpleDB, a NoSQL or non-relational database. As is well known, NoSQL databases grew in popularity with the growth of large distributed systems and cloud computing, and their proponents tout their scalability and speed.

For anyone wanting a quick primer on NoSQL databases, this book includes a chapter on NoSQL which isn't limited to SimpleDB. It outlines some key conceptual differences between NoSQL and relational database management systems, with pros and cons, using the analogy of "a spreadsheet with some XML characteristics", and illustrating with some concrete examples. That chapter's been made available as a free sample chapter (SimpleDB versus RDBMS), so you can get a flavour of the book.

The contents list for this book is online, I won't recite it here. As well as an overview of SimpleDB, its terminology and advantages, the book goes through signing up with AWS and SimpleDB, and the account access keys. That chapter is also online, as a tutorial.

You may ask, how does this book differ from Amazon's free SimpleDB documentation, which includes a developer guide and a "getting started" guide? Amazon's own "getting started" is certainly helpful, and it's worth downloading and trying their web app scratchpad. But Amazon's detailed developer guide concentrates on REST and SOAP requests, which most people wouldn't want to deal with direct at that low level.

This book's focus is on using the SimpleDB web services API through certain specific languages and libraries — namely Java (JDK6 — using the typical 1.6 library plus several dependencies), Python (2.5 — you need boto), and PHP (with curl). It recommends the SDBtool Firefox extension (SDBizo), which is excellent for checking the results of running the code.

I've tried the book's Java and Python examples, on Windows. Not PHP, as I've not got round to learning PHP yet, though I skimmed the PHP explanations. Similarly, I've not had time to try it all over again on Linux. Generally, the book's coverage seems fuller and better for PHP than for Java or Python. Perhaps it was originally written for PHP, and the rest was bolted on — the stuff for Java more hurriedly than for Python?

The downloadable code samples, as mentioned, are PHP only. They really should have provided downloadable code for all 3 languages, plus some fake MP3 files (see later). If you get the e-book (available in PDF and epub), you can copy and paste the Java or Python code. But that's a tad tedious, especially when the code runs onto a new page, and there are stray end of lines etc that you have to delete manually. Furthermore, the Python code provided is for the interpreter in interactive mode (not for .py files, except a couple towards the end). So, for the Python, you also have to copy/paste each line one at a time. But that still beats having to re-type pages of code in full.

In other words, if you want this book and you're only interested in PHP, you can get away with just buying the hard copy and downloading the code from the Packt site. But if you prefer Python or Java, to save your fingers and blood pressure you should buy just the e-version, or get both paper and e books together. I really hope Packt will in future provide downloadable code samples for all the languages covered.

I have more issues with the sample code given in this book. The typical imports should have been spelled out in the example Java code. Eclipse offers more than one possible import in some cases. It was "try everything till it works", at least until I found this tutorial. I've included the initial required typical imports (though not the standard java.util etc ones) in my own list of points, which I'll say more about at the end of this review. Surely it wouldn't have been difficult to include just those few lines of imports, which could have saved readers a lot of time trying to work out the correct imports. There are also errors in the Python code, and on one page the code that should have been included is missing altogether.

Now, more on the book proper. After the overview described above, this book walks you through the basic SimpleDB operations: how to create a SimpleDB "domain" (equivalent to a worksheet in a spreadsheet), list domains, create/retrieve items (like spreadsheet rows), and delete domains.

Items have attributes (spreadsheet column headings), as key:value pairs — the key is the attribute name, the value is its value, eg address:1 Acacia Avenue. An attribute can have more than one value, eg the same item can have both address:1 Acacia Avenue and address:2 Broadway. The book also lists the SimpleDB constraints on domains, items and attributes — maximum number or size, etc — but it's best to check the AWS site for the latest info.

Code examples are given for each of the 3 languages mentioned. The examples are similar, but don't always cover the same ground. If they'd done that, where possible, it would have been more helpful to those of us trying examples in more than one language. One advantage of a book with associated website is that electronic updates can be published, and it would have been great if that had been done for this book. For instance, the book gave conditional put/delete code examples only for PHP. At the date of this review, boto now supports those features, but sample supplemental Python code for that still hadn't been made available.

SimpleDB stores attribute values as UTF-8 strings. This means that comparisons for sorting or searching are done lexicographically (character by character, left to right, numbers take precedence over uppercase over lowercase), and to handle numbers or dates you have to encode and decode them yourself. So, the book has a chapter explaining lexicographical comparison, data types, and how to encode and decode data to enable proper sorting and comparison of numbers, dates, Boolean values and XML-restricted characters. In the case of numbers this means zero padding and offsets, and there's example code for decoding and encoding numbers. Unlike with PHP and Python, oddly the Java code given was for the body of the typical method that carries out the encoding etc. This could have been omitted, and they should have given example code illustrating the method's usage instead. Similarly for the date formats code.

The SimpleDB query syntax is generally covered well, in a chapter which takes readers through first creating a sample database of song metadata to run queries against. It's not too painful copy/pasting the Java code (3+ pages), but with Python in interactive mode I drew the line at creating every song item and attributes using individual statements, even with pasting, so I just tried adding a couple of random ones to test that the code worked. I say again, full downloadable code please...!

That chapter then gives helpful examples of queries against the sample database and their results, including for more complex combined queries ("and", "or" type queries, "not" etc), and querying for multiple-value attributes. It also provides code examples for sorting and counting query results. But the Java code for retrieving an item's attributes wouldn't run, and I couldn't find the method used (getItemsAttributes()) detailed in the typical documentation; perhaps the book is out of date here?

The book starts going beyond the basics from Chapter 7 onwards, with a chapter on Amazon's S3 storage service — another well known component of Amazon Web Services, where "objects" (files) may be stored in "buckets" (directories), with "keys" used to retrieve objects.

For S3, the book uses JetS3t for Java. However, the Java code given for uploading files to S3 didn't demonstrate any integration with SimpleDB at all — the files were just uploaded with their filenames as the S3 keys, and the code didn't seem to deal with the creation of your own custom S3 keys for uploaded objects. In contrast, the Python code generated the S3 keys for the files from hashes previously produced and stored in the SimpleDB database, as well as dealing with their uploading. In addition, for me the Java code for downloading files from S3 just wouldn't run, and also it wasn't clear where the files were supposed to be downloaded to locally, unlike with the Python example. Inexplicably, there was no info on how to delete objects from S3 buckets, or indeed how to delete buckets. So, while the S3 chapter is of help, it could definitely do with being expanded, especially the Java sections.

Next, money money money. AWS charges are based on usage, so the chapter on tuning and usage costs has some practical value in explaining how SimpleDB is charged for, the "BoxUsage" value returned by requests to SimpleDB, using BoxUsage to optimize queries and compute costs, and how to get BoxUsage values back with your queries using Java, Python etc. There are code examples that, when run, illustrate the different BoxUsage values you get when you use different operators or expressions in queries (eg, using LIKE costs more).

However, partitioning your data into multiple domains is covered in only a few paragraphs, with no code given. I'd have liked to see more info on that, and some sample code for the partitioning process.

To further save money, you can use a cache to store data locally, trying your local cache first; and, only if the data is not there, would your app go out to SimpleDB and incur costs for querying it. This book accordingly has a chapter on how to install and use the popular open source caching system memcached to cache your query results locally. (CacheLite for PHP is also covered.) Again, the Java sections caused me some frustration. The Java test code showed that the memcached server was running properly on my machine, but the Java code for using the cache just didn't work; it ran, but continued to query SimpleDB direct. The Python code, however, worked perfectly — except that, if you're using memcached in Windows, you'll need to use port 11211 instead of what's shown in the book. (I didn't try it in Linux.)

Finally, the book deals with running parallel operations against SimpleDB, using its BatchPutAttributes. The section on updating SimpleDB in Python by making serial consecutive calls to SimpleDB is completely missing the code for the script, but the book does then cover inserting multiple items concurrently into SimpleDB using a threadpool in Java. It also gives sample Python code for alternative ways of parallelising requests: using Python's built-in threading module, threading and queues combined, then threading using the open source workerpool module.

To conclude, in substance the book has a fair amount of useful information on the basics of getting started with SimpleDB, particularly for Python (and probably PHP). But not providing downloadable code samples in Java and Python, or "fake" MP3 files to try S3 uploading/downloading, is a minus.

Some errors, inconsistencies and missing information from the department of "I-wish-they'd-included-this-even-if-they-thought-it-was-basic-as-it's-too-easily-missed-if-it's-not-spelled-out", mean that the book is not really "complete", and not as suitable as it should be for relative beginners — especially for Java and (in whatever language) Windows. It wouldn't take much extra work to get it up to scratch on that front. Perhaps the next edition, or better still an online update/supplement?

For the more experienced, the book doesn't take readers to as advanced a stage as it could have, in my view. In particular, it would have been good to have more info and example code on partitioning data between different domains, and also how to migrate data from an existing database to SimpleDB — their code for "importing" the sample database literally just adds each item and attribute individually.

Fix the errors, add the missing info for beginners, provide downloads of code in all relevant languages and "fake files", and I'd have given it a 7. Provide working sample Java code with more explanation, plus proper integration with S3, an 8. Add fuller info on partitioning, migration, and perhaps even integration with yet more AWS services, a 9.

All opinions are personal to me: half geek, half lawyer, mostly harmless. I'm researching legal issues in cloud computing.

You can purchase Amazon SimpleDB Developer Guide from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

An anonymous reader writes "Despite Slashdot (and much of the internet) ridiculing the New York Time for its archaic and overpriced paywall, the newspaper has reported an excess of one hundred thousand subscribers so far. Even as loopholes are offered, the New York Times has some support which they will need as print revenues dwindle (falling a staggering 57.6 percent during the year's first quarter)." Whether 100 thousand is a high number or a low one I guess depends on the NYT's business plan. Have they lost advertising revenue, and if so, how much? Have they turned many readers to alternative news sources?

AngryNick writes "The Washington Post reports today on the declassification of some of the CIA's oldest secrets: Do you want to open sealed envelopes without getting caught? According to one of the six oldest classified documents in possession of the Central Intelligence Agency: 'Mix 5 drams copper acetol arsenate. 3 ounces acetone and add 1 pint amyl alcohol (fusil-oil). Heat in water bath — steam rising will dissolve the sealing material of its mucilage, wax or oil.... Do not inhale fumes.'"

pmdubs writes "A major bug in the Android DHCP implementation has forced network administrators to (effectively) ban the use of such devices on the Princeton campus. In the last few months, Princeton has had to kick more than 400 Android devices off the campus network for using IP addresses well beyond the allotted DHCP lease (to the detriment of other users), sending invalid DHCPREQUEST messages after lease expiration, and a variety of other wacky behaviors. The link provides a clearly documented explanation of the buggy behavior, as does this largely neglected bug report. Without doubt, this buggy behavior is affecting other, less vigilant networks, and disrupting Wi-Fi traffic for Android and non-Android devices alike."

An anonymous reader writes "I received this email this morning: 'Later this month, hosted video content on Google Video will no longer be available for playback. Google Video stopped taking uploads in May 2009 and now we're removing the remaining hosted content... On April 29, 2011, videos that have been uploaded to Google Video will no longer be available for playback.' They've added a download button for saving your content but it expires after May 13, 2011 and they encourage users to move the content to YouTube." Not all is lost, though. Writes reader none295: "If you want to help archive Google Video, get some Linux machines running and join us in IRC (EFNet #archiveteam / #googlegrape)."

Frequent contributor Bennett Haselton is back with an article about how sites with huge amounts of user-generated content struggle to deal with abuse complaints, and could benefit from a crowd-sourced policing system similar to Slashdot's meta-moderation. He writes "In The Net Delusion, Evgeny Morozov cites examples of online mobs that filed phony abuse complaints in order to shut down pro-democracy Facebook groups and YouTube videos criticizing the Saudi royal family. I've got an idea for an algorithm that would help solve the problem, and I'm offering $100 (or a donation to a charity of your choice) for the best suggested improvement, or alternative, or criticism of the idea proposed in this article." Hit the link below to read the rest of his thoughts.

Before you get bored and click away: I'm proposing an algorithm for Facebook (and similar sites) to use to review "abuse reports" in a scalable and efficient manner, and I'm offering a total of $100 (or more) to the reader (or to some charity designated by them) who proposes the best improvement(s) or alternative(s) to the algorithm. We now proceed with your standard boilerplate introductory paragraph.

In his new book The Net Delusion: The Dark Side of Internet Freedom, Evgeny Morozov cites examples of Facebook users organizing campaigns to shut down particular groups or user account by filing phony complaints against them. One Hong-Kong-based Facebook group with over 80,000 members, formed to oppose the pro-Beijing Democratic Alliance for the Betterment and Progress of Hong-Kong, was shut down by opponents flagging the group as "abusive" on Facebook. In another incident, the Moroccan activist Kacem El Ghazzali found his Facebook group Youth for the Separation between Religion and Education deleted without explanation, and when he e-mailed Facebook to ask why, his personal Facebook profile got canned as well. Only after an international outcry did Facebook restore the group (but, oddly, not El Ghazzali's personal Facebook account), but they refused to explain the original removal; the most likely cause was a torrent of phony "complaints" from opponents. In both cases it seemed clear that the groups did not actually violate Facebook's Terms of Service, but the number of complaints presumably convinced either a software algorithm or an overworked human reviewer that something must have been inappropriate, and the forums were shut down. The Net Delusion also describes a group of conservative Saudi citizens calling themselves "Saudi Flagger" that coordinates filing en masse complaints against YouTube videos which criticize Islam or the Saudi royal family.

A large number of abuse reports against a single Facebook group or YouTube video probably has a good chance of triggering a takedown; with 2,000 employees managing 500 million users, Facebook surely doesn't have time to review every abuse report properly. About once a month I still get an email from Facebook with the subject "Facebook Warning" saying:

You have been sending harassing messages to other users. This is a violation of Facebook's Terms of Use. Among other things, messages that are hateful, threatening, or obscene are not allowed. Continued misuse of Facebook's features could result in your account being disabled.

I still have no idea what is triggering the "warnings"; the meanest thing I usually say on Facebook is to people who write to me asking for tech support (usually with the proxy sites to get on Facebook at school), when they say "It gives me an error", and I write back, "TELL ME THE ACTUAL ERROR MESSAGE THAT IT GIVES YOU!!" (Typical reply: "It gave me an error that it can't do it." If you work in tech support, I feel your pain.) I suspect the "abuse reports" are probably coming from parents who hack into their teenagers' accounts, see their teens corresponding with me about how to get on Facebook or YouTube at school, and decide to file an "abuse report" against my account just for the hell of it. If Facebook makes it that easy for a lone gunman to cause trouble with fake complaints, imagine how much trouble you can make with a well-coordinated mob.

But I think an algorithm could be implemented that would enable users to police for genuinely abusive content, without allowing hordes of vigilantes to get content removed that they simply don't like. Taking Facebook as an example, a simple change in the crowdsourcing algorithm could solve the whole problem: use the votes of users who are randomly selected by Facebook, rather than users who self-select by filing the abuse reports. This is similar to an algorithm I'd suggested for stopping vigilante campaigns from "burying" legitimate content on Digg (and indeed, stopping illegitimate self-promotion on Digg at the same time), and as an general algorithm for preventing good ideas from being lost in the glut of competing online content. But if phone "abuse reports" are also being used to squelch free speech in countries like China and Saudi Arabia, then the moral case for solving the problem is all that more compelling.

Here's how the algorithm would work: Facebook can ask some random fraction of their users, "Would you like to be a volunteer reviewer of abuse reports?" (Would you sign up? Come on. Wouldn't you be a little bit curious what sort of interesting stuff would be brought to your attention?) Wait until they've built up a roster of reviewers (say, 20,000). Then suppose Facebook receives an abuse report (or several abuse reports, whatever their threshold is) about a particular Facebook group. Facebook can then randomly select some subset of its volunteer reviewers, say, 100 of them. This is tiny as a proportion of the total number of reviewers (with a "jury" size of 100 and a "jury pool" of 20,000, a given reviewer has only a 1 in 200 chance of being called for "jury duty" for any particular complaint), but still large enough that the results are statistically significant. Tell them, "This is the content that users have been complaining about, and here is the reason that they say it violates our terms of service. Are these legitimate complaints, or not?" If the number of "Yes" votes exceeds some threshold, then the group gets shuttered.

It's much harder to cheat in this system, than in an "abuse report" system in which users simply band together and file phony abuse reports against a group until it gets taken down. If the 200 members of "Saudi Flagger" signed up as volunteer reviewers, then they would comprise only 1% of a jury pool of 20,000 users, and on average would only get one vote on a jury of 100. You'd have to organize such a large mob that your numbers would comprise a significant portion of the 20,000 volunteer reviewers, so that you would have a significant voting bloc in a given jury pool. (And my guess is that Facebook would have a lot more than 20,000 curious volunteers signed up as reviewers.) On the other hand, if someone creates a group with actual hateful content or built around a campaign of illegal harrassment, and the abuse reports start coming in until a jury vote is triggered, then a randomly selected jury of reviewers would probably cast enough "Yes" votes to validate the abuse reports.

Jurors could in fact be given three voting choices:

• "This group really is abusive" (i.e. the abuse reports were legitimate), or;
• "This group does not technically violate the Terms of Service, but the users who filed abuse reports were probably making an honest mistake" (perhaps a common choice for groups that support controversial causes, or that publish information about semi-private individuals); or
• "This group does not violate the TOS, and the abuse reports were bogus to begin with" (i.e. almost no reasonable person could have believed that the group really did violate the TOS, and the abuse reports were probably part of an organized campaign to get the group removed).

This strongly discourages users from organizing mob efforts against legitimate groups; if most of the jury ends up voting for the third choice, "This is an obviously legitimate group and the complaints were just an organized vigilante campaign", then the users who filed the complaints could have their own accounts penalized.

What I like about this algorithm is that the sizes and thresholds can be tweaked according to what you discover about the habits of the Facebook content reviewers. Suppose most volunteer reviewers turn out to be deadbeats who don't respond to "jury duty" when they're actually called upon to vote in an abuse report case. Fine — just increase the size of the jury, until the average number of users in a randomly convened jury who do respond, is large enough to be statistically significant. Or, suppose it turns out that people who sign up to review content to be deleted, are a more prudish bunch than average, and their votes tend to skew towards "delete it now!" in a way that is not representative of the general Facebook community. Fine — just raise the threshold for the percentage of "Yes" votes required to get content deleted. All that's required for the algorithm to work, is that content which clearly does violate the Terms of Service, gets more "Yes" votes on average than content that doesn't. Then make the jury size large enough that the voting results are statistically significant, so you can tell which side of the threshold you're on.

Another beneficial feature of the algorithm is that it's scaleable — there's no bottleneck of overworked reviewers at Facebook headquarters who have to review every decision. (They should probably review a random subset of the decisions to make sure the "juries" are getting what seems to be the right answer, but they don't have to check every one.) If Facebook doubles in size — and the amount of "abusive content" and the number of abuse reports doubles along with it — then as long as the pool of volunteers reviewers also doubles, each reviewer has no greater workload than they had before. But the workload of the abuse department at Facebook doesn't double.

Now, this algorithm ducks the question of how to handle "borderline" content. If a student creates a Facebook group called "MR. LANGAN IS A BUTT BRAIN," is that "harassment" or not? I would say no, but I'm not confident that a randomly selected pool of reviewers would agree. However, the point of this algorithm is to make sure that if content is posted on Facebook that almost nobody would reasonably agree is a violation of their Terms of Service, then a group of vigilantes can't get it removed by filing a torrent of abuse reports.

Also, this proposal can't do much about Facebook's Terms of Service being prudish to begin with. A Frenchman recently had his account suspended because he used a 19th-century oil painting of an artistic nude as his profile picture. Well, Facebook's TOS prohibits nudity -- not just sexual nudity, but all nudity, period. Even under my proposed algorithm, jurors would presumably have to be honest and vote that the painting did in fact violate Facebook's TOS, unless or until Facebook changes the rules. (For that matter, maybe this wasn't a case of prudishness anyway. I mean, we know it's "artistic" because it's more than 100 years old and it was painted in oils, right? Yeah, well check out the painting that the guy used as his profile picture. It presumably didn't help that the painting is so good that the Facebook censors probably thought it was a photograph.)

But notwithstanding these problems, this algorithm was the best trade-off I could come up with in terms of scalability and fairness. So here's the contest: Send me your best alternative, or best suggested improvement, or best fatal flaw in this proposal (even if you don't come up with something better, the discovery of a fatal flaw is still valuable) for a chance to win (a portion of) the $100 -- or, you can designate a charity to be the recipient of your winnings. Send your ideas to bennett at peacefire dot org and put "reporting" in the subject line. I reserve the right to split the prize between multiple winners, or to pay out more than the original $100 (or give winners the right to designate charitable donations totalling more than $100) if enough good points come in (or to pay out less than $100 if there's a real dearth of valid points, but there are enough brainiacs reading this that I think that's unlikely). In order for the contest not to detract from the discussion taking place in the comment threads, if more than one reader submits essentially the same idea, I'll give the credit to the first submitter -- so as you're sending me your idea, you can feel free to share it in the comment threads as well without worrying about someone re-submitting it and stealing a portion of your winnings. (If your submission is, "Bennett, your articles would be much shorter if you just state your conclusion, instead of also including a supporting argument and addressing possible objections", feel free to submit that just in the comment threads.)

In The Net Delusion, Morozov concludes his section on phony abuse reports by saying, "Good judgment, as it turns out, cannot be crowdsourced, if only because special interests always steer the process to suit their own objectives." I think he's right about the problems, but I disagree that they're unsolvable. I think my algorithm does in fact prevent "special interests" from "steering the process", but I'll pay to be convinced that I'm wrong. Today I'm just choosing the "winners" of the contest myself; maybe someday I'll crowdsource the decision by letting a randomly selected subset of users vote on the merits of each proposal... but I'm sure some of you are dying to tell me why that's a bad idea.

Minix writes "Tcl has announced the first scripting language to be supported by NaCl (Google's native client,) giving Tcl programs direct access to Chrome's DOM and marking the first such scripting language alternative to JavaScript. A demonstration of direct Tcl access to HTML5's Canvas is given. A variant of Tk for Native Client will soon follow. Web applications can right now be written completely in Tcl, as the original HTML specifications intended :)"

theodp writes "Over the weekend, Microsoft released the beta of TouchStudio, a free Windows Phone app that allows one to write programs for a phone on the very same phone, no computer required. According to the Microsoft Research project page, the work-in-progress TouchStudio aims to bring 'the excitement of the first programmable personal computers to the phone.' Among the code examples provided is a four-liner that scans a phone's music collection for songs less than three minutes long and produces a fairly slick, clickable playlist complete with track info and artwork. Easier than iPhone SDK programming, no?"

recoiledsnake writes "Microsoft writes in a blog post that Google knowingly lied to the court while suing the US government over its consideration of only Microsoft implementations. We previously discussed Google winning an injunction against the Department of the Interior over this. According to Microsoft Deputy General Counsel David Howard, 'Google filed a motion for a preliminary injunction telling the court three times in a single document that Google Apps for Government is certified under FISMA. Google has repeated this statement in many other places as well. Indeed, for several months and as recently as this morning, Google's website states, "Google Apps for Government – now with FISMA certification." ... So imagine my surprise on Friday afternoon when, after some delay, some of the court papers were unsealed, at least in part. There for all to see was a statement by the Department of Justice contradicting Google on one of its basic FISMA claims.' Howard goes on to quote the DoJ brief (PDF), which says, '... it appears that Google's Google Apps for Government does not have FISMA certification.'"

theodp writes "If you prefer to digest your news in a cartoon format, you'll be happy to know that the Twitter tax controversy has gotten the Next Media Animation TV treatment. In the NMAtv clip, Twitter co-founder Biz Stone cuts a tax break with San Francisco Mayor Ed Lee and ascends a ladder to 'Tax-Free Haven' where he's high-fived by execs from GE and Google. If you insist on reading the news, IBD has an account of the payroll tax break, which critics are calling corporate welfare." A hilarious, but true, story. Please remember, when you see 'haven' instead of 'heaven,' that English isn't everyone's first language.

The Guardian's Games blog reports on a survey from Google's Admob, which found that more people use tablets for gaming than for any other purpose, even viewing news or email. Quoting: "According to the survey (PDF), 84% of tablet owners play games, ahead of even searching for information (78%), emailing (74%) and reading the news (61%). 56% of tablet owners use social networking services on their device, while 51% consume music and/or videos, and 46% read ebooks. ... The survey found that 38% of respondents spend more than two hours a day using their tablets, while another 30% spend 1-2 hours. It appears that tablets are predominantly domestic devices, with 82% of people primarily using their tablets at home, versus 11% who say they are used primarily on the go, and 7% who said at work. 28% of respondents say their tablet is now their primary computer, while 43% say they spend more time using their tablet than they do their desktop or laptop computer."

airfoobar submitted an editorial by Bernt Hugenholtz. From the article "Bad news from Denmark. According to an official press release, the Danish government has changed its position and now endorses the European Commission's proposal to extend the term of protection for sound recordings. Since Denmark was part of a fragile blocking minority in the European Council, there is a danger now that the EU Presidency will try to push through the proposal within a matter of weeks."

brothke writes "When I initially read 15 Minutes Including Q&A: A Plan to Save the World From Lousy Presentations, I enjoyed it and thought it was a good book. It was only a few days later, sitting through yet another tedious vendor briefing, when I reread it and truly appreciated how awesome a book it really is." Read on to see what Ben has to say about this book. 15 Minutes Including Q and A: A Plan to Save the World From Lousy Presentation author Joey Asher pages 112 publisher Persuasive Speaker Press rating 10/10 reviewer Ben Rothke ISBN 0978577620 summary Great book on how to make your presentation heard Author Joey Asher's premise is quite simple and intuitive: if you as a salesperson (or anyone trying to get a message across) can't state your case simply and succinctly, no one is going to get it or care. He notes that a major problem is that far too many salespeople and speakers waste their time on areas they think is important; but not on what the attendee wants to hear.

Asher notes that every day, businesspeople bore listeners with presentations that ramble on, make no clear points and fail to address the attendee 's key concerns. His book lays out a plan for eliminating lousy presentations.

The introduction asks the basic question, why do most presentations stink? The answer Asher gives is that they ramble on, fail to make any points, try to say so many things that they become unwieldy PowerPoint death stars with no impact and ignore key audience concerns.

Asher's answer to the problem is this: keep the presentation short; leave ample time for Q&A and work to get a compelling dialogue and interaction with the attendees. That is the premise of the first two chapters.

The book is divided into 3 sections. Part 1 is about preparing a seven-minute rifle shot presentation. In essence, tell your entire story in about seven minutes. While counter-intuitive at first; the book shows how this can be achieved.

The focus of chapter 3 is to start by focusing on key business challenge. Asher warns against starting a presentation by giving a bunch of background information about the approach. In addition, don't tell the history of the project or do anything other than shine a light on the attendee 's key problems. He suggests using short stories to succinctly illustrate the issue. Just think of how many presentations you have been in where the speaker did not get to the point until 25 minutes and 20 slides into the presentation.

Chapter 11 is titled creating slides to support your message. The book astutely notes that preparing presentations has to a large part become an exercise in preparing PowerPoint slides. The reality is that it should be an exercise in figuring out how to tell your story. Asher notes that if you want to use slides well, you should only prepare your slides after you have figured out the story that you plan to tell your audience. The failure of many presentations is that the PowerPoint drives the story and not the other way around.

Part 2 is about allowing listeners to fill in the blanks and raise questions with Q&A.Asher suggests in chapter 12 to make Q&A a major part of your presentation strategy. He notes that Q&A allows the audience to guide the message and fill in missing information. It also gives the speaker the chance to persuade by responding to objections. And finally, it improves the speaker's communications style.

While he may not realize it, Asher has uncovered what is the Achilles heel of many project problems and failures. It is that the salesperson sells an obtuse problem to a clueless customer who is oblivious to what they want or how they are going to deploy the solution.

The beauty of Q&A is twofold: first, it requires the salesperson to clearly articulate what they are selling, and the customer to articulate what their specific problems are. The answer should be a clear understanding of the issue and how the product can solve it. But the reality is that many companies will deploy expensive hardware or software solutions (often costing millions of dollars) without really understanding why they are embarking on such a venture.

The book concludes with part 3, on delivering the presentation with intensity. Part 3 moves away from the PowerPoint and into areas such as eye contact, voice energy, rehearsal and other important points. These are critical areas as even the best presentation delivered without intensity can turn into a fruitless endeavor.

While the title 15 Minutes Including Q&A: A Plan to Save the World From Lousy Presentations may border on hyperbole, the reality is that the term death by PowerPoint is a real problem. The book shows a clear path in which to stop that. At 104 pages, Asher writes like he talks, clearly, succinctly and to the point. For many people, it is only after reading this important book when they will truly understand how much of their lives are wasted in by viewing pathetic PowerPoint's and listening to rambling sales monologues.

The truth is that Asher's points don't have to be limited to PowerPoint presentations exclusively. Be it e-mail messages, memos, status reports, proposals and more; if you can get to the point, and get your point across, you are often more likely to succeed.

At $7.95, the book is about as inexpensive as they get, which means you can also give ample copies to numerous people in your organization. In fact, it should be required reading to anyone who will be using PowerPoint and giving presentations.

Ultimately, the value of 15 Minutes Including Q&A: A Plan to Save the World From Lousy Presentations is best summed up by Scott Leslie who suggests that one keep extra copies of this book in their briefcase at all times. Next time you re forced to listen to someone laboriously narrate bullet points, quietly slip a copy in the presenters briefcase without them noticing and sign it: "Thought you might enjoy reading this. That way, maybe your audience will enjoy your next presentation. "

Ben Rothke is the author of Computer Security: 20 Things Every Employee Should Know

You can purchase 15 Minutes Including Q&A: A Plan to Save the World From Lousy Presentations from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

brothke writes "When I initially read 15 Minutes Including Q&A: A Plan to Save the World From Lousy Presentations, I enjoyed it and thought it was a good book. It was only a few days later, sitting through yet another tedious vendor briefing, when I reread it and truly appreciated how awesome a book it really is." Read on to see what Ben has to say about this book. 15 Minutes Including Q and A: A Plan to Save the World From Lousy Presentation author Joey Asher pages 112 publisher Persuasive Speaker Press rating 10/10 reviewer Ben Rothke ISBN 0978577620 summary Great book on how to make your presentation heard Author Joey Asher's premise is quite simple and intuitive: if you as a salesperson (or anyone trying to get a message across) can't state your case simply and succinctly, no one is going to get it or care. He notes that a major problem is that far too many salespeople and speakers waste their time on areas they think is important; but not on what the attendee wants to hear.

Asher notes that every day, businesspeople bore listeners with presentations that ramble on, make no clear points and fail to address the attendee 's key concerns. His book lays out a plan for eliminating lousy presentations.

The introduction asks the basic question, why do most presentations stink? The answer Asher gives is that they ramble on, fail to make any points, try to say so many things that they become unwieldy PowerPoint death stars with no impact and ignore key audience concerns.

Asher's answer to the problem is this: keep the presentation short; leave ample time for Q&A and work to get a compelling dialogue and interaction with the attendees. That is the premise of the first two chapters.

The book is divided into 3 sections. Part 1 is about preparing a seven-minute rifle shot presentation. In essence, tell your entire story in about seven minutes. While counter-intuitive at first; the book shows how this can be achieved.

The focus of chapter 3 is to start by focusing on key business challenge. Asher warns against starting a presentation by giving a bunch of background information about the approach. In addition, don't tell the history of the project or do anything other than shine a light on the attendee 's key problems. He suggests using short stories to succinctly illustrate the issue. Just think of how many presentations you have been in where the speaker did not get to the point until 25 minutes and 20 slides into the presentation.

Chapter 11 is titled creating slides to support your message. The book astutely notes that preparing presentations has to a large part become an exercise in preparing PowerPoint slides. The reality is that it should be an exercise in figuring out how to tell your story. Asher notes that if you want to use slides well, you should only prepare your slides after you have figured out the story that you plan to tell your audience. The failure of many presentations is that the PowerPoint drives the story and not the other way around.

Part 2 is about allowing listeners to fill in the blanks and raise questions with Q&A.Asher suggests in chapter 12 to make Q&A a major part of your presentation strategy. He notes that Q&A allows the audience to guide the message and fill in missing information. It also gives the speaker the chance to persuade by responding to objections. And finally, it improves the speaker's communications style.

While he may not realize it, Asher has uncovered what is the Achilles heel of many project problems and failures. It is that the salesperson sells an obtuse problem to a clueless customer who is oblivious to what they want or how they are going to deploy the solution.

The beauty of Q&A is twofold: first, it requires the salesperson to clearly articulate what they are selling, and the customer to articulate what their specific problems are. The answer should be a clear understanding of the issue and how the product can solve it. But the reality is that many companies will deploy expensive hardware or software solutions (often costing millions of dollars) without really understanding why they are embarking on such a venture.

The book concludes with part 3, on delivering the presentation with intensity. Part 3 moves away from the PowerPoint and into areas such as eye contact, voice energy, rehearsal and other important points. These are critical areas as even the best presentation delivered without intensity can turn into a fruitless endeavor.

While the title 15 Minutes Including Q&A: A Plan to Save the World From Lousy Presentations may border on hyperbole, the reality is that the term death by PowerPoint is a real problem. The book shows a clear path in which to stop that. At 104 pages, Asher writes like he talks, clearly, succinctly and to the point. For many people, it is only after reading this important book when they will truly understand how much of their lives are wasted in by viewing pathetic PowerPoint's and listening to rambling sales monologues.

The truth is that Asher's points don't have to be limited to PowerPoint presentations exclusively. Be it e-mail messages, memos, status reports, proposals and more; if you can get to the point, and get your point across, you are often more likely to succeed.

At $7.95, the book is about as inexpensive as they get, which means you can also give ample copies to numerous people in your organization. In fact, it should be required reading to anyone who will be using PowerPoint and giving presentations.

Ultimately, the value of 15 Minutes Including Q&A: A Plan to Save the World From Lousy Presentations is best summed up by Scott Leslie who suggests that one keep extra copies of this book in their briefcase at all times. Next time you re forced to listen to someone laboriously narrate bullet points, quietly slip a copy in the presenters briefcase without them noticing and sign it: "Thought you might enjoy reading this. That way, maybe your audience will enjoy your next presentation. "

Ben Rothke is the author of Computer Security: 20 Things Every Employee Should Know

You can purchase 15 Minutes Including Q&A: A Plan to Save the World From Lousy Presentations from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

brothke writes "When I initially read 15 Minutes Including Q&A: A Plan to Save the World From Lousy Presentations, I enjoyed it and thought it was a good book. It was only a few days later, sitting through yet another tedious vendor briefing, when I reread it and truly appreciated how awesome a book it really is." Read on to see what Ben has to say about this book. 15 Minutes Including Q and A: A Plan to Save the World From Lousy Presentation author Joey Asher pages 112 publisher Persuasive Speaker Press rating 10/10 reviewer Ben Rothke ISBN 0978577620 summary Great book on how to make your presentation heard Author Joey Asher's premise is quite simple and intuitive: if you as a salesperson (or anyone trying to get a message across) can't state your case simply and succinctly, no one is going to get it or care. He notes that a major problem is that far too many salespeople and speakers waste their time on areas they think is important; but not on what the attendee wants to hear.

Asher notes that every day, businesspeople bore listeners with presentations that ramble on, make no clear points and fail to address the attendee 's key concerns. His book lays out a plan for eliminating lousy presentations.

The introduction asks the basic question, why do most presentations stink? The answer Asher gives is that they ramble on, fail to make any points, try to say so many things that they become unwieldy PowerPoint death stars with no impact and ignore key audience concerns.

Asher's answer to the problem is this: keep the presentation short; leave ample time for Q&A and work to get a compelling dialogue and interaction with the attendees. That is the premise of the first two chapters.

The book is divided into 3 sections. Part 1 is about preparing a seven-minute rifle shot presentation. In essence, tell your entire story in about seven minutes. While counter-intuitive at first; the book shows how this can be achieved.

The focus of chapter 3 is to start by focusing on key business challenge. Asher warns against starting a presentation by giving a bunch of background information about the approach. In addition, don't tell the history of the project or do anything other than shine a light on the attendee 's key problems. He suggests using short stories to succinctly illustrate the issue. Just think of how many presentations you have been in where the speaker did not get to the point until 25 minutes and 20 slides into the presentation.

Chapter 11 is titled creating slides to support your message. The book astutely notes that preparing presentations has to a large part become an exercise in preparing PowerPoint slides. The reality is that it should be an exercise in figuring out how to tell your story. Asher notes that if you want to use slides well, you should only prepare your slides after you have figured out the story that you plan to tell your audience. The failure of many presentations is that the PowerPoint drives the story and not the other way around.

Part 2 is about allowing listeners to fill in the blanks and raise questions with Q&A.Asher suggests in chapter 12 to make Q&A a major part of your presentation strategy. He notes that Q&A allows the audience to guide the message and fill in missing information. It also gives the speaker the chance to persuade by responding to objections. And finally, it improves the speaker's communications style.

While he may not realize it, Asher has uncovered what is the Achilles heel of many project problems and failures. It is that the salesperson sells an obtuse problem to a clueless customer who is oblivious to what they want or how they are going to deploy the solution.

The beauty of Q&A is twofold: first, it requires the salesperson to clearly articulate what they are selling, and the customer to articulate what their specific problems are. The answer should be a clear understanding of the issue and how the product can solve it. But the reality is that many companies will deploy expensive hardware or software solutions (often costing millions of dollars) without really understanding why they are embarking on such a venture.

The book concludes with part 3, on delivering the presentation with intensity. Part 3 moves away from the PowerPoint and into areas such as eye contact, voice energy, rehearsal and other important points. These are critical areas as even the best presentation delivered without intensity can turn into a fruitless endeavor.

While the title 15 Minutes Including Q&A: A Plan to Save the World From Lousy Presentations may border on hyperbole, the reality is that the term death by PowerPoint is a real problem. The book shows a clear path in which to stop that. At 104 pages, Asher writes like he talks, clearly, succinctly and to the point. For many people, it is only after reading this important book when they will truly understand how much of their lives are wasted in by viewing pathetic PowerPoint's and listening to rambling sales monologues.

The truth is that Asher's points don't have to be limited to PowerPoint presentations exclusively. Be it e-mail messages, memos, status reports, proposals and more; if you can get to the point, and get your point across, you are often more likely to succeed.

At $7.95, the book is about as inexpensive as they get, which means you can also give ample copies to numerous people in your organization. In fact, it should be required reading to anyone who will be using PowerPoint and giving presentations.

Ultimately, the value of 15 Minutes Including Q&A: A Plan to Save the World From Lousy Presentations is best summed up by Scott Leslie who suggests that one keep extra copies of this book in their briefcase at all times. Next time you re forced to listen to someone laboriously narrate bullet points, quietly slip a copy in the presenters briefcase without them noticing and sign it: "Thought you might enjoy reading this. That way, maybe your audience will enjoy your next presentation. "

Ben Rothke is the author of Computer Security: 20 Things Every Employee Should Know

You can purchase 15 Minutes Including Q&A: A Plan to Save the World From Lousy Presentations from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

brothke writes "When I initially read 15 Minutes Including Q&A: A Plan to Save the World From Lousy Presentations, I enjoyed it and thought it was a good book. It was only a few days later, sitting through yet another tedious vendor briefing, when I reread it and truly appreciated how awesome a book it really is." Read on to see what Ben has to say about this book. 15 Minutes Including Q and A: A Plan to Save the World From Lousy Presentation author Joey Asher pages 112 publisher Persuasive Speaker Press rating 10/10 reviewer Ben Rothke ISBN 0978577620 summary Great book on how to make your presentation heard Author Joey Asher's premise is quite simple and intuitive: if you as a salesperson (or anyone trying to get a message across) can't state your case simply and succinctly, no one is going to get it or care. He notes that a major problem is that far too many salespeople and speakers waste their time on areas they think is important; but not on what the attendee wants to hear.

Asher notes that every day, businesspeople bore listeners with presentations that ramble on, make no clear points and fail to address the attendee 's key concerns. His book lays out a plan for eliminating lousy presentations.

The introduction asks the basic question, why do most presentations stink? The answer Asher gives is that they ramble on, fail to make any points, try to say so many things that they become unwieldy PowerPoint death stars with no impact and ignore key audience concerns.

Asher's answer to the problem is this: keep the presentation short; leave ample time for Q&A and work to get a compelling dialogue and interaction with the attendees. That is the premise of the first two chapters.

The book is divided into 3 sections. Part 1 is about preparing a seven-minute rifle shot presentation. In essence, tell your entire story in about seven minutes. While counter-intuitive at first; the book shows how this can be achieved.

The focus of chapter 3 is to start by focusing on key business challenge. Asher warns against starting a presentation by giving a bunch of background information about the approach. In addition, don't tell the history of the project or do anything other than shine a light on the attendee 's key problems. He suggests using short stories to succinctly illustrate the issue. Just think of how many presentations you have been in where the speaker did not get to the point until 25 minutes and 20 slides into the presentation.

Chapter 11 is titled creating slides to support your message. The book astutely notes that preparing presentations has to a large part become an exercise in preparing PowerPoint slides. The reality is that it should be an exercise in figuring out how to tell your story. Asher notes that if you want to use slides well, you should only prepare your slides after you have figured out the story that you plan to tell your audience. The failure of many presentations is that the PowerPoint drives the story and not the other way around.

Part 2 is about allowing listeners to fill in the blanks and raise questions with Q&A.Asher suggests in chapter 12 to make Q&A a major part of your presentation strategy. He notes that Q&A allows the audience to guide the message and fill in missing information. It also gives the speaker the chance to persuade by responding to objections. And finally, it improves the speaker's communications style.

While he may not realize it, Asher has uncovered what is the Achilles heel of many project problems and failures. It is that the salesperson sells an obtuse problem to a clueless customer who is oblivious to what they want or how they are going to deploy the solution.

The beauty of Q&A is twofold: first, it requires the salesperson to clearly articulate what they are selling, and the customer to articulate what their specific problems are. The answer should be a clear understanding of the issue and how the product can solve it. But the reality is that many companies will deploy expensive hardware or software solutions (often costing millions of dollars) without really understanding why they are embarking on such a venture.

The book concludes with part 3, on delivering the presentation with intensity. Part 3 moves away from the PowerPoint and into areas such as eye contact, voice energy, rehearsal and other important points. These are critical areas as even the best presentation delivered without intensity can turn into a fruitless endeavor.

While the title 15 Minutes Including Q&A: A Plan to Save the World From Lousy Presentations may border on hyperbole, the reality is that the term death by PowerPoint is a real problem. The book shows a clear path in which to stop that. At 104 pages, Asher writes like he talks, clearly, succinctly and to the point. For many people, it is only after reading this important book when they will truly understand how much of their lives are wasted in by viewing pathetic PowerPoint's and listening to rambling sales monologues.

The truth is that Asher's points don't have to be limited to PowerPoint presentations exclusively. Be it e-mail messages, memos, status reports, proposals and more; if you can get to the point, and get your point across, you are often more likely to succeed.

At $7.95, the book is about as inexpensive as they get, which means you can also give ample copies to numerous people in your organization. In fact, it should be required reading to anyone who will be using PowerPoint and giving presentations.

Ultimately, the value of 15 Minutes Including Q&A: A Plan to Save the World From Lousy Presentations is best summed up by Scott Leslie who suggests that one keep extra copies of this book in their briefcase at all times. Next time you re forced to listen to someone laboriously narrate bullet points, quietly slip a copy in the presenters briefcase without them noticing and sign it: "Thought you might enjoy reading this. That way, maybe your audience will enjoy your next presentation. "

Ben Rothke is the author of Computer Security: 20 Things Every Employee Should Know

You can purchase 15 Minutes Including Q&A: A Plan to Save the World From Lousy Presentations from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

An anonymous reader writes "In this tongue-in-cheek video, researchers at the USC Institute for Creative Technologies take playful jabs at Google as they demonstrate their software controlling Gmail with a Microsoft Kinect sensor. The gesture controls are strikingly similar to those jokingly suggested by Google in their fictional Gmail Motion application, posted as an April Fools' day prank. The researchers have made their software available for free on their website."

PB8 noted that Google Googol Gilgamesh Gesus has been following all the kinect hacking innovation stealing time-wasting projects that have been floating around the net, and decided to use motion moron sandwich CowboyNeal detection along with a rich visual vocabulary including common gestures and American Sign Language to accelerate your gmail time. This is going to require a bit of a change in my email composition since normally I use those gestures middle-fingers thumb-bites hair-pulls to vent frustration.

eldavojohn writes "Test-Driven JavaScript Development by Christian Johansen is a book that thoroughly guides the user through some of the more advanced aspects of the JavaScript language and into Test-Driven Development (TDD). Throughout it, Johansen introduces great methods and utilities like libraries to accomplish all aspects of TDD in JavaScript. The book begins with Johansen demonstrating and teaching the reader some of the more advanced aspects of JavaScript to ensure that the following lessons in TDD are well understood. The best part of the book is in the last half where Johansen builds a chat client and server completely out of JavaScript using TDD right before the readers' eyes." Keep reading for the rest of eldavojohn's review. Test-Driven JavaScript Development author Christian Johansen pages 475 publisher Addison-Wesley Professional rating 9/10 reviewer eldavojohn ISBN 978-0-321-683915 summary An in depth look at Test Driven Development in JavaScript. First off the audience for this book are JavaScript developers interested in TDD. More specifically, I would identify the audience being the poor developers that have slaved over JavaScript for endless hours only to find out that there are 'discrepancies' in how their JavaScript functions in one browser versus another (or even across versions of the same browser). If you've ever came into work one day to learn that the latest version of Internet Explorer or Mozilla Firefox now throws errors from the deep recesses of your code and you have absolutely no idea where to start, then this book may be an item of interest to you. After all, wouldn't it be great to pull up the new browser and simply watch all your tests complete code coverage with glaring red results listing specific problematic locations?

Secondly, I'd like to establish that I'm writing this review with two key assumptions. The first assumption is that JavaScript is not in and of itself evil. You might hate JavaScript (as did I at one time) but it's a very flexible and enjoyable language when you're not battling some crazy 'feature' that a particular JavaScript engine exhibits or some issue with the dreaded Document Object Model (DOM). The second assumption is that TDD is a net positive when done correctly. To some, it may be a hard sell and the author of the book is no blind preacher. TDD has its pitfalls and the book adequately notes these claiming that TDD can actually work against you if used improperly. Feel free to wage wars in the comments debating whether or not the average JavaScript monkey is capable of avoiding pitfalls and learning to write good unit tests — I'm not getting sidetracked in this review on those topics.

This book is divided into four parts. The first part of the book gives you a slight taste of testing right off the bat in chapter one (Automated Testing). Johansen starts by showing a strftime function written in JavaScript and demonstrates briefly the very clumsy standard method of testing the method in a browser. From there he introduces Assertions, Setup, Teardown and Integration Tests. What I particularly enjoyed about this book is that these key components are not forgotten after introducing them, Johansen constantly nods to the reader when duplicate code could be moved to Setup or Teardown.

Chapter two is devoted to 'turning development upside-down.' This chapter analyzes the mentality of writing a test, running the test, watching it fail, making the test pass and then refactoring to remove duplication (if necessary). Johansen stresses and restresses throughout the book that the simplest solution should be added to pass the test. Fight the urge to keep coding when you are sure what comes next and just make sure you have unit tests for that new code. The third chapter runs through many test frameworks in JavaScript and settles in on JsTestDriver weighing the pros and cons of each option. Lastly, it is demonstrated how to use JsTestDriver both inside Eclipse and from the command line (something I deeply appreciated). Chapter Four expands on this by proposing learning tests which are tests that you keep around to try out on new browsers to investigate what you depend on. I'm not entirely sold on this practice but this chapter is definitely worth the look at performance testing it provides in a few of the more complete aforementioned frameworks.

The next 145 pages are devoted to the JavaScript language itself. The reader will find out in later chapters why this was necessary but this second part felt too long and left me starving for TDD. There's a ton of great knowledge in these chapters and Johansen demonstrates an impressive display in his understanding of ECMAScript standards (all versions thereof) and all the JavaScript engines that implement them. In the following four chapters, the reader is shown the ins and outs of scope, functions, this, closures, anonymous functions, bindings, currying, namespaces, memorization, prototypical inheritance, tons of tricks with properties, mixins, strict mode and even the neat features of tddjs and JSON. What I was most impressed with in this chapter was how much care Johansen took with noting performance pitfalls in all of the above. Example: "closures in loops are generally a performance issue waiting to happen" and on for-in arrays he says "the problem illustrated above can be worked around, as we will see shortly, but not without trading off performance." Johansen seems tireless in enumerating the multitude of ways to accomplish something in JavaScript only to dissect each method critically. If you skip these sections, at least look at 6.1.3 as the bind() implementation developed there becomes critical throughout much of the book's code.

Chapter nine provides yet more dos and do nots in JavaScript with a tabbed panel example that demonstrates precisely what obtrusive JavaScript is and why it is labeled as such. Chapter ten is definitely not to be skipped over as it provides feature detection methods (specifically with regard to functions and properties) that are seen in later code snippets. Part two is devoid of any TDD yet rich in demonstrating the power of JavaScript. This is where the book loses a point for me as this seemed too long and a lot of these lessons — though informative — really seemed like they belonged in another book on the JavaScript language itself. I constantly wondered when I would start to see TDD but to a less experienced developer, these chapters are quite enlightening.

In the third part, we finally get to some TDD in which an Observer Pattern (pub/sub) is designed using tests with incremental improvements in true TDD fashion. Most importantly to the audience, we encounter our first browser inconsistencies that are tackled using TDD. This chapter illustrates how to make your first tdd.js project using the book's code and build your first tests followed up with the isolation of the code into setup and teardown functions. Rinse, wash, repeat for adding observers, checking for observers and notifying observers (all key functionality in the common observer paradigm). This is a great pragmatic example for TDD and the chapter wraps up with error checking and a new way to build a constructor. As we do this, we have to make changes to the tests and Johansen illustrates another critical part of TDD: fixing the tests after you've improved your code.

The twelfth chapter takes our Ajax friend the XMLHttpRequest object and gives it the same treatment as above. Of course, you might know it as the Msxm12.XMLHTTP.6.0 object or a variety of names so this is where our browser differences are exposed. On top of that, we're exposed to stubbing in order to test such an object. The author explores three different ways of stubbing it while building tests for GET requests. After building helpers to successfully stub this, we move on to POST, finally send data in a test and then pay attention to the testing of headers. Personally these two chapters were some of the best in the book and illustrated well a common method of utilizing TDD and stubbing to build up functional JavaScript.

Chapter thirteen builds on the previous chapter by examining polling data in JavaScript and how we might keep open a constant stream of data. Before jumping to the solution, the author investigates strategies like polling intervals and long polling which have their downfalls. We eventually come to the Comet client (which uses JSON objects) and build up our test cases that support our development of our new streaming data client. One important aspect brought up is the trick of using the Clock object to fake time. This was completely new to me and very interesting in simulating time with tick() to quickly fake and test expected lengths of time.

Chapter fourteen was definitely outside of my comfort zone. JavaScript on the server-side? Blasphemy! Johansen begins to bring together the prior elements to form a fully functional chat server all in JavaScript through TDD. In this chapter the reader is introduced to node.js and a custom version of Nodeunit the author modified to make a little more like JsTestDriver. The controller emerges through the TDD cycles. Responses to POST, adding messages, the domain model and even storage of data are given test cases to insure we are testing feature after tiny feature. Toward the end of the chapter, an interesting problem arises with our asynchronous interface. In testing it, how do we know what will result from a nested callback? Johansen introduces the concept of a Promise which is a placeholder that eventually provides a value. Instead of accepting a callback, the asynchronous method returns a promise object which is eventually fulfilled. We can now test adding messages in asynchronous manner to our chat room. The chapter builds on the chat server to passable functionality — all through TDD.

Chapter fifteen concentrates on building the chat client to the above server and in doing so provides the reader with TDD in regards to DOM manipulation and event handling. This chapter finally covers some of the more common problematic aspects of client-side JavaScript. Again, this chapter yielded many tricks that were new to me in TDD. JsTestDriver actually includes two ways to include HTML in a test and Johansen shows how to manipulate the user form on a page in order to test it automatically. The client is developed through TDD and node-paperboy is called in to serve up static files through http with Node.js. The message list displayed in the client is developed through TDD and then the same process used on the user form is done with the message form submission. The author brings in some basic CSS, Juicer and YUI Compressor to reduce all our work down into a 14kB js file containing an entire chat client. With gzip enabled it downloads at about 5kB. Potent stuff.

I was sad that more pages weren't spent on the final section. Chapter sixteen further expounds upon mocking, spies and stubbing. It lists different strategies and how to inject trouble into your code by creating stubs that blow up on purpose during testing. And we get a sort of abbreviated dose of Sinon, a mocking and stubbing library for JavaScript. The author repeats a few test cases from chapter eleven and moves on to mocking. Mocking is mentioned throughout the book but is passed over due to the amount of work required to manually mock something. The chapter ends with the author saying 'it depends' on whether you should use stubbing or mocks but it's pretty clear the author provides stubbing as he enumerates the pros and cons of each.

Chapter seventeen provides some pretty universal rules of thumb to employ when using TDD. From the obvious revealing intent by clear naming to strategies for isolating behavior, it's got good advice for succeeding with TDD. This advice aims to improve readability, generate true unit tests that stay at the unit level and avoid buggy tests. It's worth repeating that he gives a list of 'attacks' for finding deficiencies in tests: "Flip the value of the boolean expressions, remove return values, misspell or null variables and function arguments, introduce off-by-one errors in loops, mutate the value of internal variables." Introduce one deficiency and run the tests. Make sure they break when and where you would expect them to or your testing isn't as hardened as you might expect. Lastly the author recommends using JsLint (like lint for C).

There's a lot of information in this book but I think that the final examples were actually too interesting for my tastes. Often I grapple with the mundane and annoying parts of client side DOM — nothing on the server side. While this might change at some point in the future, I couldn't help but feel that the book would have been better with additional examples of more common problems than a chat client in JavaScript. I was certainly impressed with this example and it will hold the readers' attention much more than what I desire so I feel comfortable recommending this book with a 9/10 to anyone suffering from browser inconsistencies or looking to do TDD in JavaScript.

You can purchase Test-Driven JavaScript Development from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

guruevi writes "SABAM, the Belgian RIAA, wants truckers to start paying for the copyrights to listen to the radio in their cabin (Google translation of Dutch original). SABAM already has a system in place to extract fees from businesses for having radios in the work area for businesses with more than 9 employees, and they find that truckers' cabins are areas of work and thus infringe on their copyrights. The local politicians think this is going too far; they believe truckers need a radio for safety reasons and view a truck cabin as 'an intimate place.'"

An anonymous reader writes "Going after Apple and RIM, Kodak says, 'every digital camera and phone with a camera' infringes on its patents. A judge sided against Kodak in January, but now the US International Trade Commission has agreed to review the judge's decision. With the ITC's ability to block imports, Apple and RIM may have no choice but to fork over dough to Kodak in the event of an unfavorable decision. If the ITC can toss out court decisions like this, one wonders how much hope there is for patent reform. The patent in question is Patent Number 6292218: 'Electronic camera for initiating capture of still images while previewing motion images.'"

f1vlad writes "Philologists have added popular internet abbreviations to the one hundred twenty-six year-old Oxford English Dictionary. Among these are the popular OMG, LOL, and FYI. 'Dictionary compilers said that although the terms are associated with modern electronic communications, some are surprisingly old. The first confirmed use of "OMG" was in a letter in 1917. "Things people think are new words normally have a longer history," Graeme Diamond, the dictionary's principal editor for new words, said Friday.'"

loekessers writes "Breaking in to an encrypted router and using the WiFi connection is not an criminal offense, a Dutch court ruled. (Original article in Dutch; English translation.) WiFi hackers can not be prosecuted for breaching router security. The judge reasoned that the student didn't gain access to the computer connected to the router, but only used the router's internet connection. Under Dutch law, breaking into a computer is forbidden. A computer in The Netherlands is defined as a machine that is used for three things: the storage, processing and transmission of data. A router can therefore not be described as a computer because it is only used to transfer or process data and not for storing bits and bytes. Hacking a device that is no computer by law is not illegal, and can not be prosecuted, the court concluded. "

An anonymous reader writes "Today the first ID cards that include iris and fingerprint biometric information were registered and issued in the Mexican state of Guanajuato. (Original article in Spanish.) The juicier part of the story is that for now, only children will be enrolled in this national biometric database. It is intended that by December 2012 all children in the country will be registered. The alleged purpose of the new ID card is to hinder the abduction of children and prevent child exploitation. The first ID cards are being issued in the same city that last year started implementing a mandatory iris scan for convicted felons and voluntary members of the public in a Minority Reportesque plan to combat delinquency that features iris readers in public transport and ATMs. This comes from the country that last year attempted and failed to create a national database of mobile phone users, again with the purported intention to tackle extortion and kidnappings."

Antique Geekmeister writes "Twitter has just decided to discard the community of developers who've created interesting and innovative UI applications. The announcement shows that they intend to switch from the 'bazaar' model of development to the 'cathedral,' with much tighter control of user interfaces for 'security' and 'consistency.'"

dnsdude told us about the latest developments regarding rumored Libyan Internet censorship. It appears that massive censorship is occuring with two of the five .ly root name servers being unreachable. It's difficult to tell if this is because of intentionally bad routes, or the result of actual infrastructure damage.

xt writes "A recently submitted paper in arXiv claims that by using Bessel beams it is theoretically possible to pull particles towards the light source, opening up new avenues for optical micromanipulation (the direction of the force is size dependent, so it could be used for particle sorting). There is also a simpler article translated in English (original article in Greek)."

Hugh Pickens writes writes "The NY Times reports that there are indications that a sea change is taking place in consumer behavior as a result of the great recession: Americans are buying less tech stuff and making it last longer (reg. may be required). Although in many cases the difference is mere months, economists and consumers say the approach may outlast a full recovery and the return of easy credit, because of the strong impression the downturn has made on consumers. For example Patti Hauseman stuck with her five-year-old Apple computer until it started making odd whirring noises and occasionally malfunctioning before she bought a new computer for Christmas — actually, a refurbished one. 'A week later, the old one died. We timed it pretty well,' says Hauseman, adding that it was not so much that she could not afford new things, but that the last few years of economic turmoil had left her feeling that she could be stealing from her future by throwing away goods that still had value. Consumers are holding onto new cars for a record 63.9 months, up 4.5 months from a year ago and 14 percent since the end of 2008, according one research firm. Industry analysts also report that people on average are waiting 18 months to upgrade their cellphones, up from every 16 months just a few years ago. 'We're not going back to a time of our grandmothers' tales of what they kept and how they used things so carefully,' says Nancy F. Koehn, a professor at the Harvard Business School and a historian of consumer behavior. 'But we'll see a consistent inching or trudging towards that.'"

mangu writes "Iran said on Saturday it is removing the fuel from the reactor of a Russian-built nuclear power plant, a move seen as a big blow to its controversial nuclear program. The plant was first launched by the shah using contractors from Siemens. It was shelved after the Islamic revolution and it lay unfinished through the 1980s. In the early 1990s, Iran sought help for the project after being turned away by Siemens over nuclear proliferation concerns. In 1994, Russia agreed to complete the plant and provide the fuel, with the supply deal committing Iran to returning the spent fuel. The plant has faced hiccups even after its physical launch, with officials blaming the delays in generating electricity on a range of factors, including Bushehr's 'severe weather.' But they deny it was hit by the malicious Stuxent computer worm which struck industrial computers in Iran, although they acknowledge that the personal computers of some personnel at Bushehr were infected with it."

brothke writes "With many different types of log and audit data, Security Information and Event Management (SIEM) attempts to fix that by aggregating, correlating and normalizing the log and audit data. The end result is a single screen that presents all of the disparate data into a common element. While great in theory, the devil is in the details; and there are plenty of details in deploying a SIEM on corporate networks. Security Information and Event Management Implementation provides a solid introduction, overview and analysis of what a SIEM (also known as SIM, SEM, SEIM and others) is, and what needs to go into it for an effective deployment and operation." Read below for the rest of Ben's review. Security Information and Event Management Implementation author David Miller pages 464 publisher McGraw-Hill Osborne Media rating 8/10 reviewer Ben Rothke ISBN 0071701095 summary Provides an excellent overview of the topic and will be of value to those reading looking for answer around SIEM As a technology, SIEM provides real-time monitoring and historical reporting of information security events from networks, servers, systems, applications and more. Many firms have deployed SIEM as a method to address regulatory compliance reporting requirements, in addition to using it as a mechanism in which to build a robust information security operation, integrating the SIEM into their security management and incident response areas.

With that, the good news is that the SIEM market is now at a mature state, with numerous vendors competing off each other. Combined with the level of SIEM adoption, it's ready for prime time. But ensuring it works in prime time is heavily dependent upon the requirements definitions and planning.

The books 15 chapters are organized in three parts: Introduction to SIEM: Threat Intelligence for IT Systems, IT Threat Intelligence Using SIEM Systems and SIEM Tools. Part 3 (chapters 8-15) provides the bulk of the reading.

Part 1 provides a high-level overview of the topic and covers information security fundamentals. Chapter 2 details the various threats that the SIEM will be used to defend against. While chapter 3 gets into regulatory compliance, which is a key driver for many SIEM rollouts.

Part 2 details four SIEM vendors. The products the authors selected to showcase are: OSSIM, ArcSight ESM, Cisco Mars and Ounce Labs QRadar. While it is debatable if OSSIM is a SIEM, I am not sure why the authors did not include the netForensics product. This is especially true since the nFX SIM One software is one of the better tools which works on large deployments in which customization is needed.

A mistake many firms makes when considering a SIEM is spending too much time selecting a specific SIEM vendor and not enough time defining their specific security requirements for the SIEM product. The book does a good job of communicating the important of effective requirements definition. An important notion around requirements definition is that it must not involve just IT and security groups alone. Other groups including audit, regulatory, legal, administration, applications and more must be involved.

The book provides examples of real-world advice. A good point made in chapter 11 is the need to realize that a SIEM takes time to develop and is an out of the box solution. The authors note that one should not expect full inventory activity and actionable information immediately. It often may take a few weeks for that information to be normalized into data that is actionable.

Part 3 goes into the various products. In chapter 12, while about QRadar, lists 10 highly detailed questions that must be answered irregardless of what SIEM vendor will be used. These 10 questions (for a formal SIEM definition, there are a good 30 or more that can be asked) require a firm to truly understand their infrastructure and environment, before they deploy a SIEM. The authors note that these questions are meant to facilitate a firm doing their homework around the SIEM. Detailed answers to these questions should not be underestimated, as failure to do them in advance can lead to a SIEM deployment that will ultimately fail.

For many readers, the screen print of a QRadar system settings console on page 278 may be enough to scare them away from a SIEM. This screen, of which there are many in QRadar, list over 50 settings that must be configured in order to effectively use the software. While many of the default settings can be used; firms should know exactly what their settings should be if they want to get the most out of SIEM solution.

In many books, the appendix is often public information which is simply added as filler to increase the page count. The appendix The Ways and Means of the Security Analyst is superb. It details the human element of the SIEM, the security analyst, which is often what will make or break the SIEM. The analyst is the one who will use the SIEM and attempt to make sense of it. A SIEM deployment without good analysts is ultimately useless.

It should be noted that even though the book has the term implementation in the title, it is not really a full implementation reference. It should be viewed as a comprehensive introduction to SIEM. The reason is that when one digs into the deeper layers of a SIEM deployment, there are significant complexities that must be dealt with. Anyone who attempts to deploy SIEM based on this guide alone will likely be disappointed. This is not a fault of the book; rather a reality of the complexity of a SIEM, and the amount of pages it requires to be written.

While the book does have implementation guidelines around the insulation and configuration of 4 SIEM products, the real challenge in a SIEM is the post-installation configuration issues, and not simply the installation. Perhaps the authors will take this as a challenge to create a second volume of this book detailing those issues.

With that, the book does provide an excellent overview of the topic and will be of value to those reading looking for answer around SIEM. Those looking for a solid introduction to the world of SIEM should definitely get a copy. Don't think about a SIEM without it.

You can purchase Security Information and Event Management Implementation from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

brothke writes "With many different types of log and audit data, Security Information and Event Management (SIEM) attempts to fix that by aggregating, correlating and normalizing the log and audit data. The end result is a single screen that presents all of the disparate data into a common element. While great in theory, the devil is in the details; and there are plenty of details in deploying a SIEM on corporate networks. Security Information and Event Management Implementation provides a solid introduction, overview and analysis of what a SIEM (also known as SIM, SEM, SEIM and others) is, and what needs to go into it for an effective deployment and operation." Read below for the rest of Ben's review. Security Information and Event Management Implementation author David Miller pages 464 publisher McGraw-Hill Osborne Media rating 8/10 reviewer Ben Rothke ISBN 0071701095 summary Provides an excellent overview of the topic and will be of value to those reading looking for answer around SIEM As a technology, SIEM provides real-time monitoring and historical reporting of information security events from networks, servers, systems, applications and more. Many firms have deployed SIEM as a method to address regulatory compliance reporting requirements, in addition to using it as a mechanism in which to build a robust information security operation, integrating the SIEM into their security management and incident response areas.

With that, the good news is that the SIEM market is now at a mature state, with numerous vendors competing off each other. Combined with the level of SIEM adoption, it's ready for prime time. But ensuring it works in prime time is heavily dependent upon the requirements definitions and planning.

The books 15 chapters are organized in three parts: Introduction to SIEM: Threat Intelligence for IT Systems, IT Threat Intelligence Using SIEM Systems and SIEM Tools. Part 3 (chapters 8-15) provides the bulk of the reading.

Part 1 provides a high-level overview of the topic and covers information security fundamentals. Chapter 2 details the various threats that the SIEM will be used to defend against. While chapter 3 gets into regulatory compliance, which is a key driver for many SIEM rollouts.

Part 2 details four SIEM vendors. The products the authors selected to showcase are: OSSIM, ArcSight ESM, Cisco Mars and Ounce Labs QRadar. While it is debatable if OSSIM is a SIEM, I am not sure why the authors did not include the netForensics product. This is especially true since the nFX SIM One software is one of the better tools which works on large deployments in which customization is needed.

A mistake many firms makes when considering a SIEM is spending too much time selecting a specific SIEM vendor and not enough time defining their specific security requirements for the SIEM product. The book does a good job of communicating the important of effective requirements definition. An important notion around requirements definition is that it must not involve just IT and security groups alone. Other groups including audit, regulatory, legal, administration, applications and more must be involved.

The book provides examples of real-world advice. A good point made in chapter 11 is the need to realize that a SIEM takes time to develop and is an out of the box solution. The authors note that one should not expect full inventory activity and actionable information immediately. It often may take a few weeks for that information to be normalized into data that is actionable.

Part 3 goes into the various products. In chapter 12, while about QRadar, lists 10 highly detailed questions that must be answered irregardless of what SIEM vendor will be used. These 10 questions (for a formal SIEM definition, there are a good 30 or more that can be asked) require a firm to truly understand their infrastructure and environment, before they deploy a SIEM. The authors note that these questions are meant to facilitate a firm doing their homework around the SIEM. Detailed answers to these questions should not be underestimated, as failure to do them in advance can lead to a SIEM deployment that will ultimately fail.

For many readers, the screen print of a QRadar system settings console on page 278 may be enough to scare them away from a SIEM. This screen, of which there are many in QRadar, list over 50 settings that must be configured in order to effectively use the software. While many of the default settings can be used; firms should know exactly what their settings should be if they want to get the most out of SIEM solution.

In many books, the appendix is often public information which is simply added as filler to increase the page count. The appendix The Ways and Means of the Security Analyst is superb. It details the human element of the SIEM, the security analyst, which is often what will make or break the SIEM. The analyst is the one who will use the SIEM and attempt to make sense of it. A SIEM deployment without good analysts is ultimately useless.

It should be noted that even though the book has the term implementation in the title, it is not really a full implementation reference. It should be viewed as a comprehensive introduction to SIEM. The reason is that when one digs into the deeper layers of a SIEM deployment, there are significant complexities that must be dealt with. Anyone who attempts to deploy SIEM based on this guide alone will likely be disappointed. This is not a fault of the book; rather a reality of the complexity of a SIEM, and the amount of pages it requires to be written.

While the book does have implementation guidelines around the insulation and configuration of 4 SIEM products, the real challenge in a SIEM is the post-installation configuration issues, and not simply the installation. Perhaps the authors will take this as a challenge to create a second volume of this book detailing those issues.

With that, the book does provide an excellent overview of the topic and will be of value to those reading looking for answer around SIEM. Those looking for a solid introduction to the world of SIEM should definitely get a copy. Don't think about a SIEM without it.

You can purchase Security Information and Event Management Implementation from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

An anonymous reader writes "Brazilian technology news site O Globo posted an interesting comparison on how free anti-malware behaves against non-English threats (Google translation of Portuguese original). By using a database of over 3000 samples from Brazil's Security Incident Contact Center, the numbers are quite different from all US anti-malware reviews. While Avira achieved the best score, 78%, Microsoft Security Essentials stopped less than 14%. This can be a headache for some large multinational corporations, whose IT departments deploy US anti-malware on the entire network, but have network segments outside US with many 'unknown' threats roaming around. I wonder what the results would be in other countries."

An anonymous reader writes "In the wake of Nokia's announcement that it will be cheerfully throwing its existing developer community under a bus by not offering Qt for Windows Phone, a project to implement Qt on Android has announced its initial alpha release. Necessitas project lead Bogdan Vatra writes, 'I had a dream that one day, I'll be able to deploy existing Qt software on any Android platform. I had a dream that one day, all Qt applications will use system wide shared Qt libraries. I had a dream that one day, all Qt applications once compiled and deployed to one android platform, will run on any other newer android platform and will last for years without any recompilation. I had a dream that one day, I'll be able to create, manage, compile debug and deploy Qt apps using a first class citizen IDE. Now, those dreams become reality.' The Necessitas wiki offers some documentation on Qt for Android. A demo video of Qt for Android in action is also available."

intellitech tips news of a study examining the Gulf of Mexico sea floor in the wake of the Deepwater Horizon disaster. Marine scientists have found a thick layer of oil, and say it has devastated life there. "Studies using a submersible found a layer, as much as 10cm thick in places, of dead animals and oil, said Samantha Joye of the University of Georgia. Knocking these animals out of the food chain will, in time, affect species relevant to fisheries. She disputed an assessment by BP's compensation fund that the Gulf of Mexico will recover by the end of 2012. ... 'The impact on the benthos was devastating,' she told BBC News. 'Filter-feeding organisms, invertebrate worms, corals, sea fans — all of those were substantially impacted — and by impacted, I mean essentially killed. Another critical point is that detrital feeders like sea cucumbers, brittle stars that wander around the bottom, I didn't see a living (sea cucumber) around on any of the wellhead dives. They're typically everywhere, and we saw none.'"

CWmike writes "Google released the first beta of Chrome 10 on Thursday, and Computerworld found it to be 64% faster than its predecessor on Google's V8 JavaScript benchmarks. But in another JS benchmark — WebKit's widely-cited SunSpider — Chrome 10 beta was no faster than Chrome 9. Yesterday's Chrome 10 beta release was the first to feature 'Crankshaft,' a new optimization technology. Google engineers have previously explained why SunSpider scores for a Crankshaft-equipped Chrome show little, if any, improvement over other browsers. 'The idea [in Crankshaft] is to heavily optimize code that is frequently executed and not waste time optimizing code that is not,' said the engineers. 'Because of this, benchmarks that finish in just a few milliseconds, such as SunSpider, will show little improvement with Crankshaft. The more work an application does, the bigger the gains will be.' [Chrome 10 beta download here.]"

eldavojohn writes "Riding the tail of Apple's 30% announcement, Google's Eric Schmidt has announced One Pass, a new method for users to pay for content. The BBC is reporting that Google is taking a 10% cut. One Pass will work on Google sites and on phones and tablets as the announcement notes: 'Readers who purchase from a One Pass publisher can access their content on tablets, smartphones and websites using a single sign-on with an email and password. Importantly, the service helps publishers authenticate existing subscribers so that readers don't have to re-subscribe in order to access their content on new devices.' This is to be handled through Google Checkout."

RedEaredSlider writes "Aimed at stripping search results of pages from 'low-quality' sites, a new Google Chrome extension allows users to block specified websites from appearing in search results. The names of these sites are then sent to Google, which will study the collected results and use them to determine future page ranking systems. Google principal engineer Matt Cutts wrote in a post on the Google blog that the company hopes the extension will improve the quality of search results. The company has been the target of criticism in recent months, much of which centered around the effect that content farms were having on searches."

Giorgio Maone writes "Italian Police just seized the Savona e Ponente Blog because the 60-year-old journalist Valeria Rossi posted a satirical article titled 'I want to kill Berlusconi,' writing that 'you can't feel guilty of wishing him death, because he's not human: he's an alien, with incredible psychic powers.' Otherwise, how could such a clown, with multiple pending trials for corruption, tax offenses, abuse of power and even child prostitution, convince the majority of the other politicians and a consistent slice of Italian people to keep him as their prime minister for almost 20 years now? Here's a mirror of the incriminating text (Italian)." And here's a translation to English.

Mr. McGibby writes "After the announcement of the partnership between Nokia and Microsoft this morning workers voiced their concern with the deal by walking out of Nokia facilities. It is believed that as many as a thousand workers marched out today (or took the day off using flex time) so that the company would know that they don't believe the partnership is in their best interest, even after CEO' Stephen Elop's startlingly frank 'burning platform' memo earlier this week."
Looks like many investors felt the same way.

Antisyzygy writes "President Obama is calling for $53B to be appropriated for the construction of high-speed rail in the United States over the next 6 years. Assuming Congress approves this plan, the funding would be spent on developing and/or improving trains that travel at approximately 250 miles/hour, as well as spent on connecting existing rail lines to new developed high speed lines."

eldavojohn writes "Coinciding with the 32nd anniversary of the Iranian revolution, Iran opened a center to receive satellite images built 'entirely by Iranian engineers.' Iran promised that by the end of their year (March of 2011) they would launch two observational satellites: Fajr (Dawn) and Rasad-1 (Observation-1). You might recall two years ago when they launched Omid, which completed about 700 orbits in two weeks. There are reports that new launch rockets will be revealed in February to launch the new satellites — all equipment is claimed to be entirely Iranian made. Iranian media is reporting that one of the satellites 'carries remote measuring equipment that would be used in meteorology and identifying sea borders.' The Iranian Student News Agency says Explorer 4 (Kavoshgar 4) is meant to transport humans and other living organisms into space, and that the sensory on the satellites 'is able to find gas and oil resources, identify coal mines, jungles and agricultural products as well as salty-marsh and contaminated environments.' These rapid fire achievements are not the only bragging Iran has done as of late; they also claim 'new gamma radiation units for medical treatments and a supercomputer billed as among the top 500 most powerful in the world. But, fact or fiction aside, the satellites have old enemies speculating."

eldavojohn writes "Coinciding with the 32nd anniversary of the Iranian revolution, Iran opened a center to receive satellite images built 'entirely by Iranian engineers.' Iran promised that by the end of their year (March of 2011) they would launch two observational satellites: Fajr (Dawn) and Rasad-1 (Observation-1). You might recall two years ago when they launched Omid, which completed about 700 orbits in two weeks. There are reports that new launch rockets will be revealed in February to launch the new satellites — all equipment is claimed to be entirely Iranian made. Iranian media is reporting that one of the satellites 'carries remote measuring equipment that would be used in meteorology and identifying sea borders.' The Iranian Student News Agency says Explorer 4 (Kavoshgar 4) is meant to transport humans and other living organisms into space, and that the sensory on the satellites 'is able to find gas and oil resources, identify coal mines, jungles and agricultural products as well as salty-marsh and contaminated environments.' These rapid fire achievements are not the only bragging Iran has done as of late; they also claim 'new gamma radiation units for medical treatments and a supercomputer billed as among the top 500 most powerful in the world. But, fact or fiction aside, the satellites have old enemies speculating."

another similar writes "This article teaches us that if you happen to have a bad break up with someone who's reasonably tech-savvy, your descriptively captioned photos might end up all over the internet. From the article: 'Upset boyfriends and girlfriends are nothing new. There are plenty of stories of girlfriends getting back at their ex-boyfriends for mistreatment and visa versa. But in the age where Google ranks supreme, you do not want to mess with a girl who knows how to manipulate Google.'"

eldavojohn writes "My friend Drew was notified via Twitter that one of his Flickr images had been selected as poster child for freeloaders who abuse the benefits system in an Elsevier news story in the Netherlands. The original image clearly gives an CC BY-NC 2.0 license to the image which doesn't appear in the story — a story which generates revenue for Elsevier. My friend doesn't speak Dutch so he's a little confused about what, if anything, he can do in this situation. I'm reminded of a family's Christmas photo showing up on a billboard in Prague and I wonder if photo sharing sites are treated as free to abuse regardless of copyright by foreign businesses? Has anyone else heard of this sort of thing happening with images from social photo sharing sites?"

eldavojohn writes "The US government's Broadcasting Board of Governors has revealed in a completed FOIA request the development, testing and planned use of Feed Over E-mail (FOE) to push news through China's firewall. This FOIA request (PDF) indicates that the US government is interested in making sure Chinese people receive up-to-date news, and it wants to expand the arsenal of anti-censorship tools (for news at least). The FOE project is GPLv3 and maintained by Sho Ho of BBG."

An anonymous reader submitted a video clip that allegedly demonstrates a hacker working in a honeypot. If you fear for the future security of the internet, this video will set your mind at ease.

greg_barton writes "The Energy From Thorium blog reports, 'The People's Republic of China has initiated a research and development project in thorium molten-salt reactor technology. It was announced in the Chinese Academy of Sciences annual conference on Tuesday, January 25.' The liquid-fluoride thorium reactor is an alternative reactor design that 1) burns existing nuclear waste, 2) uses abundant thorium as a base fuel, 3) produces far less toxic, shorter-lived waste than existing designs, and 4) can be mass produced, run unattended for years, and installed underground for safety."