Shoes is a tiny graphics toolkit that embeds ruby. It allows you to do anything. You can draw squares and circles and they can move about and say “Good Morning” when they chance upon each other. Shoes lets you add layouts to your applications with ease. It borrows ideas from Processing, Lua, and HTML to make an intuitive language to convert your ideas into programs that you can share with your friends.
Learn about the architecture and construction of CloudKit, an Open Web JSON Appliance. Along the way, see how the emerging Open Stack — including OpenID and OAuth+Discovery — can be used to build open and discoverable web services in Ruby. Other topics of exploration will include cooperative Rack middleware stacks, non-relational storage with Tokyo Cabinet, new IETF drafts covering HTTP Discovery, online/offline synchronization with plain old HTTP, and more.
Every site based on a RDBMS will eventually hit a database scalability bottleneck. In this session we will introduce Hypertable, an open-source implementation of BigTable, and HyperRecord, an extension of ActiveRecord using Hypertable for storage. We will demonstrate Zvents’ use of these technologies to scale a high-traffic, data-intensive consumer web application, writing billions of cells daily.
Yehuda’s GoRuCo talk was on the subject of Rails as a Ruby citizen – that while Rails was already a pretty good Ruby Citizen with 2.3, 3.0 is about making it a better citizen.
Who is the Rails Developer?
Many are building apps on top of Rails, not considering making an extension, just building on what’s available. Others are building extensions full-time. In the vast many are power users working on long-term projects, building apps primarily, but in the course of it making tweaks and extensions to Rails.
What Does it mean to be a Ruby Citizen?
Rails is built on many other Ruby libraries: Rack, Test::Unit, Erb (soon to be replaced with Erubis).
Other libraries use Rails as a library, e.g Spree, ActiveMerchant, Radiant, Sproutcore.
Also, Rails works with other libraries, and can be optionally used with them, for example as in the case of Haml.
Rack as an example of the benefits of Citizenry
Prior to Rack, frameworks would right special handlers for each of its interfaces, with all sorts of attendant inconsistencies. Rack, when introduced, seemed to solve this problem, and so was incorporated into Merb.
But Rack is actually much more than this. It enables you to write Middleware, which is components of code integrated to the generic Rack interface. This enables functionality to be consolidated into single-purpose middleware components, with all other components remaining ignorant of the others.
In Rails 2.3, they applied Rack to Rails, making each controller a middleware endpoint selected by the router, which was another middleware component.
But good Rack endpoints don’t do dispatching, they just pass-through one-to-one. So in 3.0, the router will point at a specific action.
As with ruby libraries in general, Rails is a citizen in the Rack ecosystem, using Rack, working with other Middleware, and providing its own which is then used in other frameworks.
To this end, Rails 3.0 will split out things like rescuing, params parsing and session handling into middleware which is then usable downstream without pulling in all of Rails.
In Rails you can use middleware via “config.middleware.use Foo”
By generalizing Rails via Rack, Rails is able to use generalized Integration testing by simply treating Integration test as a Server which issues commands to the Rails stack via the standard Rack interface. Already Rails 3.0 works with rack-test.
Why does ORM agnosticism matter? ActiveRecord is Ruby, DataMapper is Ruby, one should be able to just require the alternative and use the library.
But Rails has dependencies on the ORM, for example in the form_for helper, which works for a specific interface.
Merb 1.0 offered “Agnosticism” by offering 2 interfaces, one for ActiveRecord, one for DataMapper. If you wanted to work with merb, you had to offer one of those interfaces, as CouchDB did.
To provide a general solution, Rails needs to provide a standard abstract interface which anyone can implement in order to interface with Rails.
One can meet this interface by:
- Complying, either with a direct interface on your object or a shim that provides the interface.
- Proxy, which maps your object’s interface to the expected one.
Rails will ship with the prototype version of this, Yehuda is planning to write the jQuery equivalent, Mootools and others will provide their equivalents as well.
In Rails 2.3, simple actions would spend 20% of their time in filters. Filters are important in small applications which do a lot of traffic and performance-intensive apps.
Historically, parts of Rails filters (Before, After, Conditions) had been factored out into ActiveSupport, but Around filters and skipping were more difficult to filter out, and so hadn’t been. Rails 3.0 integrates all the rails filtering in a performant way.
In 2.3, Rails asks the filter a bunch of questions, even if it’s a simple filter, which you’d expect to be fast, then sends. This checking is runtime, when all the necessary information is available in advance.
Rails 3.0 uses metaprogramming to compile the various filters down into a single method which is simple and quick.
Action Mailer and Action Controller had diverged and require separate implementations on many fronts. The better way is to call use modules to attach functionality to either class, from a common base. It uses super to iterate over each modules implementation in order.
The result is a bunch of layers doing a single thing, taking and producing normalized data. You can remix and insert your own equivalents.
In Rails 3.0 one can set _action_view method with a renderer object which then implements alternatives to or extensions on the Rails action_view helpers.
Equivalent to ActionController, with expensive modules excluded, to which you can attach your own functionality.
On of Yehuda’s goals: “How easy would it be to implement Sinatra on top of Rails?”
Likewise, how can Rails be made such that it’s functionality is more available to other projects such as CloudKit.
Q & A
In Q & A, Yehuda notes that in Rails you can get away without knowing too much about inheritance and subclassing, while “more crazy” languages force you to know this. He hopes that Rails 3.0 will bring more awareness of this to Ruby.
Building a massively scaled, fault tolerant web service isn’t easy, but it’s definitely easier if you know which architectures work and which don’t. In this talk we’ll survey the architecture and complexities of a scalable web service including edgeware, middleware, message systems, load balancing, cache hierarchies, queueing theory, coordination primitives for distributed computation, designing for latency, inter-process communication, load balancing versus locality, write versus read throughput, non-relational datastores, database replication topologies, logging distributed computations, fault tolerance, deployment at scale, forensics, and the merits of suicide.
It has been said that Ruby is a slow language, but that is not true. Numerous Ruby projects have shown that it is possible to write fast, scalable software using Ruby. Merb, for instance, is faster than any major PHP web framework.
In this talk, Carl will show how to take the many available tools, such as ruby-prof, RBench, and kcachegrind, and turn any old Ruby into a speed machine. The tips and processes will be demonstrated with real world examples of optimizations that have been done to the Merb and Rails 3 projects.
Many of us discovered Ruby because of Rails, but there are many more frameworks for both web development and other application domains. We have assembled authors and contributors from six of the major application frameworks written in Ruby: Rails, Merb, Sinatra, Adhearsion, RAD and Shoes. We’ll get to hear what they have to say about what makes Ruby good (or bad) for building frameworks, and what opinions they have of other frameworks. Come with your questions, and demand answers!
A high-performance proxy server is less than a hundred lines of Ruby code and it is an indispensable tool for anyone who knows how to use it. In this session we will walk through the basics of event-driven architectures and high-performance network programming in Ruby using the EventMachine framework.
Ben Stein of Mobile Commons is giving a talk on Cross-platform Mobile App development. They hadn’t done any client mobile work, but lately clients have been asking “what about iPhone?,” “what about Android?” and the like. Whether or not this question of navigating the mobile client world is important to you now, Ben predicts it will soon be, as that’s where we’re headed.
Thoughts and experiences from Mobile Commons’ first mobile client apps:
Mobile give you capabilities not available elsewhere:
- Accelerometer & Orientation
- Phone & Contacts
- Sound & Vibrate
This is a big list – serious stuff.
Uncool things about mobile
- Unreliable network connectivity
- Java, Objective-C
- Memory Management
Options for mobile
- Maybe your Rails Web app is good enough
- A mobile-formatted version of the web site
- A client app
- alternate stylesheets
- separate mobile subdomain
- No cool mobile features
- No app store distribution
** have to bookmark, no $$
iui, iPhone, Rails
- iui & rails-iui: gives you stylesheet and typical iPhone ajaxy interaction
- Mime::Type.register ‘text/html’, :iphone
- Rich User experience
- Cool device features
- App store distributions
Native Apps: Cons
- New technologies
- Different technologies
- Frameworks to learn
“There are only so many hours in the day to learn new technologies.”
Alternative Tech Stack
- Webkit rendering engine (HTML/CSS)
- Business logic in web application
(accelerometer, location, phone, &c.)
- HTML5 Client-Side Storage (SQLite + JS)
- Proposed 6 years ago, working group started in 2007. Implementations emerging, particularly in Webkit, which is the common mobile renderer.
- Video Tag
- Client-side Storage
- and more…
3 Types of Storage
- Structured Storage
- Client Database
HTML5: App Cache
Also defines a mechanism for enabling intelligent client-side caching.
- Defines an interface for client-side databases
Ben then demos a sticky-note app which works currently in Safari, and works with client-side persistent storage.
Security & Privacy
This makes cookie resurrection easy, so the designers include a same-domain policy in the spec, to reduce access.
GMail on the iPhone
Currently uses the app-cache and asynchronous updates to enable offline access.
- Open-source Project by Nitobi
jQuery minus all the browser compatibility code, optimized for Webkit & Mobile phones.
Don’t use Curl to test these apps, use HttpClient, which deals with much of the basics, including authentication
The phone number is linked with the a ‘tel:// ‘ URI which then allows initiating a call from within the phone.
These projects can be built and managed out of eclipse for Android and XCode for iPhone.
- Apps don’t quite feel native. A bit slower, not quite as polished.
- Not good for graphics, games, &c.
- App store policies? Reports that some apps have been rejected for using these frameworks.
- HTML5 spec not yet finalized
- Tons of fun work to add HTML5 functionality to Rails
Q & A
What about Migrations?
There’s no easy answer, this is one of the reasons we switched to Web development, because we have more control and the easy ability to push updates. Client migration support is also theoretically possible, but has yet to be implemented.
Have you ever tried to catch a train running at a million miles an hour? Jumping into the traffic stream at Wikipedia is an insane adventure I’ve been going through. Exactly how do you launch a new platform that could instantly have millions of hits in a few hours? How do you do that and not spend 3 years researching? A fun tour of how I got Ruby at Wikipedia and did it with confidence, bravado, and alcohol. There will be cussing and lots of funny stories that should be highly educating and an insight into my technical philosophies.
This talk will present the TrustTheVote project and the “I count!” movement. It will cover the technology roadmap, progress so far, and next steps, including expansion of development efforts and opportunities for involvement in design and construction of trustworthy voting technology that everyone will be able to see, touch, and try—technology that will be fully federally certified and have the endorsement of the States’ elections directors through a unique approach that can ensure widespread adoption. If you have ever wanted to know what you can do to make a difference in our electoral process, then this talk is for you.
- Single Responsibility
- Open Closed
- Liskov Substitution
- Interface Segregation
- Dependency Inversion
All of Sandi’s code is available here.
Fact: your application is going to change. How will your application handle that change?
Robert Martin says your app can behave a couple of different ways:
- Rigid: Making a change somewhere will break something somewhere else.
- Fragile: You can’t predict where that break will be.
- Immobile: It’s hard to change your code.
- Viscous: It’s easier to do the wrong thing than to fix things.
In the beginning, though, your app was perfect. “Dependencies are killing you!”
Design might save you.
The Design Stamina Hypothesis says that, after a certain point, you’ll have done better if you had designed first.
“Skip design, if you want your app to fail.”
To avoid dependencies, your design should be:
- Loosely coupled
- Highly cohesive
- Easily composable
- Context independent
SOLID principles we can ignore in ruby:
Really only a problem for statically-typed, compiled languages. Because we’re in Ruby, we don’t have this problem! Win!
“Dynamic languages obey this rule in the most extreme way possible: duck typing.”
When you design, don’t break the contract of the superclass in the subclass.
Sandi draws her examples of applicatoin change from the source code at: http://skmetz.home.mindspring.com/img28.html.
Lesson #1: Resistance is a Resource.
- Don’t be attached to your first idea
- Embrace the friction
- Fix the problem
If testing seems hard, examine your design. Tests depend upon the design of the code. “TDD will punish you if you don’t understand design.”
During refactoring, ask yourself:
- Is it DRY?
- Does it have one responsibility?
- Does everything in it change at the same time?
- Does it depend on things that change less often than it does?
The answers should all be ‘yes’.
Sandi references her code to demonstrate when and how to mock and use dependency injection to achieve Single Responsibility, in which a class both downloads and acts upon the downloaded data.
She urges developers to do the simplest possible refactoring when extracting responsibilities from a class.
“Refactor, not because you know the abstraction, but because you want to find it.”
Sandi uses a very interesting example of building a Config class which behaves differently in different Rails environments. The first version had a lot of smell, and with a combination of hash parameters, YAML file, and metaprogamming, she demonstrates how to be open for extension, but closed for modification.
Sandi explains that paying attention to your classes’ dependencies is important. If a relatively static class is dependent on a class that changes more often, that’s a smell! Use dependency injection to avoid Dependency Inversion.
“TDD, BDD and DRY are all good, but they are not enough.”
“Design because you expect your app to succeed, and the future to come.”
Sandi recommends reading:
In this session, David Stevenson explores how to run untrusted code inside a ruby application using a sandbox. With this powerful technique, users can upload code that integrates as part of a larger application, making it ideal for custom business rules, dynamic games (think SecondLife), and science/math applications. Ruby’s english-like syntax and ease of creating DSLs makes it a good scripting candidate for non-technical people.