Come meet us on June 27-28 2019

.

Keynote

The (reference) Elm compiler as we know it right now is currently implemented in Haskell, and emits JavaScript code. I’ll be talking about my side-project: an Elm compiler written in Elm, emitting JavaScript—sure—but hopefully allowing for native code, WebAssembly and other possibilities!

Topics include:

• what it will allow us to do (hint: a lot of exciting stuff! prepack-like optimizations, interpreter, debugger, eval…)
• how to structure a compiler
• how it can then be exposed as a library to allow experimentation and cool extensions!

There is no doubt that the Elm architecture and Virtual DOM make Elm enjoyable for building web apps. When it comes to the domain of real-time graphics, it still remains underdeveloped. Even though this opens up a whole new range of opportunities, is Elm ready for such experiments?

Having accepted a challenge of building a dice roller game, I ended up rolling my own physics engine. With no prior experience in computational physics, I studied existing implementations. Through a try and error, I programmed the necessary bits in pure Elm.

From this talk you will learn how it was possible because of existing tooling. You will see how types and immutability make complex algorithms easier to comprehend. And of course, you will share my excitement of watching the demos on the big screen!

At my company we are mainly building E-Commerce websites using Elm. Some examples in production are: - https://vanbruun.com - https://scanfast.se - https://himla.com - https://shop.izettle.com (needs iZettle account)

Each site is built as a single monolith Elm application, sizes ranging 80-110k lines of code. About 50% of the code base is shared and reused between projects. We are about 20 developers working on these (and other) projects.

These circumstances presents some challenges: - Re-usability & maintainability cross project - Testing - On-boarding new developers - Accessing Browser APIs - Performance (web workers) - Code splitting (soon)

5 months ago we started discussing how we can improve our code base to meet these challenges. Our conclusion was to move away from a monolith and break up the application into several smaller apps that talks to each other (the actor model).

This work has now started and that is what this talk is about. Was there any improvement in the end?

I’m a product designer that always hit early roadblocks when learning code. Where do I start? How do I make changes without breaking everything? Because of the challenges, I assumed “my brain must not be wired for programming.”

This changed when I found Elm. The experience of learning Elm gave me the confidence to add code to my design toolkit. Now I use Elm in client work and to experiment with new kinds of design tools. Designers can write more than just views: learning to think like a developer has changed the way I approach work as a designer.

My goal is to help developers and designers work better together using Elm, and see more designers join the Elm community.

My talk will cover: -How Elm became a valuable part of my design toolkit -Specific learning roadblocks and how I overcame them -How these lessons reveal opportunities for better shared tooling between developers & designers -What design tooling can steal from Elm

.

Building my first Elm app was a two-for-one deal: learn functional programming and learn to sight-read sheet music! I’ll share my greatest challenges and most valuable lessons from building this musical side project, with Elm as my first introduction to purely functional programming.

Highlights include:

• Using the Web MIDI API with Elm via JavaScript interop to get input from a digital piano directly in the web browser
• Visualizing the music with Elm’s SVG package
• Exploring SVG animations in the Elm ecosystem
• Elm’s best features from the perspective of a beginner
• Funny beginner mistakes (how not to use Elm!)

Tagline for this personal project: learn to hear with your eyes and play from your heart!

It is no doubt that all Elmers are making an application that is going to be LARGE! We are also the same. The bigger our application got, the more severe, challenging decisions we were required to make in viewpoint of software architecture, design pattern - you name it.

My talk shows a long journey of our product with Elm including decisions we have made, troubles we dealt with, and so on.

Audience can learn how to make their application scalable all the way around blunders in the viewpoint of real world use of Elm.

This is the true story which comes from the largest Elm application in Japan.

What under water stones is when you try use Elm for games, that renders 60FPS, what must be done different. How use patterns designed for imperative programming in FP.

Markdown is an ideal tool for documenting and thus a suitable format for Open Educational Resources, but as a static markup language it is also boring. So the idea was born to create a DSL that is based on Markdown but intended to be used for developing online courses, that look like screen-cast with various interactive elements. Starting this project with Elm, it was more or less an explorative journey, with rapid changes in the DSL and the interpreter that were guided by the elm compiler. Code-blocks are now executable and editable, quizzes can be defined in various ways, images are generated from ASCII-art, effects and transitions combined with text2speech that enable interactive storytelling, among other features. But the course itself is still a valid Markdown document that can be edited by any ordinary person, even without programming skills. The interpreter build around the Elm-architecture hides all complexity, such as code evaluation, internal message routing, lazy parsing, etc. - https://LiaScript.github.io

