We will start with walking through some of the early work in computer architecture—setting the stage for what we are doing today. Then continue through distributed computing, discussing things like:

• Important Impossibility Theorems (FLP, CAP)
• Consensus Protocols (Raft, HAT, Epidemic Gossip etc.)
• Failure Detection (Accrual, Byzantine etc.),
• Current exciting research, like:
  • ACID 2.0,
  • Disorderly Programming (CRDTs, CALM etc).

All these ideas and approaches to distributed computing have influenced the creation of Akka Cluser. In this talk, Jonas explains what ideas influenced their decisions, the theory behind Akka Cluster and he provided some insights in the future roadmap too.

Everyone loved this talk at the Scala eXchange 2013, with lots of tweets buzzing around during and after the talk.

A lot of the ideas discussed in this talk have influenced Jonas to write (the first version of) The Reactive Manifesto, which explains the need for Reactive Applications: Applications that are Event-driven, Scalable, Resilient and Responsive. Skills Matter supports the Reactive Manifesto because we believe it is the architecture for the future. Indeed, the ideas and technologies that form the foundation of the Reactive Manifesto, have been shared and explained in many talks at Skills Matter over the last few years.

Not satisfied with being new to the Scala language, Akka's actor model, and the unique constraints of the Heroku platform, circumstances conspired to add PostgreSQL, MongoDB & Redis to our tech stack.

Just three months after the first, experimental release of Scala macros in 2.10, we had a Scala team meeting where we decided that macros look good for becoming non-experimental in 2.12. Why go from an experiment to an official part of the language so swiftly? Well, that's because macros are genuinely useful in a wide range of applications, making impossible things possible and tedious things enjoyable.

The beautiful thing about macros in Scala is their natural integration into the language that gives rise to a number of unexpected and handy interactions with other language features. In this talk, you will learn about the most important of such interactions and will understand the mechanisms that underlie them, becoming able to realize the full potential of Scala macros in your libraries and applications.

ThisWeekInScala has become the de-facto source for the latest Scala releases, news, blogs, presentations and tutorials. Released every week, the blog is read by thousands of developers.

In this session I'll be live-coding for most of the time, showing you how easy it is to:

1. Send an HTTP request and receive HTTP responses on the client-side
2. Write a low-level HTTP server
3. Use the high-level routing DSL on the server-side to define a simple REST API behavior.

Additionally I'll talk about what is on the agenda regarding the move into Akka as well as the transition from Netty to the new akka-http as the HTTP "driver" for the Play framework.

If you haven't used spray yourself yet the recording of the recent Typesafe Webinar gives you some good more high-level introduction to spray, which might help in making the most of this session.

Scala.js compiles full-fledged Scala code down to JavaScript, which can be integrated in your Web application. It provides very good interoperability with JavaScript code, both from Scala.js to JavaScript and vice versa. E.g., use jQuery and HTML5 from your Scala.js code, either in a typed or untyped way. Or create Scala.js objects and call their methods from JavaScript.

Other outstanding features include generation of Source Maps 2 for a smooth debugging experience, and integration with the Google Closure Compiler 3 for producing minimal code for production.

• http://lampwww.epfl.ch/~doeraene/scala-js/

• http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/

• https://developers.google.com/closure/compiler/

New abstractions for concurrency make writing programs easier by moving away from threads and locks, but debugging such programs becomes harder. The call-stack, an essential tool in understanding why and how control flow reached a certain point in the program, loses meaning when inspected in traditional debuggers.

In the mean time have a look at adept's github page to learn more.

We've heard how Twitter and LinkedIn adopted Scala on greenfield initiatives and we're excited to use a more expressive language running on a robust, familiar VM. But is the ecosystem ready to support the demands of a long-established enterprise infrastructure, mission-critical (non-Scala!) middleware and the traditional dev-test-release workflow?

We'll start by exposing what drove our decision to dive into Scala. Next: We'll talk about some of the challenges we faced designing, building, load testing and debugging our service. We will discuss some of the patterns we used moving to a more reactive platform, the availability/maturity of the tooling and some of the framework code we had to write. Finally we'll outline the benefits gained through embarking on this project and any prices we have paid for doing so.

Scala is known to be a nice blend of object-oriented and functional paradigms. A lesser known fact is that it's also a logic programming language...in type system! After all, it's not the syntax, but rather the semantics we're after right? Functional in the small, OO in the large, logic in the type system!

The goal of Metascala is to create a platform to experiment with the JVM: a 3000 line JVM written in Scala is probably much more approachable than the 1,000,000 lines of C/C++ which make up HotSpot, the standard implementation, and more amenable to implementing fun features like continuations, isolates or value classes. The 3000 lines of code gives you:

• The bytecode interpreter, together with all the run-time data structures
• A stack-machine to SSA register-machine bytecode translator

• A custom heap, complete with a stop-the-world, copying garbage collector

• Implementations of parts of the JVM's native interface

Although it is far from a complete implementation, Metascala already provides the ability to run untrusted bytecode securely (albeit slowly), since every operation which could potentially cause harm (including memory allocations and CPU usage) is virtualized and can be controlled. Ongoing work includes tightening of the security guarantees, improving compatibility and increasing performance.

