I’ve splintered my blogging efforts into a few different places.

You can find Ruby stuff on O’Reilly Ruby. I’ll also be posting by proxy for Google Summer of Code students and providing additional commentary about GSoC under another O’Reilly account.

I announced before that Ruport has its own blog, which will be the home of most random news about Ruby Reports for the forseeable future.

Finally, I’ve decided to start up a personal blog for musings on things that I can most nearly label “Not necessarily ruby”. There will be a mix of topics there, but it’s officially become my blogging junk drawer. We’ll see how long the novelty lasts.

Anyway, the original purpose of this blog was for the company I never started. I think I might actually start a company now, but it’ll likely be under a different name. So goodbye Stone Code, it was real, son.

Following Mike Clark’s idea:

[sandal@metta ~]$ gem list|grep '^[a-zA-Z]'
activerecord (1.15.1, 1.14.4)
activesupport (1.4.0, 1.3.1)
builder (2.0.0)
camping (1.5)
cgi_multipart_eof_fix (2.0.2)
color-tools (1.3.0)
daemons (1.0.4)
fastercsv (1.1.0)
fastthread (0.6.3)
firebrigade_api (1.0.0)
gem_plugin (0.2.2)
highline (1.2.6)
hoe (1.1.7)
hpricot (0.4)
mailfactory (1.2.3)
markaby (0.5)
mechanize (0.6.4)
metaid (1.0)
mime-types (1.15)
mocha (0.4.0)
mongrel (1.0.1, 0.3.13.4, 0.3.13.3)
mysql (2.7)
pdf-writer (1.1.3)
rake (0.7.1)
rc-rest (2.2.1)
rcov (0.7.0.1)
RedCloth (3.0.4)
rspec (0.7.5.1)
rubyforge (0.4.0)
rubygems-update (0.9.2)
ruport (0.8.99, 0.8.10)
ruport_hello (0.1.0)
ruport_invoice (0.1.0)
scruffy (0.2.2)
sources (0.0.1)
sqlite3-ruby (1.2.0)
tinderbox (1.0.0)
transaction-simple (1.4.0, 1.3.0)
xml-simple (1.0.10)

You may notice almost all of my list consists of Ruport or Camping dependencies. Coincidentally, 95% of my work is using these two systems. Still, it’s a little sad. It’s like I’m the kid who doesn’t get out of the house enough… oh wait…

We’re now using blog.rubyreports.org for the Ruport blog, so it makes most sense for the Ruport News to live over there.

This blog is likely to change face over the coming months, returning to it’s original purpose of being a sort of business practices, hacks for jobs, and personal research oriented weblog.

So you’ll see code from work I’m doing or at least things centered around it, stuff from my explorations in Haskell, and some talk about software practices and ideas.

For straight up Ruby, you can always come see me on O’Reilly.

It is time to usher in the new year with another issue of Ruport News. Today we will talk about a big logistical change, a recently held developers’ meeting, a new addition to the growing repository of Ruport usage guides, and other developments that are just around the corner.

The mailing list is moving to Google Groups! Frequent readers of the old mailing list will have known this already, but if you are feeling left out of the loop, do not despair. The new mailing list’s email address is ruby-reports at googlegroups dot com. If you have not done so already, you might want to head to the new signup page. For details on the move, check out the archived moving thread. The new home of the mailing list should provide for a permanent archive and easy access by more unwitting, would-be Ruporters.

As promised, let’s talk about the Ruport developers’ meeting. The virtual meeting took place on January the 8th, in channel #ruport, on the Freenode IRC network. Some of the topics of discussion included: the mailing list move, a memory leak fix in hash_record, general project management philosophy, and ideas for the new parser. For more details, check out the meeting summary or the complete meeting transcript.

Another topic of discussion at the developers’ meeting was James Healy’s work on Ruport’s formatting engine. In the same vein, James has written a formatting how-to guide that can also be accessed from the growing repository of Ruport tutorials.

Looking to the future, here are some clues as to what is in store for early February. Ruport 0.8.0 will be coming with a brand new generalized parser, new formatting hacks, refinement of the data model, and improvements to the Rope code generation tool. For more information, please refer to the frequently updated development roadmap.

-Dinko

Please abandon the old mailing list as if it were a sinking ship full of ghost pirates, and join us on our new google group.

This also means that users of Ruport who do not wish to receive email but want to be recognized as a user can join with the “No Email” option and also that our archives will be a lot easier to search now.

Hooray!

So today I took my first steps into the Haskell waters and I’m glad I did. Of course, I couldn’t get two steps into a tutorial without seeking out a test framework. Turns out there are two popular ones, QuickCheck and HUnit. The former looks like it has killer generalized assertions based on type checking, but the latter looks a lot like Ruby’s Test::Unit and is included with ghc, so it was the obvious choice for a first step.

But the instructions telling me to fire up an interpreter to get tests running seemed way too smarmy for me. After a little discussion in #haskell on Freenode where various kind folks helped me shake off some n00bness, I was able to turn this HUnit example from <shapr> into a simple, generalized test runner.

Here it is:

module TestRunner where
import Test.HUnit
import System

run t = do
  c < - runTestTT t
  putStr $ show c ++ "n";
  let errs  = errors c
      fails = failures c
  System.exitWith ( getCode errs fails )

getCode errs fails
  | fails > 0 = ExitFailure 2
  | errs  > 0 = ExitFailure 1
  | otherwise = ExitSuccess

I just stuck this in ~/lib and made a little alias for ghc to make it a little more friendly to my laziness


alias ghc='ghc -i$HOME/lib --make -o a.out'


