Obviously, the first thing you need to do is make sure you always have access to the current account as keyed by the subdomain. This means a before filter on any controller that runs under the subdomain that loads in your account. The idea is that once you load the account, you never have to pull it from the database again:
class AccountSubdomainController < ApplicationController
before_filter :current_account
protected
def current_account
@account ||= params[:current_account] ||= get_account_by_subdomain
params[:user][:current_account] = @account if params[:user]
@account
end
def get_account_by_subdomain
Account.where(:subdomain => request.subdomain.downcase).first
end
end
If you’re not using an account-specific subdomain, just modify this to pull out the account from the URL or something.
Once we have our account, we need to inject the current account into the params to keep it over the whole request. We also need them in the users subhash if authentication is currently being run. That means you need to define current_account in your authentication keys, either in the devise.rb initializer or on your model’s devise invocation:
config.authentication_keys = [:email, :current_account]
This tells devise to use not only the email request parameter but also the current_account parameter to look up users. Now we just need to override the lookup method for authentication:
def self.find_for_database_authentication(conditions)
acct = conditions[:current_account] || Account.where("users.email" => conditions[:email]).first
acct && acct.users.where(:email => conditions[:email]).first
end
That’s sufficient for the initial login, but if you stop there your app will authenticate correctly, store the user in the session, but never be able to pull it back out. We need to a way to get to the params to pull that current_account out and provide it to the user model for a proper lookup. This is where shit gets a little hacky, because we’re going to create an initializer that overrides how Warden does something:
class Warden::SessionSerializer
def deserialize(keys)
klass_name, *args = keys
# add current account into mix so we don't have to pull it from the db again!
args << params[:current_account] if params[:current_account]
begin
klass = ActiveSupport::Inflector.constantize(klass_name)
if klass.respond_to? :serialize_from_session
klass.serialize_from_session(*args)
else
Rails.logger.warn "[Devise] Stored serialized class #{klass_name} seems not to be Devise enabled anymore. Did you do that on purpose?"
nil
end
rescue NameError => e
if e.message =~ /uninitialized constant/
Rails.logger.debug "[Devise] Trying to deserialize invalid class #{klass_name}"
nil
else
raise
end
end
end
end
That’s the link between the current_account in the request and our user model. Now we just need a way to use it, and instead of using self.find like that old gist, we’d be better off implementing this on our model:
def self.serialize_from_session(*args)
key, salt, account = args
single_key = key.is_a?(Array) ? key.first : key
account.users.find single_key
end
You should be all set now. Note that this hack has not been well tested, but I thought it was high time somebody shared a different approach. Please advise if you have criticisms or a better way.
]]>It is kind of crazy to think about everything that’s happened since then. I wrote a content management system that runs a major newspaper site and handles millions of hits a month. I went to Germany again and had a great time with Tasha and my host family. I got involved in Occupy Richmond which was a life-changing experience. My essay Let the Free Market Eat the Rich! was published in the new Markets Not Capitalism compendium. And so on.
I have lots of things I want to write about – most pressingly to flesh out my ideas on political correctness culture and how it distracts the Left from building a genuinely egalitarian society. So stay tuned!
]]>But what if you want to reorder the embedded documents? Should be simple to sort an array. Our ODM - Mongoid in this case - would never represent the embedded collection as an array and not let us work with it as an array, right?
class Container
include Mongoid::Document
embeds_many :items
end
class Item
include Mongoid::Document
embedded_in :container
field :title, :as => String
end
c = Container.create
c.items.create :title => "first"
c.items.create :title => "second"
>> c.items
=> [#<Item _id: 4dd2d971322bcdab7c000003, title: "first", _id: BSON::ObjectId('4dd2d971322bcdab7c000003'), _type: nil>, #<Item _id: 4dd2d981322bcdab7c000004, title: "second", _id: BSON::ObjectId('4dd2d981322bcdab7c000004'), _type: nil>]
>> c.items.reverse!
=> [#<Item _id: 4dd2d981322bcdab7c000004, title: "second", _id: BSON::ObjectId('4dd2d981322bcdab7c000004'), _type: nil>, #<Item _id: 4dd2d971322bcdab7c000003, title: "first", _id: BSON::ObjectId('4dd2d971322bcdab7c000003'), _type: nil>]
>> c.save
=> true
>> c.reload.items
=> [#<Item _id: 4dd2d971322bcdab7c000003, title: "first", _id: BSON::ObjectId('4dd2d971322bcdab7c000003'), _type: nil>, #<Item _id: 4dd2d981322bcdab7c000004, title: "second", _id: BSON::ObjectId('4dd2d981322bcdab7c000004'), _type: nil>]
OK, so not that easy, but maybe this means we just need to set the new array explicitly.
>> c.items = c.items.reverse
=> []
Yikes. So we can treat it as an array as much as we want - as long as we don’t need to persist it. Keep in mind this is a MongoDB trait, not a failing of the ODM per se (though one would expect the ODM to help us out here!).
So what do we do? Well, I worked around it by explicitly rebuilding the array of embedded documents:
>> reordered_items = c.items.reverse
=> [#<Item _id: 4dd2e0b7322bcdae0d000002, title: "second", _id: BSON::ObjectId('4dd2e0b7322bcdae0d000002'), _type: nil>, #<Item _id: 4dd2e0b6322bcdae0d000001, title: "first", _id: BSON::ObjectId('4dd2e0b6322bcdae0d000001'), _type: nil>]
>> c.items.clear
=> []
>> reordered_items.each { |i| c.items.create i.attributes }
=> [#<Item _id: 4dd2e0b7322bcdae0d000002, title: "second", _id: BSON::ObjectId('4dd2e0b7322bcdae0d000002'), _type: nil>, #<Item _id: 4dd2e0b6322bcdae0d000001, title: "first", _id: BSON::ObjectId('4dd2e0b6322bcdae0d000001'), _type: nil>]
>> c.reload.items
=> [#<Item _id: 4dd2e0b7322bcdae0d000002, title: "second", _id: BSON::ObjectId('4dd2e0b7322bcdae0d000002'), _type: nil>, #<Item _id: 4dd2e0b6322bcdae0d000001, title: "first", _id: BSON::ObjectId('4dd2e0b6322bcdae0d000001'), _type: nil>]
This works for me, but it’s not very elegant. Any problems with this approach? Feel free to let me know.
]]>The tests are there but nominal; I’d love to see them fleshed out. I also had some ideas for making it cooler; for example, I keep an array of an object’s descendants in the object, allowing me to hierarchically order objects. This opens up some novel means to simplify how I implement the parent and children accessor. Imagine this:
field :ancestry, type => Array # contains ids of all ancestors including self, already exists
# but instead of a parent_id accessor
def parent_id
ancestry.at(-2) # the parent can be fetched from the ancestry list
end
This also allows all descendants of a given object to be easily fetched - if the id shows up in the ancestry, return it! It’s this kind of out-of-the-box thinking that has really endeared MongoDB to me. I hope you can benefit from this and help me improve it. Or help with greedy. I’d love to get said help at CVREG’s upcoming Why Day hackfest.
]]>Right now I can’t figure out how to post information to the Google Reader API. Anybody who could help me figure out why my code isn’t working is welcome to fork and submit pull requests - I know I’m missing something simple. When that feature works, you’ll be able to use greedy to change the state of items to “shared”, “read”, “unread”, etc. However, the code that merely consumes feed items is ready for action.
Greedy was extracted from another project that went up today, although not for the first time: leftlibertarian.org. Now that the Google Reader API stuff has been successfully extracted, the next step is to make the code that runs leftlibertarian.org into something anybody can use to publish their Google Reader stream as a website. Hopefully, that won’t be too long in coming…
]]>Michael at one point talked about the expense of 100% code coverage for tests, instead recommending we test the parts of the code that change the least and are most important. Ugly code in legacy projects has utility, he explained, and untested code is a rational response to churn. Afterwards, Glenn discussed software development in the context of engineering principles from older, more established disciplines like structural engineering, finding areas of similarity, analogy, and abject difference. However, his testing point compared experiments in code to experiments in more physical engineering fields, remarking on how relatively cheap tests are for us. I suppose the common thread I found concerned the emphasis on cost: that what it means for us to do our job well is to do it effectively, and not subordinate our conscience and creativity to a mechanical process.
For some background, I’ve been practicing behavior driven development for a year or two. I love the confidence that testing gives me, independent of the value to the client. Verifying that my code works is fine and all, but what lets me sleep at night is the assurance derived from approaching a problem in a rational, systemic manner. By moving in small chunks and expressing problems in terms I understand well enough to programmatically recreate, I ground myself in a real comprehension of the system I’m building at the most relevant level and stage. I avoid the confusion of jumping ahead, thinking too large scale or minutely, or making unwarranted assumptions that come back to bite.
But I’ve found there are definitely times when testing first is the wrong approach. Remember: testing is supposed to reinforce your understanding of the problem. But what happens when you fundamentally don’t understand it? When you first encounter the project, you don’t necessarily have expectations or any way of identifying what a successful outcome is. Test first is supposed to get you to think about these things, but there’s no substitute for writing and running code.
Experimentation, trial and error, and playing around are important discovery mechanisms that give us the understanding we then apply to more rigorous processes. Spending time writing tests that do nothing but reinforce the fact that you don’t know what you’re doing is stupid. I’ve found that you have to think carefully about what you’re expecting your tests to actually accomplish for you, as you can dig yourself down rabbit holes needlessly by stressing form over function.
Similarly, as Feathers pointed out, even well understood requirements and algorithms often cost more to test than its worth. Code that changes often can cause test churn that burns up effort needlessly. And often we write large swaths of code that, while useful, just isn’t that critical to the success or failure of the project. Given these tensions, 100% coverage may not simply be an unreasonable goal - it may be positively wasteful.
Again, the problem is deeper, as Glenn pointed out in his talk. Historically (and surprisingly in spite of salient warnings as early as the 60’s) “Software Engineering” with capital letters has been biased towards a philosophy of formal, defined process models that demand predictability and reproducibility. Although behavior driven development may seem to encapsulate this philosophy, remember that when we’re dealing with behavior we’re not necessarily realizing mathematical precision at the level many engineers would expect. Accuracy is important in some engineering contexts, but flexibility can sometimes trump it.
A final thought that I consider my unique contribution to this discussion: if you do test first, consider that your tests may be disposable. It’s great that you are using tests to drive the development, and building a test suite imparts tremendous satisfaction as you pile on more and more features. But just because a given test is useful to writing the code doesn’t mean it’s useful for verifying the project’s success. It may in fact be, but that should be a demonstrable standard - don’t let your personal satisfaction detract you from the big picture goal of the project.
100% code coverage is increasingly seen as superfluous because areas of code churn are just a fact of software development. You may find the changes are so targeted and frequent that more exploration and manual play pays off more than working out programmatic unit tests. Also, why wouldn’t your test suite have cruft just like your source code? Perhaps your legacy tests reflect an emphasis on certain requirements that are just too rigid. In that sense, paring down the tests-as-specs is entirely consistent with the project’s interests as it reflects the actual state of the project. Tests out of sync with current requirements are often worse than no tests at all.
Conventions and best practices are no excuse to forget our responsibilities to the client’s budget. The point is not to adopt a rule that tests are no longer important to maintain; rather, avoid blindly following any rule for its own sake, especially when you’re being paid to use your brain. Your job is not to write code; it’s to deliver client value, and that requires careful thought. Depending on the importance of a given section of code, rewriting that unit test may be less useful than scrapping it for the moment - or perhaps focusing on integration tests instead. Always be willing to step outside your comfort zone to better understand the project and realize it’s criteria for success - even if you lose a bit of sleep over it.
]]>Because of the success of Rails, there’s a lot of shitty code out there for you to fix. The harder issue is figuring out why shitty code was delivered, which can be trickier to figure out than you’d think. It can be really difficult to change the course of a project when much more than merely the code is dysfunctional.
Tammer suggested a ton of coping strategies, many of which end up being good practices for most situations. I’m sharing my cursory notes here in case others are interested. Feel free to strike up a conversation in the comments to explore these points. I’ll link to the slides when they become available.
Since this project is something I’m doing in my off time, I decided to experiment with MongoDB using the Mongoid framework. I had played with MongoMapper before, but always felt like I was using an ActiveRecord clone that didn’t take advantage of the full capabilities of a document database and was forcing and ActiveRecord-style approach on me. With Mongoid you get has_many, has_one, and belongs_to relationships that map to MongoDB concepts like embedded documents. Mongoid is fully compatible with the ActiveModel interface for Rails3, and things like associations and nested attributes work out of the box.
I also had been hearing great things about CarrierWave from co-workers. It employs the concept of an “uploader” outside of the MVC ecosystem. The uploader handles resizing, storage, and all other details. In your model, you simply “mount” the uploader and you’re golden. Of course, for this project the killer feature is the GridFS storage option, which is something I wanted to play with.
GridFS is a feature of MongoDB that allows storage of large files inside the database. It chunks the file into pieces and assigns a database index so the file can be associated with other documents. While CarrierWave takes care of getting the file into GridFS, serving the file back out is a bit trickier. CarrierWave gives you all you need to configure the url at which your file will be served, but you have to roll your own mechanism for serving it. But I’ll walk you through it.
I’ll assume you have the right version of Rails 3 installed - it’s changing too frequently to document here. Once you’ve got that, create your app with rails appname --skip-activerecord and navigate up in that piece.
I’ve discovered through trial and error that your Bundler config for all the gems mentioned here should track their respective master git branches, since a lot of the Rails 3 compatibility issues are still being worked out. I also track Rails edge because, at this point, why wouldn’t you? So, get your Gemfile looking like this:
source :rubygems
gem 'bson_ext'
gem 'rails', :git => 'https://github.com/rails/rails.git', :branch => 'master'
gem 'mongoid', :git => 'git://github.com/durran/mongoid.git'
gem 'carrierwave', :git => "git://github.com/jnicklas/carrierwave.git"
gem 'mini_magick', :git => 'git://github.com/probablycorey/mini_magick.git'
I included MiniMagick, but you can choose your own image processing library - just remember to change lines referencing MiniMagick in future code examples.
Now let’s install your gem bundle. I recommend calling bundle install vendor to get all your gems vendored in your Rails app, which makes tracking gems much more straightforward.
Next step is to run rails generate mongoid:config which generates a config/mongoid.yml file. You’ll need to fill in the details, but I recommend something a bit like this just to get started:
defaults: &defaults
host: localhost
development:
<<: *defaults
database: appname_development
test:
<<: *defaults
database: appname_test
The generator will also place require 'mongoid/railtie' at the top of your config/application.rb file. I recommend setting up your generators with Mongoid by adding this line in the config block:
config.generators do |g|
g.orm :mongoid
g.template_engine :erb # this could be :haml or whatever
g.test_framework :test_unit, :fixture => false # this could be :rpsec or whatever
end
Those generator settings will allow the resource generator to give you exactly the models, views, and controllers you want by invoking rails generate scaffold thing. Now let’s go into app/models/thing.rb and add the following:
require 'carrierwave/orm/mongoid'
class Thing
include Mongoid::Document
mount_uploader :image, ImageUploader
end
This is the equivalent of Paperclip’s has_attached_file or Attachment_fu’s has_attachment - except that you don’t do all the configuration for upload processing there. Instead you do it in the uploader class, which you can generate by invoking rails generate uploader image. This will create an uploaders/image.rb file, which is a slight quirk because Rails doesn’t know how to find this file when looking up the ImageUploader class. We’re going to change the name of the file to uploaders/image_uploader.rb so it conforms to ruby’s conventions for class definition files.
I’m going to use MiniMagick to process thumbnails, so here’s my fully configured uploader file:
require 'carrierwave/processing/mini_magick'
class ImageUploader < CarrierWave::Uploader::Base
include CarrierWave::MiniMagick
version :thumb do
process :resize_to_fill => [80,80]
end
end
There’s some CarrierWave settings we should set up globally, such as all the MongoDB and GridFS stuff. An initializer is the best place for that junk, so stick this in a new file called config/initializers/carrierwave.rb:
CarrierWave.configure do |config|
config.grid_fs_database = Mongoid.database.name
config.grid_fs_host = Mongoid.config.master.connection.host
config.storage = :grid_fs
config.grid_fs_access_url = "/images"
end
Note the config.grid_fs_access_url = "/images" line, which helps CarrierWave figure out what url to serve this under. The actual url it generates will look like /images/uploads/version_filename.jpg, which is fine for now - you can configure this to your liking later.
Now we just need to update the form to allowing file uploads. Make your “thing” form partial look like this, noting the file field and mulitpart form lines in particular:
<%= form_for(@thing, :html => { :multipart => true }) do |f| %>
<% if @thing.errors.any? %>
<div id="error_explanation">
<h2><%= pluralize(@thing.errors.count, "error") %> prohibited this thing from being saved:</h2>
<ul>
<% @thing.errors.full_messages.each do |msg| %>
<li><%= msg %></li>
<% end %>
</ul>
</div>
<% end %>
<%= f.label :image %>
<%= f.file_field :image %>
<div class="actions">
<%= f.submit %>
</div>
<% end %>
And let’s amend the show view to display the image. Notice we pass the version into the url method to access a particular version.
<p id="notice"><%= notice %></p>
<%= image_tag @thing.image.url(:thumb) %>
<%= link_to 'Edit', edit_thing_path(@thing) %> |
<%= link_to 'Back', things_path %>
We can start up the server by invoking rails server. Navigating to https://localhost:3000/things/new should give us a form where we can select an image to upload. The image should get uploaded and the “thing” saved without a hitch, but when it redirects you to view the “thing” there will be a broken image waiting for you. This is because Rails has no freakin’ clue how to access the file via GridFS. So we need to tell it how.
In order to serve the image as quickly as possible, we need a way to access GridFS without involving the entire Rails slow-ass stack. Enter Rails Metal, which allows you to process requests directly from Rack. While Rails 2 required you to place metal processing in its own directory under app, Rails 3 bakes Rack support directly into the inheritance hierarchy of ActionController, allowing you to do something like this:
require 'mongo'
class GridfsController < ActionController::Metal
def serve
gridfs_path = env["PATH_INFO"].gsub("/images/", "")
begin
gridfs_file = Mongo::GridFileSystem.new(Mongoid.database).open(gridfs_path, 'r')
self.response_body = gridfs_file.read
self.content_type = gridfs_file.content_type
rescue
self.status = :file_not_found
self.content_type = 'text/plain'
self.response_body = ''
end
end
end
Save this file as app/controllers/gridfs_controller. Notice that we’re pulling details about the request path directly out of the request. By default, CarrierWave stores files in GridFS under “uploads/filename”. Therefore, we need to turn the request path (/images/uploads/filename) into a GridFS file path by simply removing the “/images/” (note both slashes). All of these settings are fully configurable in CarrierWave, but that’s beyond the scope of this article - just don’t forget to modify this controller if you change the url or GridFS storage path.
Now the last part is to set up the route for the image. Open up config/routes.rb and add a line for our GridfsController:
Example::Application.routes.draw do |map|
match "/images/uploads/*path" => "gridfs#serve"
resources :things
end
This maps a url like /images/uploads/thumb_image.jpg to the GridfsController’s serve action.
You should now see an thumbnail image on the show view for the “thing”. Congratulations - you’re cooking with GridFS now! There’s a ton of other cool stuff in Rails 3, CarrierWave, and Mongoid, but this should give you the basics for how to handle uploads with GridFS. Have fun, and let me know if I fucked anything up!
]]>A Growl notification informing me of test results is great, and I can even tell Growl to play a sound when the notification is ready. But that sound tells me to look for the notification, not whether the tests pass or fail. To make this conversation more fluid, it would be nice if I had not just visual but also audio feedback which told me immediately what the test results were, instead of having to constantly context switch to the test results.
There have been a few attempts to do this already, but they all seem so complex. I found a simple command line sound file player called afplay that makes all this trivial. In your ~/.autotest file, add the following:
def play(filename, volume = ".15")
system "afplay -v #{volume} /Users/jeremyweiland/.autotest_sounds/#{filename}.wav"
end
Autotest.add_hook :ran_command do |at|
play(at.results.detect { |line| line.include?("0 failures, 0 errors") } ? "passed" : "failed")
end
Autotest.add_hook :run_command do |at|
play("running")
end
This will play some select sounds when tests start running, pass, and fail. Just drop audio files in ~/.autotest_sounds and name them appropriately. Here are my sounds to get you started. The “play” method can be modified to use the “say” command or play any sound file you want.
I find that being able to use my ears to help have this difficult conversation helps me stay in the flow of the conversation more, where I do better and faster work.
]]>The new site has a Google Reader account associated with it (leftlibertarian.org). Instead of going out to a list of feeds, downloading them, databasing posts, and generating web pages on requests, I just grab a JSON encoded version of my reading list as if my site were a Google Reader user and generate pages off of that! Super fast, super lightweight, super easy (once I figured out how I wanted to go about it).
The cool thing about this is that the API makes available just about all of the Google Reader features, including starring, comments, sharing, etc. The Google Reader web application is really just a front end for a rather powerful backend. Over the long run, I’d like to leverage these features to make the site more socially driven and dynamic but without needing a database or anything but a basic web server, cron, and ruby.
The site is very much beta right now. I’m using a HTML parsing library to truncate posts, so if you see anomalies there or have any other comments, let me know. admin atsign left libertarian period org
]]>class MembershipStatus < ActiveRecord::Base
if RAILS_ENV == 'test'
def self.[](label)
case label
when :pending
MembershipStatus.new(:id => 1)
when :accepted
MembershipStatus.new(:id => 2)
when :denied
MembershipStatus.new(:id => 3)
when :invited
MembershipStatus.new(:id => 4)
end
end
else
acts_as_enumerated
end
end