Sessions at Clojure/West 2012 on Friday 16th March

Rich Hickey discusses the design decisions made for Datomic, a database for JVM languages: what problems they were trying to solve with it, the solutions chosen, and their implementations.

Eventual consistency is everywhere. DNS is the canonical example, but it's becoming more important in mobile applications with sporadic connectivity and databases with high availability requirements. One of the difficulties with these systems is resolving conflicting writes. Some cases allow for last-write-wins, but other domains require a mechanism which doesn't lose data. knockbox is an open source Clojure project that takes data-structure implementations that support automatic conflict resolution, and wraps them up to be used just like any other Clojure seq, set, or map. This talk will explore the motivation behind knockbox, the data-structures themselves, using knockbox with Riak, and issues like garbage collection and synchronization.

Macros are like stress tests on our understanding of Clojure. Problems arise when writing macros that reveal holes in our mental model of how Clojure works.

Going back to basics and gaining a solid understanding of the reader, evaluation rules, quoting, and compilation goes a long way towards demystifying Clojure macros.

Through many examples, much code, and several puzzles this talk iteratively introduces a model for thinking about how Clojure evaluation works and provides specific tips on writing macros.

Come prepared to read code and think!

Even people who have been programming in Clojure for a while now can get confused by some of the constructs at the core of the language: namespaces, vars, and symbols. In this talk, we'll dive into how these things relate, and how they are processed by the read and eval phases of compilation. Understanding them better will allow you to more easily understand why Clojure code does the things it does.

Avout brings Clojure's in-memory model of state to distributed application development by providing a distributed implementation of Clojure's Multiversion Concurrency Control (MVCC) STM along with distributable, durable, and extendable versions of Clojure's Atom and Ref concurrency primitives.

This talk will provide:

• background on Clojure's in-memory model of state
• a walkthrough of Clojure's STM
• a walkthrough of Avout's design
• guidelines for using, and avoiding, distributed state in application development
• instructions on how to extend Avout with different - backend state stores
• alternative approaches to distributing Clojure's model of state.

The attachment of names to values, or “setting variables,” is a capability most useful programming languages provide. It’s almost always the case that a value affiliated with a name in one part of a program must be accessible some way in another part of the program.

What is often unclear in many programs built with these languages are the implications of mutation, or the process of pointing a name to a different value while the program is running. Because the notions of “accessing” and “changing” are often conflated at the lowest possible level of expression, it can be incredibly difficult to understand the relationships between the pieces of a program and the named value that these pieces share.

Awareness of this difficulty has manifested itself in bits of wisdom like “globals variables are bad” and “make it final,” and in principles like encapsulation.

Clojure attacks the problem directly, and by doing two things: providing a small set of unified semantics around mutation, and by making it easy to program without necessarily attaching names to values.

Clojure’s approaches empower those with an investment in the Java platform to tackle concurrent computing problems with new confidence, and are both ultimately possible through Clojure’s recognition that values themselves don’t change – only their names do.

This talk will introduce Immutant, an application server for Clojure. Immutant is built on the extensible JBoss AS7 platform, exposing its rich set of built-in services to applications via simple API's. These services include asynchronous messaging, background processing, job scheduling, long-running daemons, simple deployment, clustering, and much more.

By providing these integrated services, the accidental complexity inherent with the evolution of an application relying on multiple disparate processes, e.g. Cron, Memcached, RabbitMQ, etc. is significantly reduced.

Immutant was inspired by TorqueBox, a Ruby application server also built on JBoss AS7. Immutant may be combined with TorqueBox to provide a single process capable of deploying both Ruby and Clojure applications, not to mention legacy JavaEE, leveraging the skills of the development teams in an organization without complicating the responsibilities of its operations team. This results in interoperable applications deployed on a single platform, built from best-of-breed libraries and frameworks irrespective of language.

You know about Clojure's deftype & defrecord. You have seen them in action. Now you need to create a new type that plays well with Clojure's own collections. Should you use a record, or do you need a type? Which protocols do you need to implement? Or were those interfaces? Decisions, decisions.

In this talk your friendly guide BG will walk you through the process of creating custom types that interoperate with core Clojure collections. You will learn when to use types vs records, about various internal Clojure interfaces & their associated behaviour.

This talk will equip you with real world knowledge about the internals of Clojure collections and building your own datatypes.

In particular, the talk will cover -

• When to use records or types (or neither)
• Internal Clojure interfaces (and corresponding ClojureScript protocols)
• How to find which interfaces to implement
• Mutable types(!)
• How your type behaves with eval and the reader
• Example implementations

