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.
A fun code analysis.
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:
by Jana Vogel
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.
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.
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
determing when to factor pieces of your existing Rails application code
into an engine, for reuse across multiple applications.
by James Coglan
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.
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.
by Srdan Kvrgic
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.
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.
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!
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.
by Joan Wolkerstorfer and Isaac Wolkerstorfer
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.
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.
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.
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.
by Mike Burns
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:
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.
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.