Ruby is now almost two decades old. It has become a very mature language. The developers who have been using Ruby are a lot more experienced now. Our community has long since crossed the chasm and we are in the early majority stage. Even though we have many people who are well versed in the language we are again experiencing an influx of new developers.
I want to help those new developers feel comfortable enough to believe they can learn and become just as involved as the older developers. Also, I want to make sure that the older developers understand how they can help these new developers that are coming into our community. There are things we can do to make sure our community grows with great people and projects that are useful for everyone. I want the Ruby community to show the Open source community how we should be treating each other so that amazing things can be done.
Some products on the web are successful. Some not. Some products are great, some fall short of greatness. Some visionary-developer relationships are inspired partnerships, and some are uninspired and unproductive.
Taking a look at two common developer mindsets, I'll be touching on why luminary developers sometimes can stumble at product development, and on the flip side, what makes an average developer great. What I thought made a great developer, isn't the exactly what I think today.
Ruby is the most flexible language out there, imposing no limitations on the developers, giving all the expressiveness possible. Or so we think. But there are languages pushing dynamic features and expressiveness far beyond what is possible in Ruby. Some are old, like Lisp and Smalltalk, some are just emerging, purely experimental languages, like Ioke or Newspeak. In this talk, we will take a look at some of these languages and what they can do that Ruby can't. What does it mean, to be homoiconic? How does a language without keywords work? Can I dispatch in more than one direction? And what is partial evaluation?
Rails is considered a secure web application platform and has a fairly good protection against common web application attacks. Still, if you don't follow the Rails way, you may easily expose your application to common attacks. Knowing the threats is important for coding with a security state of mind.
This talk will highlight the common web attacks as well as some Rails specific attacks and how to prevent them
Heroku has deployed over a million 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.
Rails performance is a complicated topic. There are many levers to pull,
buttons to push and knobs to turn.
What is performance and how is it different from scalability? Why performance
matters? When it matters and when it doesn't?
Each millisecond you scratch off your app makes your users like it more, but
it's very easy to dive into performance optimization and loose the big picture.
We've all encountered them - the fat controllers.The huge monstrosities that handle everything in your project and a bit more.
But it doesn't have to be like that, clean controllers exist - and you can enjoy working on a project that has them.
We'll go through a few methods of trimming the fat from your controllers and make them stay thin!
Resque has been plagued by issues over the past half a year due to inactivity on the project. For instance, resque doesn't handle the cleaning up workers on distributed systems like Heroku. This issue (#319) has been open for over a year. redis.rb 3.0.0 came out on May 23rd which brings improved performance and backward incompatible changes. Also due to this inactivity, other queueing libraries like Sidekiq have come up to fill the void with new features.
We'll use my story of taking over Resque as a case example for maintaining an Open Source project. I made a lot of mistakes along the way that you can hopefully avoid. Some examples include balancing pushing forward with new features and maintaining the latest stable release or getting comfortable with the prior design decisions. We'll close the talk with a roadmap to Resque and how it fits with Rails 4 and ActiveQueue.
There are many approaches to testing server and client library APIs - various tradeoffs, problems that come up, etc. Some are obvious, some are a little more tricky. I'll run through some approaches.
The operative side of large scale SAAS web company is very challenging. Modern web applications are highly distributed, use multiple platforms and technologies, and built out of many independent asynchronous services. In addition, while practicing Agile development and very frequent changes in production, it becomes critical to be able to safely and rapidly deploy, monitor, increase, decrease and, if needed, rollback changes.
In this talk, we will present some of the tools we built here at Kontera for dealing with these challenges, using an in-house platform built on top of Ruby tools
This talk is a tour of the development process inside GitHub. It’ll cover how GitHub builds software, from idea to production. We'll go over high level philosophies of software development, then dive into what tools and processes GitHub uses to streamline project management and development.
Ruby on Rails is a great framework for quickly building complex web applications.
It's easy to get started, and it's easy to keep adding
new features. But what happens when your creation gets too large? You need to break it up into services!
What does that look like in practice? Where do you start? There are answers to be found in the story of Engine Yard Add-ons.
While all the other speakers will talk about the strength and greatness of Rails, Arik will try to convince you why not to use it and to remind you that it's Rails on Ruby and not Ruby on Rails.
Convention over configuration, DRY, Rails opinionated approach do a great job freeing developers from repetitive, mind numbing rituals.
Still there are decisions that should be made over and over again.
Let's talk about some of them that probably could have been
generalized as well.
We don't have all the answers but we definetely have some questions.
Practical, day-to-day tips that will help you write more robust specs. Especially for newcomers to TDD, brittle tests are a big problem, but RSpec and common sense can go a long way to remedy that!