O'Reilly Ruby

Is QWERTY harming language design?

2008-05-12T05:13:47Z

One of the rather unique features of the Fortress¹ programming language is that it has builtin support for Unicode operators. For example, instead of using “==” you would use U+2261. After reading the spec, and a recent thread on ruby-core, I’ve been wondering something . Are language designers too limited in their decisions about syntax because of the limitations of the QWERTY² keyboard?

Larry Wall’s first rule of computer language design is, “Everybody wants the colon”³. Maybe the problem is that we just don’t have enough symbols on our darned keyboards. The result is that we’re left fighting over the scraps that QWERTY gives us, e.g. the colon. My opinion is that a limited number of usable characters limits our thinking and our expressiveness. Perhaps it’s time for computer programmers to consider whether or not we should have special keyboards. I mean, plumbers and electricians and carpenters have special tools that your average homeowner doesn’t own, right? Why should computer programmers use the same tools (i.e. keyboard) that your average computer owner uses?

Maybe it’s time that we accepted the fact that programmers need a different keyboard from your average, non-programming computer user. Another row of keys above the current QWERTY keyboard, with two characters per key, gives us another 30+ code points. Or even just a redefinition of the current function keys would suffice. With these at our disposal, language designers can then write grammars & parsers that actually use these characters.

Are there issues? Sure there are. First and foremost is that it will take a new keyboard layout that programmers can agree on.⁴ Second, there are differences between typical desktop and laptop keyboard layouts. Third, vendor specific keyboard layouts with special, predefined keys will have to be considered.⁵

But none of those issues changes my opinion that we’re being hampered by QWERTY.⁶

¹http://research.sun.com/projects/plrg/fortress0618.pdf
²http://en.wikipedia.org/wiki/QWERTY
³http://www.perl.com/pub/a/2001/04/02/wall.html
⁴I thought the W3C might have something to say on this topic but I was unable to find anything. Links welcome.
⁵Mainly Microsoft and Logitech I imagine, but probably others.
⁶Yes, this is a reworked entry from an older, personal blog post that some of you may recognize.

Ruby Mendicant: Hadean Prawn

2008-05-03T18:34:05Z

Back in March, I announced the Ruby Mendicant project after several readers of this blog encouraged me to pursue the idea. For those who didn’t see the follow up details elsewhere, here’s the readers digest version:

Thanks to 70 donors, and donation matching from Ruby Central, Inc. and MountainWest Ruby LLC, I am now able to take 22 weeks off from my commercial work to focus on open source development in Ruby. I had a number of project ideas, but the general consensus is that my time would be best spent building a fast, sleek, and simple PDF library for Ruby. I’ve decided to call this library Prawn, for the time being.

Since I have just reached my first checkpoint on the project, I figured I’d give folks an update on where things are.

Development on the project officially began on April 15th, but admittedly, it has been a slow ramp-up from there. I decided to give myself a few days to acquaint myself with the massive 1310 page specification Adobe provides for PDF. However, within a week I was able to put together a rough outline of my development plans.

I’m happy to say I’m already getting a lot of help. The good folks at Active Reload hooked me up with a free Lighthouse instance for Prawn, which has been a dream to work with so far. Beyond infrastructure, I’ve also been getting other help. I ran a few of my initial design ideas by David Black, and have been working actively on high level design with James Edward Gray II. If I want to claim that Prawn will be a clean and beautiful library to work with, I figured I’d need to get the insight of some Ruby masters.

Implementation-wise, it’s unrealistic to expect contributions this early in the game. Nevertheless, I’ve been receiving a ton of help from James Healy, Ruport’s resident PDF expert and maintainer of PDF::Reader. He even prototyped line drawing for me, which was a great way to get started on Prawn.

So after a couple weeks of development, what can Prawn do? The answer is best shown by a picture:

The code to generate this hexagon looks like this:

pdf = Prawn::Document.new
pdf.fill_color "ff0000"
pdf.fill_polygon [100, 250], [200, 300], [300, 250],
                 [300, 150], [200, 100], [100, 150]
pdf.render_file "hexagon.pdf"

Though it’’s not terribly exciting to look at, Prawn now has all the primitives you’ll need to do basic drawings. It supports Bezier curves, lines, circles, and polygons. It has full color support, though you’ll find it to be a whole lot more barebones than PDF::Writer (it only supports HTML/CSS formatted RGB color strings e.g.”f0f2cc”). I’ve used PDF::Writer’s page geometries to allow you to set the page sizes to a huge amount of different formats, from US Letter to A4 and god-knows-what-else. Banded together, these features make up Hadean Prawn, the first checkpoint on the geologic timescale of the project.

Prawn is still missing a lot of higher level graphical functions, implementing only a tiny fraction of what you might find in other libraries. It is intentionally dumb about a lot of things, and I assume I’ll need to circle back and extend functionality substantially down the line. Right now the focus is on being tiny, and keeping things as simple as possible.

There are already several examples in the source to get you started, if you’re the adventurous type. There is also a full spec suite, which I plan to make as comprehensive as possible to make Prawn easily hackable and a bit more stable than the current PDF libraries available in Ruby.

In the coming weeks, I’ll be working on the next checkpoint, which is Archean Prawn. This will be approached in the same way Hadean Prawn was, but with a focus on text primitives rather than graphics. I have no idea if I will focus on internationalization just yet, but it is definitely an important goal of Prawn. I will do some reading about this and figure out the details, and let folks know what I find out.

If you want to get involved with Prawn at this point, my best suggestion is to go track the project on github. You can also keep an eye on Prawn’s Lighthouse for updates. I’ve been using the wiki and tracker actively, so it’s worth keeping an eye on. Finally, you can come look for me (<sandal>) in #ruport or #prawn on Freenode if you’d like to chat.

If you’re interested more in the meta-aspects of things, i.e. the Ruby Mendicant project itself, please come join our google group and share your thoughts. Because this an effort funded by the community, for the community, I’d like the give everyone the opportunity to voice their thoughts and opinions.

I plan on doing a status update like the one you’ve just read once every couple weeks or so, but in the mean time, if you’d like to get involved, please do so!

See you in a couple weeks when Prawn has basic text operations and maybe more.

A Ruby WTF

2008-04-28T16:54:45Z

While working on Prawn, I ran into this (not-so) fun little gotcha:

>> 1.to_sym
=> nil
>> 101241.to_sym
=> nil

Anyone cool enough to tell me what this feature is all about?

Update:

