This talk gives a quick introduction into the not so well known Fiddle, which has been a part of MRI since 1.9. It allows direct interaction with C code via a Foreign Function Interface, which enables wrapping native code without compiling C extensions, making the lives of users of your projects much easier.

As a developer, diving in a new code base is not uncommon: you’ve just been hired, you change projects, you want to help an open source project, the open source library your project depends on is buggy, etc. It’s like swimming through a underwater cave, you don’t know what treasures or monsters you’ll find, if the path is treacherous, or if it’s a true labyrinth where you’ll get lost. However, if you plan your visit, you can prepare, equip yourself, and survive to find the gem you’re looking for…

Working as a developer while raising a child isn’t as difficult as you may think.

Many adults are parents, and many can still become one some day. Becoming a parent changes a lot of things in your life. What it doesn’t change is your ability to work. It surely changes your priorities, and you don’t get much sleep during the first few years, but this doesn’t have to prevent anybody from doing awesome work.

If we have this in mind, it’s strange to observe what an exotic status parents and children have in our industry. The amount of family-friendly employees and workspaces is tremendously low. Also, work which is organised in a way that doesn’t require everybody to work 40 hours a week is particularly rare, as my current difficulties in finding a new job with fewer hours has shown.

Parents in our industry have become visible in recent years. Therefore, parents are often disregarded when a startup is founded. Creating a family-friendly workspace isn’t difficult, it’s just uncommon.

This talk will introduce what it means to be a parent working as a developer and how work can be organised in a family-friendly way. It will show the way in which working in a family-friendly workspace benefits everybody, leaving you with a practical list of ideas of how you can improve your worklife.

Game programming in Haskell: it is possible. I'll talk about the pros and cons of using Haskell for a game, and how to build a game from scratch.

The talk will cover the basics of functional reactive programming, a technique to handle reacting to user inputs in a UI. I'll also touch on Game design, which is actually the hard part.

How do you teach proper software engineering? How do you design a teaching program that highlights the pain of maintaining software to students who have never actually had to maintain software? And, while doing that, how do you keep your students engaged?

Teaching at an experimental group at the Technical University of Moldova, I’m able to employ new techniques including testing, live coding and software maintenance into a regular university curriculum.

Some of the techniques work well to convey the difficulties of writing software, others were failed experiments involving chinchillas and drug dealers. It’s a different age for teaching. The students have already had experience with hackathons, code camps, fancy javascript frameworks and it’s our mission as educators to stay relevant and provide engaging material. I believe that we can leverage the new tools and drastically improve the way we teach software development.

Since the inception of the programmable computer we have grappled with the challenge of validating the outcome of a conversation in code between a human and a machine. Programming as a performance embraces this challenge, putting it at the centre of a performance. Focusing on the liveliness and complexity of dancing with a machine in realtime. In a performance a human edits and writes algorithms, expressing their thoughts and composition in front of an audience. Binding to their fingertips control of light, sound and poetry. Sharing their screens and code and its effects on the world.
This talk will dive into the world of the live programmer and how you can turn your Ruby coding skills into a live performance. Discover what performance and expression has to teach us about programming.

Life is good. More and more people who never thought they could code, people of diverse backgrounds are learning to write Ruby and become full time developers. Outreach programs are doing an amazing job of getting these people into the community, but now we are facing an even bigger problem. Getting them to stay there. 57% of women alone leave the tech industry once they are there. At every turn, we are told we can’t do it, offered different untechnical positions, or bullied out by toxic cultures. This talk will explore the barriers people of different backgrounds face to stay in technical positions, even once they have overcome the barriers to get there. It will present different perspectives and bring light to things we can do as an individual, an employer, a co-worker and as a community to solve this large problem that we face.

How often have you heard – or said – the phrase “$PERSON just isn’t technical”?
If you’re our speaker, you’ve heard it plenty of times over the past 15 years, and frequently applied it to yourself and other colleagues who didn’t quite fit into well understood “technologist” categories.
But what does technical actually mean? What makes someone technical? What makes them not technical?
In this talk, the speaker will explore how “not technical” is a dangerous phrase we use to ensure that we need never question our hidden biases about others and their aptitudes. She will demonstrate how this phrase not only encourages a lack of collaboration, but leads to stagnation in the growth of your orgnization by actively discouraging your peers from learning new skills.
She will conclude with concrete steps attendees can take to better understand the capabilities of everyone on their team – coders or not – so their projects, company or teams can be most successful.

Every other company is looking for ninjas, cowboys or superheroes. Every other conference talk is full of jokes, puns, comedy skits and personality. Nowadays, conferences breathe showmanship, but in our need to be the best of the best, or the funniest of the funniest, we are excluding others. When less than exceptional becomes not good enough, the barrier of entry goes up and it is the underrepresented groups that suffer. When did we start mistaking programming conferences for stand up comedy shows? Our drive to be edgy, exceptional, memorable or controversial too often ends up with distressed audiences and badly handled PR scandals. This talk’s aim is to reflect on how this is a problem, how we’re all losing and how the cult of the stage hero needs to stop.

Kids have this magical ability to take something you think you understand well and turn it upside down within an instant. They challenge norms and ask questions that you never thought existed or could be asked.

In this talk, I’ll go over some of the challenges I faced introducing kids to the world of programming, and how their inquisitiveness changed the way I look at software development, how I learn to get better at it and finally, how it boosted my confidence in my code. Teaching anyone is a rewarding, learning experience, and it motivated me to become active in the community.

Ruby is a great language for building CLIs. There’s an amazing selection of existing libraries like Thor, GLI, or even OptionParser. You probably use a number of Ruby tools everyday like chef, the heroku toolbelt, , and of course the rails command line tool.
Though it’s easy to build a Ruby CLI, distributing it to end users is much more complicated because it requires a Ruby runtime. One option is to rely on Ruby being already installed on the end user’s computer. The other is to bundle ruby as part of the distribution package. Both of these are problematic so much that Vagrant, CloudFoundry and hub (Github command-line tool) have all switched over to Go.
But there’s still hope! In 2012, Matz started working on a lightweight embeddable ruby called mruby. Since mruby is designed for being embedded in other compiled languages, it also solves the distribution problem. In this talk we’ll look how we can write CLI tools using mruby to produce a self-contained binary that can be shipped to end users.