I.NFECTIO.US

Download the lastest tarball

Extract the source

src> tar zxf PDFlib-Lite-6.0.3.tar.gz
src> cd PDFlib-Lite-6.0.3

If using 6.0.3, download this patch to the root of your extracted PDFlib-Lite source, apply the patch, and regenerate the configure script

PDFlib-Lite-6.0.3> patch -p0 < configure.in.diff
PDFlib-Lite-6.0.3> autoconf

Run the configure script. Use --help for additional options/language bindings. Your paths may be different, if you can't figure it out, switch to Windows.

On linux:
PDFlib-Lite-6.0.3> ./configure --with-ruby=/usr/bin/ruby --with-rubyincl=/usr/lib/ruby/1.8/i686-linux

On MacOSX (you built your own Ruby right?):
PDFlib-Lite-6.0.3> ./configure --with-ruby=/usr/local/bin/ruby --with-rubyincl=/usr/local/lib/ruby/1.8/i686-darwin8.5.2

If you followed these instructions, the configure script should tell you that the Ruby bindings are active.

Ruby language binding for PDFlib: yes

Build the library, (the 'make test' is required for these instructions to work)

PDFlib-Lite-6.0.3> make
PDFlib-Lite-6.0.3> make test
PDFlib-Lite-6.0.3> make install

All right, so now you'd think it would work since you've installed it. Remember when I said the Ruby bindings were broken, besides the patch to get PDFlib to realize it has Ruby bindings, you also have to manually copy the library to your Ruby's site_ruby/ directory. Optionally, you can symlink the real library found in your /usr/lib or /usr/local/lib directory.

PDFlib-Lite-6.0.3> cd bind/pdflib/ruby

On linux:
PDFlib-Lite-6.0.3/bind/pdflib/ruby> cp PDFlib.so /usr/lib/ruby/site_ruby/1.8

On MacOSX:
PDFlib-Lite-6.0.3/bind/pdflib/ruby> cp PDFlib.bundle /usr/local/lib/ruby/site_ruby/1.8

We'll cover usage of PDFlib in part II of this article which should be complete in a week or so.

One of the problems I've seen with Rails as of late is that the database schemas for the unit tests get out of sync with each other. As new features get added, some db_definitions get updated and others missed. The core group is well aware of this issue and DHH left a challenge in a ticket I created to add missing table definitions from a previous changeset.

I decided I would take him up on his challenge and went to work. I printed off all the db schemas and started comparing them with each other, highlighting where they differed. This was my first indication as to the scope of this conversion.

Since the purpose of converting over to using schema.rb is to maintain one schema for all the tests, it would be helpful if all the existing definitions were at least similar to begin with. Most of the differences can be fixed without issue. Converting a varchar(3000) field to text, or a timestamp to datetime is no big deal as far as the unittests are concerned. The biggest road block is that some tables are defined using features that don't exist in AR::Schema. Features like foreign keys, arbitrary primary keys and sequences. User-defined column definitions is yet another example where AR::Schema isn't up to the job. For example, the Postgres tests use a table with geometric field types.

I had a pretty good idea how to implement everything except for sequences, so I started coding and within a few hours had the test suite working with MySQL using schema.rb. Before I dove much further into making all the adapters work with schema.rb, I decided I better get some feedback on whether these changes I was making to Rails schema generation would even be accepted into core. Unfortunately, I didn't get any feedback from the core developers.

I think the biggest issue they would raise is whether or not the SchemaDumper would be able dump these changes. The short answer is no, which coincidently, is probably the same answer my patch would get. So I scrapped my work on converting the unittests over but will consider making a plugin which adds this functionality (and much more) for more advanced schema generation/migrations. You just won't be able to dump your schema out into a schema.rb file.

Let me know if you think this would be useful and I'll put something together.

One of the great features of Rails is its plugin system. It allows you to add new functionality to the framework without modifying the original source. On my current project, I had a need to create a CachingAutoCompleter and I wanted to do it within Rails.

Rails has a method that will work just fine, text_field_with_auto_complete. The problem lies in the fact that this method creates an Ajax.Autocompleter, whereas I need an AutoComplete object with my caching functionality. I could modify the script.aculo.us source for Ajax.Autocompletor and add my caching layer but surely there's gotta be a better way, something akin to the Rails plugin system.

Click the image below to watch a screencast (7MB) of how I accomplished this goal.

You can download the source of the CachingAutoCompleter here.

So I locked myself in my office Saturday and decided to rebuild the sorely lacking date_helper.rb that comes with Rails.

It was quite the daunting task for there were no less than 12 existing tickets for bug fix/enhancements. 17 hours later, a new date_helper was born that resolves all the issues and its quite DRY as well. Now we just gotta hope the developers get a chance to look at it sometime. Some of the fixes it contains have been around for ages so I'm assuming the core members don't use dates very often in their applications.

Heres a CHANGELOG:

• Makes :discard_year work without breaking multi-attribute parsing in AR. #1260 #3800
• Adds html id attribute to each element. #1050 #1382
• Adds :index and @auto_index capability to model driven date/time selects. #847 #2655
• Add :order to datetime_select, select_datetime and select_date. #1427
• Make scaffolding work with database time values. #2489
• Added time_select to work with time values in models. #2833 #2489
• Added :include_seconds to select_datetime, datetime_select and time_select. #2998
• All date/datetime selects can now accept an array of month names with :use_month_names. Allows for localization. #363
• Adds :date_separator to select_datetime. Preserves BC.
• Adds :time_separator to select_time. Preserves BC.

While tinkering around with the acts_as_nested_set act of ActiveRecord, I tried to build a threaded forum with it. I ran into some difficulties in that a nested_set is designed to only have one root. Obviously, in a threaded forum, each thread would be its own root. So after wasting a couple hours trying to make nested_set work, I decided to use what I consider to be the best part of Rails: plugins. "acts_as_threaded" was born 1 hour later.

While I used it to build a threaded forum in this demo, it's design was inspired by a different project at work. The acts_as_tree behavior could have worked, but I needed a better way of containing my children (much like in real life).

I've included an 11 minute screencast of building an ugly looking Threaded Forum, but the concepts are there. I can still remember spending many man hours with my programming team at Bravenet to design and build the forum product we offered there. If Rails existed back then, we could have built it in a day. (Leave me a comment on how the screencast turned out.)

Click the image to view the screencast of acts_as_threaded in use: (8 MB)

As usual, you can download the plugin here. I will submit it as a patch when I solidify it and create the tests.

If you are following the tutorial, here is the display code in full.

def display_threads(threads)
    content = ''
    for thread in threads
      content << content_tag('div',
                  content_tag('div',"* " + link_to("#{h thread.title}", {:action => 'show', :id => thread.id}, {'style' => 'color: #00f'}) + " " +
                  content_tag('span', " by #{h thread.name} · #{thread.created_at.strftime('%b, %d %Y - %I:%M %p')}", 'style' => 'font:10px tahoma;color:#666;')),
                  'style' => "margin:5px 0px;padding-left:#{thread.depth*20}")
    end
    content
  end