Sorry, Kristian, for the incorrect spelling. My niece just married a guy named "Christian" in December so that American spelling was on my mind...
-Owen On Mon, Feb 15, 2010 at 5:07 PM, Owen Dall <[email protected]> wrote: > 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 > -- 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.