I guess it isn’t totally clear what I was asking here. I’m not actually trying to convert integers to Symbols. In fact, my specs were failing because I expected some_number.respond_to?(:to_sym) to be false!

As it turns out, Fixnum#to_sym does have a purpose, but it is quite different than something like String#to_sym.

>> :foo.to_i
=> 14369
>> 14369.to_sym
=> :foo

I knew about the existence of #id2name and it didn’t surprise me much, given the way Symbol objects are implemented. Still, for the folks who keep reminding me about what Symbol objects are, please save your comments because that’s not the point here.

The point is that when I see “foo”, I can easily say. Oh… “foo”.to_sym will give me :foo.
When I see [16393, 16401, 16409], I don’t think “Gee… that must be: [:cat, :monkey, :tomato], I just need to map it with to_sym”.

So what this boils down to is an API clarity thing. Even if a Symbol is closely bound to an integer implementation-wise, I think it’s a bit of a flaw to assume that to be important conceptually. Among our readers, has anyone used Fixnum#to_sym in real code? I’d be very interested in seeing a common use case for this feature. If there isn’t one, maybe a less ambiguous name, such as id2sym might be more appropriate.

What’s more, even with the existing name, it’d be nice if some_number_that_has_no_symbol.to_sym would blow up with an error rather than return nil.

Sorry for the earlier confusion, hopefully this update clarifies that I was talking about a design peculiarity., and not some burning desire to get myself back a :1.

Help Lessig Tag Congress

2008-04-27T15:39:37Z

Sorry, it isn’t entirely Ruby related… it is Python Django to be specific, but it is a message aimed at you (”the wiki-worker types”) from Lawrence Lessig recruiting people to tag members of Congress at Change-Congress.org:

Today we’re launching the second stage of our project. We’re asking wiki-worker-types (and that includes you) to help us tag all candidates and Members of Congress, by tracking for each whether they support the planks of reform in the Change Congress movement or not. We’ve built a set of tools that you can use to document — for each plank of reform — whether a candidate supports that plank or not. After that information is verified by a volunteer administrator, we’ll add it to a map of reform that we’re building. After we’re done, we’ll have a picture of the level of support for fundamental reform of Congress. And with that map, we’ll launch stage 3 of our project — raising money to support candidates who support reform

Django has the edge in the civic-Web20-computing space as Holovaty’s Django was always more focused on the public square from the beginning. You would think Rails would be a no brainer for this, but in my brief encounter with the world of political web sites, many of the people I was talking to thought that PHP was king (ick). (In related news, this is the best online book interface I’ve seen yet.)

Surprising Contender: NetBeans as a Ruby+MySQL IDE

2008-04-27T01:35:33Z

I’m sure you don’t believe it, doesn’t seem like NetBeans is going to take the Ruby developer world by storm, but Sun seems to be pouring money into Ruby support. I’m skeptical that the Ruby community is going to embrace Netbeans, but in this entry, I present some hints that NetBeans may be well on its way to becoming the Ruby IDE of choice. The idea that an IDE traditionally associated with Java development is going to take the Ruby world by storm might seem insane at first glance, but read on…

Sun is focused on developer market share…

…nothing else. Pouring money into Ruby support and acquiring MySQL for a cool billion play into this perfectly. While everyone has been moaning about the Death of Java for years, it remains the biggest draw on Safari, and the biggest book market. Ruby has the fastest growing community. My conspiracy theory is that the MySQL acquisition coupled with the HUGE Netbeans focus means that Sun is after you. Sun sees Ruby as having the energy, they want to channel your mojo. (JavaOne should really be renamed at this point, I predict they are going to talk about Ruby almost as much as Java this year.)

Which brings me to NetBeans…

Kovacs Pitches a Curveball

Sun relentlessly pushes NetBeans at every conference, to the point where every time I’m in a Sun presentation I expect someone to relate it back to The Great IDE: NetBeans. Almost every time I talk to some Sun PR operative they are talking to me about NetBeans. I’ve met some people that use NetBeans, but most tend to use either Eclipse or IntelliJ. Michael Kovacs writes about his past and present view of NetBeans over on his blog in “So long TextMate?… Hello NetBeans? Really? Yeah, really.”

Michael Kovacs: I’ll admit it, I’m one of many folks that used to treat NetBeans as a whipping boy. Questioning why Sun would bother dumping money into the horse that so obviously lost the race to Eclipse and IntelliJ to win the hearts and minds of Java developers around the world.

He continues:

Michael Kovacs: I grabbed a nightly build of 6.1 and installed it. Right away I noticed that they made a special build for ruby where they’ve stripped it down to where it is focused on supporting ruby and rails apps. They added a theme that looks similar to textmate to make me feel more at home. Many keybindings are similar to Textmate (though not all but they are easily configurable). You can easily debug your rails apps with the graphical debugger. The generators work. Code completion works okay at times. API docs are easily visible inline during code completion. Navigating around the project is now easy where before that was the single biggest outage that kept me from even considering it. You can easily jump to type definitions. Simple refactoring is supported…..

Right, last time I installed Netbeans was just after last year’s JavaOne, and I came away with the idea that it was weighty, not very agile. I forget how big the download was, but it was more than Eclipse. I’m convinced there are some great things about the tool, and that it has come a long way, but I’m still somewhat incredulous. Although, Kovacs is no Sun fanboy, so his post got my attention.

So, let’s just assume that Kovacs is right and NetBeans is a real contender now… enter MySQL..

James Hints at NetBeans 6.5: MySQL Integration

You’ll probably warm up to NetBeans 6.5 once it becomes MySQL Administrator and MySQL Query Analyzer. James from Sun Discusses MySQL Support in NetBeans 6.5 and you can see list of planned database features for NetBeans 6.5. Maybe we’ll see the existing MySQL tools integrated in situ… from the wiki:

…MySQL WorkBench will solve this if we can integrate with it in some way…

Now that might give me a real reason to start using the tool. If Sun really wanted to be draconian about it they would absorb MySQL Administrator and MySQL Query Browser into NetBeans and make NetBeans the only way to run the tools. Now, if NetBeans became the supported way to manage MySQL, many Rails programmers would find themselves with an installation of NetBeans (with integrated MySQL Administrator, Query Browser, and Workbench). Then they can start attracting you to NetBeans Ruby support….. then after that they start to convince you to start deploying applications using JRuby…. then they dangle something like Glassfish integration in front of you and XA transactions (because everyone ends up needing them).

I’m still skeptical, but I’m going to RubyOne….. err… JavaOne with open eyes. If Kovacs is right, then NetBeans might just turn into the logical choice.

