path/to/image.png isn’t precompiled
…
Precompiling assets failed, enabling runtime asset compilation

Turns out it is a rails 3.1.0 bug and upgrading rails to 3.1.1 (3.1.1.rc1 as of the time of this writing) solves the problem.

I took the challenge – here’s my story.

I quickly found two editors for windows I wanted to try out: E TextEditor and Sublime Text. I tried out E and it seemed to work very nice and a lot like my beloved TextMate for mac. First problem solved.

On to ruby, rubygems and native extensions. Welcome to hell.

First obstacle: there doesn’t seem to be a decent console/terminal application for windows, I tried cmd, powershell and console 2. Simple stuff like copy/paste is a pain. Really discouraging.

Then, I tried it all. Starting out with cygwin I managed to almost get there. Actually got SQLite 3 running and managed to create, migrate and run a scaffold rails app. Installing MySQL proved to be the show stopper. After having tried every trick in the book, I ended up with the compiler crashing due to a type error when trying to compile the mysql client from source. I started looking for alternative solutions.

But wait, there is a ruby installer for windows. Native windows ruby – why not? Ruby installs allright, but then trouble emerges. I didn’t manage to get anything running, and I don’t remember the exact problem anymore. I quickly handed over the workstation to helpdesk to get it reinstalled with Debian.

In conclusion: DO NOT use windows for Rails development.

I’ve tried to compare the two approaches and line up the pros and cons in the context of the other. Here’s what I found:

(1) Axure has a neat set of documentation features, providing context and team scoped documentation – notes can be attached to each element and marked with eg. “customer” or “developer”. Nice – I might have to come up with something to counter that.

(2) I heard that Axure can actually export html/css, which means that the development phase could benefit from reusable design/markup elements. So I downloaded a trial and made a quick prototype, consisting of standard elements. I then exported it to look at the generated html. All very easy. But the generated html/css was worse than I had feared. A mixture of upper- and lowercase tags with a ton of inline styles and all positioned using inline-styled divs with a transparent image inside. I was choking. No competition there at least.

Conclusion

First and foremost: there’s something more general in this comparison, than just Axure vs. Rails. I think it’s safe to substitute Axure with more or less any of the commonly used wysiwyg wireframing tools out there today. Likewise, it’s not a matter of Ruby on Rails rather than any MVC web programming framework (you could use web2py if you’re more of a python kind of person). So the comparison could have been named “Wireframing tools vs. MVC frameworks”, but it’s much more fun to pick on specific tools than giving a generalized criticism of something no one really relates to.

There is a key parameter, that the comparison does not take into account. And that is the time used to build a prototype. I have no evidence giving me any foundation to compare time consumption between the two approaches. It’s a pity, because that is what it comes down to in the end: the cost of the prototype.

That said, I think there is a tipping point around the complexity of a prototype, where Rails seems to be the better choice, when enough complexity is added.

This is my condensed take on getting ajax working smooth with jQuery UJS and Rails 3

It seems a discussion has been taking place, determining how Rails 3 and jQuery’s default behavior would work the best. If you want in-depth understanding, I certainly recommend reading this really great article on the Alfa Jango blog, explaining the whole issue with thorough examples.

If you just want to copy paste and get on with what’s important to you, this post might be for you…

First off: I’m using rails 3.0.3 and jquery-rails 0.2.6, which in turn uses jQuery 1.4.4. I expect jQuery 1.5 will not affect the way jQuery UJS and Rails works together.

