Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
Blackberry

Submission + - BlackBerry 10 unveiled (theglobeandmail.com)

Submitted by arcite
arcite writes: Research in Motion Ltd's new CEO, Thorsten Heins unveiled BlackBerry 10 in Florida today. Will new features such as a virtual keyboard that learns from typing behavior to a camera that easily focuses on faces be enough to scrape back precious market share (which could possibly fall to 5%) from the likes of Apple and Android? With no physical device yet revealed and a release date ranging anywhere from August to October, it will be an uphill battle.

Comment Dead in the water (Score 1) 3

by kilo242 (#35698364) Attached to: Congress passes self passing bill!
So, the House passes this bill, and the Senate still refuses to respond. The House does not have any authority to enforce this law. If both the Senate and the President are not in support of the law, why should they care about any of the provisions in said law?

Submission + - New quantum record: 14 bits! (nanowerk.com)

Submitted by Tx-0
Tx-0 writes: Quantum physicists from the University of Innsbruck have set another world record: They have achieved controlled entanglement of 14 quantum bits (qubits) and, thus, realized the largest quantum register that has ever been produced. With this experiment the scientists have not only come closer to the realization of a quantum computer but they also show surprising results for the quantum mechanical phenomenon of entanglement.
By now the Innsbruck experimental physicists have succeeded in confining up to 64 particles in an ion trap. "We are not able to entangle this high number of ions yet," says Thomas Monz. "However, our current findings provide us with a better understanding about the behavior of many entangled particles." And this knowledge may soon enable them to entangle even more atoms.
Books

Submission + - Book Review: Test-Driven JavaScript Development (tddjs.com)

Submitted by
eldavojohn
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.

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, memoization, prototypal 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.

To sample some of the book, check out the Safari Books page. Test-Driven Javascript Development is available in many open formats with watermarks or from Amazon.com. Slashdot welcomes readers' book reviews — to see your own review here, read the book review guidelines, then visit the submission page."

Submission + - Using the Open Records Law to Intimidate Critics (nytimes.com) 4

Submitted by Layzej
Layzej writes: On March 15 Professor Bill Cronon posted his first blog. The subject was the role of the American Legislative Exchange Council in influencing recent legislation in this state and across the country. Less than two days later his university received a communication formally requesting under the states Open Records Law copies of all emails he sent or received pertaining to matters raised in the blog.

Remarkably, the request was sent to the universities legal office by Stephan Thompson of the Republican Party of Wisconsin, with no effort to obscure the political motivations behind it. In a recent editorial the New York Times notes that demanding copies of e-mails and other documents is the latest technique used by conservatives to silence critics.

Submission + - US ITCMay Reverse Judge Ruling in Kodak v Apple (bloomberg.com)

Submitted by Anonymous Coward
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 U.S. International Trade Commission has agreed to review the judges decision. The US ITC will potentially reach the opposite the decision, and with the ITC's ability to block imports, Apple and RIM may have no choice but to fork over dough to Kodak. 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."
Android

Submission + - Samsung's happy Galaxy Tab users are actors. (technologizer.com)

Submitted by
harrymcc
harrymcc writes: "At the CTIA Wireless show in Orlando this week, Samsung unveiled new Galaxy Tab tablets and showed videos of interviews with "true-life" users who raved about the Tab, including a travel writer, a filmmaker, and a real-estate CEO. One problem: the writer and the CEO are actually New York stage actors."
Microsoft

Submission + - MS Removes HTTPS from Hotmail for Troubled Nations (eff.org)

Submitted by Anonymous Coward
An anonymous reader writes: Microsoft has removed HTTPS from Hotmail for many US-embargoed or otherwise troubled countries. The current list of countries for which they no longer enable HTTPS is known to include Bahrain, Morocco, Algeria, Syria, Sudan, Iran, Lebanon, Jordan, Congo, Myanmar, Nigeria, Kazakhstan, Uzbekistan, Turkmenistan, Tajikistan, and Kyrgyzstan. Journalists and others whose lives may be in danger due oppressive net monitoring in those countries may wish to use HTTPS everywhere and are also encouraged to migrate to non-Microsoft email providers, like Yahoo and Google.
Apple

Submission + - Judge: Apple products don't infringe Nokia patents (networkworld.com)

Submitted by Anonymous Coward
An anonymous reader writes: Apple today won a battle in an ongoing legal war with Nokia over patents that touch on pretty much all of Apple's product line. Since 2009, Apple and Nokia have sued and countersued each other into oblivion. In one particular legal action from May 2010, Nokia filed suit against Apple with a complaint to the ITC (International Trade Commission) alleging that Apple's iPhone and iPad 3G infringe on 5 of Nokia's patents.
Idle

Submission + - Ohio man gets a $16.4 million cable bill (yahoo.com)

Submitted by wiredmikey
wiredmikey writes: You may have heard the story about the man living in a 14x60 trailer who got a $12,864 electric bill, or the Corpus Christie man who was billed $7.7 million by his water company, or the Canadian whose cell phone provider hit him up for $85,000...

In this case an Ohio man's attempt to make a payment on his cable bill to Time Warner was rejected, and he learned that the company had calculated his past-due amount at more than $16 million.
Businesses

Submission + - AT&T's Metered Billing Off By Up To 4,700% (itworld.com)

Submitted by
jfruhlinger
jfruhlinger writes: "Metered billing for home Internet service may be the way of the future. But shouldn't we have the right to expect that the meters will at least be accurate? As AT&T moves its DSL and fiber customers to plans where they'll have to pay for overages, some users have noticed that the company' assessment of how much data is being used can be wildly inaccurate."
Science

Submission + - Journey to the mantle of the Earth by 2020 (cosmosmagazine.com)

Submitted by Anonymous Coward
An anonymous reader writes: A half-century after the first attempt to drill through the ocean crust into the Earth’s mantle, a new campaign armed with improved technology is underway that could reach the mantle by the end of the decade, researchers say.

Submission + - Auditor Calls For Government Ban on Gmail, Hotmail (itnews.com.au)

Submitted by
aesoteric
aesoteric writes: "The Australian National Audit Office has called on all Australian government agencies to block free web-based email services like Gmail and Hotmail to mitigate security and information integrity risks. The auditor noted that such public email services "should be blocked on agency IT systems, as these can provide an easily accessible point of entry for an external attack and subject the agency to the potential for intended or unintended information disclosure." Not surprisingly, the move is seen by some as an attempt to prevent a WikiLeaks-style disclosure from occurring."

Slashdot Top Deals

A holding company is a thing where you hand an accomplice the goods while the policeman searches you.

Close