Ruby on Rails Portfolio After One Year

I realized today that it’s been about a year since I started working with Ruby on Rails.  I ended up putting together a portfolio of the work I’ve done with Ruby / Ruby on Rails in the last year.  Here it is!

GitHub Projects

Database Spider UI:
Article: Day 1: Spider Database Navigator Website

Dynamic Server-Side Property Grid
Article: A PropertyGrid Implemented in Ruby on Rails

Where are my Facebook Friends:
Article: Where In The World Are My Facebook Friends?

Basic Authentication (not using Devise):
Article: User Authentication in Ruby on Rails

Other articles on Ruby / Ruby on Rails:

Comparing Ruby and C# Performance

Function Composition, Function Chaining, Currying, and Partial Functions / Application in F# and Ruby

C# and Ruby Classes

Ruby on Rails Websites

personal projects implemented in Ruby on Rails

websites developed for my clients:

(these websites use significant pre-existing work from the open source community as well as other team members, so I certainly cannot take full credit for them, but I have made significant contributions to them):

Why you should never use MongoDB

An excellent real-life story of actual experience with MongoDB:

I recommend that anyone considering a “document-based” database read this and thoroughly understand what Sarah is talking about…

…because the world IS relational.

This rebuttal was brought to my attention:

Personally, I find this statement: “And yes, this is a somewhat relational model.” amusing.  Well, since it’s relational, doesn’t a relational database seem like the right tool?  And what does “somewhat relational” mean?  It either is or it isn’t, in my opinion.  There’s no “somewhat” here.

A PropertyGrid in Ruby on Rails

Using JQuery UI and minimal Javascript to create a dynamic server-side property grid editor control that can be initialized in a fluid programming style or with a minimal DSL.

Get the code: git clone


  • Collapsable groups
  • Support fo jQuery UI controls
  • Easily extensible to support new control types
  • “Fluid” programming of grid groups and properties
  • Don’t like a “fluid” approach?  A minimal DSL is provided
  • Minimal javascript, most of which is auto-generated
  • Control is generated on the server-side

screenshotI needed a general purpose property grid editor that supported some fancy things like date/time pickers, color pickers, etc., based on record fields known only at runtime (this is ultimately a part of my next installment of the “Spider UI” article series.)  There’s a snazzy Javascript-based property grid here, but I wanted something that was minimally Javascript and more Ruby-on-Rails’ish.  I also wanted a server-side control that could interface well with record field types and that would dynamically generate the grid based on schema information like table fields.

I have put together is a set of classes to facilitate building the content of a property grid control on the server-side.  You will note that I opted for actual classes and a “fluid” programming style, but if you don’t like the way the actual implementation looks using a “fluid” technique, I have also put together a very minimal internal Domain Specific Language (DSL) that you can use instead — basically just method calls that hide (using static data) the internal management of building the property grid instance.

As in my previous articles, I will be using Sass and Slim scripting for the CSS and HTML markup.

…  The rest of this article is forthcoming!

Making A Difference

From July – October this year I was working on taking a Brazilian open-source crowd funding (or “crowd sourcing”) application and tailoring it for a specific niche for a group out in Denver CO. Among many of the changes, we also added a non-monetized way of “funding” a project, namely skills or resources, the idea being, if you have some skill (like website design, graphic design, got a tractor for plowing some earth? — stuff like that) you could participate in the project as well. And being localized to Denver, the idea is to connect people directly to the projects in their neighborhoods.

We started with 3 seed projects, and one of them has exceeded its funding request! The interesting thing for me is, I’ve worked in this industry for 30+ years, and while I’ve done some really cool things, pretty much everything I’ve ever done has been “a job.” So it was with this project as well until this one project got its funding. It got me to sit back and I had this “wow, I’ve done something that allows people to come together and do something for others” feeling. It’s quite an interesting feeling, to work on something that facilitates other people’s activities and dreams, rather than just working on an “end product.”

The project that got funded is here if you want to take a look. I know this yet one more crowd sourcing site of several (kickstarter and indiegogo are probably the most well known) but it has been really amazing to put this together and see something fruitful actually come of it.  I can only imagine how neat it will be when there are (potentially) hundreds of these local projects going on in Denver.


TinyTds::Error: No column name was specified for column 2 of ‘__rnt’

This is an obscure error that I encountered today and about which I found very little information.  In my particular case (see my previous post regarding the Spider Database UI), I encountered this problem as soon as I added a feature by which selected records of the current user table could be used to qualify the records shown for the parent and children relationships.

What this means is that, previously, I was simply showing all records of the parent and child relationships, which was being loaded in the index function of the table viewer controller:

@parent_dataset = load_fk_tables(@parent_tables)
@child_dataset = load_fk_tables(@child_tables)

Now however, I was qualifying the parent and child tables based on the (optional) selected records of the selected user table:

@parent_dataset = load_fk_tables(@parent_tables, self.parent_qualifiers)
@child_dataset = load_fk_tables(@child_tables, self.child_qualifiers)

The error in the subject line of this post began occurring at this point.  Interestingly, as soon as I forced the record to load through any means, such as:

records = DynamicTable.where(where).paginate(page: page, per_page: items_per_page)


d = records[0]


records.each do |record| q=5 end

The problem went away.    I am actually completely at a loss to explain why lazy-loading is the issue — digging into the will_paginate and active_record source code, I didn’t find anything that would particularly lead me to understanding the issue.  However, I do know that forcing the load solved the problem.  Possible explanations:

  1. This may simply have to do with having more than one set of tables set up for lazy loading.  I notice this problem occurs only when I have multiple tables in the “lazy load” state being referenced by the view.
  2. This may be related to some interaction with will_paginate, as it seems that the offending query deals with selecting rows within a page range and also involves hidden fields (like ‘__rn’) that will_paginate adds to the query.
  3. It also has something to do with TinyTds.  There are some interesting posts about this error and TinyTds, but they’re not related, as far as I can tell because there are no un-aliased fields.  None-the-less, because TinyTDS is emitting the error, it is clearly suspect somewhere in the process.

Regarding number 3, here’s the query it’s trying to execute:

SELECT TOP (7) [__rnt].* FROM ( SELECT ROW_NUMBER() OVER (ORDER BY [Person].[StateProvince].[StateProvinceID] ASC) AS [__rn], [Person].[BusinessEntityAddress].* FROM [Person].[StateProvince] ) AS [__rnt] WHERE [__rnt].[__rn] > (0) ORDER BY [__rnt].[__rn] ASC'

You will note that __rnt is definitely not defined!  So somewhere in the lazy load process, __rnt gets lost.

Hopefully this post will provide a clue to others that encounter this bizarre problem.






Ruby on Rails, SQL Server, and dynamic “spider” Database Navigation

I’ve posted an article on The Code Project, which is the start of a web-based “database spider UI” — written in Ruby on Rails!  The implementation of this first cut accomplishes:

For the website:

  • Connect to SQL Server (yes, Ruby on Rails can connect to SQL Server.)
  • Use a separate database for session and other metadata store, leaving the database we’re connecting to for navigation untouched.
  • Rather than physical Models for each table, implement a dynamic Model.
  • Dynamic discovery of user tables and foreign key relationships by inspecting the database schema rather than relying on the Rails application schema (which would be otherwise generated from concrete Models backed by physical tables.)

For the user interface:

  • Selecting a table from a list
  • Viewing the data for that table
  • Selecting parent and child tables to navigate to
  • Selecting records to qualify navigation and display of parent/child records
  • Pagination
  • Breadcrumb trail of parent/child navigation

A tiny screenshot (see the article for a larger screenshot):