Scala e xchange 2013 haoyi li on metascala a tiny diy jvm from Skills Matter.

In Jan's exciting, invigorating, Broadway-style live-coding session, we will build a Tweet mood analysis application. Jan will show how to use spray-client with the new Akka I/O to download the tweets. The application will then store the tweets in Cassandra and then attempt to perform simple mood analysis. Discover whether people are indeed happy about #Scala tweets and miserable about #Java8 tweets.

To make the most of the session, you will need to have basic understanding of Scala and conceptual understanding of Akka; you do not need to worry about Cassandra nor Spray. Everyone is welcome, though novices may find the pace too fast to follow.

Hadoop and all it's eco system has settled down for good in our hearts and / or minds. It's quite old and has proven to be quite reliable for certain kinds of tasks. Yet one problem still remains - writing Map Reduce jobs in plain Java is really a pain.

The API is clunky and does it's best to hide the actual algorithm beneath tons of boilerplate. Throughout the years many tools and aproaches have shown up - Hadoop's own Streaming API or the great Cascading library.

We'll dive into code examples as well as look into how Scalding actually works, so you can try it out on your cluster when you come back to work on Monday (and smile a bit more when asked to write a Job next time!)

Until recently, users seeking a way of doing Scalable I/O had two choices: NIO, which provides an esoteric interface requiring serious expertise and concurrency control, or Netty - which provides a rich and powerful layer above NIO. The downsides to Netty however include an extremely idiomatic Java API, and a series of separated threads and thread pools left out of the control of the user.

There is, however, hope for the Scala user who abhors free range threading and wants a more Scala-sane interface to a network. Working with the Spray has recently introduced a new, lightweight Non-blockimg network I/O interface built around Akka's core Actors.

Further insights will include a demonstration of Akka I/O's built in system for Backpressure — allowing true handling & awareness of an overloaded network buffer, and compositing of Futures on top of the Actor API to emulate a more functional interface.

Graph databases provide a rich data model that allows us to model, query, and manipulate highly connected data far more than we've been used to in either the relational world, or in many of the contemporary NoSQL stores.

Lenses have been called “jQuery for data types”: they give you a way to poke around in the guts of some large aggregate structure. Lenses compose (so you can make big lenses by gluing together little ones), and they exploit type classes to allow a remarkable degree of flexibility (get, set, fold, traverse, etc).

With the arrival of Scala Macros a new breed of optimization opportunities present themselves for the Scala Parallel Collections.

Many abstraction penalties have been overcome through macro-based callsite specialization. This eliminates boxing and iterators, uses heavy inlining and applies fusion optimizations - consequently achieving optimal baseline performance.

Parallel Collections also come with a redesigned scheduler that achieves better load balancing for tasks with heavily skewed workloads. In addition, the new scheduler is highly configurable and can be tuned for specific applications. And finally, the new Scala Parallel Collections features a new API based on implicit value classes that reduces the number of intermediate classes and allows looser coupling with standard library collections.

You have probably heard Jonas Bonér talk about Akka. Words like scalable and reactive are buzzing around the industry. There clearly is a growing need for scalable, reactive, event-driven applications but there is not all that much practical information out there about how to build serious applications this way. How would you go about designing an application around these new(ish) concepts? What does it mean for an application to be reactive? What works and what doesn't?

We will show you which application and domain concepts should be modeled as actors, when and how to use Futures, how to prevent bottlenecks when calling blocking code, what Akka extensions are for, how to expose a REST API on top of Akka with Spray, how to test all of the above, and much more.

In short: we will assume you have heard the What and the Why so we will concentrate on the How.

The currently developed upcoming Lift 3 (Scala 2.10+) contains innovative ways to craft web applications, like for instance actors that communicate between JS client and Lift server.

ScalaTest 2.0 is a vast enough forest that it is hard to see all the useful trees.

Using primarily demos in the Scala REPL, Bill will show you several use cases and applications of implicit parameters that will help you understand the tradeoffs between implicit conversions and parameters and how to take advantage of implicit parameters in your own designs.

Slick is Typesafe's open source database access library for Scala. It features a collection-style API, compact syntax, type-safe, compositional queries and explicit execution control. Community feedback helped us to identify common problems developers are facing when writing Slick applications.

Eventually consistent data is common in modern web applications. We all know about eventually consistent data stores, popularised by Dynamo and Cassandra, but there are other sources of eventually consistent data. Mobile applications can go offline, but that doesn't stop people from using them, requiring synchronising data when they come back online. For robustness and to reduce network latency, applications may be hosted in multiple data centres connected by relatively high latency connections. It's infeasible to maintain strong consistency between these connections, again requiring synchronisation at regular intervals. How do we reconcile eventually consistent data?

One way is to use data types that we are guaranteed to merge without conflict. Then we easily reconcile all the different replicas in our system with a simple merge operation that we know cannot fail. These data types are known as conflict-free (sometimes commutative or convergent) replicated data types (CRDTs).

It seems straightforward to create, say, CRDT counters, but can we create CRDTs for complex data types such as sets? It turns out we can. There are wide variety of CRDTs available.

Akka is a toolkit and runtime for building highly concurrent, distributed and fault tolerant event-driven applications, but it can also be very useful for those of us who more commonly build applications that run happily on a single EC2 micro.