Elm started its journey at Veepee in 2017. Since then, multiple teams have adopted it and pushed it in production. In this talk, we will tell you the technical and human story of our products through multiple anecdata:

- How we managed to convince people to give Elm a try, and how we onboard newcomers on Elm,

• What our projects are, what they do, and how this translates into Elm code,
• Our not-elm technical environment: the backends, the operations and how it meshes with Elm.
• The mistakes we made when starting Elm, and how we recovered.

The hope is that after this talk, you will find your own way to start Elm in your company and build successful production stories

The most difficult part of directing a live, multi-camera video production, is avoiding mistakes. You mean to switch to Camera A, but put up the title card, instead, requiring difficult work to go back in and edit.

But Elm’s type system lets us model our data such that we can make such mistakes impossible. Using Algebraic Data Types to model my video layers and State Machines to model my transitions, I can effectively make impossible video states impossible.

The talk will include a live-streamed demo of controlling robotic cameras, switching video cameras, adding graphics, all from a web front-end built in Elm, while I’m speaking. It will all go out on the Elm Europe 2019 Livestream feed.

At the end of the first day, we’ll have a party with a jazz concert, and some food. Let’s talk about what inspiring projects we want to create with elm together. Climate change ? Education ?

Get together and talk to strangers about elm, it’s the place to do that !

Elm achieves a lot by paradoxically “doing less”. It’s a really interesting effect!

We have been experimenting for 1.5 years on expanding the “do less” ideology. Instead of a backend with an API, database, interchange format, hosting, deployment, migrations… what if we had none of those? Could we think of web development differently? While lots of discussion has been had about “putting Elm on the server” over the years – we’ve tried to explore in a different direction entirely.

This talk will explore our soon to be released project, Lamdera; the first language-as-a-service platform (as far as we’re aware!). We’ll share discoveries we made while building it, why the web development approach we have today is as it is, and what “truths” we might be able to reconsider as we approach 2020.

We’ll be doing some live coding in Elm and have audience participation in order to demonstrate our ideas and get live feedback from the community.

Emulating a retro game console is a many-faceted task. Besides emulating the central processing unit, there are many other components that need to be emulated and integrated before games become really playable. This talk will focus on the Game Boy’s APU, the Audio Processing Unit.

As the Game Boy is limited in memory, computing power and storage, simply playing audio files is out of the question. To accomplish this task, the Game Boy synthesizes audio out of thin air, based on control instructions.

You will learn what sound actually is, how computers work with it, what tradeoffs can be made and why retro computers have their own distinct sound.

Last but not least, we will take a deep-dive into the Game Boy specifics and how its APU can be emulated with Elm.

More and more of our data is location aware and we are starting to care about showing and visualizing geospatial data. In this talk I will introduce a library for decoding, storing, measuring, transforming, generating, aggregating and interpolating that kind of data along with real world examples from the domain of disaster recovery using satellite technology and how these techniques can be used to build clever geospatial dashboards in Elm. I will also briefly demonstrate how one might visualize this kind of data using gampleman/elm-mapbox.

Games are fun to play and fun to make! Elm is a great way to get started building games. We’ll take a whistlestop tour of 2d-game math, visuals, dealing with time, common data modeling solutions, and more. You will be equiped with the knowledge to participate in a game jam and turn your ideas into a playable game.

The talk will cover basic concepts of binary encoding, and then look in detail at how using binary decoders with elm/bytes is similar to using elm/json and elm/parser, and in particular where it is different. The questions I want to answer are:

• in broad strokes, how can elm data be encoded as bytes, and decoded again
• compared to Json decoding, what is different
• what are the trade-offs between using binary encodings and (for instance) Json
• what kinds of binary data can we now work with (and does it makes sense to do that)

The content is based on my experience decoding font files. I’ve written about the topic (and some of the pitfalls) in these discourse threads:

• https://discourse.elm-lang.org/t/decoding-bytes-with-offsets/2579
• https://discourse.elm-lang.org/t/experiences-using-elm-bytes-for-decoding-font-files/2861

Part of the work can already be found on Github

• https://github.com/folkertdev/elm-cff

.

In this talk, we will look at a project where we read data from an audio file using the WebAudio API and use the data to generate browser-based art, evolving through time. We’ll do some live coding with the project to show how to start with a small idea and build upon it. After demonstrating the project, we’ll then dig into the code and review the use of opaque types, looking specifically at how they are used in the project to expose an API that can be used to change elements in response to audio events. Let’s have a bit of fun and make some surprising, delightful art for the web!

“A function or expression is said to have a side effect if it modifies some state or has an observable interaction with calling functions or the outside world.” - Wikipedia