jQuery UJS has gone from defaulting to JS (resulting in a missing template error by default), through defaulting to anything (*/*) (resulting in rails returning the first format it finds available) to now accepting any format, but preferring JS. Let me show you how to utilize this.

In your view:

link_to "My ajax function", rails_path,
  :id => 'something-new', :remote => true

In your controller:

class SomeController < ApplicationController
  respond_to :html, :js

  def new
    respond_with(@some = Some.new, :layout => !request.xhr?)
  end
end

Now the respond_with will first try to render the new.js.erb file, and if that doesn’t exist, it will render the new.html.erb.
Note that the layout will not be rendered if this is an ajax call (:layout => !request.xhr?) – very neat.

For an in-depth view on respond_with, I can recommend Ryan Daigles post about that.

Or if you want to render an html partial only, you’ll have to respond explicitly to the JS format:

  def new
    respond_with(@some = Some.new) do |format|
      format.js { render :partial => "partial",
        :content_type => 'text/html', :layout => false }
    end
  end

And don’t forget to listen for the response on the client (if it’s html format) – in application.js:

$(document).ready(function(){
  $('#something-new').bind('ajax:success',
    function(evt, data, status, xhr){
    $('ul#things').append(xhr.responseText);
  })
});

class Parent < ActiveRecord::Base
  has_many :children
  validates :children, :presence => true
end

If you need a custom message, that’s built into the new validation syntax for rails 3:

  validates :children, :presence =>
    { :message => 'there should be at least one child' }

Simply wanted to share this, just in case it could save someone the hassle of building a custom validator.

But too often, the opposite is the case. Users and goals are constrained by technology, specifications, and contracts. This is depressingly true. But it doesn’t have to be this way. Just choose the right prototyping technique and gain benefits in the entire value chain.

We all know the setting. Starting up a new project should be fun and inspiring. The success of the project often depends on this. But sadly, too often the enthusiasm of the project manager and her team comes to an abrupt end, when the ideas and visions has to be formalized in a requirements specification.

Now, we all agree that requirements should be documented and communicated in a concise manner, but does it really need to be a written specifications with lots and lots of paragraphs, trying to describe an interface and a workflow, that is then interpreted in as many ways as the number of people involved?

Of course not.

… a modest investment in interactive prototyping will usually pay for itself several times over, given the savings in medium-term development and long-term support costs. Just as you wouldn’t dream of building a house without deciding whether it was an apartment or a semi-detached house, you really shouldn’t embark upon any software development without pinning down the exact nature of the system, and the best way to do that is to use prototyping techniques…

Reynard Thomson

A Painting Says a Thousand Words. We all know, and of course, we also apply that knowledge when specifying our new, revolutionizing web application. Most projects employ usability specialists and makes use of the fine art of interaction design (if you don’t, you must be living on the moon), producing sets of wireframes and sketches or design mockups that paint a decent painting of our beloved baby-web-app.

I want to bridge those gaps. I want to bridge those gaps using truly agile development.

So what’s all the fuss about?

Well, there are still gaps. There’s a gap between the mockup and the final html/css template. There’s a gap between the wireframes or the clickable presentation slides and the logic dealing with external data sources and presentation of complex information sets. There’s still a gap between project stakeholders taking part in the interaction design process, and the developers in the cubicles out there that’s going to implement that baby. You can probably think of more.

I want to bridge those gaps. I want to bridge those gaps using truly agile development. And I want to start by taking your prototypes to the next level. I give you:

High Fidelity Evolving Prototypes

Imagine a room full of enthusiastic people, throwing ideas at a usability specialist, sketching it all on a whiteboard while discussion is going on, and new ideas pop up. Imagine a lunch break, with people so engaged that they keep coming up with new ingenious ideas during the break, discussing, laughing, having fun. Imagine coming back from the lunch break and WHAM – there’s a working prototype, deployed and all. Everyone can see it, access it and try it out, everyone can have opinions, and the next iteration can begin.

That’s me doing that prototype. It’s me doing 20 iterations over the course of 20 days, delivering a working prototype with prioritized features in a proof-of-concept state. That’s that requirements specification no one wanted to write, right there, embedded in the prototype. That’s when the project owner embarks on a journey, where only the process is known, not the result, letting true agility show it’s worth. And that’s how the project owner will:

• gain stakeholder support
• improve estimate accuracy
• improve the quality of requirements
• prevent misunderstandings and miscommunications
• reduce costly changes late in the development phase

That’s when technology, requirements specifications and contracts are tools to support your business, not constrain it.

View the full photo-set on flickr

Se også Viktorialaugets hjemmeside.

Kulingræs med Viktoria from Jeppe Liisberg on Vimeo.