Hobo - the web application builder for Rails

Great, can’t wait to see the next new brilliant innovation.

I waitses patiently! :)

Thanks,

Gollum, is that you?

It is like the night before Christmas, once you know it is almost here it is hard to wait patiently!

P.S. Don’t be a perfectionist! ;^)

I have every respect for the effort to bring this to the community (having tried something similar myself). I understand that there are other commitments that require attention.etc.etc.
But a bit of communication is cheap. If you tell us where you think this is going, it will be easier for us to judge how deep we want to dip our toes.

I don’t subscribe to the “Silence is golden” mantra… you’re not looking for a mushroom community, are you?

Point taken Jurgen and believe me we’re not deliberately keeping you in suspense. We’re working flat out on bringing Hobo up to steam as a production ready development tool, while at the same time using it in a real live scenario with a customer to make sure it does what we say it does.

Our next release will be a major milestone for Hobo, and we’re incredibly excited. We were hoping to have things ready today (20th) but unfortunately Tom’s wife is not feeling well and that’s put things back a little in the schedule. We also want to do a more comprehensive release this time to tide people over until we can produce proper documentation (which is scheduled for action in the next few weeks).

From our point of view, we think Hobo genuinely has a fantastic future ahead of it. But we’re Brits, so we’re not used to shouting from rooftops about stuff. :-)

All of our experience with it to date is proving out our initial impression that it has the potential to be an incredibly powerful and fast development tool in every way. Bear with us for just a little while longer and hopefully you’ll agree with us!

Thanks for your answer, and again: I take my hat off for what you’re doing.
The three contenders for the next big leap for rails IMHO are streamlined, ajax_scaffold and hobo. I do realise that you see hobo as something different, but hey, you’re not the only one’s to be opinionated.
In these initial phases it’s acceptable that you go into stealth mode to better surprise us with your vision and skill. Even to make non-backward compatible changes.
But if this really takes off, you will benefit from more discussion and agreement on a roadmap.

I think you’re comparing apples and oranges here. Ajax_scaffold, streamlined and hobo are three completely different things.

Anyway, having played with Hobo a bit I can say that DRYML and its implicit context have already sold me. The rest is icing on the cake.

Nice icing, want it! need it! .. but still icing :)

Michael,

Would you explain what you mean by “DRYML and its implicit context”? Sounds like a good thing, but I don’t know what it means :)

Also, why has DRYML’s “implicit context” sold you on Hobo?

Thanks for taking the time to reply.

Ed,
go to the tab “Download & Getting Started”. The answer is in a document linked from there, with the “obvious” title “DRYML, meet ActiveRecord”.
You may need to read the other documents on DRYML first.
But perhaps Michiel can contribute some nice practical examples…
I guess we ought to move off to the forum at this point in time.

Thanks for the nice words guys, it’s great to get feedback. We’re acutely aware that there are a growing number of things competing for the attention of the amazing Rails community, so we want to make sure we create and stick to a sustainable roadmap as things progress. Regarding discussion Jurgen, you’re absolutely right of course and we really really want to get as much ‘opinionated’ discussion going as we can.:-)

We do have a substantial vision for Hobo - the other day for a laugh I ran up a quick chart of where we would like to see it all go and it completely filled a landscape A4 sheet of paper - and how it develops will be determined by what you guys tell us works and doesn’t.

One thing we would like to know, and maybe that’s a forum topic, is whether anyone apart from us has actually tried using Hobo for any kind of Rails project. Even a small test one?

In my current project I have some requirements that have caused me to drop Hobo for now.

You see, I’m not a graphics person, so if I eventually want someone to give my app a nice visual look I need to find that person. And it’s easier to find a person who can do plain HTML/CSS work than someone also familiar with RHTML or DryML.

So I have migrated my layouts to Masterview. Of course, this means that I’m missing out on other Hobo goodies, but that’s prioritizing for now.

Maybe there’s a way of doing this with Hobo, but I’m not experienced enough to see it.

Well, DRYML rocks my boat for a number of reasons.

First of all rendering partials annoys me. Too much code, too many little fragments littered across too many files. I like having the fragments in the same file as I use them or if I re-use them I like throwing them into a library file.

And speaking of re-use, using ‘this’ implicit context means I already have factored out most class specific stuff and when re-using it I don’t have to explicitly tell the environment what I’m using or how I want to use it. Convention rocks.