This is the story of how we adopted Elm in our young startup, and how we evolved alongside our growing codebase.

I’ll try to debug several side effects Elm had on our world. Some that can be directly traced to Elm: how we managed to avoid writing CSS ever again, or how our quality code standards took a step up when developing our second product, and some more insidious: how functional programming sneakily influenced our coding style, how we changed our way of writing tests, or how our application backend changed as Elm took more and more place.

elm-search provides a unique way to search exposed values of all published packages by approximate type signature.

In this I will share my story of implementing the initial version to learn the language Elm with its tooling, ecosystem and community. We will have a look at the search algorithm and then explore what lead me to write a new version with an improved search and more features. Finally we’ll have some fun with package statistics and see how elm-search can help in learning and teaching Elm and what it might do to improve the developer experience.

Do you want to play your own levels in Boulder Dash? Well, you actually can! And I can tell you how it is made. This combination of gaming, functional programming, and a nip of nostalgia will give us an interesting and addictive result where you can unleash all your creativity.

In this talk, we will discuss how you can apply the tricks of game programming to make a funny game in Elm. As kind of a fun experiment, I recreated the game Boulder Dash with my love of game programming to better learn Elm. The experiment got “a bit out of hand” and the game turned more into a game engine. Not only can we play Boulder Dash, but we can also watch the Game of Life and solve the challenge of day 15 of the Advent of Code 2018. Because why not? I would like to share my enthusiasm for the project and share how things are done. How are some challenges solved functionally? And how can you create your own games using JSON? The goal is to inspire people and to also make something funny.

Elm’s not just great for web development – it’s also a wonderful tool that you can use to make interactive, creative visuals! By following the same fundamental principles established in the Elm Architecture, you can start making HTML-based art in a matter of minutes.

I will start my talk by giving a brief history of generative computer art from its inception. Then I will describe more modern forms of computer art, including “algorave”-style live coding.

I will go on to explain the framework I use to achieve different effects and how Elm’s type system simplifies the production of recursive art.

Then I will introduce some of the art that I’ve worked on in Elm, which combines the live coding style with a slider interface that allows the viewer to directly manipulate the parameters of the piece and layer many complementary effects.

I will conclude with a live demonstration, hopefully set to music :)

I was the first IT employee at COYA AG I decide to choose elm vs other alternatives in November of 2016

Developer and Designer collaboration has always been a challenging subject. Designer:” Can you please make the red background slightly darker?” Dev.: “You mean #FF3300 or #FF9922 ?” What if we had a tool that designers and developers could use in order to create an efficient collaboration and avoid these kind of impediments ?

This tool is called a Design System and has been a buzz word in the digital world for a couple of years. Material Design, IBM Carbon etc… All these are shared design rules and principle that are provided by leading tech companies in order to help their teams build cohesive and qualitative products.

In this talk, we will see how through Elm and its great ecosystem we can build a DSM that can help Developers and Designers build great products. We will define a Design Language made of colors, typography and layouts thanks to the expressiveness of the Elm Type System.Then we will make reusable views and combine them in order to build a Pattern Library.

I have written a lot of code (including some Elm code) that deals with generating audio and simulating realistic sounding musical instruments. It’s been a deep dive for me into fascinating different theories of sound. I’d like to share what I have picked up. Here is an outline:

• Additive synthesis is really simple: just combine many sine waves
• Saw tooth waves, square waves (show and explain a cool fourier series gif)
• Talk about bells a little bit, and show how different bell sounds really just come down to a certain profile of sine waves
• Talk about the really basic mechanics of whats happening in a bell as it vibrates
• Grainular syntehesis: modelling sound as atomic sound “grains”
• Show how a vibrating bell is more like a “grain” of sound traveling through the bell itself, and that sounds generally can be modelled as atoms expressing themselves in a medium
• Changing a sounds speed without changing its tone is really tricky, but grainular synthesis makes it simple.

Test-Driven Development is a powerful programming technique because it:

• Tightens feedback loops
• Helps you get one small use case fully working before moving on to the next one
• Let’s you start with your intention before doing the implementation

In this talk, you’ll learn how to get those same benefits using elm’s compiler like a test framework. This isn’t a replacement for Test-Driven Development in elm, but rather a complementary technique.

Kent Beck says that our goal is to write “clean code, that works,” but that we make it harder on ourselves by trying to start with clean code, and then make it work. Similarly, in elm it’s a lot more difficult when we try to get clean working code, and then get it compiling. Start by finding the Shortest Path to Compile. Once we’re compiling, getting the correct values (getting it working) becomes far easier! And once we have correct values, refactoring (getting it clean) becomes far easier!