Here in the U.S., we have some serious problems with our voting system:

• No Federal Guidelines about how votes are counted
• No assurance in California that absentee votes are counted
• Problems with the voting machines and the companies who make them
  • Most voting machines are written on Windows95
  • 4 vendors creating voting systems in the US, may be 2 by the end of the year.
  • Very high barrier to entry: certification costs millions $, this is actually a dis-inventive to innovate
  • Natural conflict of interest: shareholder interest collides with public interest.  The companies have feduciary responsibility so the shareholder interst always trumps public interest.

The Open Source Digital Voting Foundation is seeking to fix this “critical democracy infrastructure.” We should consider it a “digital public works project” since it is so imperative, creating transparency by using an open source approach.  They are creating an endowment to support a public technology repository.

“Sunlight is the best disinfectant”

Overview:

• Dev process: core team essential for continuity
• RFC Services: similar to IETF process
• Design Congress: state elections directors arround the country in a virtual community to drive the business requirements
• Federal Certification undertaken by the non-profit

All the software will be dual license; Public Development License & Commercial Deployment License, so that it can be easily adopted by corporations.  The goal is to create transparency by using an open source aproach, and actually build things that we can see, touch, and try.

Major work areas (*=Ruby on Rails projects):

• Digital voter registration system*
• Ballot design*
• Ballot casting and counting
• Election management* – back office web app for supporting the admin tasks of an election, including district data
• Operating system platform: they are building on “commodity” hardware and components, but for some customer who are seeking additional security features they are collaborating on open source hardware with Intel and AMD

A good portion of the work is Rails-based, with Pivotal Labs as a development partner.  He also noted that they are in the process of putting together a “core team,” recently joined by Alec Totec, one of the original Netscape engineers (a very smart, practical guy who I had the opportunity to work with in ’95 tracking down bugs in the Netscape Plugin API when I worked on Shockwave).

After the talk, I got the chance to speak to John Sebes, OSDV CTO. He noted which projects are being implemented with RoR (see * items above). Some of the web apps they are buiding will solve fairly simple technical problems, but they answer a huge need.  The folks who run the elections generally work with very poor quality software with awkward UI that can lead to errors.  For example, one might think that putting together a ballot would be straight-forward, but there are countless examples of very basic design flaws, which could be remedied by some relatively simple, effective software.  He told a story of the election of Rush Holt, who was fortunately uncontested, yet the ballot made it very hard to tell the intent of the voter:

I can imagine all sorts of ways that ballot design in general could be improved for usability in addition to fixing outrageous bugs in the system like the one illustrated above.  As a voter and open source developer, I am very excited about this project.

There are lots of ways to get involved.  Join their new facebook group to stay in touch.

First, she gave us an overview of the AIDS epidemic, especially in Africa:

• Africa has 12% of the world’s population, but 60% of the people with AIDs
• In Malawi
  • 14% of adults have AIDS
  • 8 people die every hour from aids
  • there are 280 doctors
  • 3500 HIV/AIDS patients per doctor

When she arrived, patients would wait in long lines to see a doctor and patient intake would typically take 15 minutes.  It was all paper-based an error-prone.  In Malawi, they have a national id program where every ID card has a bar code.  This could be used for easy patient intake.  After they developed the hardware/software solution, it would take less than 1 minute to register new patients and less than 10 seconds for returning patients to get through the intake process.

The solution was designed to help  in a number of areas:

• Patient Registration: entering new patient data, generate national id bar code, or scan an existing one
• Encounters: any patient interaction
• Observations: diagnosis, progression, vitals, patients complaints, drug regimen
• Prescriptions: drugs, ingredients, inventory, etc.

They overcame challenges with spotty internet connections and low bandwidth.  They use a wireless mesh network, which is self-healing.  The portable computer they used was based on the I-Opener (initially bought from the US on eBay, then 2000 were donated) which was hacked to include a touchscreen, ethernet, PoE (power over ethernet) and a bar code scanner.  The software is Ubunto, Ruby on Rails, and MySQL.

More details on the software:

• BART – Baobab Anti-Retroviral Treatment
• OpenMRS Data model
• templating using ERB
• App calls via AJAX
• Rspec tests

Jacqui told a great story about Gem the Janitor (yes, that is his real name) who just picked up the device during a busy time when all of the nurses were busy, figured out the interface quickly and started helping register people.  Now he runs the whole intake process.

Why RoR?

• great community
• common consensus on best practices
• active contributions to OSS
• very accessible information on every part of the stack
• supurb interactive tutorials like peepcode
• Ruby is easier to learn offline that other languages, comes with documentation
• ActiveRecord: makes complex data models easier

