Back from the grave!
Kristian
Wow, I thought the Hobo book was going to press by now. At least that
was the impression I got in early December when I was pushed to
deliver the chapter on DRYML tracing... and failed to deliver! Ouch!
Since then I have left the Hobo camp pretty much. Instead I've been
working on some other things, including getting to grips with
Sproutcore. Now I'm heading off to the Caribbean in a few days :)
Been feeling that Hobo has been overtaken in many areas by various
other plugins and developments as time has moved on. In Ruby world
things move almost too quickly!
Why not create a new "Hobo" like project (perhaps with another name)
from scratch, with the same goalds - to make it really easy to rapidly
create web applications using Rails 3 and the best plugins out there
in various areas. Perhaps from the start adding some more meta-model
programming approaches to it all? (as I see it that has been much of
Hobos current strengths). I feel the curent Hobo suffers from to much
"custom code" having to be maintained instead of just wrapping other
gems out there in a nicer way, fx Formtastic, Devise and some nice
role mapping solution?
The meta-model should use a ruby DSL approach, not a static model!
Why not also take more advantage of the new Thor powered Rails
generators and templates. Been working a lot with these technologies
myself lately. They just need some nice code refactoring library to
really kick ass! Then skip the whole schema centered approach and go
for schemaless persistence backends such as Mongo DB and the like. But
can you deploy Mongo DB and similar to fx Heroku yet?
Schemaless DBs would eliminate a lot of complexity.
The end goal - keep the architecture of both the framework and the
"generated" app simple and flexible.
Design every framework component of functionality/feature set as a
plugin or gem, each created using BDD with Features, Scenarios and
Specs to act as verification and documentation to facilitate
extensions by others in the community. Why not join forces with other
groups working on similar Meta frameworks on top of Rails?
Hmm... just some ideas.
Now I'm in the process of developing a nice litle "application
indexer" - to auto generate and keep in sync an index (YAML "DB") of
all my various types of apps and their individual configurations...
and to issue various actions to be performedon these apps depending on
their type and configuration (fx moving the app to a new dir?).
Cheers!
Kristian
PS: I hope to redo my tracer plugin sometime with BDD and Rspec from
the start and centered around producing a nice, working DSL for
defining unobtrusive tracing... will also work on a lib with a DSL for
common code refactorings.
Kristian
Pink Palm framework
-------------------
Client - Sproutcore
Server - Rails 3
Client - Sproutcore
-------------------
Generate a standard Rails REST driver for the client storage layer.
Theme generator
- Select basic Theme from Theme Gallery (web preview - download from
github repo)
- Adjust various facets using dialogs? (fx colors etc)
- Generate SASS stylesheets hooked up to Sproutcore app.
Drop DRYML!
Use Statecharts (Sproutcore) to handle state transitions in the
client, see Evin Grano.
Have a Ruby DSL to define/generate the Statecharts code. Each state
has a call to a javascript function with relevant parameters which
handles
the state transition! Generate Statechart graph from DSL using
Graphviz. Somehow the Graph generator should handle splitting a chart
up in multiple pieces. This could be assisted from the code side, by
naming state groups and then have the generator create a new graph for
each such state group.
Define the view using Sproutcore Views. Community creates custom
Sproutcore views that can be used with themes.
Integrates various nice javascript widgets as Views, fx from jQuery UI
etc. See SCUI (SproutCore UI) project.
Server - Rails 3
----------------
Pink Palm app. generator.
Rails templates for applying addons
Rails generators for adding Mongo models etc.
Rails app.
- Model: Mongo DB with MongoMapper/Mongoid
- Controllers: Rails 3 RESTful (Base)
- Routes: Rails 3
- Testing
- RSpec
- Cucumber
- Capybara (replaces webrat)
- Shoulda (optional)
- Factorygirl/Mocha
Scaffold server app from YAML file:
Model, RESTful resource Routes, Controllers, Validations, Indexes and
Scopes (new Searchlogic gem?).
Have 2-way sync between YAML config and app code.
Integrate various server gems for use in the YAML config file using
Rails templates.
Feel free to respond with ideas, comments flames, ice, fire or
whatever ;)
Matt Jones
On Feb 13, 2010, at 3:22 PM, Kristian wrote:
>
> Why not create a new "Hobo" like project (perhaps with another name)
> from scratch, with the same goalds - to make it really easy to rapidly
> create web applications using Rails 3 and the best plugins out there
> in various areas. Perhaps from the start adding some more meta-model
> programming approaches to it all? (as I see it that has been much of
> Hobos current strengths). I feel the curent Hobo suffers from to much
> "custom code" having to be maintained instead of just wrapping other
> gems out there in a nicer way, fx Formtastic, Devise and some nice
> role mapping solution?
>
I'm personally pretty "meh" on some of those specific examples:
- Devise has some interesting ideas, but 90% of what it does is
already in Hobo or readily accessible. The Warden integration is
interesting, but cross-language solutions like CAS are more likely to
be helpful - lots of us have to deal with crusty old legacy PHP apps...
- Formtastic has some nice ideas (the grouping especially), but much
of the other "gee-whiz" stuff is already in Rapid - most notably, the
handling of associations via selects / radio buttons. The examples in
the Rdoc remind me of DRYML, but now with 800% more % signs!
- role mapping: nobody is *ever* going to be happy with a single role
mapping solution. Either you end up having a giant ACL system doing a
job better suited for an "administrator flag", or vice versa. I'd be
interested to see more recipes along these lines, but a plugin
solution is always going to cause problems.
Also note that there's not anything *preventing* you from using most
of these plugins - I'd assume, for instance, that Formtastic would
pretty much drop-in. You'd lose all the autogeneration and permissions
control that Rapid bakes in, but it would be possible.
> The meta-model should use a ruby DSL approach, not a static model!
> Why not also take more advantage of the new Thor powered Rails
> generators and templates. Been working a lot with these technologies
> myself lately. They just need some nice code refactoring library to
> really kick ass! Then skip the whole schema centered approach and go
> for schemaless persistence backends such as Mongo DB and the like. But
> can you deploy Mongo DB and similar to fx Heroku yet?
>
> Schemaless DBs would eliminate a lot of complexity.
> The end goal - keep the architecture of both the framework and the
> "generated" app simple and flexible.
Schemaless DBs are very popular with developers right now - and they
do offer some very powerful features. HOWEVER, there's still an awful
lot of work out there that's rooted in old-school RDBMS applications,
and most of the NoSQL stuff falls down once you want to start
generating ad-hoc reports.
> Design every framework component of functionality/feature set as a
> plugin or gem, each created using BDD with Features, Scenarios and
> Specs to act as verification and documentation to facilitate
> extensions by others in the community. Why not join forces with other
> groups working on similar Meta frameworks on top of Rails?
> Hmm... just some ideas.
The whole "split everything into a billion bits" movement kind of
annoys me - for instance, the fact that it takes about 30 gems to get
a sample Merb app going. Modularity is one thing, but something isn't
really "modular" until there are TWO interoperable implementations for
a component. Until then, it's really just "divided". The "ORM
agnosticism" trend followed the same pattern - ActiveModel is finally
starting to simplify things, but before that being ORM independent
really just meant writing everything N times to support N ORMs; see
the Merb port of restful_authentication for an example.
More thoughts to come on the other post in this thread...
--Matt Jones
Matt Jones
On Feb 13, 2010, at 4:05 PM, Kristian wrote:
> Some ambitious ideas for a new Rails 3 - Sproutcore framework.
>
> Pink Palm framework
> -------------------
>
> Client - Sproutcore
> Server - Rails 3
>
> Client - Sproutcore
> -------------------
>
> Use Statecharts (Sproutcore) to handle state transitions in the
> client, see Evin Grano.
> Have a Ruby DSL to define/generate the Statecharts code. Each state
> has a call to a javascript function with relevant parameters which
> handles
> the state transition! Generate Statechart graph from DSL using
> Graphviz. Somehow the Graph generator should handle splitting a chart
> up in multiple pieces. This could be assisted from the code side, by
> naming state groups and then have the generator create a new graph for
> each such state group.
The first hit I got when looking for statecharts linked them to UML,
which triggered my "DO NOT WANT" reflex. :) Further digging turned up
the Sproutcore implementation, which bears a striking resemblance to
the way GUI apps have been in the past. I'd be interested in learning
more, but the sproutcore-statechart repo referenced in several posts
appears to be gone...
> Define the view using Sproutcore Views. Community creates custom
> Sproutcore views that can be used with themes.
> Integrates various nice javascript widgets as Views, fx from jQuery UI
> etc. See SCUI (SproutCore UI) project.
Again, SCUI looks interesting - but I've got apps to develop *today*,
not in 6 months!
> Server - Rails 3
> ----------------
>
> Pink Palm app. generator.
> Rails templates for applying addons
> Rails generators for adding Mongo models etc.
>
> Rails app.
> - Model: Mongo DB with MongoMapper/Mongoid
> - Controllers: Rails 3 RESTful (Base)
> - Routes: Rails 3
> - Testing
> - RSpec
> - Cucumber
> - Capybara (replaces webrat)
> - Shoulda (optional)
> - Factorygirl/Mocha
>
> Scaffold server app from YAML file:
> Model, RESTful resource Routes, Controllers, Validations, Indexes and
> Scopes (new Searchlogic gem?).
> Have 2-way sync between YAML config and app code.
Once again, an interesting idea - but why would I want to fool around
trying to say things in YAML that are better said in Ruby? Barring
massive intervention like grokking S-expressions into YAML arrays,
there's just too much that isn't expressible there: for instance, give
me a YAML representation of a named_scope with a lambda (which is all
of them, in Rails 3).
A few points in summary:
- the whole idea of configuring an app via a giant YAML file is
revolting. It smells way to Enterprise-Javay for my tastes.
- Sproutcore is definitely something to watch, but there are some
serious barriers to using it in many apps:
-- you end up repeating everything twice, once on the client side and
once on the server. The YAML configuration envisioned above appears to
be an attempt to address that, but there's still going to end up being
bits that aren't covered and have to be maintained twice as a result.
-- as a corollary, the majority of business logic in the app is on the
client. If you ever wanted to watch C-level execs clench their
buttholes really fast, mention this. Rightly or not, there's still
some paranoia about competitors "stealing the app".
-- the biggest issue facing JS client-side apps: IE6. It's still out
there, and will continue to irritate decent web developers for at
least the next few years. Between an incompatible and flaky DOM and
the 15x slower JS, it's a serious issue.
-- the second biggest issue: the *back* button. No matter how many
times you tell users, "don't click back", they'll do it. HTML5
promises some relief for this with better state tracking, but see the
preceding point and add IE7's lack of support for HTML5 to the mess...
----
In summary, I'd agree with the idea that richer, client-powered apps
are likely the future. Unfortunately, 90% of the businesses and
nonprofits out there aren't even running on *today*; big chunks of the
world are still being held together by Access DBs, giant cross-linked
Excel files and Word documents CCed to everyone in a department.
(Seriously - I just set up a Dropbox account for a small professional
association who was actually doing the CCed Word docs thing!)
Anyways, I look forward to seeing what you come up with - despite the
rest of this post, *somebody's* got to get away from the PHP fumes
long enough to actually build the next wave of frameworks. :)
--Matt Jones
Owen
Easier Said Than Done, IMHO.
"
Boy, when you get to my age you see good ideas die and reappear again.
"NoSQL" variable-length, multi-valued engines started with Dick Pick
(IBM 360 - 1965, then minicomputers(1973) and then hit the PC world in
the 1982 under the name "Revelation". yes, it was a "revelation" to
those of us trying to build commercial applications on the lowly PCs
of those days.
Hundreds of vertical market apps and thousands of mission-critical
apps used these engines. Their strength was is in their rapid
development ans prototyping capabilities. No need for data
migrations. (That's why I liked Hobo taking care of that for me.)
As Matt mentioned, reporting was the big problem. You had to build
your own (did that) or transfer to a "standard" database engine (also
did that) to satisfy enterprise-level clients.
Having said that, MongoDB has a natural synergism with Hobo. (But our
government clients are just getting comfortable moving from Oracle to
MySQL.)
I think this is a healthy discussion to have. Dialectic is good. But
who is going to do the experiments? Resources are limited...
-Owen
kevinpfromnm
fallout from hobo's (imminent?) 1.0 release settles. Conceivably it
could change the hobo landscape if it attracts more developers.
Owen Dall
--
You received this message because you are subscribed to the Google Groups "Hobo Users" group.
To post to this group, send email to hobo...@googlegroups.com.
To unsubscribe from this group, send email to hobousers+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/hobousers?hl=en.
--
Thanks,
- Owen
Owen Dall
-Owen
Thanks,
- Owen