Automated QA Testing at EA: Driven by Events

A discussion with Michael Donat, Jafar Husain, and Terry Coatta

To millions of game geeks, the position of QA (quality assurance) tester at Electronic Arts must seem like a dream job. But from the company’s perspective, the overhead associated with QA can look downright frightening, particularly in an era of massively multiplayer games.

Automated QA Testing at EA: Driven by Events

 

Related:
Orchestrating an Automated Test Lab
Finding Usability Bugs with Automated Tests
Adopting DevOps Practices in Quality Assurance

Design Exploration through Code-generating DSLs

High-level DSLs for low-level programming

BO JOEL SVENSSON, INDIANA UNIVERSITY
MARY SHEERAN, CHALMERS UNIVERSITY OF TECHNOLOGY
RYAN NEWTON, INDIANA UNIVERSITY

DSLs (domain-specific languages) make programs shorter and easier to write. They can be stand-alone—for example, LaTeX, Makefiles, and SQL—or they can be embedded in a host language. You might think that DSLs embedded in high-level languages would be abstract or mathematically oriented, far from the nitty-gritty of low-level programming. This is not the case. This article demonstrates how high-level EDSLs (embedded DSLs) really can ease low-level programming. There is no contradiction.

Design Exploration through Code-generating DSLs

 

Related:
Purpose-Built Languages
The Ideal HPC Programming Language
Creating Languages in Racket

 

Finding More Than One Worm in the Apple

If you see something, say something.

MIKE BLAND

In February Apple revealed and fixed an SSL (Secure Sockets Layer) vulnerability that had gone undiscovered since the release of iOS 6.0 in September 2012. It left users vulnerable to man-in-the-middle attacks thanks to a short circuit in the SSL/TLS (Transport Layer Security) handshake algorithm introduced by the duplication of agoto statement. Since the discovery of this very serious bug, many people have written about potential causes. A close inspection of the code, however, reveals not only how a unit test could have been written to catch the bug, but also how to refactor the existing code to make the algorithm testable—as well as more clues to the nature of the error and the environment that produced it.

Finding More Than One Worm in the Apple

 

Related:
Security is Harder than You Think
Nine IM Accounts and Counting
Browser Security Case Study

Domain-specific Languages and Code Synthesis Using Haskell

Looking at embedded DSLs

ANDY GILL, UNIVERSITY OF KANSAS

There are many ways to give instructions to a computer: an electrical engineer might write a MATLAB program; a database administrator might write an SQL script; a hardware engineer might write in Verilog; and an accountant might write a spreadsheet with embedded formulas. Aside from the difference in language used in each of these examples, there is an important difference in form andidiom. Each uses a language customized to the job at hand, and each builds computational requests in a form both familiar and productive for programmers (although accountants may not think of themselves as programmers). In short, each of these examples uses a DSL (domain-specific language).

Domain-specific Languages and Code Synthesis Using Haskell

Related:

OCaml for the Masses
The World According to LINQ
DSL for the Uninitiated

The NSA and Snowden: Securing the All-Seeing Eye

How good security at the NSA could have stopped him

BOB TOXEN

Edward Snowden, while an NSA (National Security Agency) contractor at Booz Allen Hamilton in Hawaii, copied up to 1.7 million top-secret and above documents, smuggling copies on a thumb drive out of the secure facility in which he worked, and later released many to the press. This has altered the relationship of the U.S. government with the American people, as well as with other countries. This article examines the computer security aspects of how the NSA could have prevented this, perhaps the most damaging breach of secrets in U.S. history. The accompanying sidebar looks at the Constitutional, legal, and moral issues.

http://queue.acm.org/detail.cfm?id=2612261

 

The Curse of the Excluded Middle

“Mostly functional” programming does not work.

ERIK MEIJER

There is a trend in the software industry to sell “mostly functional” programming as the silver bullet for solving problems developers face with concurrency, parallelism (manycore), and, of course, Big Data. Contemporary imperative languages could continue the ongoing trend, embrace closures, and try to limit mutation and other side effects. Unfortunately, just as “mostly secure” does not work, “mostly functional” does not work either. Instead, developers should seriously consider a completely fundamentalist option as well: embrace pure lazy functional programming with all effects explicitly surfaced in the type system using monads.

The Curse of the Excluded Middle

 

Related:
A Conversation with Erik Meijer and José Blakeley
Multitier Programming in Hop
FPGA Programming for the Masses

 

Forked Over

 

Shortchanged by open source

Dear KV,

 

How can one make reasonable packages based on open-source software when most open-source projects simply advise you to take the latest bits on GitHub or SourceForge? We could fork the code, as GitHub encourages us to do, and then make our own releases, but that puts the release-engineering work that we would expect from the project onto us.

 

Forked Over

Forked Over

George V. Neville-Neil

 

Don’t Settle for Eventual Consistency

Stronger properties for low-latency geo-replicated storage

WYATT LLOYD, FACEBOOK; MICHAEL J. FREEDMAN, PRINCETON UNIVERSITY; MICHAEL KAMINSKY, INTEL LABS; DAVID G. ANDERSEN, CARNEGIE MELLON UNIVERSITY

Geo-replicated storage provides copies of the same data at multiple, geographically distinct locations. Facebook, for example, geo-replicates its data (profiles, friends lists, likes, etc.) to data centers on the east and west coasts of the United States, and in Europe. In each data center, a tier of separate Web servers accepts browser requests and then handles those requests by reading and writing data from the storage system

Don’t Settle for Eventual Consistency

 

Related:
Proving the Correctness of Nonblocking Data Structures
Eventual Consistency Today: Limitations, Extensions, and Beyond
Structured Deferral: Synchronization via Procrastination

Please Put OpenSSL Out of Its Misery

OpenSSL must die, for it will never get any better.

POUL-HENNING KAMP

The OpenSSL software package is around 300,000 lines of code, which means there are probably around 299 bugs still there, now that the Heartbleed bug — which allowed pretty much anybody to retrieve internal state to which they should normally not have access — has been fixed.

That’s really all you need to know, but you also know that won’t stop me, right?

Please Put OpenSSL Out of Its Misery

 

A Primer on Provenance

Better understanding of data requires tracking its history and context.

LUCIAN CARATA, SHERIF AKOUSH, NIKILESH BALAKRISHNAN, THOMAS BYTHEWAY, RIPDUMAN SOHAN, MARGO SELTZER, ANDY HOPPER

Assessing the quality or validity of a piece of data is not usually done in isolation. You typically examine the context in which the data appears and try to determine its original sources or review the process through which it was created. This is not so straightforward when dealing with digital data, however: the result of a computation might have been derived from numerous sources and by applying complex successive transformations, possibly over long periods of time.

A Primer on Provenance

 

Related:
Provenance in Sensor Data Management
CTO Roundtable: Storage
Better Scripts, Better Games