Easily searching across an application’s data is a pervasive need. If you are lucky, you can get away with simple sorting or searching on a single column, but it is more likely that you need full text search across multiple models, all from a single search. Thanks to the power of Postgres’ full text search, rolling your own search isn't too difficult. Following an actual feature evolution which I worked on for a client, we will start with a search feature that queries a single column with LIKE and build up to finding results across multiple columns on multiple tables using database views, optimizing the query time with full text indices and representing the results as a polymorphic association on an ActiveRecord model in Rails.
Peer into the dark and mysterious world of Ruby internals, delve to the point that the basic String becomes a complex web of optimizations, flags and peculiarities. The starting point for String Theory is the observation that immutable strings are more performant than mutable ones, and 23 character stings are more performant than longer ones. The how and why of these idiosyncrasies is where our journey begins. We'll pull apart the Ruby VM to explore how String is implemented in C, to fully understand String Theory we'll need to journey into Ruby memory structures and ultimately to the garbage collector. Get your spelunking gear ready as we discover how the GC has evolved, once we emerge from the darkness you'll see Ruby in a whole new light.
When is it okay to build an orbital laser to destroy an ant-hill?
Many cry "overkill" when design principles are applied to trivial problems. And for good reason: in the context of work, excessive embellishment gets us into trouble. Complexity costs us time and money.
This talk explores how stepping outside of the realm of work and applying outrageous engineering practices to toy problems can deepen our understanding of the trade-offs that we make. Comically simple problems provide the perfect ground for developing actionable heuristics which can be applied to those monstrous complexities that we face in the real world.
It's about a decade that we use Ruby for the web. Some of the products of these years have tons of messy code, slow builds and painful upgrades to deal with. If your application uses fat models AND fat controllers, you know what I mean.
Lotus is a minimal, but yet powerful framework that is focused on good object oriented design, testability and speed. You will learn about the patterns that it implements to solve these problems and to push Ruby performance to the limit. We need new ideas to evolve as a Community and as individuals. Good news are that you can apply them on today. Let's talk together!
Performance is one of the most important features of any application. Research has shown that every 100 milliseconds decrease in speed can reduce sales by 1 percent. Ruby is not known as a fast language but there are things we can do to optimize the performance of our Ruby code. This talk will show how to properly benchmark your Ruby code and discuss various techniques for making code faster and more memory efficient.
Pun intended! Ruby is an awesome language but can learn a lot from Go. In this talk, I profile and compare both languages and discuss what Ruby can learn from Go.
While Ruby makes us rethink Object Oriented Programming, Go makes us rethink the programming paradigm itself!
This talk covers some aspects of Go and why things are the way they are (and sometime should be). - Syntax sugar and importance of static data types. - No classes but interfaces and how it re-programs us. - No exceptions but only errors. - CSP and channels - an awesome way to communicate. - Concurrency and goroutines.
This is not an RTFM talk about Go. I plan analyse not what is there in Go but WHY it's there. For example, why do we get a random key-pair every time we iterate a Hash in Go and why Ruby should not have OrderedHash! This is just one example among the many in the talk.
This talk aims to make the open the eyes of the listener to some ideas that can help make Ruby even more awesome.
Most developers code to music...some are even musicians themselves. Is it possible to streamline workflow by adjusting how we listen to music and what music we listen to?
Studies have shown that exposure to certain kinds of music can help to develop cognitive strength and improve performance of tasks. This talk will explore those studies and show what sort of things can be done to improve the listeners environment and help people to create better code.
The Ruby ecosystem is known for its plethora of gems (and – sadly only a few – of its standard libraries), but the base interpreter itself is a treasure trove with small, beautiful jewels of pleasant syntax and fairly unknown, but elegant solutions that spring to help in the most surprising circumstances.
This talk covers some of the lesser known pieces of Ruby’s core (think ‘obscure, but highly-useful-when-applicable Enumerable methods’), syntax and general language ideas like callables and case matching. Come and see how Ruby can help you before the first require!
Rails was born in 2004, the time of the "Ajax revolution". With the help of a little bit of prototype, scriptaculous and RJS, Rails made its mark in part because it facilitated creating beautiful and highly interactive web user interfaces in no time at all.
This talk will explore three approaches in two parts to build a front end for your Rails application:
1) In the first approach - "the Rails Way" - I exploit all the parts of the default Rails stack, as blessed by DHH himself. This includes jquery-ujs, Turbolinks and Sprockets. Fundamentally with this technique, most HTML is still generated server-side. Included in this part of the talk is a discussion if Progressive Enhancement makes sense, and a demonstration of the techniques involved.
2) The second approach is the "Angular Way", exposed together with the 3) third approach, the "Ember Way". With both perspectives, I show how to build "full" client-side web applications. Included in this part of the talk, in particular, are: a discussion about which of the two popular frameworks fits the Rails mindset best, and which brings the steepest learning curve, "to pipeline or not to pipeline": does it still makes sense to stick with Sprockets or is more meaningful to use a separate build toolchain (e.g. grunt and bower) in the front end?