• Ruby and Coffee programmer. The founder of Arkency and GameBoxed. One of the wroc_love.rb conference organizers. Rails teacher at University of Wroclaw.

    He's originally a backend developer, with Rails experience since 2004. He knows all the pains and beauty of Rails. Now, after working for the last 2 years on frontends, he knows how to build them properly. He will teach us all the lessons he's learned and he's going to show a lot of production frontend code.

    Single Page Applications with CoffeeScript
    Advanced workshop

    We, the backend programmers, often have troubles working on JS frontends. We avoid it, even when that would be the best User Experience.

    What if you knew how to manage the JavaScript (or rather CoffeeScript)?

    What if you could use even nicer architectures than the ones you build on the backend?

    Once you realize, that the frontend is a separate application and once you learn good patterns of the real MVC, you will be proud of your frontend code.

    DCI, the new hotness in the Rails world, can work even better on the frontend and AOP can be really helpful in the Model Gui communication.

    Prerequisites - https://gist.github.com/3353574

  • Chris is a programmer from Melbourne, Australia. He spends his days building deployment tools and backend systems at a large Internet company and his evenings wining, dining and rock climbing. He is excited about learning new things, and exploring those subjects in depth.

    Clean Docs

    A lot of the principles of clean code are forgotten when writing documentation.

    Have a single source of truth and don't repeat yourself. Avoid writing brittle code. Use ubiquitous terminology and choose searchable names. Be consistent in your formatting. Test your code. Refactor and practise successive refinement. Don't write any more than you need to.

    These principles of clean code can be applied with great effect to the production and maintenance of documentation, but there's more to it than that. Code needs to satisfy machines and coders. Documentation needs to satisfy people who perform a range of different tasks: from cursory inspection through to intensive development.

    This talk will review relevant principles and examine real-world examples, leaving you with a practical mental checklist for writing documentation that will help your users and your software thrive.

  • Dirkjan Bussink spends his working days between cows in the scenic country side of the Netherlands at Nedap (http://www.nedap.com). There he works on software and sometimes even plays with actual hardware devices. As one of his hobby's he likes tinkering with Rubinius and has been an active contributor for the last three years.

    Rubinius Workshop - Diving into the internals of Rubinius
    Advanced workshop

    This workshop will consist of two parts, first a part in how to optimize some Ruby code so we can run stuff faster. We will use things such as benchmarks and the profiler to investigate the issue and write up a fix.

    The second part is a debugging session much like the online video I published half a year ago at https://vimeo.com/34622441. We will investigate a tricky crash in the garbage collector and use tools such as GDB, the Rubinius disassembler and others to investigate and fix this issue.

    Prerequisites - http://2012.eurucamp.org/2012/08/14/rubinius-workshop-preparation

  • Dominik is a Ruby developer by heart. He thrives when working in an open-source environment and loves people who freely share their ideas (and code) with others. He relishes the infinite possibilities that come with that freedom. He's created several open source tools, such as pullerman and git-review.

    Create your own tools (and share them)!

    Have you ever heard about that awesome tool that will help you achieve your goals with less effort, that fits perfectly into your workflow and makes your code look sexy? No? Then maybe you should stop waiting for someone to tell you about it. Instead write that tool yourself and share it with the community!

    Besides showcasing a couple of those tools you might not yet have heard about, this talk will primarily dive into the process of creating your own tools and improving them by sharing them with others.

  • Erik is the creator of one of the most popular Rails engines: RailsAdmin. He is also the author of MultiXML and T, a command-line power-tool for Twitter. When he's not hacking on those projects, he helps maintain OmniAuth among other Ruby gems and open-source Rails applications, including RubyGems. He was a 2010 Ruby Summer of Code mentor and a 2011 Google Summer of Code mentor, while serving as a Code for America Fellow. He resides in San Francisco, California.

    Writing a Rails Engine

    As of Rails 3.2, plugins are officially deprecated. They have been replaced by Rails Engines, a class of public methods for hooking into Rails applications. This session will explain how to write a Rails Engine from scratch or convert your existing plugin to an engine. It will also cover best practices for making your engine play well with others and determining when to factor pieces of your existing Rails application code into an engine, for reuse across multiple applications.

  • Florian solves problems on the open web. He works with his tiny software shop Polarblau somewhere close to the polar circle for companies of all sizes around the globe. Between gigs he builds http://pleaserevise.com and http://heypayme.com/. Florian prefers Ruby over PHP, Coffeescript over Javascript, beer over bubbly, open source over proprietary software, bike over car, work over meetings, small over big, action over talk, learning over degrees and his family over everything.

    Maintainable CSS with SASS (even in large projects!)
    Advanced workshop

    You’re writing beautiful, well tested and refactored code. You do your best to keep your views clean. But your stylesheets are a wasteland you would rather not enter and no dedicated designer around. — Sound familiar? Writing, maintaining and refactoring (yes!) clean and readable stylesheets even in large projects is possible and this workshop will give a few ideas on how to keep the work on the GUI fun.

  • Florian is the wearer of many hats: he's done research in Brazil on space life science, worked in Melbourne on preserving dying languages using modern technology, and is also co-founder of the Technology Astronauts.

    He loves languages, to draw on his iPad using an overly large selection of styluses, to hop on a roadbike, and conquer mountains (overly large, too).

    Superheroes can do it and so can you!

    You don't know it yet, but you're like Peter Parker, before he was bitten by a radioactive spider. You're Bruce Wayne, before his parents were killed. You're the daughter of Hyppolyta and Zeus.

    How are you putting your abilities to use? You're probably already giving back to the tech community by writing great open source projects. However, you can make a much greater difference by stepping outside your field for a moment – and by returning afterwards, with new ideas, and experiences.

    I'll show one example of this – doing field work in preserving endangered languages in Papua New Guinea, using my knowledge in technology. With Google stepping in to help save Endangered Languages, this is rapidly becoming a topic of great importance.

    Chances are, you can't just run away to a strange faraway place. So what can you do, right now? What's your calling? Follow it!

  • Isaac is a Rogue Developer at 6Wunderkinder, where he writes API code in Ruby, front-end code in JavaScript, and internal tools in whatever he feels like that day.

    He started programming in 1991 on an Atari ST 1040 using Omicron Basic, and has never truly recovered (though he's started weaning himself off GOTO).

    He tends to jump back and forth between wanting to build things people will use and tinker on abstract, pseudo-philosophical ideas. This leads him to switch from working in start-ups to academia and back every few years or so.

    All You Need Is Love

    Inferring from the title, you might think this talk is completely misplaced for a Ruby conference and would better fit in a wedding fair. But the message describes a future trend not only for programming, but for every kind of creative work: love driven development.

    Companies like Github and Valve have already implemented a corporate culture based on freedom. Their employees are free to work on whatever they think is important and should be worked on. Some may think: ‘That is chaos! Madness!’ But really, this is how startups work. The major advantage of this kind of corporate culture is: people will love their work. And if they do so, they will give their best and your company will be truly successful.

  • James is a programmer at London live music start-up Songkick, currently working on a migration to SOA. While not helping people go to more concerts, he works on several open-source Ruby and JS projects, including the popular messaging system Faye. He hates wasting his time and tries to design programs that avoid doing so.

    Do I need DI?

    There's been much talk in the Rails community lately about more strongly object-oriented approaches to design. The argument goes, we should create more maintainable applications through modular code, focusing on the Single Responsibility Principle, Dependency Injection, and so on. These approaches tend to be talked about in quite abstract terms, cited as being 'good for testing' or simply 'the right way to do OOP'. But really they're just a means to an end: how do you know when one of these approaches is good for you?

    In this talk you'll see several examples of the real-world uses of dependency injection I've used in my own projects. You'll say how and why DI emerges from the program's design goals, how it affects the implementation, and what effects it has on the project's structure, and you should gain enough understanding to judge when to introduce it in your own work.

  • Jana is a Berlin based freelance webdeveloper. She started as a media designer and later on studied International Media and Computing. Nowadays, she's mainly programming in Ruby/Padrino and enjoys developing great frontends.

    Using slanger and websockets to power a warehouse backend

    Websockets are fun for chats and online games. But are there serious uses? We developed a warehousing interface using websockets and slanger that enables every workstation to see all current shipments in realtime. With only Firefox or Chrome as target platforms, this was an easy and pleasurable task. This talk will run you through the details of such a system from front to back and also show the most common pitfalls so that you don’t have to find them out yourself.

  • As current maintainer of Sinatra, Konstantin is an Open Source developer by heart. Ruby has become his language of choice since 2005. He regularly contributes to different widespread projects, like Rubinius, Rack, Travis, Rails and MRI.

    In 2012, Konstantin received the Ruby Hero Award for his outstanding contributions to the community.

    He currently holds the position of "Berry Sparkling Lord" at Travis CI.

    Sinatra in 8 lines, or How to do crazy stuff with Ruby

    A fun code analysis.

    %w.rack tilt backports INT TERM..map{|l|trap(l){$r.stop}rescue require l} $n=Sinatra=Module.new{extend Rack;a,D,S,$p,q,Application=Builder.new,Object.method(:define_method),/@@ *([^\n]+)\n(((?!@@)[^\n]*\n)*)/m,4567,a %w[get post put delete].map{|m|D.(m){|u,&b|a.map(u){run->(e){[200,{"Content-Type"=>"text/html"},[a.instance_eval(&b)]]}}}} Tilt.mappings.map{|k,v|D.(k){|n,*o|$t||=(h={};File.read(caller[0][/^[^:]+/]).scan(S){|a,b|h[a]=b};h);v[0].new(*o){n.to_s==n ?n:$t[n.to_s]}.render(a,o[0].try(:[],:locals)||{})}} %w[set enable disable configure helpers use register].map{|m|D.(m){|*_,&b|b.try :[]}};END{Handler.get("webrick").run(a,Port:$p){|s|$r=s}} %w[params session].map{|m|D.(m){q.send m}};a.use Session::Cookie;a.use Lock D.(:before){|&b|a.use Rack::Config,&b};before{|e|q=Request.new e;q.params.dup.map{|k,v|params[k.to_sym]=v}}} puts "== almost #$n/No Version has taken the stage on #$p for development with backup from Webrick"

  • Laurent is the founder of HipByte, a new company that crafts revolutionary software tools.

    He worked at Apple for 7 years as a senior software engineer, on both iLife and OS X. A long time rubyist, he created and still maintains the MacRuby project. In a previous life, he worked on IDA Pro and was an active contributor to RubyCocoa and GNOME.

    RubyMotion: Ruby In Your Pocket

    RubyMotion is a revolutionary toolchain for iOS development using Ruby. With RubyMotion, developers can finally write full-fledged native iOS apps in Ruby, the language you all know and love. In this session, we will cover what RubyMotion is and how easy it is to write an app with it.

  • Portrait: Lourens Naudé

    Lourens Naudé

    Independent Consultant

    Lourens is an independent consultant currently based in sunny Madeira Island, but originally from South Africa. He specializes in backend / platform / domain solutions and is well versed in full stack, from VM to high level protocols and known for his offbeat Ruby patches and extensions. Current interests include disruptive communications technology like ZeroMQ / libxs and he is working on ZeroMQ monitoring features for better operations support.

    Weekdays are spent in the Operations team at Wildfire. See github.com/methodmissing for Open Source contributions.

    ZeroMQ: Scriptable Sockets

    ZeroMQ is a socket abstraction and concurrency framework that's changing the way we think and reason about distributed systems. Mailboxes, atomic message delivery and swappable transports allow for fast, flexible and resilient network topologies. Its I/O model also sits very well with all Ruby implementations. In this talk we'll discuss:

    • What's wrong with socket I/O ?
    • Supported messaging patterns
    • Transport agnostic messaging
    • Resiliency (operations and upgrades)
    • Building out topologies just in time (interjection principle)
    • Performance and throughput
    • The Mongrel2 Ruby adapter
    • How to use it from Ruby
    • Small case study
  • Mathias is the author of the Riak Handbook and the Infrastructure Head Honcho at Travis CI.

    Outdoor activity
  • Matt has been building for the web for over 10 years, doing everything from web design and front-end development all the way through to back-end development.

    Matt has worked with Javascript, Perl, PHP, Python, Ruby, various XML technologies. In his day-to-day work he mainly works with Ruby, Rails, HTML/CSS, and Javascript. He was one of the organisers of the 2010 NoSQL Europe conference, and last year he organised the first History Hack Day.

    Along the way he's co-written a book on CSS (Friends of Ed's Cascading Style Sheets: Separating Content from Presentation), which is currently in its second edition and has been translated into Italian and Spanish, led a software team at the BBC, and spent five of the last ten years running design- and development-focussed consultancies. Recently, he was part of the small development team which built the Alpha prototype of the UK Government's landmark http://www.gov.uk/ project.

    Rails Routing for fun, profit, (and sanity)
    Advanced workshop

    The basics of Rails Routing are pretty straightforward: you have your resources and you're done. Beyond the simple cases, you can quickly get into massively repetitive routing declarations, having to abandon resources even though the route you're trying to create is only a tiny bit different.

    I'll take you on a guided tour behind the scenes and show you how to make use of more advanced bits of the Routing DSL to tame your routes.rb, remove your routing stress, and reduce the chance of being eaten by a Grue.

    Prerequisites - Rails 3.2 and Bundler must be available on your laptop.

  • Mike plays many roles at thoughtbot, including the Haskell enthusiast, their sole Linux user, an object-oriented programmer, Unix historian, and the head of the European branch.

    When Not to Use Object-Oriented Techniques

    Object-oriented Ruby is a hot topic in the Rails world and beyond, but it is not always the appropriate solution.

    In this talk I discuss various OO techniques, when to use them, and when a simpler pattern exists in the functional, declarative, or procedural world — including, yes, the Rails framework itself. You will leave knowing when to use an aspect instead of a decorator, a mixin instead of a presenter, or a monoid instead of a factory.

    Topics will include:

    • The benefits of code coupling.
    • What makes Rails so anti-OO, and why that is good.
    • Testing non-object oriented code.
    • Good uses of classical OO design patterns.
    • How to use a continuation.
  • Nick is proud to be a member of the Ruby open source community. His projects, Cells and Apotomo, have been bringing increased view modularity and event-driven programming to Rails for years. He has enjoyed attending, and speaking at, Ruby conferences around the world. Buy him a beer some time, and with very little prompting, he will tell you why there should be no such thing as a double-render error, why you should not confuse your models with your resources, and how to play a mean bass in a punk rock band.

    Off the Tracks - Challenging the Rails Mindset

    Rails - a word that stirs programmer's blood. It has brought us testing, easy web app building, database abstraction and hundreds of extension gems. Why not take it to another level and discover how Rails can be turned into a real OOP framework? By exploring chosen gems, let's discuss what MVC really is and how it boosts your AJAX user interface, how to apply patterns like DCI, dependency injection and POROs to your database layer and how to expose your Rails system through a real RESTful API. Also, have you ever tried using Rails helpers outside of Rails, maybe in Sinatra? Let's do it and learn about some refreshing aspects of this framework.

  • Pablo arrived to the Ruby world after working with Python and Asterisk-based VoIP solutions. He currently works at Cubox doing mostly Ruby stuff for the web.

    Monolithic vs Distributed Software: No Holy Grails

    One of the biggest problems in web development today is scalability. It's a big problem, and not always easy to solve. The sheer number of requests that large applications need to process is huge, and increasing every day.

    One of the most elegant and widely adopted techniques to deal with this is favoring distributed architectures over monolithic ones. Having a distributed network of tiny apps makes it easier to have a robust, maintainable codebase. Adopting the Unix philosophy of doing one thing right is a topic that has been coming up at conferences and on blog posts all over the world lately, and with good reason.

    But is a distributed architecture always the best solution? Is then a monolithic approach "wrong" from the get go? Sometimes building a distributed system is worth it, sometimes it just isn't. In this talk I put forward my thoughts and experiences dealing with refactoring your application into several small ones, how to build a monolithic app that can be easily split, how to approach the refactor gradually and incrementally, so as not to lose the ability to deliver new features, and how to decide when it's simply not worth it.

  • Piotr is a software developer based in Kraków, Poland. He's been using Ruby as his main language of choice since 2005. He's a member of DataMapper Core Team and a contributor to many open source projects. He's a big fan of OOP and clean code and likes to blog about it at solnic.eu

    Living in the data mapping world

    Ideas we've been talking about for the last couple of years are finally becoming a reality, and DataMapper 2 is shaping up this year. I'll show you what it's like to say good bye to ActiveRecord -- it's awesome, you'll see.

  • Piotr is an assistant professor at Warsaw University of Technology (where he happily sneaks Ruby, EventMachine and newfangled database systems into the creaking world of twentieth-century academia), a Ruby developer at Rebased and an alumnus of Mendicant University. He’s also a long-time contributor to various open source projects for the civic sector and co-organiser of NetWtorek – monthly NetTuesday meetings of people from the NGO/non-profit and IT sectors, as well as SocHack – quarterly 48-hour hackatons for worthy causes, in coordination with Random Hacks of Kindness, Open Data Day and Open Education Week.

    Ruby on the Command Line

    Ruby, thanks to its various frameworks, is known to be the language for web applications – and recent developments in graphic libraries make it a worthy contestant in the world of GUI-driven desktop programs. But Ruby is also great for writing command-line applications; the ability to mix no-boilerplate top-level functions with full-fledged OOP means its usage can vary from one-off trivial scripts to complicated, option-heavy command-line powerhouses.

    This talk presents the nuts and bolts of writing a command-line application with Ruby – from option parsing and accessing standard input/output to playing nicely with POSIX standards like exit codes and signal/interrupt handling.

  • Sebastian is a cofounder of FundExplorer, a Switzerland based Ruby/Rails consulting and product shop. He gets a buzz out of cramming as many Ruby calculations inside a Rails request as he can.

    Complex Calculations Within a Web Request

    Ruby is slow, so therefore we let complex calculations run outside a web request using tools like delayed_job or extract them to C or Java code. But what if these two options are not available?

    In the first part of my talk, I will use an example app featuring a recommendation algorithm to show you how to load thousands of database records and the ins and outs of caching object graphs. In a second part of my talk, I'll discuss writing more efficient and faster Ruby code.

  • Driven by their quest for code aesthetics and their passion for Ruby and its ecosystems, Dirk and Sebastian work together at bitcrowd in Berlin, an agile software company with focus on Rails and iOS. Their current favorite challenge: Connecting JavaScript frameworks to Rails in a way that does not hurt.

    Joosy - a JavaScript application framework based on Rails and CoffeeScript
    Advanced workshop

    In this workshop we'll give an introduction to Joosy and its concepts, compare it to Backbone and especially we want to code with you. Bring your laptops and hack with us. We'll build a simple CRUD app with 2 connected models and authentication.

    Prerequisites - you should have at least medium skills in Rails and CoffeScript to enjoy the session; please check out the GitHub repo mentioned below and make sure you have Ruby 1.9.3 installed.


  • Pressing run on the ZX Spectrum at the age of 6 led Srdan inevitably to the MSc in Computer Engineering and a position as the backend-architect at a startup that scaled from a handful of users to tens of millions within a couple of years.

    Srdan currently works at Burt, developing a multi-billion request ad-tracking service using JRuby. Hey, it's only fun if it's exponential.

    Idempotence as the holy grail of scaling

    One of the biggest challenges when handling big data is making sure your system is coherent after an unexpected crash or machine failure. Designing your system for idempotency will make sure you can reprocess parts of your data to fill in the gaps without accidentally affecting the good data.

    Once you've got the idempotency down, you are free to venture boldly into a veritable Narnia* of scaling solutions.

    This talk will describe the problem and offer a couple of solutions by looking at some real-life implementations.

    * But, you know… warmer. And with fewer lions.

  • Steve is a Ruby Hero, teacher, and an aspiring digital humanities scholar. He spends most of his time contributing to Open Source projects, and maintains both Hackety Hack and Shoes. He also teaches and helps develop curriculum for Jumpstart Lab.

    Development and Philosophy

    We spend most of our times obsessing about the actual act of programming. Is this method name too long? Should I refactor this code? How do I fix this bug? However, sometimes, large gains can be made by drawing in experience from totally different fields.

    I think there's a lot a programmer can learn from the study of epistemology, logic, metaphysics, moral and political philosophy, and aesthetics. In this talk, I'll give an overview of a bunch of interesting thinkers, philosophical problems, and how they relate to the worlds of software development, open source, and startups.

  • Txus is co-founder and lead developer at Codegram, a Ruby/Rails shop based in Barcelona, the company behind Barcelona Ruby Conference.

    He's an active member of the Ruby open-source community. Among others he has contributed to the Rails framework, RSpec, Rubinius and is the author behind many open-source projects at Codegram.

    One of his many passions is understanding the very internals of programming languages: compilers and virtual machines, so he usually spends a lot of time learning and researching the subject, and building his own programming languages and virtual machines.

    Polyglot Rails applications with Rubinius

    Many of us write, maintain and scale Rails applications for a living. And we enjoy it because we love Ruby. As developers, we love its expressiveness, conciseness, and the freedom and happiness it gives us. But at the same time, Rubyists are often attracted to other programming languages and willing to learn them: Ruby programmers are often eager polyglots.

    According to the Sapir-Whorf theorem, our thoughts are constrained by our language: we think in terms of language. And the more languages we speak, and the richer those are, the broader our mental universe becomes. In the same way, different programming languages enable us to think differently about technical problems.

    What if we could write Rails applications using multiple programming languages? Can you imagine different programming paradigms all running together in the same application? Passing Ruby, Clojure, Python objects back and forth, interacting with each other, within the same VM?

    Fortunately Rubinius, a high-end Ruby implementation, empowers us with this possibility. In this talk I'll share my experience with this approach and explain a bit about the technical foundations implied.