Netbeans Rails Support

If you are interested in seeing what Netbeans has to offer wrt Rails, take a look at Tor Norbye’s blog.

(Time to stop) Stubbornly Clinging to Emacs

I still use Emacs for Ruby programming, everytime I’ve tried to get into something like Aptana, I’ve been frustrated by this or that. Eclipse can become a bloated hog very quickly, and Aptana’s array of confusingly named products doesn’t help. I often wish that I could go back in time and dissuade the Aptana guys from contacting the RadRails project, Aptana tries to do too much IMO - All I want is a Ruby IDE, and I get some sort of crazy “Ajax server” called Jaxer.

Although I use Eclipse with success in other languages, I’ve never seen the need for an IDE in Ruby. I said the same thing about Java up until 2002 when it became abundantly clear that the language complexity was forcing me to adopt an IDE. That hasn’t happened to me yet with Ruby. Even with greater MySQL integration, I’m still not convinced I would make the jump to an IDE for Rails. It is likely time to revisit Netbeans.

Subscribe to Tim’s O’Reilly Network Feed

mod_rails for Apache is now a Reality

2008-04-13T01:30:22Z

The long-awaited mod_rails for apache was released yesterday by Phusion, a Netherlands based IT company. As many of you have already done, I hopped on board to see how it worked and was amazed on how easy it was to get up and going.

Ryan Bates, a guy whose voice many of us Rails coders have grown to know and love, assisted the Phusion team in creating a short screencast on how to install Passenger onto your Mac.

It was basically 3 steps:

1. Install the RubyGem
2. Run the passenger installer script
3. Modify your apache conf file to include the new virtual host

Can it really get easier than that? I submit that it can not.

In my opinion, Passenger is filling a void that has haunted the Ruby on Rails community for some time. Matz is quoted as saying “It is often said that Rails is weak on deployment; PHP runs fairly fast just by uploading scripts. Rails is slow on development mode, and requires restarting on production mode (and bit complex to configure). modrails might be the answer for it.”.

To get Passenger, go to http://www.modrails.com

Gobi: A Ruby Implementation for Go Enthusiasts

2008-04-01T23:00:27Z

Reposting from the official announcement on RubyTalk

Gobi version 1.0.0 has been released!

* http://gobi.stonecode.org
* http://metametta.blogspot.com
* gregory.t.brown@gmail.com

I am happy to announce the first release of my new fork of Ruby called
Gobi. The goal of Gobi is to implement features that I have noticed to
be completely missing.

For example, Ruby’s standard library does not even implement a
datastructure that can easily represent a Go board. Gobi has this
built in as an NArray based, highly efficient structure:

 >> x = Goban.new
 >> x.place_stone(:black, :at => "a4")
 >> x.place_stone(:white, :at => "c16")
 >> x.place_stone(:black, :at => "a4")
 StoneCollisionError: There is already a stone at a4.
   from (irb):3 in `place_stone`
   from (irb):6

As you can see from the example above, Gobi is very friendly to those
writing computer Go applications. For those wishing to write AI bots
to play the game, Gobi also goes through a lot of effort to make Ruby
more efficient.

A major improvement in performance was gained through the removal of
automatic garbage collection. This means that programmers need to be
sure to clean up after themselves, but any Rubyist who also has an
interest in Go will surely be sufficiently skilled to design programs
that avoid memory leaks.

The implementation of object destructors in Gobi is simple, due to the
addition of a release_resources hook in Object. A delete keyword has
also been added, which will explicitly start up the garbage collection
process.

Here’s an example of manual garbage collection in Gobi:

 class Foo
   def initialize
     @board = Goban.new
   end
   def release_resources
     delete @board
   end
 end

Please keep in mind that although the built in classes all have
sensible release_resources implementations, that if you’re feeling
adventurous, you can of course override them. A current fun game in
Gobi is to run a stopwatch and see how quickly memory runs out when
you write some code like this:

 class String
   def release_resources; end
 end

 string = 'a'
 1_000_000_000.times do
   string = string.succ
 end

Of course, though humorous, this should serve as a warning to you: Be
sure to properly discard your objects!

This announcement just scratches the tip of the iceberg of what Gobi offers.

Other cool features include:

- The removal of Ruby 1.9’s giant interpreter lock, as Go programs
tend to benefit from the power of true concurrency. (Unfortunately,
these patches are very platform dependent)

- A major reshifting of Ruby’s standard library. Things like option
parsing, zlib support, and fileutils aren’t really that useful for
programming computer Go applications, so they have been removed. Many
new libraries have been added, including an SGF analysis tool and a
GTP network implementation.

- An interface to a special (Proverb Semantics Parsing) PSP tool,
which allows you to train Go playing robots by simply reminding them
of proverbs such as “Hane at the head of two stones”, and “The empty
triangle is bad”, rather than resorting to low level, complicated AI
programming. This system can be used via irb while a game is under
review in Gobi’s built in Tk based SGF editor. Gobi shows that by
mindlessly memorizing proverbs, Go playing bots can decrease their
rank by two stones in half the time that an average human can.

- The removal of all lesser data structures such as the Array, the
Hash, and the Set. In Gobi, all of these structures could trivially
be built as a subclass of the Goban, so there is no need to keep them
around.

Though I will be taking off 6 months from Gobi development to work on
the Ruby Mendicant project, I hope that people enjoy this early
experimental release and that soon Ruby will be free from the core
team’s shackles to do what it truly deserves to: Reach 30 kyu on KGS
with a Gobi based bot!

Though only time will tell, I am considering reworking Gobi to fork
Aaron Patterson’s excellent Brobinius implementation, as Gobi deserves
some high quality Grosenbach screencasts.

* http://gobi.stonecode.org
* http://metametta.blogspot.com
* gregory.t.brown@gmail.com

CruiseControl Progress Charts

2008-03-18T16:14:15Z

CruiseControl.rb, by ThoughtWorks, is an elegant Continuous Integration dashboard for Ruby projects. This article shows how to call the RoR command “rake stats” once per build, capture the results, and chart them to track trends over time.

Our goal is this chart:

If you think of more trends to display, our architecture will make them easy to add. We start by counting the lines of tests & code, and calculating their ratio. These signals occupy different orders of magnitude, so a logarithmic scale reveals their common slopes. We use Gnuplot to make such charts easy; this paltry output is only the beginning of Gnuplot’s abilities.

CruiseControl.rb

