Scala.IO logo

The Scala event in Paris!

October 23rd and 24th, 2014. Paris, France

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. Except for lightning talks, if your submission get accepted you'll get a free pass for the conference (up to 2 speakers).

We are looking for 3 kinds of talks:

Conference (45 minutes)

Long talks are around 45 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.

Short Conference (20 minutes)

Normal technical or report are typically 20 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.

Lightning talks (10 minutes - during lunch)

Lightning talks are a great way to introduce a subject you like or deeply care about to a smaller audience. They are an opportunity for every speakers to communicate at a more personnal level.

Workshop (3h00)

Workshops are 3 hours 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 laptop or a computer provided by Scala.io (if available). Workshops also are intended for the participants to share with the speakers. Workshops will require a specific planning and setup (we are working on it), we will contact you for organisation details.

Timeline

The Call for Proposal will:

  • Open Tuesday 27th May 2014
  • Close Sunday August 17th, 2014
  • We will disclose few selected talks on rolling basis

Submission

Head over to cfp.scala.io to create your profile and submit your talk.

More information

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

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.