As for Appcelerator: I have tried to create a few apps with it. Hmm .. I'm not very excited. Some app tags are not working as they should ... rendering problems and others. For me that is a signal to leave this technology.
As for my choice of framework for my future web apps: Now I'm still choosing between these 3 frameworks (initially cut from 20+ :-) Grails (Groovy Java) , Django , Web2py My framework expectations: fast website development times steady runtime good DB support = db transcactions + custom sqls (joins + triggers + pl/pg sql) enough power and performance for little and even mediocre sites (I do not consider this framework for huge apps - I guess that only Grails could do it which is a + point for it :-) Any comments why I should go a web2py way (can web2py do all these) ? Thank you On Fri, Oct 31, 2008 at 8:15 PM, Yarko T <[EMAIL PROTECTED]> wrote: > The nature of the problem is different from the nature of the solution... in > that, the technology is _completely_ irrelevant; > > The solution provider's problem is [1] understanding the problem [2] > understanding the technology (to know what solution level can be > offered.... and [3] competitively costing the solution. > > In the second problem space, the question "what does appcelerator / and or > web2py provide me - the solution provider" - is completely relevant. > > Who's problem perspective we are talking about is what seems to be in > question. I mean appcelerator (or anything like this) is evaluated from the > perspective of solution-provider's-problem. For a discussion of the > differing aspects of problem vs. solution (and how you can tell which you > are talking about) see > http://www.ccsr.uiuc.edu/web/Techreports/1990-94/CCSR-91-14.pdf > > On Fri, Oct 31, 2008 at 12:24 PM, achipa <[EMAIL PROTECTED]> wrote: >> >> We seem to be using different terminology, apart from that, I agree (I >> would have said defining the problem *is* a task which is part of the >> whole project, just as prototyping is a task/phase in itself, >> sometimes overlapping other tasks to an extent). The importance of >> clients understanding the technologies involved at least to a certain >> level can hardly be avoided. Otherwise, they simply won't know what is >> possible (and won't communicate it to you as a problem or requirement >> and thus will be very hard to discover). On the other side is the 'too >> savvy for his own good' problem, where they request a *specific >> solution* without both of you analyzing the problem and requirements >> (like requesting/specifying the development of a complex feature which >> has already been technologically surpassed or there is an acceptable >> solution available from third parties). But we digress, this is >> generic software development talk, and has less to do with >> appcelerator and web2py. >> >> On Oct 31, 4:46 pm, "Yarko T" <[EMAIL PROTECTED]> wrote: >> > Defining the problem is part of the task; prototyping can help clarify >> > / >> > validate; the preliminary part I don't think requires client knowledge >> > of >> > technology, nor consultant/company knowledge of client problem - it is a >> > discovery phase, which is equally important when you _think_ you have a >> > grasp of what is needed. >> > >> > There is no one "right" or "best" strategy, but a bagful... but one >> > thing >> > common is "rapid prototyping", or mockups, _and_ effective listening >> > (that >> > is NOT jumping to solution - a common engineer's behavior, necessarily: >> > we >> > are those who solve, after all) are all part of it. >> > >> > In terms of web application solutions, malleability of "look", >> > presentation >> > to user is something that helps delivery (underlying business logic is >> > perhaps the most stable component of a solution, evolving rather than so >> > much changing; we seem to have the DB / backend part in pretty good >> > shape). >> > >> > Proposed engineering adjuncts / solutions like Appcellerator I think >> > need to >> > be evaluated in the light of how well it serves the engineering needs as >> > I >> > outline above, particularly support of effectively being able to iterate >> > as >> > client needs are better understood & discovered through a process. >> > >> > On Thu, Oct 30, 2008 at 7:40 PM, achipa <[EMAIL PROTECTED]> wrote: >> > >> > > We were talking about the tech part of prototyping (the idea to >> > > prototype phase of project). The prototyping you outline contains also >> > > a preliminary part - the development of the idea itself. Often the >> > > client does not really know what he wants or has a very limited grasp >> > > of the technology and solutions available. In these cases, good old >> > > pen and paper (even if electronic like google docs, or just annotated >> > > mockup screenshots) are a very valid and good way to go to get an >> > > actual spec, which then can go to tech people to be prototyped and >> > > developed/refined further. >> > >> > > On Oct 30, 10:38 pm, "Steve Shepherd" <[EMAIL PROTECTED]> wrote: >> > > > Just to pickup on the prototyping discussion, >> > > > I have pulled my hair out about this for over 3 years. >> > > > The key to prototyping is to allow very quick changing of ideas to >> > > > match >> > > the >> > > > GOALS of the user. >> > > > If you code it you start pouring concrete and immediately start >> > > > building >> > > > walls to further innovation. >> > > > The more effort a coder invests in developing the prototype the more >> > > > resistent to changes the mind automatically becomes. >> > > > I finally settle on a simple Google doc with hand drawing of the >> > > > screen >> > > with >> > > > implementation notes at the bottom. >> > > > Its not perfect but it does allow collaboration with google docs and >> > > > it >> > > > doesn't have a whole technical knowledge thing to breakdown. >> > >> > > > Below I have included an example of a screen I am developing for an >> > > > applicaiton: >> > > > (The square brackets are buttons and dropdowns) >> > >> > > > The Marketing Manager Main Page >> > > > ------------------------------ >> > > > * >> > > > [Add a Campaign] [Select an Action[v]]**- (1 to 2 of 15) Campaigns >> > > > * *Select* >> > > > *Title >> > > > * *Information >> > > > * *Responses* >> > > > * >> > > > ( )* >> > > > *Messages to Prospective Students for Hort 2 Course prior to them >> > > signing >> > > > up* >> > > > (4) Messages, Horticulture, Agri Learning Category, Followup, >> > > > Modified >> > > > Yesterday, By Me The Information section is a combo of a number of >> > > > fields >> > > of >> > > > information. >> > > > (10) People linked >> > > > (2) Sent a Response >> > > > (20% Responses) >> > > > (3) Added last 10 days [Adjust] >> > > > * >> > > > * *(*)* >> > > > *A Welcome for new Hort 2 Students before course starts.* >> > > > (2) Messages, Horticulture Category, Countdown, Modified Last Week, >> > > > By >> > > Jan >> > > > Davies >> > >> > > > *Include >> > > > * *Filter the Campaigns >> > > > * [X] >> > > > Horticulture >> > > > [X] >> > > > Agri Learning >> > > > [ ] >> > > > Sport >> > > > [X] >> > > > Last 7 Days >> > > > [ ] >> > > > Last Month >> > > > [X] >> > > > By Me >> > > > [X] >> > > > By Others >> > > > *Options* >> > > > *Add a Filter* >> > >> > > > ------------------------------ >> > > > Design Info You can hover over the 2 and change the number of >> > > > records on >> > > a >> > > > Page. etc etc >> > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