This exemplary Ruby on Rails application provides these important files and folders:

`app/controllers/projects_controller.rb`	we will add a `statistics` view here
`app/models/project.rb`	we will add supporting methods here
`builder_plugins/installed/statistician.rb`	when the builder encountered significant events, such as successful builds, it calls registered methods in here. We add a new `statistician.rb` class to call `rake stats` and record its results
`lib/`	you might plop `gnuplot.rb` in here; otherwise, get it with `gem install gnuplot`
`projects/your_application/statistics.yaml`	we add a database of your application’s statistics
`public/images/charts/your_application.svg`	to view a chart, we render its SVG file into here

`builder_plugins/installed/statistician.rb`

Add this file there, and bounce your server:

require 'fileutils'
require 'code_statistics'

class Statistician

  def initialize(project)
    @project = project
  end

  def build_finished(build)
    run_in_here = @project.path + '/work'
    FileUtils.cd(run_in_here){  append_stats(@project)  }
  end
end

STATS_FOLDERS = [
  %w(Controllers        app/controllers),
  %w(Helpers            app/helpers), 
  %w(Models             app/models),
  %w(Libraries          lib/),
  %w(APIs               app/apis),
  %w(Components         components),
  %w(Integration\ tests test/integration),
  %w(Functional\ tests  test/functional),
  %w(Unit\ tests        test/unit)
].freeze

class CodeStatistics;  attr_reader :statistics;  end

def collect_stats
  #  code callously ripped from statistics.rake !
  folders = STATS_FOLDERS.select{|name, dir| File.directory?(dir) }
  cs      = CodeStatistics.new(*folders)
  statz   = cs.statistics
  tyme    = Time.now.to_i
  yaml    = { "build_#{ tyme }" => statz }.to_yaml
  return yaml.sub(/^---/, '')  #  abrogate that pesky document marker!
end

def append_stats(project)
  yaml = collect_stats
  plop = project.path + '/statistics.yaml'
  File.open(plop, 'a+'){|f| f.write(yaml) }
end

Project.plugin :statistician

That code registers a callback, to call when any project ends. It uses code_statistics.rb to collects line counts for your project, then it appends them to the end of projects/your_application/statistics.yaml. Install that module, trigger a few builds, and examine that YAML file to see your trends in their raw format.

`project.rb`

The callback indexed the database using a timestamp - the number of seconds since 1970. To read the database, we pull everything into an Array and sort it by that timestamp.

Add this to app/models/project.rb:

require 'fileutils'
require 'gnuplot'

class Project

  def get_stats
    statistics = File.read(path + '/statistics.yaml')
    statistics = YAML::load(statistics)
    statistics = statistics.map{|k,v| [k.sub('build_', '').to_i, v] }
    return statistics.sort
  end
...

That method took out the prefix “build_“, and converted the timestamp back into an integer.

`gnu_plot_stats`

Now that we have an array of statistics, we need to convert them into a chart. You can add the following code anywhere that projects_controller.rb can see; I happened to add mine to the end of app/models/project.rb:

require 'gnuplot'

def timefmt;  '%Y/%d/%m-%H:%M';  end

def fetch_codelines(stat, fields)
  return stat.values_at(*fields).map{|values| values['codelines'] }.sum 
end

def ftime(timestamp)
  Time.at(timestamp).strftime(timefmt)
end

ALL_TESTS = %w(Unit\ tests Functional\ tests)
ALL_CODE = %w(Components Libraries Helpers Controllers Models)

def gnu_plot_stats(project, signals = {})
  signals = { 'Code' => ALL_CODE, 
              'Test' => ALL_TESTS }.merge(signals)
  name = @project.name
  path = "#{RAILS_ROOT}/public/images/charts"
  Dir.mkdir(path) unless File.directory?(path)
  output_file = "#{path}/#{name}.svg"
    #  drastically prevent false positives in manual tests
  File.unlink(output_file) if File.exist?(output_file)

  Gnuplot.open do |gp|
    Gnuplot::Plot.new( gp ) do |plot|
        #  decorate the chart
      plot.xdata 'time'
      plot.key 'outside title "   Code Lines   "'
      plot.grid 'ytics'
      plot.timefmt timefmt.inspect # for quote marks
      plot.term 'svg'
      plot.output output_file
      plot.title name
      plot.logscale 'y'
      stats = project.get_stats
        #  set the time range
      timestamps = stats.map(&:first)
      statistics = stats.map(&:last)
      mini = timestamps.first - 60
      maxi = timestamps.last  + 60
      plot.xrange "['#{ ftime(mini) }':'#{ ftime(maxi) }']"
      times = timestamps.map{|v|  ftime(v.to_i)  }
      maxi = 0

        #  collect each signal and add its plot line

      plot.data = signals.keys.sort.map do |legend|
        fields = signals[legend]
        
        values = statistics.map{|stat|
                    if fields.respond_to? :call
                      fields.call(stat)
                    else
                      fetch_codelines(stat, fields)
                    end
                  }
        maxi = [maxi, *values].max
        
        Gnuplot::DataSet.new( [times, values] ) { |ds|
          ds.with = "linespoints"
          ds.title = legend
          ds.using = '1:2'
          ds.linewidth = 4
        }
      end

        #  set the chart height
      next_order_of_magnitude = 10 ** (Math.log10(maxi) + 1.1).to_i
      plot.set 'yrange', "[0.01:#{next_order_of_magnitude}]"
    end
  end  #  this 'end' writes the output SVG
  
    #  Gnuplot can't beautify the SVG enough, so we tweak these things
  svg  = File.read(output_file)
  doc  = REXML::Document.new(svg)
  node = REXML::XPath.first(doc, "//text[ '#{name}' = . ]")
  return unless node
  node.attributes['style'] = 'fill: #507ec0; font-family:Arial,sans; font-size: 0.8cm;'
  node = REXML::XPath.first(doc, '/svg')
  node.attributes['height'] = nil
  node.attributes['width'] = nil
    #  and finally write the SVG again
  File.open(output_file, 'w'){|f| doc.write(f) }
end

The top-level method, gnu_plot_stats, can call with more signal commands, as an option hash. A signal’s key is its legend, and its value is either an array of signals to sum, or a lambda to call, for more advanced processing. That’s how we will find the ratio of test to code lines.

`project_controller.rb`

To get this chart into our users’ faces, we need a new action in a controller. Providing links to this action is left as an exercise for the reader.

Add this statistics action to app/controllers/projects_controller.rb:

