Stuart Halloway

By Stuart Halloway

edn and Fressian are self-describing, schema-free, batteries-included, extensible data languages. In this talk, you will find out where you might benefit from these languages over e.g. JSON or XML.

Systems use many languages, and not just programming languages such as Java, C#, Ruby, or Python. Systems also relay on data languages, both for data on the wire, and for data at rest. These data languages differ greatly in their design objectives and capabilities, and are often less understood than their programming language counterparts.

This talk will introduce two data notations: edn and Fressian, which share several common characteristics. Both are

• self-describing
• schema-free
• batteries-included
• extensible

These capabilities align well with the dynamic, flexible needs of real systems. And in their key difference (text vs. binary), edn and Fressian cover the bases of human readability and maximum performance.

By Stuart Halloway

No business objectives will be accomplished during this talk.

The purpose of "Pure Fun" is to participate in the sheer joy of using computers. Each talk is an individual performance where you might see or participate in some of the following:

• Exploring music with SuperCollider and Overtone
• Flying an A/R drone helicopter
• Controlling a robot
• Developing a core wars game
• Visualizing data from ridiculous sources

By Stuart Halloway

Traditional automated testing approches combine input generation, execution, output capture, and validation inside the bodies of single functions. Generative testing approaches gain expressive power by isolating these steps.

With generative testing:

• a generator is a declarative description of possible inputs to a function
• execution is up to your program
• outputs are data, and can be captured for future study
• validators are programs that have access to the generators, the program, and the outputs

There are a number of benefits to this approach:

• once test data generation is separate, it is immediately obvious that such data generation should be statistical, not merely a few hand-picked cases
• validators can be reused in a variety of
• it becomes easier to identify and develop declarative, logic-based validations, rather than imperative ones
• the various phases can be decoupled and run at different times

This talk introduces test data generation and generative testing, using for its examples the data.generators and test.generative libraries developed by the author.

Resources

• test.generative
• data.generators
• chapter 10 of Programming Clojure

By Stuart Halloway

Simulation allows a rigorous, scalable, and reproducible approach to testing. The separation of concerns, and the use of a versioned, time-aware database, give simulation great power. This talk will introduce simulation testing, walking through a complete example using Simulant, an open-source simulation library.

Simulation allows a rigorous, scalable, and reproducible approach to testing:

Statistical modeling

Simulation begins with statistical models of the use of your system. This model includes facts such as "we have identified four customer profiles, each with different browsing and purchasing patterns" or "the analytics query for the management report must run every Wednesday afternoon." Models are versioned and kept in a database.

Activity streams

The statistical models are used to create activity streams. Each agent in the system represents a human user or external process interacting with the system, and has its own timestamped stream of interactions. With a large number of agents, simulations can produce the highly concurrent activity expected in a large production system.

Distributed execution

Agents are scaled across as many machines as are necessary to both handle the simulation load, and give access to the system under test. The simulator coordinates time, playing through the activity streams for all the agents.

Result Capture

Every step of the simulation process, including modeling, activity stream generation, execution, and the code itself, is captured and stored in a database for further analysis. You will typically also capture whatever logs and metrics your system produces.

Validation

Since all phases of a simulation are kept in a database, validation can be performed at any time. This differs markedly from many approaches to testing, which require in-the-moment validation against the live system.

Separation of concerns

The separation of concerns above, and the use of a versioned, time-aware database, gives simulation great power. Imagine that you get a bug report from the field, and you realize that the bug corresponds to a corner case that you failed to consider. With a simulation-based approach, you can write a new validation for the corner case, and run that validation against your past simulation results, without ever running your actual system.

This talk will introduce simulation testing, walking through a complete example using Simulant, an open-source simulation library.

By Stuart Halloway

Clojure is a powerful dynamic language that compiles to many target environments, including the JVM, JavaScript, and the CLR. In this talk, you will learn how to think in Clojure, and why you should want to.

Clojure encourages functional style with persistent data structures, a rich library of pure functions, and powerful processing support via the seq and reducer abstractions. Clojure implements a reference model for state, where references represent atomic successions of values, and change is encapsulated by value and reference constructors. This reference model is more substantive and suitable to application development than individual techniques such as Software Transactional Memory (STM) or actors.

The most important single principle behind Clojure is simplicity. Clojure's abstractions are simple and orthogonal. A la carte polymorphism, careful support for names and namespaces, the reference succession model, and a wide selection of small, composable protocols make Clojure programming swift, surgical and accurate.

Clojure's expressiveness does not mean that you have to compromise on power. It is an explicit design goal of Clojure to provide access to the power of the underlying platform, and for programmers never to have to "drop down" to the platform level for performance-sensitive work.

On the Web

• Programming Clojure by Stuart Halloway and Aaron Bedra