by Dave Thomas
At the start of the day, we list out all the topics and prioritize them based on the class's wishes. From there, we start at the top and see how far we get. There's a mixture of talk, demonstrations, and exercises, and I generally let the class lead me down rabbit holes as long as enough people are interested. In general, the more experienced the audience, the faster we go. In general, people will need at least 6 months Ruby to keep up. A year or two is the sweet spot.
Topics may include:
by Corey Haines
Coderetreat is a day-long, intensive practice event, focusing on the fundamentals of software development and design. By providing developers the opportunity to take part in focused practice, away from the pressures of 'getting things done', the coderetreat format has proven itself to be a highly effective means of skill improvement. Practicing the basic principles of modular and object-oriented design, developers can improve their ability to write code that minimizes the cost of change over time.
The JRuby core team members Charles Oliver Nutter and Hiro Asari lead the first JRuby workshop in the Southern Hemisphere.
Topics that will be covered include:
Attendees should have a Java VM installed (Java 6 or higher) and have familiarity with the basics of Ruby. RVM will make installation easier, but it is not required.
Rails Girls kicks off with an installation party on the evening of Tuesday, February 19 before attendees are guided in the use of Ruby on Rails to build a web application.
Registration is free!
For more details of the event, please visit Rails Girls Melbourne.
You've got your iPhone app almost ready to go, but now you need a website. You're an iOS developer, not a web developer, and every day that goes by is another day that your app ISN'T in the App Store. You can outsource your server-side development, but that costs both time & money. What if you could build your own website? Our Rails for iOS Developers Workshop will help you get your responsive website up and running, using the powerful Ruby on Rails framework, from creation to deployment, in straight-forward, easy to follow steps.
by Corey Haines
Corey Haines helps developers improve their fundamental software design skills through the use of focused-practice events, such as coderetreat. He trains teams on development technical practices, and builds projects and products when not on the road.
by Chris Kelly
New Relic recently made the big move to Ruby 1.9.3 which showed meaningful improvements over 1.8, particularly in garbage collection. So this talk is taking a look at what changed in Ruby's garbage collection that caused much of the improvements. We will start with the fundamentals of garbage collection but work down to the nitty gritty C code to get to the details of what's going on, starting with rb_newobj(). You should walk away with an understanding of how garbage collection works in MRI and a nice appreciation for the overall lifecycle of Ruby objects.
Most developers know enough about refactoring to write code that's pretty good. They create short methods, and classes with one responsibility. They're also familiar with a good handful of refactorings, and the code smells that motivate them.
This talk is about the next level of knowledge: the things advanced developers know that let them turn good code into great. Code that's easy to read and a breeze to change.
These topics will be covered solely by LIVE CODING; no slides. We'll boldly refactor right on stage, and pray the tests stay green. You might even learn some vim tricks as well as an expert user shows you his workflow.
by Toby Hede
A fun code analysis.
Heroku has deployed millions of web apps. When you've run that many applications, it's hard not to notice when frameworks and developers do things wrong, and when they do them right. We've taken a look at the most common patterns and boiled down the best of our advice in to 12 simple factors that can help you build your next app to be stable, successful, and scaleable. After this talk you'll walk away with in depth knowledge of web framework design patterns and practical examples of how to improve your application code.
How many companies are hiring Ruby developers right now? How many are finding qualified candidates? Why aren't workers swarming into our industry to fill up all these empty developer positions? Is learning Ruby really that hard? Why is learning Ruby so hard? Isn't it a language built by people for people? Shouldn't that be easy for anyone to pickup and use? Why isn't everyone building Ruby apps? I'm going to tell you. The good, the bad, and the goofy of trying to teach Ruby, Rails, and everything else we take for granted as RoR developers. There may even be a guest appearance from a real life Ruby Newbie to demonstrate!
by Terence Lee
If you've ever done anything in ruby, you've probably used rubygems and to search or install your favorite gem. On October 17, 2012, rubygems.org went down. A Dependency API was built to be used by Bundler 1.1+ to speed up bundle install. Unfortunately, it was a bit too popular and the service caused too much load on the current infrasture. In order to get rubygems.org back up the API had to be disabled. You can watch the post-mortem for details.
Members in the community stepped up and built a compatible Dependency API service called the Bundler API. Working with the rubygems.org team, we were able to bring the API up for everyone within a week. In this talk, I will cover the process we went through of extracting the API out into a separate Sinatra app that now runs on Heroku. I'll go over how the API works and how Bundler itself uses it. Since we don't have direct access to their database, we needed to build a syncing service to keep our local cache up to date. We'll discuss the original sequential implementation of the sync code and how we improved performance through the use of a consumer thread pool. The sync time down was cut from 16 mins to 2-3 mins. Next, we'll talk about the productization steps we took for visibility to make sure the app is performing well.
We're prototyping a replay service, to replay production traffic to different Heroku apps. With this we can compare the performance between the current MRI app in production and the same app running on JRuby. This will also allow us to test any changes/features against real production load. We'll go over how to set this up.
by Pat Allan
One of the most notable things about Ruby is its community - the passion towards writing good code, the opinions on how code should behave, the tools it produces, the people it draws to it, and yes, occasionally the arguments and drama.
Is this something we should take for granted? Should we be actively guiding the community to behave in a particular way? What makes up a healthy community? Are there ideas and wisdom can we take from other communities? So many questions – let's see if we can find some answers!
Social app development challenges us how to code for users' personal world. Users are giving push-back to ill-fitted assumptions about their identity — including name, gender, sexual orientation, important relationships, and other attributes they value.
How can we balance users' realities with an app's business requirements?
Facebook, Google+, and others are grappling with these questions. Resilient approaches arise from an app's own foundation. Discover schemas' influence over codebase, UX, and development itself. Learn how we can use schemes to both inspire users and generate data we need as developers.
As a rapidly growing company, GitHub's faced some challenges in how to make sure that everyone can get up and running on projects or continue to work on one of the dozens of existing projects if they've never set it up before. What a nightmare! That's what prompted @jbarnette and @wfarr to develop The Setup. The Setup aims to solve all the problems that used to plague on-boarding GitHubbers onto projects with a lot of automation and a case of the "It Just Works". This presentation talks about the history of The Setup, how it works, and some of the lessons learned along the way.
Most Ruby code makes heavy use of mutable state, which often contributes to long term maintenance problems. Mutability can lead to code that's difficult to understand, libraries and applications that aren't thread-safe, and tests that are slow and brittle. Immutability, on the other hand, can make code easy to reason about, safe to use in multi-threaded environments, and simple to test. Doesn't that sound nice?
This talk answers the question "why immutability?", covers the building blocks of immutable code, such as value objects and persistent data structures, as well as higher order concepts that make heavy use of immutability, such as event sourcing and pure functions, and finally discusses the tradeoffs involved in going immutable.
Over the last two years, I've traveled the world to pair with expert designers and developers on short projects to learn their day to day secrets and understand their philosophies. I've condensed this to 45 minutes of tricks, insights, opinions, and old-fashioned rants from Ryan Singer (37signals), Kyle Neath (GitHub), Neven Mrgan (Panic), Zed Shaw, Gary Bernhardt (Destroy All Software), and others.
Aaron Patterson is one of Ruby’s most respected and loved programmers. A committer to both Ruby and Ruby on Rails and a member of Seattle's Ruby community, he also has a sense of humour that has endeared him to many audiences.
Drinks and canapes will be served.
20th–22nd February 2013