Thanks to Tim Golden for arranging a WebEx recording of our meeting last Thursday. It’s nowhere near as good as being there, but it does leave more pizza for the rest of us!
https://rmcres.webex.com/rmcres/lsr.php?AT=pb&SP=MC&rID=12020837&rKey=948CB787A0A2E83B
See my notes from the meeting, here.
Jonathan Linowes was kind enough to drive from “the other side of the Notch” all the way down to the seacoast to present to the New Hampshire Ruby Group on the 15th of January (note that the NH Ruby group has moved their regularly scheduled meetings to the third Thursday of the month). Fourteen members attended the meeting, which started with a round of introductions. Pizza, soda and T-shirts were provided courtesy of EngineYard — thanks!
A typical scene at a Linux user group meeting for the first ten minutes of a meeting to be consumed with the speaker struggling to get his X windows display to sync up with the projector. I’m beginning to suspect that the Ruby group equivalent is for the speaker to discover he’s packed the wrong DVI-mini-DVI-HDMI-Video-VGA adapter and no one else has the right video adaptor for his MacBook despite a half-dozen machines present. I wonder if Apple made a mistake by changing this adaptor in every model.
ReviewRamp is Jonathan’s project – a SaaS web site for a group to bring in documents, route them through their own defined process, and approve/disapprove/select documents. Jonathan offered examples such as business plan reviews, marketing plans and job applications. Designed to look as much like a desktop application as possible, ReviewRamp has a simple GUI, with templates and wizards to make it a couple of clicks to process. Under the hood, Jonathan talked about the architecture, which includes RESTful protocols, and a design intended to scale to thousands of projects, hundreds of submissions and a handful of reviewers per project. Unlike many JavaScript-only sites, RevewRamp works well with JavaScript disabled; sweetened with JavaScript enabled. ReviewRamp is publicly in beta. Jonathan presented some slides of the models: reviewers, projects, pages, subpages, fieldsets. This last was a segue into the 3rd presentation: fields are generated via metadata for each project, but the database tables don’t change for each project, so each project has virtual tables vis Jonathan’s DynamicTable design.
Next, Jonathan had a presentation on “Cucumber: How I Slice It” Jonathan had worked PHP and other languages before, was very attracted by Ruby as a new language and the philosophy of testing, testing and more testing. Unit-testing, test-driven-design, behaviour-driven-design. Jonathan also pointed us to Brandon Keepers presentation as an excellent starting point.
Jonathan showed us some of his Cucumber scripts, which include a lot of pretty cool extensions to the base, like {show me} to actually end a test by launching a browser so he could visually verify a result. It was apparent that Jonathan really took to the testing regime, adding extensions like “He” or “She” instead of always including “The current logged in user” or “the current project”
Should you use RSpec or Cucumber? Both, according to Jonathan: each has strengths and weaknesses. RSpec is more tuned to unit-test individual functions where Cucumber is more tuned to describing behavior and outcomes.
Check out
cap deploy:features
to run Cucumber on the deployed app (typically, you’d do this on a staging server, not a production server)
Shows some example Cucumber scripts. They describe in English the point of the test, and use keywords (“GIVEN” “WHEN” “{actorname}”), an action and an expected result. This is actually parsable Ruby code that defines fixtures and features and processes defined within the story runner. It’s not just a requirement, it’s actually the test as well!
Finally, running out of time, Jonathan jumped into his DynamicRecord presentation, where he had developed a method that was ActiveRecord compatible so that it could be integrated in the rest of a standard rails app, but actually queried against virtual tables that were created on the fly rather than actual tables on disk. Interesting stuff, and I’m looking forward to seeing this code pushed into OpenSource, Jonathan’s eventual goal.
Thanks to Jonathan for the great presentations, to Nick for running the presentation, to Tim for hosting the facilities and attempting to webcast the presentation, to Engine Yard for the pizza and T-shirts, and to all the members who made it to the meeting!
You can download the 3 presentations from the NHRuby site here: ReviewRamp, Cucumber, DynamicRecord, or view them online (Flash/JavaScript required) here.
Thom Holwardy points out three blog postings with some great tips on Using the Bourne Again Shell Effectively using the vi or emacs-style editing. [a late, lost post from Friday the 13th – ooo!]
Twelve folks attended the June meeting of the Central New Hampshire Linux User Group, held as usual on the first Monday of the month, but at the summer venue of the Hopkinton Public Library. Attendance was a delightful mix of regulars and new visitors.
As the crowd had some new members, I spent some time introducing the GNHLUG and its many chapters, its purpose and that upcoming events (there are many!) can be found on the gnhlug.org web site. We had a round of announcements and introductions and got into the main presentation.
Mark Boyajian has been working with Bill Sconce to demonstrate and encourage the use of Open Source software at the Lawrence Library in Pepperell, MA, strongly encouraged by the Library Director Debra Spratt. Deb has been instrumental in getting equipment set up, encouraging them to establish an information kiosk where they could feature news and posters about Open Source, as well as setting up an older machine with Linux. Mark brought along some pictures to show their setup and talked about the good reception they’ve got from attendees and the interest generated. Mark had some success stories to share and some interesting stories of the misconceptions he tried to address.
Thanks to Mark for the presentation, to Bill Sconce for providing the projector, to the Hopkinton Public Library for use of the facilities, and to all for their attendance and participation.
Larry Dignan asks, “OLPC: How do we gauge success? Will 490,000 units do?… So what’s success here? My take is Negroponte’s project is a success simply because it brought an issue to the forefront and got tech giants on board.”
I believe Negroponte’s goal was to put tools in the hands of children eager to learn to use them. Let’s hope that success continues; there’s a lot more need than the initial half-million OLPCs.