RHTML fragments are messy. There is too much code and it looks ugly. With DRYML I can simply throw out most of the control code and have nice, short and semantically clean and maintainable pieces.

For applications most of the design work is CSS-based and not HTML-based. Hundreds of partials and views with embedded ERB make for hard reading. With DRYML there is not that much markup left to grok.

Most designers I’ve worked with tend to poke at the templates a bit and then view the resulting source (or live inspect the DOM with DOM Inspector or Firebug nowadays). Having the vast majority of the application markup in a few large DRYML documents is, I think, going to make these designer’s lives a lot easier. (For exactly the same reason I like it).

I am working on a small app I want to do in Hobo. The main thing slowing me down at the moment is the time I spend reading the sources (oh, and going RESTful..). A few examples of non-boilerplate apps and a bit more background on how Hobo does AJAX would speed this up a lot.

I’ve recently built a fairly huge single-page client application in JavaScript using the Dojo toolkit, which is famously lacking in documentation. They do however have a big tests/ directory which serves as a good use example for all the widgets and features and which provides the hooks necessary to dive into the (often cryptic) code.

Going through the Hobo sources (which are very clean) shows me that you have big plans and are probably already using Hobo to do a lot more things than you’d expect from watching a screencast.

I’m reeealy hoping for the next release to be within the next week so that I can start my next project using hobo. Should be magnificent.

The skill matter ror exchange gvid presentation is really good, I’m sure the screencasts will be even better!!! keep up the good work!

Any news on the next release?

On 25 Feb 2007, at 15:12, Tom wrote:
p.s. customising (as opposed to replacing) the default views is kind

of a pain in the current Hobo release. The next version, out very
soon (this coming week hopefully) introduces a mechanism to make it
much easier.

This has really whetted my appetite.

Sorry folks, we’ve been delayed by a few unexpected factors outside of Hobo, but things are coming along great now, so hopefully the release will happen any day now. Sorry I can’t be more explicit, but you’ll understand the reason when the it all happens. :-)

Because of the philosopy and the vision of the solution that you have been sharing…..
Waiting is more than worthy …
Thanks, for the news and the effort; I’m glad I shall be able to start a couple of applications based in your solution which are planned for this semester in the University that I work !

My guess on the mysterious factor is ajax scaffold.

Whatever.
This hobo thingy is falsely marketed.

1. It was launched without docs
2. The new version promised a month ago still no sign of nothing
3. Once this wonderful new thing that supposed to show up in any day now … will also have no documentation.. and will promise documentation ..

life goes on..

Paul - I’m very wary of Ajax overkill. To my mind there’s enough Ajax in the auto-generated pages already.

But anyway — don’t take too much notice of Nigel and his big mystery — he’s rather excitable ;-)

We have some new features, some docs, some improvements to the website…

Whatever — I’m sorry you feel that way. You’re more than welcome to a full refund ;o)

whatever, your frustration is understandable to some extent, but hobo is not doing something that the ruby (and rails) community is not guilty of at large.

Ruby landscape is littered with half baked projects and broken “documentation” projects. Add to that the “EFF YOU!” attitude engendered by the rails core (especially DHH) and you have a discouraging mix.

Maybe Ruby/rails is really easy to start a project with, but it has always been intriguing to me that there NEVER is any good documentation for 99% of the projects. Hobo is not doing anything new. If anything, they’re following the trail of dashed expectation to the letter.

the sad cycle goes something like this:

1. release a screencast

2. claim “extreme usability” while not providing proper documentation

3. Then just sit on some promised release as it gets cooked.

4. Eventually the interest wanes and by the time something actually arrives, there isn’t anyone around to take notice.

5. Release some documentation after telling people to go eff themselves because it is free. not that the Hobo team has done that, but the pattern is generally the same, ie; to denigrate the supposed users if they stop their ass kissing for a minute and actually ask for something.

6. something released but it is too little, too late. The product dies a slow death

7. Someone else starts at step 1 with some equivalent hyper claim and the cycle starts somewhere else all over again.

Why is it that most rails “producers” claim that their product will make life easy for endusers and then end up telling users to read the source because they just can’t be bothered with the discipline of taking documentation just as seriously as the code part?

I think we can’t be too harsh on Tom and the hobo team because they are at least sharing their product, but then again, why these promises when obviously the so called “screencasts”/docs are not even ready?