Many a programmer fantasy and breathless blog post is rooted in the search for the perfect programming language, that sublime medium that will accentuate our talents, mitigate our failings, guide us to succinctly define our processes yet get out of our way when we wish — all while letting us deploy our creations in the environments we care about.

Of course, no language is perfect, including Clojure. As immensely attractive as its various qualities are, it has its own warts and baggage that you should be aware of as you consider it for tomorrow's projects or push it into production today. This talk will present many of these shortcomings — from the technical to the social to the existential — along with mitigating factors that might make the difference between Clojure frustrating you, and your loving it.

Chas Emerick is a coauthor of Clojure Programming (http://clojurebook.com) from O'Reilly, and a contributor to Clojure itself and dozens of open source Clojure projects. He's been deploying Clojure in production since 2009 — primarily to solve various improbable document extraction problems — having adopted it as his primary language the year before. He writes about software development, entrepreneurship, and other passions at http://cemerick.com.

Swing has never had a sterling reputation. It is (correctly) perceived as complicated, over-designed and generally difficult to work with. Seesaw is a user interface toolkit built in Clojure that makes UI development fun again. It unifies many abstractions that are scattered or non-existant in the Swing API, for example: event handling, selection, semantic "value", binding, and more. In this talk, we will learn how to combine these capabilities to rapidly construct desktop applications in Clojure. Put away proxy, reify, doto and friends. You won't need them here.

Experiences from the field building automated integration and load testing using The Grinder, Clojure, Pallet, and a continuous integration system. The Grinder is a Java load testing tool that supports scripted tests written in Clojure or Python. Starting with a simple web application, we will explore the possibilities and tricks of using the Grinder to run integration and load tests; spawning an on-demand test-bed with Pallet; running tests and generating reporting with continuous integration.

Pallet is a DevOps platform for the JVM, written in Clojure. Systems administrators today already automate the building of their infrastructure in the cloud. This talk is about a better way to do so, one that is functional.

In this talk, we'll describe how Pallet provides a set of abstractions over infrastructure components and operation tasks; how you can build automation on top of these abstractions, making the process of automating the infrastructure a matter of functional programming. We will describe the main abstractions in Pallet, covering the key concepts of: operating systems, shell scripts, cloud providers, software packages, clusters of servers, relationships between servers, and a few more. We will then show how any automation programmed against these abstractions is highly reusable and portable to different cloud providers and operating systems, and how the automated infrastructures are highly flexible and easily scalable. To conclude, we'll show how you can build higher level abstractions that match your domain, in this case by building automation for a Hadoop Cluster.

About the speaker: Antoni Batchelli started programming computers for fun when he was eight years old with a ZX Spectrum and has not stopped since then. Over the years, Toni has worked in consulting, startups, academia and corporations. He has gone back and forth between coding, architecting and managing, having fun in each role, while always working on large software installations. In 2009, Toni started Disclojure (http://disclojure.org), a website devoted to news about Clojure. in 2009, Toni met Hugo Duncan, with whom he has since them been working full time on Pallet (http://palletops.com) , an Open Source, Clojure-based DevOps platform; and VMFest, a Virtual Machine automation library. Toni is now focusing on promoting the use of Pallet.

About 3 kids per classroom are affected with ADHD or other forms of executive dysfunction and despite many talents, can struggle to learn how to succeed. They often face heightened conflict levels with frustrated teachers and parents. Ultimately 32% drop out.

Clinical experts and PhDs at the University of Utah have come together with technologists and are gaining ground on ADHD through novel treatment approaches. They are brewing a concoction of solid science and emerging tech using mobile apps, game mechanics, and a private social mentoring network. Picture kids having fun in school again, earning rewards on iPods and reinforced by parents in-the-know with push updates.

We'll dig through the system design and key components, and see how Clojure, CouchDB, iOS, and other pieces work in a distributed but coordinated effort to impact lives. We'll get an inside perspective of developers and designers who have tackled this while balancing day jobs and other responsibilities, and see if a good cause and the love of learning and applying great tech is enough to win.

Can you use Clojure to build web apps? Hell yes! Not only do we have Ring and Compojure, we also have recently a development framework called Joodo that'll give Ruby on Rails some competition. In this session we'll demonstrate how Joodo makes it almost effortless to generate and deploy web apps to Google AppEngine and Heroku, for free.

Testing in Clojure has become an interesting and controversial topic. As with most programming languages, quite a few options have sprung up around testing over the years. Most recently, a library called test.generative has quietly made its way into the Clojure world.

Inspired from ideas out of Haskell's quick check and other similar libraries, test.generative is a very different approach to testing that involves describing the inputs and outputs of your system via functions and letting the test framework generate possible scenarios. When done properly, this method of testing can produce far more test cases than any sane human would want to write and maintain. Like other benefits and ideas around testing, test.generative forces its users to think differently about how their software is constructed and helps drive better code out the other side.

Join Aaron Bedra as he walks through writing some Clojure code and testing it with test.generative. Aaron will start with a simple idea and talk about all the different reasons and ways one might test a solution to the problem. He will explore ways of testing that don't involve any test frameworks at all. Then, just as you think he's about to completely miss the point of the talk, he will pull it all together and show the secret sauce behind test.generative and why you should adopt it into your projects going forward.

From status updates on Twitter to business data in salesforce.com, APIs enable applications to access services across the web. Most modern APIs are RESTful, and many of those use the OAuth protocol to authenticate end users for secure API access. This session provides a high-level explanation of OAuth, contrasts it with OpenID, and shows how a Clojure web app, running on Ring and Compojure, can implement OAuth and securely access web APIs.

"We seek, not to build guard rails, but to paint lines on the road. This way we can go faster, others can use the road too and we have waypoints to help us when things get 'foggy'. You still have to know how to drive." ~ Ben Rady, author of "Continuous Testing with Ruby." This presentation will discuss how teams can adopt (and adapt) Continuous Testing (CT) practices for clojure. After defining what the practice is (and is not), the presentation continues in three parts:

An overview of the goals of the practice including
Seek to write "executable documentation"
Develop an environment of constant feedback about what is changing
Favor speed over completeness (the goal is *not* about proving correctness)
Compliment the REPL, don't replace it
Illustrate how a CT workflow in clojure differs from adopting similar practices in other languages
What is often a two stage iteration (test/code/test/code/etc) becomes three (repl/test/code/repl/test/code/etc)
That test-first versus REPL first is a false-dichotomy and ultimately dogmatic irrelevance
That the immutable nature of clojure and the power of using a REPL serves to emphasize the "exececutable documentation" value of CT
Practical considerations and demonstration including:
Tools (We've tried midje, lazytest and Expectations and settled on Expectations and why)
Setup (including repl, leiningen, etc)
Driving out a solution to an illustrative task using CT

If Clojure adoption is on the rise, where are the commercial success stories and how was Clojure used in these successes?

This talk examines three personal startup successes where Clojure was utilized to varying degrees. Each piece of the story will discuss the technology need, risk, and tradeoffs encountered as Clojure was consider, as well as what the language provided that led to success. Finally, an outline is extracted on how to apply Clojure as a problem solving tool where agility and continual learning naturally emerge as convenient by-products.

This story starts out literally like a movie - millions of dollars on the line and the clock is ticking. We had a large dataset we needed to run expensive calculations on and our existing tools couldn't cut it. Clojure came to our rescue with its wonderful combination of simplicity and performance. But that's just the beginning. I'll also tell the tale of how our little Clojure script grew up. I'll talk about how we constructed our test suite, our experience refactoring Clojure, and the delicate art of introducing new developers to their first Lisp.

In Clojure, data is king. But what does that mean? This talk will introduce "data-oriented programming" as a discipline and show how it can make programs easier to write, easier to test, and more performant. If you can represent your problem as a pure function manipulating data structures, you win. This talk uses examples in Clojure but the concepts are applicable to any programming language.

Inspired by Alice in Wonderland, we will take a whimsical look at monads and how to understand them by implementing them in Clojure.

We'll follow the adventures of a developer who fell asleep while reading one of Philip Wadler's papers on monads (and eating too much cheese). Along the way, we'll discover why monads are important for a functional language and might accidentally achieve enlightenment by implementing the three different types: the Identity Monad, the Maybe Monad, and the State Monad.

Overtone places a whirlwind of sound synthesis and music making opportunities within realistic reach of all Clojure programmers. However, the staggering set of possibilities can often overwhelm the intrepid music programmer seeking their first musical experience.

This talk will introduce an overview of a number of key synthesis and live programming concepts and techniques arming you with an arsenal of important tools to start your adventures with.

Be warned: this presentation will release the Clojurepunk within you.

This unjam will gather current and prospective Overtone hackers together to create an exciting opportunity for collaborative performance.

We will start with simple instructions of how to create basic sounds on the Overtone REPL and then let people creatively modify and generate noises spontaneously to create a cacophony of noise. We will then look into ways to structure and coordinate this sound so that we feel more like an orchestra or band than bunch of monkeys randomly hacking away. We will take two approaches - first we'll try and come up with a collaborative composition which will be conducted by one of the attendees. Finally we will look at how using one Overtone instance as a coordination server can allow rhythms and beats to be tightly synchronised.

The session will be fun, noisy and will strongly encourage exploratory and on-the-fly Clojure hacking.