April 3, 2009
Continuous Integration Support for Wikis
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.In a way, wikis have been using Continuous Integration (CI) since their inception: new content, configuration settings, and even plugins are always being added to wikis. Unfortunately, no wikis that I know of have any formal support for CI. In particular, I don't see any test suites that help wiki administrators and users detect and correct broken content, configuration problems, and/or dysfunctional plugin combinations. Perhaps it's time to resolve this deficiency.-- Continuous Integration, Martin Fowler
March 20, 2009
An indicator light for gas stovetops
Leaving a burner turned on after cooking has finished is wasteful of energy and unsafe, but it is also an easy mistake to make. A harried or forgetful cook might well turn off the lights and leave the kitchen, leaving a burner going for hours. For this reason, electric stovetops have indicator lights which glow when a burner is on.However, gas stovetops have no such indicators. Adding one after the fact is likely to be difficult and might well be dangerous: modifying gas appliances is not a safe hobby for amateurs. Can we fashion a solution that is reliable, safe, convenient, etc?
March 19, 2009
Video Resources for Rubyists
There are a slew of video resources available on the web, including the fabulous offerings at sites such as www.ted.com, www.poptech.org/popcasts, http://www.jaoo.dk, and mitworld.mit.edu/browse. I would strongly recommend taking a look at these, if you have a tuit or two...However, these sites aren't focused on the interests of Ruby; so, here are some that are. Increasing the number of recorded talks is a win-win -- the community gets a record of the talks; the conference and presenter get publicity.
December 12, 2008
TWiki and Foswiki: the road ahead
TWiki has been around for about a decade. It is an "Enterprise Wiki", offering a number of features that work well in corporate environments (eg, access controls, forms, scripting, skins, webs). It is a solid and mature piece of technology, with a substantial user base.Recently, a rift in the TWiki developer community caused the project to fork. Peter Thoeny retains the TWiki trademark and web sites, but most of the developers have joined Foswiki. (For details, see the Foswiki and TWiki versions of the story.) This essay attempts to predict where things will go from here and suggest how developers and administrators can cope with the inevitable dislocations.
November 23, 2008
Merb: less magic, more engineering
As discussed in "How I arrived at Ruby", I've become a big fan of Ruby. As soon as I realized that I really, really wanted to work in Ruby (a couple of years ago, at this writing), I started looking for ways to use the language professionally. (Hobby programming is lots of fun, but it doesn't pay the bills. :-)I found that Ruby is being used in a number of contexts (eg, administrative scripts, Cocoa and Google SketchUp programming). However, Ruby on Rails was clearly the high-order bit (or maybe byte :-), in terms of industry buzz, contract and job opportunities, etc. So, I got some books and dived in.
November 3, 2008
How I arrived at Ruby
I've used interpreted languages for several decades, starting with the Lisp and command language interpreters I found on Stanford's WYLBUR (really, ORVYL) system in the early 70's. Most of my early programming, however, was done in compiled languages (eg, Assembler, C, COBOL, Fortran). I didn't get into serious scripting until I started using Unix.
November 2, 2008
Using Ruby, Perl, Python, and PHP in concert...
About a year ago, I was tasked with "tidying up" the Protégé-Frames User's Guide. This consisted of a few hundred files of rather ugly machine-generated HTML. To reduce the effort of cleaning up and maintaining the files, as well as the chance of editing errors, I wanted to mechanize the process as much as possible. That is, eliminate the repetitive and voluminous header and footer blocks, auto-generate indexes and navigational links, etc.After writing some support code, I was able to re-cast the HTML into RHTML (HTML with embedded Ruby). A two-pass generation process allowed me to collect page names and navigational information, then generate both index pages and nicely cross-linked content pages. However, that wasn't the end of the story...
Subscribe to this site's feed:
