Ruby snippet for flexible blurbing of text

Here’s a cute little method I use for extracting blurbs from text. Specify a minimum character count as the argument, and the method returns a string containing the minimum text plus whatever it takes to reach the next period, question mark, or exclamation point.

def blurb(size=75)
  reg = Regexp.new ".{#{size}}[,;:-_\\w\\s]*[\.\!\?]"
  body.slice(reg)
end

Developer dependencies in RubyGems 1.2.0 using add_development_dependency

As the release note says, RubyGems 1.2.0 now supports two levels of gem dependencies, runtime and developer. If you don’t use add_development_dependency to specify a dependency, RubyGems treats it as a runtime dep.

Google, in its questionable wisdom, tells me that there’s not much interest in this feature. Echoe is already using it, which is simultaneously unsurprising and reassuring.

Perhaps I shouldn’t find the lack of widespread acclaim strange. I suppose Ruby developers don’t hack other people’s code, they just use it. GitHub will change this, perhaps already is changing this. Case in point: I cloned a project today just to see how it works, with no intention of actually using it. The project’s tests failed because I didn’t have three dependencies: one runtime, two developer.

Super. Let’s add some RubyGems 1.2.0 typed dependencies (17 Awesome Points go to anyone who can figure out the project based on this snippet).

  spec = Gem::Specification.new do |s|
    ...
    s.add_runtime_dependency 'right_aws'
    s.add_development_dependency 'Shoulda'
    s.add_development_dependency 'mocha'
    ...
  end

Now, build the gem using whatever means have been provided, and install it with its developer dependencies.

… Wait, what? The release announcement doesn’t tell me how to do trigger the developer dependencies. Google is no help, either. And good luck finding RDocs for RubyGems.

After I started grumbling, but before diving into the rubygems source, I remembered to run gem help install. There I found this beautiful, kissable tip:

 --development                Install any additional development
                              dependencies

Here’s the information you came for: To install a gem with developer dependencies, use gem install --development

Developer dependencies should also be useful with a rake setup task, as Assaf Arkin advises having for all public projects. Somebody’s going to have to dive into the source code to figure out how to make that work.

So now I have added some niceness to a project I cloned from GitHub. It’s not much more work to fork the project, commit my changes, and shoot off a pull request. All for a project I’m not really going to use. Long live GitHub.

How to compile mdbtools on Mac OS X 10.4 and 10.5

Update: MacPorts appears to have a working port of mdbtools now.

Prerequisites

You’ll need MacPorts, the mdbtools source, and a simple patch. Use macports to install glib2, libtool, and automake:

port install glib2 libtool automake

One commenter reported that he had to upgrade version 2.5.35 of flex. I had no trouble with the version of flex included with Leopard, viz. 2.5.33.

MDB Tools source

You can get the mdbtools source from CVS, via the instructions at the sourceforge site, and my patch here.

Alternatively, use a git repo I started because CVS makes baby Theanthropos cry:

git clone git://gitorious.org/mdbtools/mainline.git mdbtools

autogen.sh && make && make install

cd into the mdbtools directory and run autogen.sh Pass any configuration args to autogen.sh, and it will pass them along to configure. /usr/local is the default prefix. The options below set the install location, enable compilation of the mdb-sql tool, but not gmdb2, the Gnome MDB File Viewer and debugger.

./autogen.sh --prefix=/users/Matthew/local --enable-sql --disable-gmdb2
make
make install

Assume that make and install work: you can test the results like so:

mdb-ver /path/to/thingy.mdb
mdb-tables /path/to/thingy.mdb
mdb-schema /path/to/thingy.mdb

How to read the Rubigen home page

You’ll need Firefox and Firebug.

  1. Navigate to http://rubigen.rubyforge.org/.
  2. While shielding your eyes, open Firebug and go to the HTML tab.
  3. Click on the body element.
  4. In the Style pane, set background-color to #000000.
  5. You may also wish to set the background-color of a elements to #000000

Compiling git on fresh Ubuntu 7.0.4

Note to self: packages I had to install for “make all doc” to work for git 1.5.3.8.

$ history | grep install

   36  sudo apt-get install curl
   41  sudo apt-get install libcurl
   49  sudo apt-get install tk8.4
   53  sudo apt-get install cpio expat
   55  sudo apt-get install zlib
   61  sudo apt-get install build-essential
   66  sudo apt-get install zlib1g-dev 
   72  sudo apt-get install asciidoc
   75  sudo apt-get install xmlto

John Galt, meet Paul Graham

From the Arc tutorial, line 372

arc> (is 'a 'a)
t

(for those who don’t get the joke, don’t worry, it wasn’t that funny. Neither was Ayn Rand.

Installing Arc on Mac OS X

Installing the Arc language on Mac OS X is trivial, assuming you have the right version of MzScheme.

Install MzScheme 352 with MacPorts

Arc requires MzScheme, version 352. The install instructions warn: “Don’t use the latest version. There is said to be some bug/feature in it that breaks Arc.” The version of mzscheme in MacPorts is 371, so we have to tweak the portfile, and the only historical versions of mzscheme I can find portfiles for are 201 and 360. There seem to have been some major build changes between 352 and 360, so I frankensteined the portfile for version 201. You can find my version here. I’m running 10.4.11 on my dev machine, and I haven’t tested anything else.

Thanks go to bitshaker.com for the instructions on setting up a local port repo.

  1. mkdir /Users/Shared/dports/lang/mzscheme
  2. Edit /opt/local/etc/macports/sources.conf to look like this:
    # To enable your local ports repository, uncomment and customize the
    # following line to point at your local dports directory
    # Example: file:///Users/landonf/misc/macports/dports
    #
    # To get macports from the macports rsync server use:
    # rsync://rsync.macports.org/release/ports/
    file:///Users/Shared/dports
    rsync://rsync.macports.org/release/ports/
      
  3. Download this portfile and copy it to /Users/Shared/dports/lang/mzscheme/Portfile
  4. Update the ports index:
    portindex /Users/Shared/dports
  5. When you run port list mzscheme, you should have an entry for mzscheme @352
  6. Install with:
    sudo port install mzscheme @352
  7. Is mzscheme the right version? Does it run?
    $ mzscheme
    Welcome to MzScheme version 352, Copyright (c) 2004-2006 PLT Scheme Inc.
    > (+ 1 2 )
    3
    (exit)
    $
      

Download Arc and run it with mzscheme

Download http://ycombinator.com/arc/arc0.tar and untar it somewhere useful on your system. ~/src/ perhaps?

$ tar -xv arc0.tar
$ cd arc0
$ mzscheme -m -f as.scm 
Use (quit) to quit, (tl) to return here after an interrupt.
arc> (+ 1 2)
3
arc> (quit)

http://arclanguage.org/install

"Tables are the [lisp] lists of html"

Paul Graham:

Tables are the lists of html. The W3C doesn’t like you to use tables to do more than display tabular data because then it’s unclear what a table cell means. But this sort of ambiguity is not always an error.

Zed Shaw:

I may never do another CSS only layout again. I’m starting to wonder how … we got sucked into that crap, especially if the only way to really get a good looking layout with CSS and div tags is with mountains of stylesheets, html, and sometimes some damn javascript.

I’m not kidding about the javascript. I’ve seen people desperately trying to force their square-peg 3 column layout through the CSS round hole resort to javascript tricks to force the columns in the right spots.…

It’s not gauche to do what’s easiest and nobody’s going run you out of Designer Town (population 100) with sharpened pitchforks and blazing torches.

Insincere apologies to Zed for the bowdlerization.

Arc, at last

Arc, a long-awaited dialect of Lisp, is finally available to the public for testing. As the man says:

“Arc is still fluid and future releases are guaranteed to break all your code. In fact, it was mainly to aid the evolution of the language that we even released it.”

Graham has been influential in encouraging the curious to try out a lisp of one sort or another. Since I first read his articles about Common Lisp and began tracking the infuriatingly undocumented progress of Arc, several new lisps have appeared. Here is wealth, and may Arc enrichen us further.

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!

The planned security model for CouchDB

While CouchDB currently has no authentication or authorization facilities, a general outline of the plans exists here:

http://incubator.apache.org/couchdb/docs/overview.html

It seems databases will have admin accounts. Full stop. No baked-in facility for user accounts. Administrators have two powers:

  1. manage design documents
  2. create other admin accounts

The Technical Overview doesn’t say, but I assume admins can also manage all documents.

Regarding non-administrative users, as I understand the plan, CouchDB will provide a rudimentary authentication delegator that accepts a login and password. “The user credentials are input to a javascript function, and the function returns a list of [reader-names] for the user, or an error if the user credentials are wrong.” I read this as meaning that the authenticating/authorizing javascript function is determined by the developer.

Write access, called “Update Validation” in the Technical Overview, is also handled dynamically by javascript: “Both the user’s credentials and the updated document are given as inputs to the validation formula, and can be used to implement custom security models…” Developers are free to implement custom authorization models, such as “author only”, where users must be listed in an author field in the document.

Read access is granted by a simplified ACL system. A CouchDB document may have a “reader list”, which specifies a list of “reader-names”. These reader-names need not correspond to user login names, so they are effectively the equivalent of groups (i.e. you can give one or more users the same reader-name). A user’s possession of a reader-name is determined by the javascript function that authenticates user logins.

Documents without a reader list are world-readable. Documents protected by reader lists are viewable only by users who possess one of the reader-names on the list. Read protection on documents applies to view results as well: “Documents that are not allowed to be read by the user are dynamically filtered out of views, keeping the document row and extracted information invisible to non-readers.”

The Technical Overview does not address this directly, but the _all_docs view must follow the same rules. That is, all unprotected documents show up in the results for all users, but protected docs only show up for users possessing the correct reader-names. The javascript functions that bind it all together will probably need administrator privileges.

Some interesting points:

  • The plans for write access allow developers to write their own authorization schemes, but the planned read access will be hard-coded to use document-based ACLs.
  • By default, document names (i.e. DocIds) are 128 bit UUIDs generated by the server. Depending on the algorithm used to generate them, these could be unguessable.
  • If the _all_docs view was not available, users would not be able to find any documents without knowledge of the (unguessable) DocIds.
  • The authentication javascript, upon success, is supposed to return a list of reader-names, but I don’t see that anything would prevent it from returning a list of DocIds.

I think we have the germ of a capability system here, even with the inflexible reader access.

Comments? Scathing refutations?

The planned security model for CouchDB

While CouchDB currently has no authentication or authorization facilities, a general outline of the plans exists here:

http://www.couchdbwiki.com/index.php?title=Technical_Overview#Security_and_Validation

It seems databases will have admin accounts. Full stop. No baked-in facility for user accounts. Administrators have two powers:

  1. manage design documents
  2. create other admin accounts

The Technical Overview doesn’t say, but I assume admins can also manage all documents.

Regarding non-administrative users, as I understand the plan, CouchDB will provide a rudimentary authentication delegator that accepts a login and password. “The user credentials are input to a javascript function, and the function returns a list of [reader-names] for the user, or an error if the user credentials are wrong.” I read this as meaning that the authenticating/authorizing javascript function is determined by the developer.

Write access, called “Update Validation” in the Technical Overview, is also handled dynamically by javascript: “Both the user’s credentials and the updated document are given as inputs to the validation formula, and can be used to implement custom security models…” Developers are free to implement custom authorization models, such as “author only”, where users must be listed in an author field in the document.

Read access is granted by a simplified ACL system. A CouchDB document may have a “reader list”, which specifies a list of “reader-names”. These reader-names need not correspond to user login names, so they are effectively the equivalent of groups (i.e. you can give one or more users the same reader-name). A user’s possession of a reader-name is determined by the javascript function that authenticates user logins.

Documents without a reader list are world-readable. Documents protected by reader lists are viewable only by users who possess one of the reader-names on the list. Read protection on documents applies to view results as well: “Documents that are not allowed to be read by the user are dynamically filtered out of views, keeping the document row and extracted information invisible to non-readers.”

The Technical Overview does not address this directly, but the _all_docs view must follow the same rules. That is, all unprotected documents show up in the results for all users, but protected docs only show up for users possessing the correct reader-names. The javascript functions that bind it all together will probably need administrator privileges.

Some interesting points:

  • The plans for write access allow developers to write their own authorization schemes, but the planned read access will be hard-coded to use document-based ACLs.
  • By default, document names (i.e. DocIds) are 128 bit UUIDs generated by the server. Depending on the algorithm used to generate them, these could be unguessable.
  • If the _all_docs view was not available, users would not be able to find any documents without knowledge of the (unguessable) DocIds.
  • The authentication javascript, upon success, is supposed to return a list of reader-names, but I don’t see that anything would prevent it from returning a list of DocIds.

I think we have the germ of a capability system here, even with the inflexible reader access.

Comments? Scathing refutations?