There are tonnes of little- or virtually unknown libraries in Ruby’s stdlib, and they found their way there for a reason. Much like revisiting Enumerable’s method list times and again makes you a better Ruby programmer, so does looking into its standard library – not only because there are things you didn’t know existed, but also because the way the’re implemented is often quite enlightening.
This talk shows some of the useful, clever and tricky uses of Ruby’s standard library – like GServer, DRb/Rinda, PStore, Ripper and SecureRandom – that do not require the installation of any gems and can be used in any environment hosting a Ruby implementation. Did you ever want to write your own server, do some distributed computing, don’t worry about persistence? It’s all there; come and see for yourself!
Ember.js is arguably the most thought-out of the bunch. One of its key principles is Convention over Configuration which might sound familiar to some of you ;) Most rich-client apps still need a server-side component, though, to fetch data from and store data to, and we all know Rails also shines when it comes to building an API.
In my talk, I'm going to go through the steps of building a real web application with Emberjs on the client side and Rails on the backend. Rest assured I'll also point to all the code we're not writing ;)
Prototyping is hard. As a digital agency, Mint Digital has created a number of prototype applications for clients, however these have been some of our least satisfying projects. Whilst we have been inspired by the project and put in the extra mile to delight, things sometimes just don't quite click.
It's taken us a while, and we've been through quite an experience to get to this point, but at Mint, we think we have solved the issue in a way that works for us, for our clients and for the end product. And all it takes is 4 days!
We'll look at the problems that prototypes can face; slippage, lack of focus and bloat. We'll see how our solution materialised out of Mint's company culture in a way that truly surprised us. We'll recap those initial issues and how we solve them and finally we'll look over how Rails helps us as developers and how we can help ourselves when creating prototype applications. By the end, 4 days is all you will need to create anything!
Learning version control is a bit like learning how to play golf. Once you know the basics of hitting that teeny ball with a gigantic club it's all fun and games but then you get frustrated and throw your bag into the river.
But once you learn a little more than the basics, you end up realizing that you can drive a golf cart all over the course and that alone is pretty fun.
This talk is all about the bite-sized bits I've picked up after years of working at GitHub. It'll be fast-paced so you can pick it apart and take at least a couple specific things relevant to your workflow that will make you more productive.
Inside every programmer there are two conflicting personalities, a hacker who gets things done quickly but sometimes leaves a messy codebase behind and a perfectionist who crafts beautiful code but sometimes gets paralyzed finding the best solution.
In this talk you will not only be exposed to this crazy theory but also will know how Ruby encourages the cooperation between those internal programmers. Starting from syntax and moving to higher level topics like structured vs OOP vs functional approaches to problems.
Ever wondered what it would take to have stable and reliable measurements for your performance? Or wished to know the evolution of it across releases and rubies? Or simply to know how fast or slow is some code?
Perfer is a benchmarking tool I developed as a GSoC project intending to solve these, and to provide an easy way to store, transform and compare the results and to make a graph of it.
The talk will start with some benchmarking best practices, explaining why using the benchmark stdlib is usually not sufficient.
I will have a look at alternatives and finally I will explain Perfer's approach and show how to use it and how it can be useful in real-world examples.
Every pirate likes to play games. Whether to pass the time during long sea voyages or entertain fellow pirates around the drinking table, games are a wonderful pastime. Unfortunately the captain does not always understand. Would it not be great to have a proper defense when the captain scolds you for idling away time? This talk will provide you with enough gun powder to counter any attack your captain launches on you for playing games on deck.
We will dive into the seven seas of computational complexity and discuss a uniform means of understanding them: games! We show that playing games corresponds to certain types of computations. And as every captain knows, before finding the treasure you have to compute where X marks the spot.
We will use ruby to demonstrate the correspondence between computations and games by creating specific games that perform certain computations and playing them life.
As a mentor for thoughtbot's Prime service, I've provided coaching to over 100 developers.
In my talk, I'll share the questions I'm asked repeatedly, and how I answer them.
This discussion will be targeted at beginner and intermediate developers striving to improve.
Likely discussion includes:
What should I do if I inherit an app with no tests?
Any advice on how to switch to vim?
How does one land her first Rails job?
How does one land a better Rails job?
How do I conquer the fear of letting others see my code?
Am I underpaid?
How do I balance integration and isolated tests?
How can I make myself stick to TDD when the going gets tough?
Plus, because it's me, we're gonna do some live coding. Take bad code. Make good. Happy times.
With Rails 4 supporting only Ruby 1.9 and above it can fully embrace the MiniTest library that ships with Ruby 1.9. What does this mean for Rails developers? Let's find out.
In this talk we'll look at using MiniTest in a simple, non-Rails, project and then work up to using it in a Rails application. We'll look at both the TestUnit and RSpec style syntaxes that MiniTest offers. We'll also learn to write custom matchers, run specific files, and much more.
Testing is important to all Ruby and Rails developers, and with such a powerful testing library already bundled with Ruby, shouldn't we learn how to use it?
This talk is about ways to hack your team for a more efficient, productive and ultimately happier existence. That's the good news. The bad news is hacking your team starts with hacking yourself.
In 1936, Dale Carnegie published a book called "How To Win Friends And Influence People". You may have heard of it. In 1989, Stephen Covey published "The 7 Habits Of Highly Effective People". I was 6 years old.
What can these old books (and others) teach us about working as part of a modern software team today?
A hell of a lot, actually.
We'll look at some of the hacks, I mean techniques, raised in these books, and investigate how they apply in the modern software team.
When someone asks you what makes your company special, you'll probably say you create something that has beauty, quality and innovation... The problem is, thats what all companies say. You think you are, or want to be better than the rest, but when are you better than the rest? Metrics is everything, without numbers there's no way to tell if you're getting better at what you do, there's no way to tell (and show) if you're better than your competition. But how do you measure the beauty of your designs? The quality of your software? The innovation of your products?
All the cool cats are using Redis, and with a reason: It's fast, it's robust, it's easy and it's web scale. Put it together with Ruby and it's fun too!
In this session I will talk about what is redis, what you can do with it, how you can use it from Ruby, why you should be using it already and some common patterns when dealing with it. I will talk about:
what REALLY FAST means
Redis data structures, and mapping them to Ruby objects
queuing slow ruby operations with Resque and Sidekiq
using redis for cross-language development
atomic counters and generating sequences
dealing with temporary data in your application
redis as a cache
shared sessions (rack-based) with redis
how to store relational data in a non relational data store
interesting problems when distributing your application. Using Lua scripting for atomic operations
reducing your memory footprint via compression
You know what? Learning how to speak another language shouldn't be hard. So lets put it in a context that we know and love - programming in Ruby. This is a talk about abstraction, counting, syntax and grammar. It's nerdy, but its fun.
What you won't see is your typical "language talk" - I won't be banging on about language theory (except to relate to Ruby), or any particular natural language.
I think this is better, because it's about applying what you already know to the task at hand. There might even be a lesson or two snuck in there - wouldn't that be nice?
Learning another language shouldn't be an insurmountable challenge, learning to speak another language even less so. I fully believe, and will explain that by our very nature as programmers, we do this all the time - I'll talk about how these same skills that let us switch from Java to Ruby to Go can be used to help us switch from English to Swedish to Japanese.
Hell, it might even help you switch from programming in Ruby to painting landscapes!
“Skinny controllers, fat models” is a well-known practice in the Rails community that everyone seems to follow. However, as your application evolves and your models grow, maintaining them can become less enjoyable than it used to be.
In the last few years, the community has been proposing patterns and techniques to deal with big AR models. Presenters, Service objects, Concerns or DCI are only a few examples of solutions suggested to alleviate the pain caused by gigantic models.
In this talk, we will critically explore these patterns in their different flavours. We'll compare them in order to expose their strengths and weaknesses and you'll learn when and how to use them to keep your Rails models as pleasurable to deal with as the first day.
This year we launched a new product in 6 weeks - from initial commit to accepting customers. We could have used a number of languages to build KBSimple, but we chose Rails to bootstrap it. The reason is simple: Rails is still the best framework for bootstrapping new web applications.
In this talk I'll go through the 6 week evolution of the product, talk about the various gems and techniques that were essential in reducing the amount of time it took to launch, and talk about some of the challenges we faced along the way.
How does one explain to their grandparents what they do for a living? Or a potential love interest? With my talk I want to cut the crap, move past jargon and offer handy comparisons even your granny will understand