class ProjectsController < ApplicationController
  layout 'default'

  def statistics
    @project = Projects.find(params[:id])
    name = @project.name
    
    gnu_plot_stats @project,
      'Test:Code' => lambda{|stats|
        test = fetch_codelines(stats, ALL_TESTS)
        code = fetch_codelines(stats, ALL_CODE)
        return test.to_f / code.to_f
        }
    render :layout => true,
           :inline => %(
        <embed src="/images/charts/#{name}.svg" 
              type='image/svg+xml' width='100%' height='400'
              style='background: url(/images/big_top_gradient.png);' />
      )
  end
...

That action generates a new SVG file, then renders it in an embedded SVG viewer.

To collect the ratio of test to production code, we pass in a lambda that calculates this. Note that Gnuplot has a “math nanny” feature, which rejects logarithmic scales with input data at 0. A finished project would find a way to clip these points.

To Do

This simple project suggests many cleanups and extensions. We might…

link the dashboard page to our URIs, such as http://localhost:3333/projects/statistics/lemmings
productize the code as a plugin
configure different projects with different signals
annotate a chart with significant integration messages
featurize the chart with time ranges
stack several charts, with different signals in each one
roll-up all the statistics into a team’s summaries.

The ultimate goal is a Big Visible Chart, or Information Radiator, for CruiseControl.rb projects.

Laurent is a champ!

2008-03-14T19:31:58Z

Though I’m typing this from a Mac right now, I’m hardly a fan boy. I spend a little less than half of my time on OS X, the rest spent on cheap PC hardware and ArchLinux, and honestly, I’m happy with both (each for different reasons)

Still, Apple definitely got some things right, and not the least of which was hiring Laurent Sansonetti. He’s the guy who’s been working on cool projects such as RubyCocoa and RubyOSA, and now has just released MacRuby.

MacRuby sounds cool:

MacRuby is a version of Ruby that runs on top of Objective-C. More precisely, MacRuby is currently a port of the Ruby 1.9 implementation for the Objective-C runtime and garbage collector.

Though I’m not actively doing Mac specific Ruby development, that doesn’t mean I can’t extend thanks to a very cool hacker who has been dropping cool free software projects on our community like it was his job…. oh wait… it is. :)

Thanks Laurent for your contributions! You’re one of the reasons why the Ruby community rocks.

The Ruby Mendicant Project

2008-03-11T17:37:53Z

When I wrote the post I’d love to quit my job! (sort of), I was mainly aiming to start a conversation.

Still, enough people took me seriously, and now I can announce that the project is officially under way. I’m in the fund raising stages to collect $8000 so that I can take off 6 months of work to focus on important Ruby open source projects. That sounds even lower than my initial estimate, and the reason for that is because Ruby Central, Inc. decided to back the project! Here’s their press release:

RUBY CENTRAL, INC. WILL MATCH FUNDS DONATED TO GREG BROWN,
UP TO A TOTAL OF $5,000

Ruby Central is always on the lookout for interesting ways to help and
support the Ruby community, and Greg Brown has provided us with one.

Greg has announced a unique plan for himself. You can see the whole plan at
http://rubymendicant.wikidot.com/proposal; meanwhile, here’s Greg’s capsule
summary of the idea:

** Through the donations of community members, I would like to put my
commercial and personal software projects on the back burner for a
prolonged period of time (3-6 months), and focus on working on open
source projects that are of high importance to the majority of
Rubyists. **

Greg has already started to receive donations. And now, Ruby Central
is coming on board to help Greg with matching funds.

Ruby Central will match gross donations to Greg, dollar for dollar, up
to $5000 (five thousand) dollars. That means that if you donate $50 to
Greg’s effort, we’ll donate $50. We’ll stick to the same timeline that Greg
has set for himself (see the above URL).

It’s not quite like anything we’ve done before, but it sounds like a good idea
at the right time, and we’re happy to support Greg’s unusual and imaginative
endeavor.

Please keep in mind that donations to Greg are not donations to Ruby
Central, and therefore do not fall under our tax-exempt status.

Ruby Central, Inc. is a 501(c)(3) tax-exempt organization, chartered to
support Ruby-related events and initiatives that benefit the Ruby community.

Peter Cooper has also decided to support the project by both donating, and posting a summary on Ruby Inside. He does a good job of covering the whole of the story, including relating to those who feel uncomfortable supporting such an effort. I totally understand people’s skepticism, and thats why I encourage people to come talk on the RubyMendicant google group if they have any doubts about the project they want cleared up. The explicit timeline for this project and the fact that I’ve promised to record public hours will hopefully put some folks minds at ease.

Peter mentions that I talked about working on PDF::Writer or Ruport, but this doesn’t really fully explain what I was thinking of doing. With respect to PDF::Writer, I was pondering a from scratch rewrite with a sexy API and less performance problems. With Ruport, I was going to work on 1.9 compatibility for all of its dependencies across ruport-util and acts_as_reportable. Though I haven’t checked in with the maintainers of these libraries yet, it’s truly a laundry list of general purpose gems I’d be working to update. Here are just a few:

RubyDBI
Gruff
Scruffy
PDF::Writer
transaction-simple
roo
rubyzip

Outside of Ruport, there are lots of libraries that I’d like to see working on 1.9, and with enough time, I could work on porting them.

The ideas list will be open for suggestions until April 1st when the donations close, the goal is to focus on things that might be hard to reach from traditional open source work that is done in people’s spare time or as part of a commercial project.

Anyway, this is going to be my last mooching attempt on the O’Reilly blog for this project. If you’ve read through the proposal I’ve put together and want to support the project, please consider a donation. If you’ve got questions, please ask them. And perhaps most importantly: If you like this idea, please spread the word. Having Rubyists show that they back this effort is worth more than cash to me, because it gives me confidence that this might actually work.

At the time of writing, with the matching from Ruby Central, Inc., I have enough money for at least ~~two weeks~~ one month of work. That means this project is a ‘go’ even if no one else donates. Of course, a lot more can be done with 26 weeks than with two.

The next post about this you’ll see here from me is going to be a progress report of what I’ve been working on. Until then, thanks so much to those who have supported and will support this project. I think it’ll be a great experiment, and that good things will come from it.

Beast acts_as_sphinx

2008-03-04T04:06:22Z

This project upgrades an online forum to add a search engine, using Test Driven Development. Our tools are RoR’s Beast, Sphinx, and (naturally) assert{ 2.0 }.

We follow this MVC guideline:

Anything a user can do to the data through the Views,
a unit test can do, the same way, through the Models