Now 265 of the 280 doctors are using this app.  The data collection enables extensive reporting, enables agencies to use the data to focus research & funding, and influence policy decisions.

You can help!

• http://github.com/baobab/
• the developers are on IRC:  freenode #baobab
• more info: www.baobabhealth.org

“Your website is a distributed network service.”

While the talk was entitled “Magic Scaling Sprinkles,” Nick dispelled the idea that any magic technology would solve scalability problems; instead, he shared some fundamental concepts of computer science underlying scalability:

• distribution
• balance
• locality

Two important concepts: throughput and latency

For example:  1 worker is able to complete a job in 1 sec. 1 job/sec is the throughput (number of jobs per unit time). 1 sec is the latency (elapsed duration from start of job to the end of a job). Latency is an efficiency question. Throughput is a scalability question. Focus of this talk on scalability.

Nick wrote a very simple echo server, ran a load test. Then added:

100000.times { Time.now }    # represents an intense loop. memory alloc + system call
sleep rand *3  #an efective representation of blocking i/o

complete code is on github

How many can we run in parallel? How many can we run per machine? How many can we run per core?

The code uses a statistics library, statosaurus, that they use at twitter (Nick’s github example contains a version of statosaurus which he says contains the key parts of the proprietary twitter package). Recommendation: log everything extensively, thread transaction ids throughout your logs. Essential for tracing down failed distributed transactions. (In SQL queries, HTTP headers, etc.)

For this example, he logs the following:

• a time stamp
• a transaction id
• wall-clock time: amount of elapsed real time
• system time: amount of time the process has spent in the CPU while in kernel mode
• user time: amount of time the process has spend in the CPU while in user mode

Note:   system time + user time < wall-clock time Since there is wait time (simulated by sleep) or if there are too many process on the machine at the same time for the number of cores, so your process is waiting in the “run queue.” That latter excessive context switching is what we want to investigate.

Generally if we take the wall-clock time and divide by (system time + user time) we get the optimal number of processes per core. This leads us to a distribution strategy.

Nick talked about different mechanisms for distribution: TCP Proxy, DNS (compelling for a chatty protocol), client (has some serious drawbacks for maintenance/upgrades). In this case, proxy is an optimal solution.

Use a strategy of “least connections” aka “by business” which is more effective than round robin.

True efficiency: never do the same work twice.

Locality: analogy to tape drive, where if you write close to where you last wrote or read, then it will be significantly faster due to spatial locality. The same applies to hard drives and databases.
Cache is a spatial locality that keeps the data near the code. Put the requests on processes where the data is most likely to be cached. Sticky sessions can be an essential technique.

“Slow code is your fault.”

How can I write fast code?
1. Write slow code: well-structured code that is easy to read. Don’t worry about performance the first time around. You can’t tell from the beginning what matters.
2. Use the scientific method.

1. Define the question
2. Gather information: where is time/memory being spent?
3. Form Hypothesis: why is this chunk of code slow/memory hog
4. Perform an experiment and collect data
5. Publish results (restart if needed)

Need questions like: “why is action X taking 600ms? ” why is 60% of a Merb dispatch cycle in content negotiation?”  Why are my mongrel instances growing to 300MB of memory”

Some useful tools:

• RBench
• ruby-prof to generate profile data / kcachegrind:  for reading profile data
• explain analyze log files
• New Relix / five runs
• memory_usage_logger
• Bleak_house (memory leaks)

Garbage collector is a conservative mark and sweep garbage collector.  When it runs all your code stops. Each run can take 50-150ms.  Triggers befre grabbing more system memory (every 8MB).

Avoid creating unecessary objects.  Understand the difference between Ruby methods (e.g. the difference between reverse! and reverse).

DataMapper’s identity map is pretty awesome.

Beware of modifying large strings.

Don’t concat strings just to pretty print them across lines.  Do this instead:

     s = "Here is my long string" 
           " that continues"

Beware of closures.

No code is the fastest code.  Be lazy.  Don’t run code till you have to.

“Compiling your code.” Iterating is slow.  Ruby’s AST is fast. (This is a little crazy, but sometimes you need it.)

Make sure you have great tests, then when you optimize you can make sure you didn’t break anything.

Shoes, Tim Elliott, framework for creating GUI apps. It is an application that embeds Ruby. It is written in C. It is designed to lower to bar for programming and make it fun. Not an MVC framework. Writing an app is more like writing a script. Written to be compiled an shared with your friends.

