Yep. Stay tuned on February 22. Sorry we missed Valentine's Day. :-) On Mon, Feb 15, 2010 at 3:45 PM, kevinpfromnm <[email protected]>wrote:
> 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]<hobousers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/hobousers?hl=en. > > -- Thanks, - Owen -- 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.