why is this behaviour so endemic to Ruby and especially Rails based projects? I always wonder. It almost seems like the Ruby community does essentially throw away stuff for the initial rush of releasing something or to use the project as a stepping stone for recognition, but there never is any long term commitment or expectation management. Ie Hype outpaces reality by a long margin.. why? why doth thou mock us thus o Ruby afficionados?

is it because there is a steep wall which people hit and then are just too busy fighting it to actually write any useable docs? and please, function defs are NOT documentation. I can’t belive people actually accept that as proper documentation. That is like step 0. (and even that is sometimes sorely lacking or outright ridiculous)

anyhoo, sorry for the rant.. I think I’m done following this blog. I’ll see hobo around when something useable for the supposed “audience” actually gets there. And for the record, the audience is NOT hard-core ruby developers (they are just fine editing a bazillion code snippets per rails project) as per the initial posts announcing Hobo.

Please excuse my frustration as well.

Name745, I’m in the same situation here - so hold the flames.

I’m still here reading this because the screencast showed a couple of ideas I’d been working on myself. Albeit with a larger scope, a more solid implementation and DRYML to boot.

Reading the code and experimenting with it shows that it’s a solid foundation and, like Rails itself, is something that’s mostly extracted from real-world apps.

So doing a Hobo release or update is probably going to be secondary to running commercial projects, family concerns, social life, etc.

Which makes it hard for an outsider (like me) to commit to Hobo. The foundation looks solid, the implementation feels right, the project has everything it needs to start work with it .. except a few docs and examples beyond ‘hobo scaffold’.

Currently, Hobo feels like a closed tower. Updates are announced without a timetable or a feature list. So no-one can guess what’s coming next or when it will arrive. This is obviously frustrating because none of us can really work or play with Hobo like this.

I would advise the Hobo team to blog a bit more about various features and use-cases instead of putting the focus on documentation and new releases with new features.

By all means pile on the features, tell us to use an experimental branch and write up a blog entry when you’ve done something new. But hang the documentation until there’s more widespread Hobo use. Lack of documentation never stopped Rails. Rails took off because it looked cool, felt right, the developers did a lot of talking with examples and people just went with it.

Tell us more about what you’re doing and why you’re doing it and the walls come down. We’re not consumers of your product - we’re fellow coders who want to leverage the power of your code.

To be honest I don’t care that much about new Hobo features. The latest release has so much potential already that I wouldn’t bat an eyelid if the next release was just ‘fixes’. ‘Breaking changes’? Don’t care. Plug it in the CHANGELOG and I’ll rewrite my code/migrations/etc. New features are cool, but I’d rather have some examples to grok the code decisions.

On the PR side of things, I have to disagree with the title of this blog post. Garbage is cool and it works well for spy novels, but it really doesn’t work here. Silent projects are dead projects. Open projects tend to be vocal.

So, I went a little bit off-track. I can sympathise with with NameX and his fellow whiners but I also am fully aware of the factors that might influence Hobo updates, being in the ‘write code for third party use’ boat myself (not in Ruby, unfortunately).

So I’m sticking around.

http://www.lanl.gov/news/albums/meetings/LockeTom0805.jpg sums it up I think :-)

Stick an underscore _ on either side of the 08 to make that link work

Okay, I wasn’t trying to flame at all, but it came out like a rant (pardon my stream of consciousness comment)

Ironically, Hobo is trying to address exactly my concerns with the state of Ruby/Rails projects in general, but my fear is that there is something in the language or the framework itself which causes the developers to hit !00% cpu on the coding side once some threshold is hit.

And I totally agree with Michiel re: releasing stuff and telling us about it even though its half baked. Although I still would like to assert that hobo is a “different kind of product” which makes the rails situps (and rails’ situps are a breeze compared to XML situps ;-) ) a thing of the past.

My concern is that many a Rails projects start out with lofty ambitions of making life easier for non “hard-core” coders, but end up being just as complicated as the thing they set out to eradicate and we’re back to square one (namely, reading the source to grok what’s going on)

I don’t think I’m explaining my intent clearly enough, but at least consider this an effort to convey that my objective is not to put down the team but to try to look at the general patterns of development in the Ruby world and try to understand what happens to so many wonderful projects which get left behind in the dust and just wondering out loud wheather it is some kind of limitation (kind of like what Python or other languages experience with their plethora of unfinished/unusable products)..

this may not have been a forum for this, but that is just as well.

OK guys - you’re right - silence,
in this case, is not golden :-). I’m writing a post now to respond to all these great comments.