Software engineering as it's taught in universities simply doesn't work. It doesn't produce software systems of high quality, and it doesn't produce them for low cost. Sometimes, even when practiced rigorously, it doesn't produce systems at all.
That's odd, because in every other field, the term "engineering" is reserved for methods that work.
What then, does real software engineering look like? How can we consistently deliver high-quality systems to our customers and employers in a timely fashion and for a reasonable cost? In this session, we'll discuss where software engineering went wrong, and build the case that disciplined Agile methods, far from being "anti-engineering" (as they are often described), actually represent the best of engineering principles applied to the task of software development.
Rails jumped on the scene five years ago in part due to excellent support for connecting database tables to Ruby classes via ActiveRecord. Rails 3 makes two major improvements to this support. ActiveModel makes it easy to turn any old object into one that looks like ActiveRecord to your Rails app. ActiveRelation makes many kinds of queries easier and makes it possible to write some queries that were very difficult in the past.
In this talk, we'll learn how to build our own model layer using ActiveRelation and ActiveModel. We'll start by learning how ARel works and how to use it. Then we'll write an adapter for our own database. Next, we'll see what ActiveModel provides and how we use it through ActiveRecord. With this in mind, we'll add functionality to our models that make them look just like ActiveRecord to our Rails app.
In the end, we'll have a good grasp on the new options for modeling data in Rails 3 and how we can use that to write cleaner apps.
Yehuda Katz has done some great Ruby refactoring for Rails 3 over the past year, but do you really understand what he's done? In this talk, Gregg Pollack will attempt to examine Yehuda's work, identify and deconstruct each programming technique that he's applied, and then teach them in a way that everyone can understand.Some of the techniques to be discussed will include: Method Compilation vs Method Missing, Microkernel Architecture, alias_method_chain vs super, ActiveSupport Concern, Catch/Throw in Bundler, and increased Rack compatibility.Attendees should walk away with a greater understanding of some advanced Ruby design patterns and a better insight into the internals of Rails 3.
Hashrocket began as a small four person shop aiming to build products and get rich doin
Most of us have worked where there's tremendous effort on planning, anticipating the needs of our customers, testing before release to our customers, re-thinking, re-considering and re-coding. To a developer, the only thing that may seem worse is when there's none of this. Regardless, we expect to know, in advance what's true about our customers.
What if both alternatives are wrong? What if, instead, we assume we're ignorant and use our creativity to learn? Then, we'd
continually run live experiments with our users to see what works; and
gather more metrics than we know what to do with; and
continually deploy changes to adapt those learnings.
Find out why we worked this way, the results we achieved and the specific tools and technologies we use.
Dive into the target audiences and differences in NoSQL storage, how to implement them and what this NoSQL thing is all about.
Discuss how SQL has limits when you get to web-scale and how NoSQL bypasses these limits.
Deploy an example application using Rails 3 and Mongoid to see how CRUD differs from your MySQL and Postgres installs.
With a growing pool of ORMs innovating in the realm of NoSQL solutions and a new NoSQL database seemingly every week, it can be difficult to decide what is right for your app. We'll talk about the features of MongoDB that make it the best document database, and what's being done to keep Mongoid at the head of the pack as the best NoSQL library of them all.
Okay, your rack app is done and you are ready to deploy it. Now, instead of developing your application you have to switch gears and start thinking about how it should be deployed. What http server should you use? How do you scale it beyond a single instance, load-balance it? How do you even get your app on a server? This discussion happens every time that you finish an application to deploy!
There is no disputing it, deployment is hard and you either have to be great at both or hire someone who is great at one. At AT&T interactive, we deploy many different applications from many different developers all the time. Additionally, we have application support staff, release schedules, server management staff, etc. etc.
In this talk, I'll introduce Beehive, a new open-source application deployment framework helps address this problem. We'll discuss why it was developed, how it works and how to use it. Without introducing any new tools, application developers can deploy their applications with a single command git push. Written primarily in ruby, c and erlang, Beehive can run on any hardware supported by the erlang vm. It's written to be entirely distributed, fault-tolerant and maintain high availability for applications.