One of the deepest mysteries in the functional programming world is the Y-Combinator. Many have heard of it, but few have mastered its mysteries. Although fairly useless in real world software, understanding how the Y-Combinator works and why it is important gives the student an important insight into the nature of functional programming. Join with us on this journey of understanding. Be prepared to curry your functions and bind your lambdas as we delve into the whys and wherefores of this paragon of functional programming. Although you will probably never have a need for the combinator, the effort put forth to understand it will improve your functional programming chops. This talk is not for the faint of heart, but the successful student will be richly rewarded. Also, you will understand why "Y-Combinator" is the perfect name for Paul Graham's start-up funding company.
I've been finding that the more I talk about front-end frameworks, the more I'm trying to drive home the point that the way we build apps needs to change dramatically - and that we as Rails developers are the ones who should be building these tools. Things like Meteor (and our new app Hammer) are good examples of this - where the environment is turned upside down in order to make great new tools. I think every developer is capable of doing these things, so I think it's important to point out how easy it is for us to make everybody's lives so much easier and more fun.
Dealing with Scale at Yammer: Caching and Services In this talk, I’ll describe Yammer architecture and how it has grown from a simple Rails application to a powerhouse serving over 6 million users this year. Our scaling strategy relies on 3 points: caching, sharding and
UX from the outside in and back
What are the keys for attracting masses if simple perfection isn't? What's wrong with Mozart anyway? Can we all be the Beatles? And should we even want to? What about the Monkees and the Hermits? Is there any technical golden path to take? How much does design have to do with it? Is less really more? What can be covered by some basic rules? Do our frameworks make/suggest appropriate decisions for us already? Swimming with the masses is not outstanding (dang!!!). But if you ask fish it's rather safe... unless you have a bunch of Orcas after you. What are the web's Orcas?
Not answering those questions yet. Just a couple hints: The responsibility for a good UX can't be left with the frontend alone. The edge is outstanding, but you have to see in what direction you find yourself standing out!
What's the pirates' way to deal with it?
As you can see from the raised questions, it's a lot about design-(also in a development kind of way)-descisions. None the less my talk will also go into a couple technical details where applicable and where time will allow. Oh, might also end up to be entertaining here and there.
Everyone knows HTTP! Well, that's not entirely true. There are large parts unknown to most web developers, well, even browser vendors, as it seems, and the wheel is invented over and over again to fix issues we wouldn't even have, if people would make use of their toolbox. There are two options to fix this: You can reading RFC 2616 over and over again or you can listen to this highly opinionated talk exploring facets of HTTP that most developers are probably not too well aware of and how to make best use of it.
Yehuda Katz is a member of the Ember.js, Ruby on Rails and jQuery Core Teams; he spends his daytime hours at the startup he founded, Tilde Inc.. Yehuda is the co-author of the best-selling jQuery in Action, Rails 3 in Action, and is a contributor to Ruby in Practice. He spends most of his time hacking on open source--his main projects, along with others, like Thor, Handlebars and Janus--or traveling the world doing evangelism work. He blogs at yehudakatz.com and can be found on Twitter as @wycats
Devops is the way to go these days, and Chef is a blessing when a rubyist wants to maintain his servers and infrastructure as any other project or piece of software. As any Devops is partly Dev, and any Dev should test-all-the-f#*ing-time, the Chef recipes and infrastructure-maintenance should be tested. Testing Chef recipes is hard, and there is no perfect solution. I'll present my efforts in trying to test recipes, roles and deployments, give some insight in why nothing currently works, and all my efforts resulted in abandoned git branches...
This talk isn’t really about localisation or internationalisation (add a ‘z’ if you prefer!) – it’s about culture and understanding. It’s about how we should all be approaching localisation challenges as people problems and to give good examples of how to get it right and where you can go so very wrong.
Your framework and tool of choice is the easy part – understanding the people you’re wanting to each out to is oh-so-very hard and too often seen as only just a translation problem – a simple matter of swapping one string for another.
I’ll talk about how people communicate across cultures, even when they are so different. Drawing on my experience as a teacher of english as a foreign language and my own travels and struggles to absorb another people’s language and culture, I hope I’ll change how you think about solving these problems in future.
Hell, I’ll even make you laugh. I hope. The most important thing though, I’ll provoke a discussion, given the diverse multilingual background of the attendees here; it could be a very good one.
My talk description has run away to vimeo vimeo.com/41094993 So I will use this space to tell you of my other hobby, which is going to conferences. Last year I've been to Euruko, NodeCamp, onGameStart and RuPy; I've noticed a pattern, there are more and more functional programming references. This is why I'd like to hear a talk that would wrap up the topic of functional programming.
A mix of node.js goals, history and road map plus all the rad things libuv does (esp. platform-specific optimizations)
Sinatra is dead, as a dead fish. We killed him during abordage. Now we can investigate his body, see his guts, and check what he has inside. Since medieval, autopsy of dead corpse was the best way of learning how human body works. We will use the same technique, examinating Sinatra, to learn how to write better code. With its 1740 lines of code, this piece of software is great example of Ruby application. We will see what jewels are hiding in its chest, notice some good practice, but also we will take a look at bad and stinky parts. Since Aleksander's only commit to Sinatra was concerned documentation, he is the right person to lead the autopsy. He will look at Sinatra with the fresh eye. Konstanin Haase won't get any hurt (probably).
Getting people to contribute to open source can be hard. This talk looks at Powder, a simple Ruby gem, and some of the ways we tried to to turn bug reports into pull requests.
Ruby is good for more than just making web pages and APIs. Its expressiveness makes it a good candidate for creating real world simulations. Out of the box, Ruby has some nuances that might make you think otherwise. In this talk, we'll review why Ruby could be a great choice for creating simulations, and discuss hurdles and solutions for problems that you will run into. Topics include concurrency, domain modeling, testing, and other exciting topics.
Rails got much more modular after 3.0 rewrite. But do you know how to use specific rails elements outside Rails? What if you would like to use ActionView with some other library (like webmachine)? Have you ever needed to render view with layouts outside of the rails stack? Or maybe you wanted to build some kind of system that fetches templates from database rather than from files? Router anyone? You know that you can use it outside rails too? In this talk I will dive into Rails internals and will show you what's there and how you can use it outside rails. Although I will focus on using those parts standalone, this knowledge will most likely help you also build your apps if you ever need something sophisticated that requires modification of regular rails behavior.
Object persistence in Ruby is a tricky subject – everyone knows how to do it (‘simply use an ORM, plug it into a relational database and you’re done!’), most know the drawbacks (‘well, sure, you need to use a document database for the more schema-less cases… or serialise the variable parts… and, of course, object references need to be handled separately…’), but few experiment with alternatives.
This talk, after recalling the popular database-driven persistence solutions, concentrates on the less known, but more interesting and often quite useful approaches – from file-based PStore (ideal for small apps), through Candy’s out-of-the-way magic, to MagLev’s true cross-process transparent object persistence.
A lot of Ruby developers use Rails for their everyday projects. Often they toy around with front-end themselves or outsource it, ending up tangled in a web of css-all-over-the-place.
Keeping your front-end code clean is hard. Before you know it you're suffering from CSS specificity issues and not-really-generic partials. Find out how to keep things tidy using the HTML5 document outline and modular Sass & CoffeeScript, for truly reusable code.
Behaviour-Driven Development is a second-generation agile methodology with a strong focus on communication. In BDD, specifications are expressed through examples in the form of scenarios.
Originally written in Ruby, Cucumber is popular a tool for automating and validating a system against its scenarios.
This is an introduction to Cucumber.js. After briefly exposing the history and goals of the project, I'll demonstrate how to write features and scenarios, step definitions, hooks, support code, how to invoke Cucumber.js from both Node.js and browser environments. And of course, you'll see how to integrate it with your Ruby and Rails projects, because - yes - it works well with them.
RubyMotion is a revolutionary toolchain for iOS development using Ruby. With RubyMotion, developers can finally write full-fledged native iPhone or iPad apps in Ruby, the language you all know and love. In this session, we will cover how RubyMotion works and how easy it is to write an app with it.
his talk will try to give you some insight in a day at the office while implementing a custom SpreeCommerce web-shop. Showing the tools of the trade and discuss choices made while implementing designs and developing extensions. Utilizing the powerful SpreeCommerce eco-system and show you how to implement designs, extend default behavior using custom extensions and avoid some pitfalls.
The following subjects will be addressed:
- Theme development using Deface (or not)
- Test Driven Extensions
- Pitfalls to avoid
- Spree Best Practices
Therapeutic Refactoring Enter deadline center stage, exit best practices, quietly, rear stage left. The results are rarely pretty. Refactoring can pry panic’s fingers away from your poor, overburdened adrenal glands and restore your sanity. Not that it went missing, of course. Never that! This talk will cover the two reasons why refactoring works as well as (or better than) whiskey, sky diving, and massages as therapy, explore a handful of effective strategies to ensure that the rubber meets the road, and contains gory before shots and slick after shots of ruby code that has served therapeutic purpose.