Our test cases simulate a user searching.

Adding a View to this project is left as an exercise for the reader. It will be Rails-easy.

Start by learning to install Sphinx, at Data Noise: acts_as_sphinx plugin.

`sphinx.conf`

A query like this provides a Sphinx index:

  SELECT posts.id     as id, 
         topics.title as title,
         posts.body   as body, 
         users.login  as user, 
         forums.name  as forum,
         topics.hits  as hits 
    FROM posts 
    LEFT OUTER JOIN topics ON topics.id = posts.topic_id 
    LEFT OUTER JOIN users  ON  users.id = posts.user_id
    LEFT OUTER JOIN forums ON forums.id = posts.forum_id

That yields a table like this:

id title body user forum hits

1 PDI this! P D I pdi aaron rails 0

2 PDI this! what? pdi sam rails 0

3 PDI this! you heard me pdi aaron rails 0

6 Galactus is coming galactus gah-lac-tus aaron comics 42

7 Galactus is coming Galactus oh no! sam comics 42

8 Agent of SHIELD agent of SHIELD sam comics 19

9 Agent of SHIELD Blah Blah aaron comics 19

10 il8n in rails? il8n in rails! aaron rails 0

etc…

id	title	body	user	forum	hits
1	PDI this!	P D I pdi	aaron	rails	0
2	PDI this!	what? pdi	sam	rails	0
3	PDI this!	you heard me pdi	aaron	rails	0
6	Galactus is coming	galactus gah-lac-tus	aaron	comics	42
7	Galactus is coming	Galactus oh no!	sam	comics	42
8	Agent of SHIELD	agent of SHIELD	sam	comics	19
9	Agent of SHIELD	Blah Blah	aaron	comics	19
10	il8n in rails?	il8n in rails!	aaron	rails	0
etc…

That’s Beast’s Post fixture data. Our test cases will lead Sphinx to return results from them. To generate that big SELECT statement, I wrote this little test case:

  def test_pre_sphinx
    posts = Post.find(:all, :include => [:topic, :user, :forum])
    assert 'keep the fixture system on its toes!' do posts.any? end
  end

Then I read the test.log, and copied out the list of LEFT OUTER JOINs required to write that big query. (Incidentally, other Sphinx plugins, such as Ultrasphinx, read your ActiveRecord associations for you, so they might simplify this step…).

Now copy the SELECT statement into your config/sphinx.conf file, and use it to index and start Sphinx:

source posts
{
    type            = mysql
    sql_host        = 127.0.0.1
    sql_user        = root
    sql_pass        = 
    sql_db          = beast_dev
    sql_sock        = /tmp/mysql.sock

    sql_query       = \
      SELECT posts.id     as id,   \
            topics.title as title, \
            posts.body   as body,  \
            users.login  as user,  \
            forums.name  as forum, \
            topics.hits  as hits   \
        FROM posts                  \
        LEFT OUTER JOIN topics ON topics.id = posts.topic_id \
        LEFT OUTER JOIN users  ON  users.id = posts.user_id  \
        LEFT OUTER JOIN forums ON forums.id = posts.forum_id 

    sql_attr_uint = hits  #  for sort_attr
}

index posts
{
    source          = posts
    path            = ../tmp/sphinx/posts
    morphology      = stem_en
}

The line sql_attr_uint declares we can sort results by hits.

`ask_sphinx`

Now add acts_as_sphinx to the Post model, and write a test to find some sample records:

require 'fileutils'

class PostTest < Test::Unit::TestCase
  include FileUtils
  all_fixtures
  
  def test_aardvark
    system 'rake RAILS_ENV=development db:fixtures:load'
    cd 'config' do
        #  index our fixtures before a test run!
      indexer_response = `indexer --rotate --all --quiet`
      assert{ indexer_response == '' }
    end
    sleep 0.7
  end
  
  def test_ask_sphinx
    response = Post.ask_sphinx('pdi')
    assert{ response[:total] == 3 }
    sphinx_found = response[:matches].keys  # <-- the post IDs!
    posts = Post.find(:all, :conditions => 'body like "%pdi%"')
    mysql_found = posts.map(&:id)
    assert{ sphinx_found.to_set == mysql_found.to_set }
  end
...

The test_aardvark case runs before all the others. Sphinx likes MySQL, but Beast tests like Sqlite3. They must meet each other halfway, to ensure any changes to our fixtures immediately appear in our Sphinx index. After our fixture directive pushes our fixtures into the beast_dev database, we invoke the indexer, and wait for it to SIGHUP the searchd process.

(Suggestions for better techniques are welcome!)

The test itself finds the three posts that discuss “PDI” - whatever that is. We then challenge Sphinx by finding the posts ourselves, and compare each set of returned IDs.

`find_with_sphinx`

Now we clone the test, and modify it to use find_with_sphinx:

  def test_find_with_sphinx
    seek = 'agent of shield'
    sphinx_posts = Post.find_with_sphinx(seek)
    assert{ sphinx_posts.total == 2 }  #  <-- find_with_sphinx provides that accessor
    best_match = sphinx_posts[0]
    _2nd_match = sphinx_posts[1]
    sought = /#{seek}/i
    assert{ best_match.topic.title =~ sought and best_match.body =~ sought }
    assert{ _2nd_match.topic.title =~ sought and _2nd_match.body !~ sought }
  end

When you clone a test, sometimes you should change its assembled sample data. Test cases should diversify, to extend their coverage.

The test finds two posts. The first one has "agent of SHIELD" in both its topic and body, and the second has it only in its title.

`sort_mode`

Next, suppose our boss requests us to find posts in order of popularity. Beast ticks the Post.hits attribute each time a user hits a page, but the topics.yml file has no positive hits, so we edit topics.yml, and declare the Galactus thread the most popular, and the Agent of Shield thread second-most popular.

galactus:
  id: 6
  hits: 42
  title: Galactus is coming
...
shield:
  id: 7
  hits: 19
  title: Agent of SHIELD
...
il8n:
  id: 8
  hits: 55
  title: il8n in rails?

To order results by the hits attribute, we must overcome a missing feature in find_by_sphinx. It only sorts by weight, but we need our batch of Post records sorted by hits. This code works around those issues:

  def sort_posts_by_hits(matches)
    posts = Post.find_all_by_id(matches.keys)
    return posts.sort_by{|post| -matches[post.id][:attrs][:hits] }
  end

  def test_sphinx_should_sort_by_hits
    popularity = { :mode => :extended, :sort_mode => [ :attr_desc, 'hits'] }
    results = Post.ask_sphinx('Galactus', popularity)
    posts   = sort_posts_by_hits(results[:matches])
    titles  = posts.map(&:topic).map(&:title).uniq
    assert{ titles == ['il8n in rails?', 'Galactus is coming'] }
  end