Then the world’s dumbest test suite can easily be run directly, more or less:

import Test.HUnit
import TestRunner

test1 = TestCase (assertEqual "Simple" 2 2)
test2 = TestCase (assertEqual "Simple2" 2 1)
tests = TestList [ TestLabel "test1" test1, TestLabel "test2" test2 ]

main = TestRunner.run tests

The first test passes, the second test fails. Whoo!

So as usually is the case when I’m entering a new neighborhood, I might be missing out on all sorts of better paths that residents are well aware of. So if this seems crazy to Haskell gurus, please do let me know, but I find it’s a fun, good first step for learning how to work with the language.

Great thanks to the many folks who helped me out in #haskell on Freenode!

This process works, and it seems to be easy enough for my clients that I don’t need to help them ‘install’ the camping application I’ve been working on for them. The problem with it, is it feels pretty hackish.

But for those who are in the early stages of a project that is destined to run as a local application eventually, and want to get something running right away, you can try this recipe out.

Essentially what you do is:

Build a self extracting archive that’ll put all your dependencies in the right places under C:\ruby

I found the easiest way to do this is do a fresh install of the Ruby One Click installer, and then just notice what’s changed.

Take your application folder and just store it alongside the dependency installer.

Add two files to your application folder if you need clicky clacky support.

1) A file that executes the camping server, be it mongrel or webrick. I also add ruby to the path here manually (and temporarily) incase it’s missing.
2) An html file that redirects to the right url to get to the running server.

I called these client.html and server.cmd in my distribution.

Take your application folder and the dependency installing archive and stick that in a self extracting archive too.

Now you’ve got a process that looks like this:

1) User installs the one click installer for ruby
2) User clicks on your ‘installer’
3) User clicks on your dependency installer
4) User clicks server.cmd
5) User clicks client.html

Now, i’m not pretending this is a ‘real’ solution. I was just pretty amazed I could get Camping+Mongrel+Ruport+SQLite3 working in something that in essence, requires 5 clicks.

Now I’ve heard some good things about rubyscript2exe, and theoretically, with gems I should be able to just automate the gem downloads (but multiple selections for C extensions thwarted me there). This just turned out to be my solution when I realized that I couldn’t move on with this project unless I could get something running on a remote machine I had no access to. If you’re in a similar situation, it might work for you.

If you’ve got a better solution (and I’m sure there are a few out there), come let me know!

What I’m really looking for is to be able to get something similar to rubyscript2exe specialized for camping. If I end up coming up with something robust, I’ll release it, so anyone with ideas, please do share.

Welcome to the holiday issue of Ruport News. Two Ruport releases have gone out since the last News post, so we have some catching up to do. In a brief glance backward, we will talk about the Ruport roadmap to 1.0. A recap of changes in Ruport 0.6.1 will follow. Finally, we will go over the improvements in the recent 0.7.0 release.

The arrival of Ruport’s roadmap to 1.0 was foreshadowed in Ruport News 8. As promised there, the roadmap was released around Thanksgiving. The roadmap can be found in a Ruport wiki entry. Since its release, the roadmap has undergone a minor update. For details on the change, refer to the related Ruport mailing list thread. Unfortunately, it does not seem possible to read thread comments from thread permalinks. To do that, you should go to the main Gmane Ruport mailing list page and find the thread entitled “Looking for help with a Roadmap decision.”

At the beginning of December, Ruport 0.6.1 was released. The performance enhancements discussed in Ruport News 8 were included in this release. Namely, Groupable was made faster, and Query made to use less memory. In addition, a bug in the table loading method was fixed. Test coverage was increased as well, and API documentation was reformatted and extended.

And finally, the big 0.7.0. Released only a few days ago, it boasts a brand new formatting engine. The new system aims to make formatting simpler and more flexible. We hope to find out if this goal has been achieved, so any and all feedback would be appreciated. Feedback should be directed to the Ruport mailing list. You can lurk on gmane or sign up to make a post. Many of Ruport’s plugins have gained some new features in 0.7.0, and there has been a premature (but welcome) spring cleaning of the internals. The invoice engine has been removed, in hopes of being re-released as an extension soon. For a temporary solution, refer to the related Ruport mailing list thread. And with that, this issue of the News is almost last year’s news. Keep safe and enjoy your holidays.

-Dinko

Thanks to Gregory Gibson of BTree Technology, we’ve got ourselves a shiny new Mac Mini Core Duo. We’ll be using this along with Parallels Desktop to build a set of testing environments for Ruport as it heads towards 1.0, which should help improve stability across platforms.

I’ve got to say, things have changed from OS X.3 to X.4
Aside from the lack of an integrated package manager (sorry: fink, darwinports, and MacPorts do not count!), I’m actually fairly comfortable popping around with a little help from QuickSilver.

It seems like since I’m a Rubyist, I should at least know how to use TextMate, so that’s on the plate as well. Rest assured vim bigots, I am only planning on learning enough to a) be functional with it as an editor and b) steal ideas to bring back to vim with me

But this is really a sweet deal for us. Providing Parallels lives up to the hype, our clients and also folks who are using free software we’re working on will be happy to know that we can get a closer glimpse of how our stuff is working in their environment, and not just hope everything works as well as it does in my finely tuned ArchLinux setup.

So, thanks again to Mr. Gibson and BTree for continuing to support Ruby Reports, it’s really a big part of what keeps us going!


>> 5475+4553
=> 10028


Between the file downloads and the gem downloads, we’ve now surpassed 10k since our first release 15 months ago.

Our 23rd release, 0.6.1 seems to be what did it.

Watch out One-Click Installer for Ruby, we’re coming for you.