Booya: Iron Fixture Extractor 1.0.0

Booya! Announcing Iron Fixture Extractor 1.0!

I posted about this tool several months ago, when it was just a wee baby, and I'm posting again because it's grown up to become part of the bread and butter of our development process and has had many features, bug fixes, and test coverage added.

This tool has been absolutely critical in building the app we're working for building complex fixture sets dynamically from our deployed staging app and incorporating into our test cases to ensure the app operates correctly with all of the crazy data nuances.  It has allowed us to leverage our business analysts deep data knowledge and make our tests reflect reality better.

I also rewrote the README to be a bit more useful:
https://github.com/joegoggins/iron_fixture_extractor

I hope others find this tool useful...

...when your data is too complex for factories, you don't want to manually maintain fixtures, and you don't want to take the risk of missing the edge-cases resident in real data:

Iron Fixture Extractor.

Pulling the plug on Torquebox and JRuby (for now)

Our team was initially very attracted to the deployment simplification promises of Torquebox and the enterprise integration capabilities of being on JRuby.  However, after struggling to create performant and understandable production and staging environments, our team has regretfully decided to back away for now--we’re not Java dudes, and there is too much complexity that we don’t know how to deal with efficiently as Rails developers with no Java background.  

For our product launch, we’re going back to Apache/MRI/Passenger--thats the only way we’ll feel comfortable maintaining and troubleshooting the system when it inevitably goes bump in response to new user interactions and under load. We wish it weren’t the case, but without significant investment in learning how JBoss, JRuby, JDBC, and Torquebox really work under the hood, we simply can’t justify the risk of running a Rails infrastructure we don’t understand.

We still think that Torquebox and JRuby is one of the most compelling Rails deployment options out there, but right now, in our opinion, its not ready unless you’ve got the stomach to get down with Java.  In light of this, we’re going to maintain MRI and JRuby compatibility for at least the next year to be prepared to switch to Torquebox/JRuby when the time is right, when either we have cultivated the needed Java knowledge on our team or Torquebox is a little easier to use for non-Java people.  We’d love to use Torquebox/JRuby and are thoroughly bummed that its not feasible to do so now for us. Talk to us in year.

Joe Goggins, Chris Dinger: Academic Support Resources Web-Team, University of Minnesota

OS X Lion + Oracle + ruby-oci8 Gem Solution (for Ruby 1.9.3)

Note to world: The how-to install ruby-oci8 on OS X Lion described here, also works for ruby 1.9.3:


    rvm install 1.9.3 -n i386 --with-arch=i386
    gem install ruby-oci8
    # doesn't blow up

Simplified dynamic fixture extraction for ActiveRecord

I jumped on the Ruby test driven development (TDD) bandwagon a while ago...mostly...

For a while though, I've struggled to do Ruby TDD for projects involving complex data from external systems because Rails fixtures are such a pain in the ass to manage and object factories don't work because the data is too complex. The apps we build lately all seem to require the gnarly real world production data for test cases.  All of the existing solutions out there didn't quite get at what I was looking for.  For these reasons, I decided to buck up and make a fixture extraction gem for ActiveRecord.

Introducing Iron Fixture Extractor, a simplified dynamic fixture extraction solution for ActiveRecord.

Easing the pain of Shibboleth integration with Shibboleth's Lil Helper

Let's face it, you're looking at this blog post because you've been roped into migrating some crusty enterprise authentication system to the new thing higher education seems to be switching to--Shibboleth.  If you've kept up in the space of open standard authentication systems like OpenID, OAuth, or OAuth2, you might be thinking, "How hard can it be, its just another auth standard?".

Unfortunately, Shibboleth is a ugly beast of an auth standard [seemingly] designed to stab you in the face with XML violence.  Its vocabulary is confusing, its configuration is wacky, and there are a million esoteric errors that provide little value in troubleshooting--in summary, it's harder than it looks.  That's why I wrote Shibboleth's Lil Helper (slh), a tool that automates the generation of Apache/IIS Shibboleth Native Service Provider configuration and metadata files.

Over the last year, our organization (Academic Support Resources) has used this tool to migrate 20 sites, 6 Apache and IIS servers, across 4 languages and have helped at least 5 departments within the University of Minnesota get setup using SLH and migrating their own infrastructure.  So far, SLH seems to solve more problems than it creates, and most folks that have used it have been pretty stoked.

Last week I had got three more phone calls asking for help with Shibboleth and SLH--I decided I ought do something to decrease the amount of time I spend walking people through the process.  The following is my attempt at making my actual self obsolete through a digital representation of myself, :).

Using Shibboleth's Lil Helper for Shibboleth Native SP integration with Apache or IIS

1. Skim the Documentation and follow the install instructions on your development machine
2. Skim the Presentation to understand end-to-end process of integrating Shibboleth with Apache or IIS with Shibboleth's Lil Helper
3. Watch and hack along with these screencasts
   All of these screencasts tackle different aspects of integrating an Linux-Apache server with the Shibboleth Native SP and the IdP server.  Though there are some minor differences between integration with IIS and Apache, this content should still be useful for illustrating the key steps in the process. Apologies in advance for the scrappy nature of these screen casts; there are certainly not as refined as I'd like, the resolution is shabby, etc.

• 01-Intro and Shibboleth Native SP before and after enabling on web-server (6m)
• 02-Rubygem installed config.rb initialized git repo created (3m)
• 03-Configuring the SP server with shibboleth2 xml and shib_apach conf (13m)
• 04-verify and generate your metadata (5m)
• 05-integrating with target language (5m)

Please consider commenting on this post or the Github Wiki with any snags, corrections, or tips that might be useful for others when integrating Shibboleth with Shibboleth's Lil Helper.

ActiveRecord Inheritance without STI (Single Table Inheritance)

Update: The Rails community rocks! Less than 24 hours after I wrote this post and posted this issue to github, I had a solution from markmcspadden and a commit into docrails to help others understand how to get around this problem. The short answer:

self.abstract_class = true

I am writing this blog post in frustration to inform folks googling for how to do ActiveRecord without STI to give up now--it doesn't work and probably never will.

Common sense would suggest that you could bypass the single table inheritance mechanism with something like:

class SuperClass < ActiveRecord::Base

end

class Child < SuperClass

self.table_name = 'the_table_i_really_want'

end

However, this doesn't work. An invocation like `Child.first` results in SQL like:

SELECT super_classes.* FROM super_classes LIMIT 1

and an error like:

ActiveRecord::StatementInvalid: Could not find table 'super_classes'

I.e. it doesn't honor the fact that self.table_name was overridden in the child.

I've tried many other variations of this to make this work, with no luck.

Thought STI is awesome, its REALLY frustrating when you want to use inheritance without it.

I know, I know, "you should use mixins instead" is the common reply. However, this seems strange that I can't use inheritance without STI--inheritance is one of the fundamental programming constructs of an object oriented language, please, don't take it away from me and give me STI instead. Please, give me both!

For example, it would be amazing if I could do something like:

class SuperClass < ActiveRecord::Base

self.hell_with_single_table_inheritance = true

end

And have:

Child.create

work as expected.

Maybe there is a way to do this, and I don't know about it--if so, please comment here and let me know and share with the Rails community!