To add my 2 cents, long term plans should probably wait until the fallout from hobo's (imminent?) 1.0 release settles. Conceivably it could change the hobo landscape if it attracts more developers.
On Feb 15, 12:19 pm, Owen <[email protected]> wrote: > Yes, Christian, I am also looking forward to what you come up with. > 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 > > On Feb 13, 6:50 pm, Matt Jones <[email protected]> wrote: > > > 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 > > -- 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.
