Scala.IO logo

The Scala and FPL friendly event in Paris!

October 24th and 25th, 2013. Paris, France

Lightning Talks

Attendees can apply for a lightning talk session. These sessions are 5 minute long and allow you to present briefly and synthetically an idea.

With or without slides, go straight to the point and enlighten your audience!

CFP CLOSED

About

The annual Scala.IO conference is a place where people can see how others are using Scala language or functional programming languages to solve real world problems; where practitioners meet and collaborate; where language designers and users can share ideas about the future of their favorite languages; and where one can learn practical techniques and approaches for putting functional programming languages to work.

Giving a Talk at Scala.IO

If you have experience using Scala or functional programming languages in a practical setting, we invite you to submit a proposal to give a talk at the conference.

We are looking for 3 kinds of talks:

Long session (42 minutes)

Long technical talks are around 42 minutes long, and should focus on teaching the audience something about a particular technique or methodology, from the point of view of someone who has seen it played out in practice. These talks could cover anything from techniques for building functional concurrent applications, to managing dynamic reconfigurations, to design recipes for using types effectively in large-scale applications. While these talks will often be based on a Scala language, they should be accessible to a broad range of programmers.

Session (24 minutes)

Normal technical or report are typically 24 minutes long. They aim to inform participants about how Scala or a functional programming language plays out in real-world applications, focusing especially on lessons learned and insights gained. Experience reports do not need to be highly technical; reflections on the commercial, management, or software engineering aspects are, if anything, more important.

Workshop (2h30)

Workshops are 2 hours and 30 minutes long. They aim to teach participant concrete skills about Scala usage. Workshops are essentially practical sessions. Participants are expected to practice in live, on their own computer or a computer provided by Scala.io (if available). Workshops also are intended for the participants to share with the speakers.

Submission

The CFP for Scala IO closed on Sunday August 25th, you will have to wait for next year, start preparing your talks.

Timeline

The Call for Proposal will:

  • open Monday July 7th, 2013
  • close Sunday August 25th, 2013
  • All selected talk are known by September 8th.

More information

For more information on Scala.IO, take a look at the Scala.IO website

Note that accepted (co)presenters (2 speakers max), will NOT need to register for the event.

Presentations will be recorded and presenters will be expected to sign a copyright release form.

Guidance on giving a great Scala.IO talk

Focus on the interesting bits: Think about what will distinguish your talk, and what will engage the audience, and focus there. There are a number of places to look for those interesting bits.

The Scala.IO audience is hungry to learn about how Scala techniques work in practice. What design have you applied, and to what areas? Did you use functional programming pattern, or DSLs, or fault-tolerant actors for large scale data processing? Teach us something about the techniques you used, and why we should consider using them ourselves.

Getting things done: How did you deal with large software development in the absence of wide developer adoption of pre-existing support that are often expected in larger commercial environments (IDEs, coverage tools, debuggers, profilers) and without larger, proven bodies of libraries? Did you hit any brick walls that required support from the community?

Be critical: It’s easy to write a rah-rah talk about how well Scala worked for you, but Scala.IO is more interesting when the talks also spend time on what doesn’t work. Even when the results were all great, you should spend more time on the challenges along the way than on the parts that went smoothly.