Stuart Halloway

Architectural Briefings are interactive presentations by and for architects on specific technology topics. The purpose is to empower architects to make decisions about the choice and application of tech. Note that you don't have to have “Architect” in your title to participate, this is for anybody who makes architectural decisions.

Developers make decisions all the time, and can never have enough information and support. At Cognitect, we run a weekly Architectural Briefing as a resource for the team. Everybody participates, both attending and speaking. In this talk, we will cover

• a template for Architectural Briefings
• how to develop and present an Architectural Briefing
• how to run an Architectural Briefing program in your organization

We will finish with an example briefing, showing how these ideas come together.

The key to understanding Clojure is ideas, not language constructs.
In this talk, we will approach Clojure via 10 Big Ideas.

Each of these ideas is valuable and useful a la carte, not necessarily
only in a Clojure together. Taken together, they beging to fill in the
picture of why Clojure is changing the way many programmers think
about software development.

• edn
• Persistent Data Structures
• Atomic Success Model
• Seqs
• Protocols
• ClojureScript
• Reducers
• core.logic
• Datalog
• core.async

The key to understanding Clojure web development is ideas, not language constructs. In this talk, we will approach Clojure web development via 7 Big Ideas. Each of these ideas is valuable and useful a la carte, and not necessarily only in Clojure. Taken together, they begin to fill in the picture of why Clojure is changing the way many programmers think about web development.

The key to understanding Clojure web development is ideas, not language constructs. In this talk, we will approach Clojure web development via 7 Big Ideas:

• edn, not json
• core.async, not callbacks
• platform, not language
• data, not objects
• protocols, not interfaces
• libraries, not frameworks
• Ash za durbatulûk!

Each of these ideas is valuable and useful a la carte, and not necessarily only in Clojure. Taken together, they begin to fill in the picture of why Clojure is changing the way many programmers think about web development.

The goal of core.async is to decouple producers and consumers of
information in software, without dictating specific thread or blocking
semantics, and without introducing callback hell. Also, to do all of this
as a library, portable anywhere you can run a dialect of Clojure.

Queues are a powerful tool for decoupling software
programs. Unfortunately, platforms that have powerful queueing
libraries (e.g. Java) may require blocking threads on the ends of the
queue. And the world's biggest platform (JavaScript in the browser)
doesn't even have queues or threads.

core.async builds upon the work done with Communicating Sequential
Processes,
and provides:

• facilities for independent threads of activity, communicating via
  queue-like channels
• both real threads and shared use of thread
  pools (in any combination), as well as ClojureScript on JS engines

In this talk, we will cover the design of core.async, and then move
directly to exploring core.async's capabilities:

• Creating unbuffered and buffered channels
• Threaded put >!! and take <!!
• Using go blocks to invert control, achieving async without threads
• IOC put >! and take <!
• Simultaneously waiting for multiple operations with alts! and alts!!
• Timeouts as “just another kind of channel”

Finally, we will assemble these primitives into substantial working
programs, building toward the Holy Grail of async: substantial UI
application development in the browser, with no callbacks in sight.

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

The software industry changes rapidly, but you can protect yourself
from these changes by creating code that is complicated enough that
only you can maintain it.

Of course you should not engage in obvious bad practices. The good
news is that you don't have to. You can follow idiomatic industry
practice and stay buzzword compliant with the latest trends, while
quietly spreading complexity throughout systems. Better yet, the
symptoms will show up not in your own code, but in other code that
uses your code, directly or indirectly. You will be a hero as you
lead larger and larger teams burning the midnight oil to keep systems
alive.

Practice these principles, and your code will have an
infectious complexity that guarantees you will always be needed to
maintain it.

• Use OO, and don't forget those setter methods!
• Prefer APIs over data.
• Start with DSLs.
• Always connect (and never enqueue).
• Create abstractions for information.
• Use static typing across subsystem boundaries.
• Put language semantics on the wire.
• Write lots of unit tests.
• Leverage context.
• Update information in place.

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.