It's Nick Malcolm

Hi there 

A big header

An image tag looks like <img src='x' onerror="alert(1);">

<script>alert(1)</script>

<

A big header

An image tag looks like <img src='x' onerror="alert(1);">

<script>alert(1)</script>

<

This time I am doing things differently.

When I come up with an idea for an app I want to sit down and code it straight away. Fire up TextMate, get a Heroku account, set up Twitter, buy a domain, do web design. And then wait for the users. And wait...

I've had a new idea, which I think has some potential. Check it out right now if you want, but make sure to come back!

The idea: Reproject, a marketplace for projects which have fallen by the wayside. We all have them, me in particular. While I don't have time to finish the projects, the code, design, mockups and market validation have some value. Reproject lets you sell your project, or buy a project and make a successful business.

I started off by trying to assess the target market through some tweets. The app is for web/mobile developers, and that's what most of my twitter friends are. I got a few responses - hoorah! I followed those up with emails, which were fairly valuable.

But it isn't enough to validate me spending time building a whole web app. What I really want is enough people to either tell me "your baby is ugly", or "this has potential I can get behind".

I could have whipped up a quick Heroku app for signing people up, and bought a domain name. Or even created the whole thing. But that's what I always do.

I want a minimal MVP.

This time I've created a launchrock landing page. I describe Reproject as briefly as I can, really honing in on what I think the core value is. I ask people to sign up if it sounds like something they want to use, and ask them to share it with their friends. 

I didn't even buy a custom domain for it! Such restraint! I chucked a subdomain on my little used website. I couldn't help myself from making a custom launchrock background and twitter account though. Mea culpa.

Who knows - this could be a swing too far in the wrong direction. With not enough to really get any valuable feedback.

Regardless, with my minimal MVP in hand, it's time to see if I can drum up any interest. If this is something you're interested in, I'd love to hear from you. When there's enough interest, then I'll start looking at really pushing Reproject ahead.

Sign up for Reproject now

You can learn more on the Reproject launchrock page, and talk to me on twitter at either @reprojectapp or @nickmalcolm.

In my controller functional tests I typically start off with something like this:

tests/function/photos_controller_test.rb setup do @photo = Factory(:photo) end test "should create photo" do assert_difference 'Photo.count' do xhr :post, :create, photo: @photo.attributes, format: "json" end assert_response :success json = JSON.parse(@response.body) assert_equal Photo.last.id, json["id"] end

The setup method creates a valid Photo object (using the Factory Girl gem). The test checks that the controller can create and return a valid Photo by passing it the attributes of a valid Photo, and in this case using json. It's a fairly simple test.

When I upgraded to Rails 3.2, the upgrade guide tells you to update your test environment to "Raise exception on mass assignment protection for Active Record models" by setting "config.active_record.mass_assignment_sanitizer = :strict" in test.rb

So, when I ran my tests, I would see

ActiveModel::MassAssignmentSecurity::Error: Can't mass-assign protected attributes: id, created_at, updated_at

My tests are failing! Oh no! Looks like it isn't as easy as simply calling .attributes anymore.

Of course, this is the expected behaviour. You don't pass the id or timestamps as parameters when you submit a form creating a new photo, and neither should you in your functional tests. Using .attributes was just a convenient, but wrong, way of passing the attributes.

Let's figure out a better way.

I added the following to test_helper.rb:

tests/test_helper.rb def unprotected_attributes(obj) attributes = {} obj._accessible_attributes[:default].each do |attribute| attributes[attribute] = obj.send(attribute) unless attribute.blank? end attributes end

This returns a hash of the attributes which aren't protected, along with their values. For example, it might return something like this:

ruby-1.9.2-p290 :084 > unprotected_attributes(Photo.first) Photo Load (0.3ms) SELECT `photos`.* FROM `photos` LIMIT 1 => {"photo"=>http://photo_url.com/photo.jpg, "description"=>"My trip to France"}

And now in my photos_controller_test.rb I update

xhr :post, :create, photo: @photo.attributes, format: "json"

to

xhr :post, :create, photo: unprotected_attributes(@photo), format: "json"

Feel free to comment below with a more elegant solution!

UPDATE

@nzkoz pointed out that I shouldn't really post every attribute willy nilly, as that's not what a form does.

Using the above solution, if an attribute is unprotected, but shouldn't be, I won't find out about it because the test will still pass.If an attribute is protected, but it shouldn't be, again, the test will pass.

What I should do is this:

If I want to test that passing a photo and a description created a valid Photo, the test should be

xhr :post, :create, photo: @photo.attributes.slice("photo", "description"), format: "json"

By explicitly stating what I actually want, I can be sure that the tests are doing what I expect.

If an attribute is protected but shouldn't be, I'll get the exception and know to fix it.