Just as Rails did for web development, the Arduino project combines powerful layers of abstraction with sensible defaults, making it easy to build hardware devices that sense and manipulate the physical world. So easy that artists, social workers, scientists, and even simple web programmers who lack electrical engineering degrees can do it.
The Ruby Arduino Development project attempts to extend these virtues by bringing the beauty and power of Ruby to the Arduino platform. RAD compiles Ruby scripts for execution on the Arduino microcontroller development board. In addition to the syntactic elegance and simplicity gained by getting to program in Ruby instead of C++, RAD provides a set of declarative Rails-like conventions and helpers that reduce boilerplate and simplify often-byzantine hardware APIs.
Webrat, a Ruby DSL for interaction with web applications, changes the acceptance testing ROI equation. By implementing an invisible, fast browser simulator you can use from within your test framework of choice (Test::Unit, RSpec, Shoulda or Cucumber), it sidesteps most of Selenium’s drawbacks while retaining the coverage value.
In August of 2008, Jacqui Maher visited Baobab Health in Lilongwe, Malawi. Baobab is a dedicated group of programmers, clinicians and administrators developing public health and patient data administration systems. They use a variety of hardware and software technologies, but their main applications are written in Ruby on Rails.
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.