Chad Woolley's blog
This fixes several bugs that people have complained about for quite a while. Please let me know if anything is broken.
GemInstaller 0.5.3 has been released!
GemInstaller
CHANGES
- 0.5.3 / 2009-08-25
- Many long overdue bugfixes and patches, see http://tinyurl.com/geminstaller-0-5-3-release for details.
- Thanks to Greg Fitzgerald, Britt Crawford, John Trupiano, Gabriel Gironda, and Eric Hodel for patches and assistance.
- Issues with case statement under Ruby 1.9
- GemInstaller cannot distinguish between gems that have the ame name but capitalized differently.
- add ./ci as default location for config file
- Disable GemInstaller install in default rails preinitializer.rb, but fork if it is used
- autogem() fails when run for newly-installed gem
- Sometimes installing fails due to RubyGems cache not being cleared between multiple API calls
DESCRIPTION
Automated Gem installation, activation, and much more!
FEATURES
GemInstaller provides automated installation, loading and activation of RubyGems. It uses a simple YAML config file to:
- Automatically install the correct versions of all required gems wherever your app runs.
- Automatically ensure installed gems and versions are consistent across multiple applications, machines, platforms, and environments
- Automatically activate correct versions of gems on the ruby load path when your app runs ('require_gem'/'gem')
- Automatically reinstall missing dependency gems (built in to RubyGems > 1.0)
- Automatically detect correct platform to install for multi-platform gems (built in to RubyGems > 1.0)
- Print YAML for "rogue gems" which are not specified in the current config, to easily bootstrap your config file, or find gems that were manually installed without GemInstaller.
- Allow for common configs to be reused across projects or environments by supporting multiple config files, including common config file snippets, and defaults with overrides.
- Allow for dynamic selection of gems, versions, and platforms to be used based on environment vars or any other logic.
- Avoid the "works on demo, breaks on production" syndrome
- Find lost socks.
Quick Start
See http://geminstaller.rubyforge.org/documentation/index.html
INSTALL
- [sudo] gem install geminstaller
Links
What OSDV means to me personally
I personally am really excited about this talk. I worked on the OSDV prototype at Pivotal last year, when we made a small prototype in a few weeks. This was subsequently presented to congress. It was an incredible experience. As a programmer, you write a lot of code which isn't that exciting, counting beans or Yet Another Social Networking Website.
OSDV, however, is something that is REALLY important. It has the potential to revolutionize the way Democracy works, and really change the world for the better.
Here goes the talk, with Matthew Douglass running the slides and Gregory Miller talking.
Intro Video
First is a video about how democracy used to work, when we trusted the outcome of votes. Now, after the 2000 Presedential Election, people lost confidence.
Now, states are getting funding to update their voting system. However, now that we are past the "Hanging Chad", we are seeing MORE, not fewer problems. The companies that make proprietary digital voting do not make the required investment to make their machines trustworthy, and rely on PC technology and proprietary code.
Shouldn't we be able to say "I count"? We should not expect the Government or Private Sector to fix this. It must be a Grass-roots movement, something big. We need to completely rethink the lifecycle of our ballots.
We have to shift away from companies guarding proprietary, black box voting to a world of "glass-box" voting. Blueprints and designs are freely available.
We need the Open Source Digital Voting Foundation.
it is not just another thinktank or group of lobbyists. It is technology professionals teaming up with volunteers. Everyone can see, touch, and try it out.
This is a digital public works project, calling people from all over the country and world to help out, take a hands-on approach, and do something.
We are the real stakeholders in our Democracy. We can all make our votes count. The time to begin is NOW.
Pop Quiz
Q: Federal guidleines for how votes are counted? A: FALSE
Q: California's absentee ballots always counted? A: FALSE
Q: Major voting vendors system rely on commodity Hardware/Software A: Sort Of. They use "Windows 95".
He then shows "Clippy" helpfully offering to finish your vote for you...
A "Free Markets" Failure
- No Competition
- High Barriers to Entry
- No Incentive to Innovate
Horribly dysfunctional market. There are FOUR vendors of voting systems in the US, there may be two by the end of year
Very high barriers to entry, hard to get it approved and legal.
When you have no competition and barriers to entry, there is no incentive to innovate. You end up with closed proprietary systems with inconsistencies and irregularities. There is a natural conflict of interest between shareholder interest and public interest.
Guess who wins every time when shareholder interest meets public interest?
Critical Democracy Infrastructure
The pillar of democracy is transparency, and the substance of the pillar is technology.
"Sunlight is the best disinfectant"
This stuff is so imperative and essential to our Democracy, it needs to be lifted up to the level of a public works project.
Why not commercial sector? They will do as little as possible, and have conflict of interest
Why not the government? Slow, and at risk of losing funding.
Our Solution
Bringing together two approaches - fault tolerance and high-availability computing, with the dynamics of open source community.
Rather than being a think tank, they have a group of people in Silicon Valley making things that we can see and touch.
Development Process
- Core team
- partner with Mozilla Foundation.
- RFC (Request For Comments) Service
- Send out requests for comment to community
- Design Congress
- A virtual community to help drive requirements, so they know there is a possibility of adoption
- Federally certified
Public Technology Repository - State and local govt, Fed govt, Commercial Vendors, test suites, dynamic continuous testing, everyone is giddy!
Two commercial vendors who are deploying with a commercial deployment license, and are being delivered open source solutions based on draft standards that the consortium is building.
Major work areas
- Digital Voter Registration System
- Ballot Design Studio
- Ballot Casting and Counting Systems
- Election Management Services
- Operating System Platform
Rails is a major part of their work. They are assembling a great core team.
It has been below the radar, but it will be more public in the future.
Questions
Q: How do we advance or improve the system? A: Yes, look over the horizon at what the future looks like - Instant runoff, etc. However, there is another half of the question. They DON'T want to build the 'perfect' system, and have it be a relic. They have to be driven by real requirements and real adoption. They have to take the EXISTING processes, and make them better. That will get their attention, and drive adoption.
Q: Are the Hardware and Interface designs open source? A: Absolutely everything is open. Everything will be transparent and funneled through the RFC process. The goal is to build an entire software ecosystem that runs against a known, virgin, commodity hardware system. Then they will examine on a device-by-device basis to plug in new parts. "Open Source Hardware" has never been done, but they will try.
Q: What are the obstacles (e.g. politicians) A: Lots of them, but their position is that they are technologists, making the best solutions. Senator Patrick Leahy said "please don't waste time trying to change systems, make things that people can touch and try".
There are "horrifying" ways the system is designed to preserve incumbency. If this works, it really changes the landscape in a big way.
Q: What percentage of elections are corrupt? A: They have been doing due diligence, and have found "remarkable" inconsistencies, some of which have resulted in criminal elections. We may think that Obama got elected, things are great, but we dodged a bullet. We are 170 days into the congressional session, and no senator from Minnesota is seated. Politicians will no longer be able to hide and say "the box did it".
Q: It seems like a huge complex problem to solve, shouldn't it be bite-sized? A: They thought about componentizing it, but the only way to do it right is to start with a clean slate. Forget incumbency, and legacy. We need open data and open processes. They are partitioning the process to different buckets, and have different teams working on them. They are laying the foundation for a pluggable, XML-based framework. They are going in a procedural fashion, and really focusing on the 2010 election.
Rapid prototyping, Agile Development approaches with Structured Approaches.
HUGE APPLAUSE AND WHISTLES!
I just released cinabox. It is intended to be The Simplest Thing That Could Possibly Work to set up a Continuous Integration (CI) server, using cruisecontrolrb (CCRB).
Watch the Screencast!
In addition to being a (hopefully) useful tool to help people easily set up CI systems for various platforms and languages, it is also an experiment in simplicity and minimalism:
- The project consists of only two simple scripts, one shell script to bootstrap ruby, and one ruby script to set up cruisecontrolrb.
- In the script, readability and simplicity are favored over clever abstractions and DRYness. Hopefully, even people who don't know shell scripting or Ruby can read the scripts and easily understand the commands it is executing.
- A standardized environment is assumed: A dedicated Ubuntu 8.04 system, Ruby 1.8.6, and latest dependencies via aptitude. PCs and Virtual Machines are cheap, and Linux and CCRB are free. There's really no reason you shouldn't be able to run a dedicated CI box. If this environment doesn't work for you for some reason, the scripts should be self-explanatory enough that you can easily hack it up to work for your environment (and contribute your version back to to the project!).
- I use the magic fairy dust of GitHub to eliminate build scripts, release scripts, packaging, versions, and pretty much all the regular boring overhead of a project. The README.txt is my only documentation. The GitHub "Download Tarball" link automatically provides packaging and uniquely-named packages (by the git hex commit id) for each "release".
I'm pretty pleased with how this turned out. I hope it will lower the barrier for people to start trying out Continuous Integration, as well as provoke some thought about simplicity and minimalism. I've tried it out on a few flavors of Ubuntu VMs and my personal box, and it works for me. Please let me know what you think, and feel free to offer any suggestions for improvement.
I just attended (and thoroughly enjoyed) the Mountain West Ruby Conf, where Evan Phoenix gave a powerful keynote speech.
He talks about the status of Rubinius, and makes some profound observations on modern open source culture and community.
Here's some highlights, but if you participate in open source, and especially if you help run an open source project, I highly recommend that you watch the video:
- Community: Rubinius' Giant Spec Suite, and its value not only as a living language specification for different implementations of Ruby itself, but as a "gateway drug" which provides a low barrier to get new contributors addicted to open source.
- Trust: Asking for forgiveness vs. permission, and the Rubinius commit policy, where any accepted patch gets you commit rights. You can always roll back a change, and debate is healthy.
- Worth: The impact of annoying fifteen year olds who make a lot noise versus "core" contributors.
- Ego: You are not the project, Mr. Ego! The importance of being wrong and admitting your faults in public.
- Innovation: Fostering innovation and debate vs closely holding the mythical "Keys to the Castle".