The sphinx.conf line sql_attr_uint = hits registered hits as an “attribute” (not a searchable), so we can sort by it. But find_with_sphinx did not sort using that variable.

We have now run off the end of acts_as_sphinx’s feature set. I chose it because it runs closest to the raw Sphinx.

That ask_sphinx call sorts our code by hits, but our imaginary boss is not satisfied yet!

`SPH_SORT_EXPR`

Our boss requests that matches in a Topic.title rank higher than popular posts without matches in the title. That leads to this stray “Galactus”, in an unrelated thread, in posts.yml…

il8n:
  id: 10
  forum_id: 1  <%# rails, not comics! %>
  body: il8n in rails! Galactus!

…and this failing test:

  def test_sphinx_should_sort_by_relevant_hits
    popularity = { :mode => :extended, :sort_mode => [:attr_desc, 'hits'] }
    results = Post.ask_sphinx('Galactus', popularity)
    posts   = sort_posts_by_hits(results[:matches])
    titles  = posts.map(&:topic).map(&:title).uniq
    assert{ titles == ['Galactus is coming', 'il8n in rails?'] }
  end

The test fails with this diagnostic; the posts are out of order:

assert{ titles == ["Galactus is coming", "il8n in rails?"] }    --> false - should pass
    titles --> ["il8n in rails?", "Galactus is coming"]

To pass that test, you may need to first edit sphinx.rb, and add this line:

  SPH_SORT_RELEVANCE     = 0
  SPH_SORT_ATTR_DESC     = 1
  SPH_SORT_ATTR_ASC      = 2
  SPH_SORT_TIME_SEGMENTS = 3
  SPH_SORT_EXTENDED      = 4
  SPH_SORT_EXPR          = 5

Upgrade the test like this:

  def sort_posts_by_weight(matches)
    posts = Post.find_all_by_id(matches.keys)
    return posts.sort_by{|post| -matches[post.id][:weight] }
  end
  
  def test_sphinx_should_sort_by_relevant_hits
    popularity = { :mode => :extended, 
                   :weights => [10, 1],
                   :sort_mode => [:expr, '@weight + hits * 1000'] }
    results = Post.ask_sphinx('Galactus', popularity)
    posts   = sort_posts_by_weight(results[:matches])
    titles  = posts.map(&:topic).map(&:title).uniq
    assert{ titles[0..1] == ['Galactus is coming', 'il8n in rails?'] }
  end

To Do

Now that our tests have taught us how to operate Sphinx, we can use Extract Method Refactor to pull out the code we want to use in production.

The next Sphinx feature to explore is its query language. Using :mode => :extended, a search term of “Galactus @user (sam)” will filter out other users.

The interfaces between Sphinx and Ruby are young and growing, and these testing techniques should help them grow!

I'd love to quit my job! (sort of)

2008-03-03T17:31:50Z

UPDATE: Okay kids, now it’s 50% fantasy. It’s up to you to cover the other 50% by donating and spreading the word, after reading my proposal. Here’s hoping for the best!

UPDATE: Though my original post was 95% a fantasy, I’ve received some funding offers that have brought it down to 75% fantasy. I will be documenting any planning I’m doing towards via a wiki called RubyMendicant. If you’d like to follow this on the bleeding edge, keep an eye out on that wiki. Otherwise, if you hear an official announcement within the next few weeks, you’ll know I decided to take the plunge, and if you don’t, then it’s safe to assume this idea went the way of the dodo. If you like this idea, please spread the word through the usual means of the intertubes by sharing this post and the wiki link with others.

Here’s a crazy idea I just had, and I’m wondering what folks think about it.

People do open source for a lot of reasons, ranging from pragmatic to idealistic. Some write a patch every six months or so, others do what they can to dedicate their life to it. Though I try to have a life outside of software, I’m definitely more on the obsessed end of the spectrum when it comes to contributing to open source software.

I find myself in a rather unique situation: Single, living alone in a small studio apartment, only taking a class or two here and there, and basically living off of small contracts. It’s not that I’m not offered big gigs, or that I couldn’t go back to school full time if I really wanted to, I just find I enjoy living a simple lifestyle that lets me spend a lot of time on community oriented projects, especially Ruby stuff.

Right now, I need to do some work each month to pay the rent, and slowly save up to make sure I don’t get evicted during a slow work month. Between BTree and Madriska, I could say that I have two of the most open source friendly commercial relationships I’ve ever seen. Though I’m working on real projects with them, things that have to actually fit some sort of business need, they give me a lot of leeway to improve open source software while working on them, Ruport is pushed along heavily by this.

I could see myself doing that for a while. Working with a few different clients I trust, who in turn hook me up with interesting projects for a variety of companies in various different domains. A lot of it might be Rails work, but not all of it is. Still, in a moment of idealistic fantasy, I thought of another idea:

What if I could just do open source for a while, non-commercially?

How much would it cost for me to do at least 80 hours a month of development on software projects such as PDF::Writer, Ruport, and some other projects I wish I had the time to get my hands on?

I did the math, and the number came out low (subjective). I could meet all my expenses and save some money for about $2000 a month. Basically, if 200 people donated $60 right now, I could take 6 months off and do nearly 500 hours of work, and that’s only if I didn’t find myself obsessed with and doing extra hours on a project. I could more-or-less maintain my lifestyle that I have now, but not take on contracting projects that are either too big or too small out of necessity. Sure, this works out to be a lot lower than my contracting rate, but I could hack entirely on open source projects, maybe write some documentation and articles, and still be able to afford a class or two a semester. Sounds beautiful to me, though I’m sure it’s just a fantasy.

Indulging me for the moment, how would I remain accountable to anyone who supported such a venture? I’d make it transparent as possible. I’d record public hours, with links to changesets, tickets, blog posts, whatever. Though people would have to accept good faith (with at least a roughly outlined plan) as to ‘where I direct the time’, they’d get to see every bit of ‘where the hours went’.

What prevents this from being a total scam? You do. Though I don’t have some A-List reputation, I still make my living based on my reputation as a developer and a contractor. If I somehow totally screwed people who supported such an effort, all it would take would be enough negative feedback from the community to prevent me from getting away with dishonesty.

