On Dec 5, 2009, at 7:19 AM, Tom Locke wrote:
> I also think Hobo should provide the small and powerful vocabulary.
> The idea that you can build a hobo app without proper Ruby/Rails
> chops has bitten quite a few people - it's wishful thinking (that
> doesn't mean you must learn Rails fully first - you can learn them
> both together).
>
Exactly - I'd even go farther and say that Hobo isn't the best place
for a new programmer. There's quite a bit of magic going on - none of
it's particularly *special* magic, and a somewhat experienced Rails
programmer will understand what's happening. But those conventions /
standard behaviors are a lot to take in for a new programmer,
especially since most of them are buried somewhere in the gem. Anybody
remember all the confusion people had when Rails scaffolding was a
single line on the controller, rather than generated code?
To me, Hobo's real target audience are the folks who already
understand things like the CRUD controller incantations, and are tired
of typing them over and over. The goal is to get the routine bits out
of the way, so the important parts (the business logic, the unique
processes) can be accomplished more clearly. You can see this
throughout the whole plugin: for example, there's nothing magical
about lifecycles that couldn't be expressed in model/controller code.
But the lifecycle block and the support in Rapid mean that it's much
easier and much clearer to encode "only user Foo can do action Bar to
an object in state Baz" rather than scattering permission and state
checks all over the controllers.
Similarly, in the current DRYML code, there's nothing that some (very
clever) use of ERB and block helpers couldn't do; I actually wrote
some code like this back when Hobo was still a little shaky last year.
Example:
def checked_span(display_state, user, &block)
if user.display_currently?(display_state)
c = 'current'
elsif user.display_completed?(display_state)
c = 'done'
else
c = 'upcoming'
end
content = capture { yield }
concat(render(:partial => '/candidates/checked_span', :locals =>
{ :user => user, :span_class => c, :content => content, :phase =>
display_state }))
end
(this is in a helper module) Its usage looks like (in a view file):
<% checked_span(:define_goals, user) do -%>
<h3><%= checklist_phase_header('Define Goals', :define_goals,
user) %></h3>
<% end -%>
Anybody who has written much DRYML will see the immediate similarity.
DRYML simplifies code like this by reducing the punctation noise (less
<%= ) and making much of the context (the user local, for instance)
more automated.
So to come back around to the start, Hobo shouldn't be thought of as
something that one uses "instead of" Rails; I don't believe it's
possible to be a good Hobo programmer without also being a reasonably
good Rails programmer.
A somewhat funny (to me, anyways) real-world analog - web programming
as building a house.
PHP: you start with a forest and some iron ore. Good luck.
Rails: 2x4s and hand tools. Much less mess than PHP, but still pretty
repetitive.
Hobo: the same 2x4s, but now you've got power tools. Who really wants
to stand around all day sawing, when there are structural decisions to
make?
Random CMS with plugins: 10000000 prefab segments the size of rooms.
You can build something that looks mostly like what you want, but
there are design compromises due to inflexibility; you've also got to
figure out which of a huge number of nearly-identical modules to
choose, and deal with compatibility issues. In many cases, if you want
to try to modify things at all, you're back to the iron ore and the
forest.
There's no debating the prefab segments get *something* up quickly,
but the real goal should be to get the *right thing* up quickly.
--Matt Jones
--
You received this message because you are subscribed to the Google Groups "Hobo
Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/hobousers?hl=en.
