Your current filters are…
Why do some people keep talking about diversity? Who cares if we're all the same? So long as we're not technically discriminating against anyone, that means we're good, right? If we only get applications from white dudes, that must mean that white dudes are the only ones out there. Right? Right?
When we feel threatened, we find comfort among people who seem most like us. As specialization increases in the community, we glom on to people who look like us, talk like us, and think like us. There's safety in a crowd.
But there are real dangers in becoming too much alike: monotony breeds more monotony. Real innovation happens when you think different than everyone else. What happens when we ruthlessly eliminate different thinkers, as we winnow the stack of resumés to those that seem most likely to "fit in"?
Come to this talk to find out what you can do to diversify - yourself, your organization, and your peers - and how you can help grow a better, stronger, more diverse community.
REST is an architectural style for distributed systems. However, many implementations forget about the distributed part of REST and simply map CRUD operations to HTTP verbs in a monolithic application. Hey, we want more! So let's have a look at the Roar gem and see how it helps working with representations, hypermedia, and decoupled architectures in Rails and Sinatra. While building both services and a consuming client we can discuss the sweet things about component-oriented architectures and french beer.
by Joseph Wilk
During an hour of programming what do you learn about your performance? How did that last refactoring go? How does that hour compare to the previous hour? How about against last week or last month? How are your habits as a programmer improving? How does your refactoring pattern differ from a masters like Martin Fowlers?
Professional Tennis players learn from detailed statistics about how they performed in a game and use this information to become better players.
Why don't we do the same in Programming? I want to demonstrate how we can, especially how we as individual programmers can help limit the time we spend in the red (failing tests) while developing. How long we spend in the red and how often can reflect on how we are working as programmers. Joshua Kerievsky created ""The Limited Red Society"", a group of practitioners that have learned how to effectively reduce red time while test-driving and refactoring code. I want to introduce this society to the Ruby world and some of the tools and ideas I have been working on.
We can gain detailed insight into your programming patterns while using a TDD flow by recording the state of your tests every time you run them. From these detailed metrics we can start to visualise how you work. How long did we spend in the red with that failed test? Was that test we wrote too big a step leaving us stuck in the red for too long? Did we spend a long time in the red because we were shaving a Yak? How many unit tests did we just break with that last change?
"The future is already here — it's just not very evenly distributed." (William Gibson)
The Ruby community is where a lot of this future already happens. We not only set the bar higher and higher every day, we've also built most of the infrastructure use day to day. Twitter, Github, Gemcutter, Pusher to just name a few projects that changed the world, the way we live and work.
With Travis CI, an open source continous integration service for the Ruby community, we are going to push the limits even further. We are going to build the test and integration infrastructure you are dreaming of: The vision behind Travis CI is to become for builds what Rubygems is for distributing libraries.
In this talk Josh and Sven, two of the core members of the developers team, will talk about Travis CI and introduce you to the vision behind it and the way it is implemented.
Computers are being built with more and more CPUs and those CPUs in turn have several cores. Powerful calculations are now performed either on many-cored machines, or on distributed systems. In this context, it's in the developer's interest to start thinking about concurrent programming. But concurrent programming with mutable is tricky. The last few years have conclusively shown that very few developers get this right when faced with conventional shared state threads.
One of the ways to simplify concurrent programming is the actor model. In the actor model, programs are made of actors sending each other messages, and acting on the messages they receive. The actors don't share any state.
In this talk I explore several ways to implement the actor model in Ruby.
25th–26th June 2011