What would indicate a great success? If after 6 months, this all worked out, and I was interested in doing it for another 6 months, if people funded it, we’d know they actually liked what I did the first time around.

Finally, this doesn’t have to be me. It could be any old hacker you choose, someone you trust that’s working on things you’re interested in. They’d tell you how much it’d cost to have them quit their day job for 6 months, and hopefully people could pool resources. Though the open source community is kept alive by small day to day contributions, we all know the power of having someone dedicated to a project with copious free time.

I’m talking in theory, because obviously there are some complications. If I personally were to do this, I’d need to cycle out of some projects, and figure out to what extent it’d piss of the people I work with. Still, I am sort of curious, is this an idea that belongs in the trashbin, or should I open up a pledgie account for donations? :)

Maybe this is something that could be done on a trial basis, such as ‘40 hrs over 1 month’. This is something I could do without putting a close to all my work. Given that, based on my needs (not my billable rate), that’d be um… 10 dollars from 100 people?

On the one hand, this seems almost like a joke to me, a sort of ‘wouldn’t it be nice if…’. Still, if some respected Rubyist wanted to steal this idea, undercut me on the price, and ask people to start donating, would I be among them? You bet ya.

Let me know what you think. I’ve tried so hard over the last few years to find ethical and practical ways to work in open source development, and they pretty much work. But because of that, I’ve mostly ignored the idealistic ones, and this is just a shot in the dark at one of those.

Structured. Warnings. Now.

2008-02-21T02:54:49Z

The Problem

I find Ruby’s current warning system, if you can call it that, lacking. Warnings are controlled by the -W flag on the command line, and are generated via the Kernel#warn method within code. There are a host of problems with this approach to warnings.

First, warnings aren’t currently testable. With Test::Unit, for example, I can ensure that specific errors are raised in certain conditions via the assert_raise method. There is no analogue for warnings. It would be nice if there were so I could test them.

Second, there is no backtrace information provided with warnings. If I discover a warning I have to wade through the source and figure out where it was generated, because a Kernel#warn call does not provide a line number or method name that I can refer back to.¹ For large code bases that can be problematic and generally annoys me.

Third, and most significantly, with warning flags it’s all or nothing. I cannot enable or disable specific kinds of warnings. Perl, on the other hand, implements warning control through pragmas. So, for example, I can specify “no warnings uninitialized” in a Perl program and warnings about uninitialized variables go away.² With Ruby it’s off, on, or even-more-on (-W0, -W1 or -W2).

The Solution

One of the things I’ve pushed for in the past in Ruby is structured warnings.³ By ’structured warnings’ I mean a system analogous to the Error class, except that a warning would only emit text to STDERR, not cause the interpreter to exit. In our hypothetical Warning class you still have backtrace information available. And, like Exceptions, there would be a standard hierarchy, with Warning at the top, StandardWarning, UninitializedWarning, RedefinedMethodWarning, DeprecatedMethodWarning, etc. Whatever we can think of.

Such a system would allow you to raise specific warnings within your code:

   class Foo
      def old_method
         warn DeprecatedMethodWarning, 'This method is deprecated. Use new_method instead'
         # Do stuff
      end
   end

The ability to explicitly raise specific types of warnings then makes them testable:

   require 'test/unit'
   class TC_Foo_Tests < Test::Unit::TestCase
      def setup
         @foo = Foo.new
      end

      # Assume we've added an assert_warn method to Test::Unit
      def test_old_method
         assert_warn(DeprecatedMethodWarning){ @foo.old_method }
      end
   end

And, for sake of backwards compatibility and convenience, a call to Kernel#warn without an explicit warning type would simply raise a StandardWarning in the same way that raise without an explicit error type raises a StandardWarning.⁴

Unlike Exceptions you could permanately or temporarily disable warnings to suit your particular preferences in the system I have in mind. For example, in the win32-file library I'm well aware that I've gone and redefined some core File methods. When I run any code that uses win32-file with the -w flag, I get "method redefined" warnings. I don't want to see those because I neither need nor want to be reminded about them.

So, using our hypothetical RedefinedMethodWarning class, I could disable them like so:

RedefinedMethodWarning.disable # No more warnings about method redefinitions!

Or, with block syntax, we could disable a particular warning temporarily:

# Don't bug me about deprecated method warnings within this block, I know
# what I'm doing.
#
DeprecatedMethodWarning.disable{
   [1,2,3,4,5].indexes(1,3) # Array#indexes is a deprecated method
}

# But here I would get a warning since it's outside the block:
[1,2,3,4,5].indexes(1,3)

Unlike the current warning system, this would allow users to still receive other types of warnings, instead of the on/off switch we have now.⁵And, in case you were wondering why I don’t just create a ‘warnings’ library that defines a bunch of warning classes and redefines Kernel#warn, the answer is that I still can’t hook into the existing warnings being raised in core Ruby via rb_warn(), like uninitialized variables or redefined methods.

With our warning system in place we could use it for other nefarious purposes down the road, like implementing an advisory typing system. But, I’ll save that for the next post. :)

See you next Wednesday!

¹Curiously, a line number is provided by the rb_warn() function, but Kernel#warn itself does not.

²However, I do not remember if you can disable them temporarily in Perl, or if there’s a way to explicitly test them. Someone feel free to fill me in.

³http://tinyurl.com/yfko6z

⁴At this point I’m sure one of you is wondering about rescue/retry semantics. My opinion on the matter is that warnings should not be rescuable. They are meant to be informational. They are not meant to control program flow. This also lets us avoid having to worry about retry semantics. Not that anyone would retry based on a warning in practice.

⁵Yes, there would have to be a Warning.enable method as well, for those times you want to trump some third party library that has them disabled, in a “last call wins” arrangement.

Do not question assert { 2.0 }

2008-02-14T21:52:19Z

Interesting:

I asked a question on Phlip’s last post about whether assert { 2.0 } was really necessary, given that it’s mostly just assert_block from Test::Unit. I noticed this question disappeared from the post, because I guess it was offensive somehow.

Though it made it through the second time around and Phlip answered reasonably, he sent me a private email explaining that he had censored me because I apparently don’t “get” assert { 2.0 }.

Not to pick a fight, but I personally believe that blog posts that have comments turned on should only be moderated for spam and/or abuse, which my comment was neither of. If you’ve got some questions about assert { 2.0 } that you’d like to see stay online without silent censorship, feel free to post them here.

This hopefully serves as a simple reminder that we should keep up with the ‘open’ in open source, and not silence technical questions randomly.