RAD, Greg Borenstein, open source hardware platform for doing hardware hacking. RAD is a framework for programming the Arduino physcial computing platform using Ruby. The Ruby code is coonverted into C code which is then compiled and run on the Arduino microcontroller. Working on a test suite that comes with a shoebox full of hardware, so you can check if things blink or bleep in the right order to see if your tests pass.

Adhearsion, Jay Phillips, a way of building telephony applications. You call into a phone number, then the Ruby call services the phone call. First app he wrote was using RAD to make it so he could make a phone call to unlock his door — he says everyone should go out and buy an Aduino controller and a bunch of LEDs and build something fun tonight.  Interesting thing about Ruby is that it allows you to “play with other people’s code.” He described a plugin system that was actually adopted from RAD.

Sinatra, Blake Mizerany, creator of Sinatra.  Sometimes MVC is too much.  Ruby is great for this.  Closures are awesome.  As Rack grows, Sinatra has been getting smaller.  Sinatra is a really strong Rack citizen.

Merb, Yehuda Katz lead maintainer.  (not talking about Merb) Hard thing about maintaining a framework is that they start with a clear mission, but as people build apps with the framework, there are requests where its hard to tell if this request is pushing application code into the framework  The best thing about Ruby is that all code is executed code.  You can define methods anywhere.  What is hard about Ruby.  It isn’t a slow language, but nothing is free.   The challenge is how to right lightweight code, yet is robust.

Rails, Josh Peek from the Rails and Rack core teams.  … interested in seeing how code can be shared between frameworks to strengthen the  ecosystem.

What features of the Ruby language make it effective for frameworks? meta-classes and closures (e.g. ActiveRecord),  “i don’t consider languages without closures to be powerful languages” (yehuda katz), defining methods on the fly, open classes, community (grass roots, people agree that they want to share code, this is unusual, agility in the community: moving to git and github, Rack, Ruby gems, RSpec, test-driven development as part of the project),  the agility of the community attributed to the agility of the language.

Is there anything about Ruby that encourages open source? the fact that it is a scripting language.  It is hard to hide your code.  The fact that Rails and Ruby are MIT Licensed, so corporations aren’t afraid to use it.  Even if 90% don’t give back, it increases the number of people who do.  Makes it so people feel free to try stuff out and modify it (and the fact that there are tests!)  There is high level of inter-operability with the “host language” for different Ruby implementations.

“If you are writing a framework, you should be writing it in the same way that you recommend people write plugins.  It’s really hard, but you have to do this.” — Yehuda Katz

“Allowing people to write test for their plugins is essential.” — Jay Phillips

What about the proliferation of Ruby implementations in different languages? kick-ass, as long as we keep holding the implementations to a high standard of compatibility.

Why was github so successful?  Why did so many projects move to git and to github so quickly? main benefit of github is the social network aspect.  When you put your code up on github, you aren’t creating an open source project, you are just sharing your code.  This decreases the overhead.  It increases people contributions.  “I think it has totally revolutionized the way people create open source software” (Jay Phillips)  Moving to git let’s you make really large changes and merge them back.  Things that are possible in git, would have been impossible in svn — you would fork forever instead of merging back in. (Yehuda Katz)

How to get the community to move to Ruby 1.9? get Rails to be on 1.9.  Why do you want the community on 1.9? speed improvements.  Yehuda Katz:  If you are doing something computationally expensive you might want to be on 1.9.  I benchmark everything.  Usually 1.9 is 2x and JRuby is 2.5x, but 1.9 has outliers of slowness.  I don’t think there is huge benefit to the community in moving to 1.9 (but I do think it is important that we all do move forward)  Jay Phillips: when JRuby and all the gems move to 1.9, the community will.  If I switch to 1.9 syntax, I will break JRuby, and I can’t do that.

Ilya describes a proxy server as his new favorite hammer. I can think of lots of cases where having an easy way to write a proxy server would come in handy. Mostly what we think of when we think of proxy servers is a “transparent, cut-through proxy,” but proxies can be useful for other purposes.

The problem that led Ilya to write a proxy server was benchmarking and performance testing. He started with HTTPPerf is good tool for simulating load, but it is only good for a single run. autoperf will make multiple runs and simulate more users.

em-proxy Very simple syntax to send traffic to both the production server and benchmark server (and only the response is returned from production). Real-time benchmarking against production traffic and user sees no performance hit. Only about 300 lines of code, shows the pattern for how to build a proxy server.

Ilya walked us through using EventMachine which has very concise, easy-to-read syntax for implementing proxy servers. This does not need to be restricted to http, but can work with any protocol.

