Recently, on my personal programming blog, I expounded on some concerns I have with Bundler. These concerns have their origin in my work on POM and related ProUtils projects such as Syckle and Box. These projects utilize requirements information. If Bundler becomes widely used outside of Rails development, and it seems it might, then it is imporatan that I figure out how to best fit Bundler into the POM's design.

Of course, as with any new technologies, my initial take on Bundler held some false assumptions, and thus some over-blown concerns. However, I still see some issues with the design. Nonetheless I figure most issues will be worked out in time --and if not, and the project is fundamentally flawed in some fahsion, then it will eventually wither, and be replaced by something better.

A big change is coming to the next release of POM, and in turn all the tools that utilize it, including Syckle, Roll, Box and WebMe. So big is the change, in fact, that it requires a mojor verison bump. So expect the next release ov POM to be 2.0. In itself the change is straight forward... Instead of the previous use of a meta/ directory for storing project metadata, POM will now use two YAML files: PROFILE and VERSION.

With regards to POM, the most cumbersome issue I have had to struggle with over the course of its long and somewhat painful development, is the question of configuration storage. You see, many years ago I hit on the idea of using the file system itself as a "hash" for heirarchical storage. In other words, instead of using a YAML or JSON or INI file, POM could use the directory structure.

There are a variety of test-double/mocking libraries available for Ruby. Mocha is probably the most well known. RSpec comes with it's own mock library. I beleive FlexMock is the venerable older gentleman on the block. And there are plenty of alternatives such as rr and stump.

I myself have been toying with an implementation, with a goal of maximizing ease of use and implemetation overhead. In my pursuit I discovered something very interesting: Ruby doesn't necessairly need a test-double library.

Per the usual for a developer with too many projects on their hands, I am constantly on the lookout for new tools to make my work easier. Being the kind of person who likes to "do it themselves", I often end-up writing those tools. Recently I endeavored to make my life a bit easier by automating, at least in part, my project's version numbers. I thought, while only a partial help, that if I added a git post-commit hook that bumped the patch number one, at the very least I could push out patches without ever having to fuss with adjusting the version number manually.

Prompted by the disocvery of improper use of relative require in a number or Ruby project's executables, my last post dicussed why and when to avoid using relative require. To summarize, there are two broad reasons to avoid relative loading. The first is simply YAGNI. In most cases you simply don't need to do it. Your script is on the $LOAD_PATH and all that is needed is the normal require 'mylib/mydir/myfile' to load it. The second, and up until today I felt the more important concern, is conformance to the File Hierarchy Standard. While there is plenty of room to use relative requires and not tread on the FHS, it is easy enough to run afoul if one is not careful and aware of the issues. Such was the case with the executables.

Recently I posted a light diatribe against improper use of relative requires in Ruby programs. I pointed-out a bit of code, I recently came across, that added a relative path to Ruby's $LOAD_PATH from within a bin/ executable.

Syckle, which until recently was called "Reap", is the oldest component of the ProUtils collection and has been through a number major redesigns. The first version of was essentially what Hoe is today albiet with fewer tasks. Likely to the dismay of any early followers of the project, the second version warped into a Rake clone. Seeing no point to a slighly improved rewrite of Rake, the third version made a complete u-turn and had every task as a separate script utilizing a special DSL. Each task script could also call on other scripts simply by name (via method_missing). This design was very interesting, but was lacking in certain respects (largely in maturity), so the penultimate version evolved these tasks into a set of stand-alone executables patterned after git's "many small commands" design. This worked well, but it proved difficult to learn the proper usage and sequence of usage of so many tools. This natually led to the current version whereby all tasks belong to a life-cycle, similar to Maven. The user triggers a cycle-phase and all prior phases are run through until the requested cycle-phase is reached.

Okay so we tried the Jekyll --the static site generator supported by GitHub. Jekyll is a good static site generator with nice blogging features. I give it a lot of credit. But I have taken a stab at a static site generator myself more than a few times and with some inspiration from Jekyll I fianlly was able create a system that is worth the effort to code. I dubbed it Brite (short for Web Write).

While there are still some features to add, this site demonstrates the fruit of my labor. I won't terry on with the details here. You can read them on the Brite website. But I will at least say, for the first time I am fully satisfied with with a static site generator, enough so to use it for all my future project sites.