Ilya described an interesting use case in detail. They created a proxy server which works with Beanstalkd, a distributed in-member work queue, where jobs are stored in MySql when they don’t need to be in memory.

Slides from the talk:

A sandbox needs to:

• Limit functionality
• Make it so code can’t break out
• Separate code space
• Bounded execution time

Sandbox gems

• Freaky-freaky sandbox gem (MRI Ruby): it’s a gem, but you can’t use gem install.  No support for 1.8.7 and later.
• JavaSand gem (JRuby): same API as the freaky-freaky sandbox, more actively maintained
• Rubinious has SubVMs, David doesn’t have experience with it

acts_as_runnable_code is a sandbox helper:
set up sandbox easily with referenced classes
pass in top-level binding

Built an example in just a few minutes that allowed people to enter experession to be evaluated and opened to the audience (offering cupcakes to anyone who broke it!).  Here’s some of the first experiments from the audience:

very simple framework, define a route, where it goes, return a string
Sinatra is not a framework, doesn’t dictate how to create your code.  It is a library.  A ruby library for making Web applications.

Why? HTTP as a language? with REST and other conventions, it is cool to think of it as a way of two apps speaking to each other.  If your library needs to “speak HTTP,” Sinatra is a good way to do that.  It’s a nice layer on top of rack.

Aaron described a vision where all libraries would have web apps interfaces: to allow you to configure your library or inspect information.  These are designed to be available on localhost, not designed for the “global web.”

For example: Aaron wrote ‘gembox‘ for Ruby Gems, which will display in a browser the list of installed gems.  Simply calls the gem APIs, but provides a UI on it instead.  The app is very little code, low effort for a significant return.

Vegas: super simple Sinatra starter.  Provides simple options for running the app (startup, saving pid, etc.)  (this is a cool idea right now, just a simple class right now)

Would be neat to be able to search for all gems that have Sinatra or Vegas interfaces.  Question from the audience about security issues.  This is still pretty early in development, but there are some neat ideas here and potentially useful tools.

MacRuby, started toward the end of ’07.  It has two ambitious goals:

• Make Mac OSX the best platform for Ruby developers
• Make Ruby the best Cocoa programming language on OSX

Apple has the higher level APIs in Objective-C.  RubyCocoa (2001) mostly written in C will bridge  Ruby & Objective-C.  Quite verbose. Rich showed a “hello world” that was about a page of code in small type.  Problem: it’s a bridge.  Thereare holes, expensive (slow), messaging syntax is diferent.  Ruby uses green threads (it is not re-entrant) — only one native thread can enter the Ruby runtime at any time. Tricky garbage collection, etc.

The development of MacRuby leveraged the key observation that Ruby is actually similar to Objective-C.  MacRuby replaced the Ruby 1.9 garbage collector with the Objective-C garbage collector.  Ruby’s hash is actually an NsMetuable dictionary.  Every Ruby class is an Objective-C class.  You can use MacRuby, at runtime to add methods to an Objective-C object.

MacRuby is 0.4.  Syntax is better, but still a lot of code for “Hello World”

HotCocoa
In the MacRuby “hello world” a lot of the code is in configuring, setting up the app, wiring things together.  HotCocoa is just a library that helps simplify this setup process.

Much more concise, but it isn’t magic.  ‘window’ returns an NSWindow, it isn’t obscured, just decorated.  You have all the NSWindow methods available,

Hello World turns into 7 lines of code!  [update: nice post with code snippets]

hotcocoa <app> (similar to rails <app>) will generate all the files needs for a Mac application.  Framework is dropped in there, so you can give the code to someone and they don’t need

HotConsole: written in MacRuby and it is irb, but {}.methods(true,true) will show you all of the methods in an MSMutable dictionary, but otherwise {} behaves just like a Ruby hash. Also let you interactively create native Mac OS widgets (create a window, add a button, make it do something) all by typing in a few lines into this interactive console.

MacRuby Experimental

LLVM replaces yarv.  In this, using MacRuby the jit generates machine code. This makes it 4-5x faster than 1.9 (which is 4-5 times faster than 1.8).  Goal is to pass all of 1.9 Ruby specs, and it is well on its way to doing this.  Also plans to make it reentrant.  Goal is to automatically generate GrandCentral code hich allows the code to run across all the cores in the machine.  Rich expects this to be complete by the end of the year.  This could also be applied to compiling ahead of time which would enable running the code on a certain devices that don’t run Ruby, yet run OSX code :)