Le 2010-11-16 à 19:43, Chuck Hill a écrit : > On Nov 15, 2010, at 8:43 PM, Ian Joyner wrote: >> On 16 Nov 2010, at 14:52, Chuck Hill wrote: >>> On Nov 15, 2010, at 6:51 PM, Ian Joyner wrote: >>> >>>> That's a good distinction about quickly. Seems most get a kick from the >>>> first learning of something to get it quickly happening. Hence >>>> lowest-common-denominator languages like BASIC become popular. It's good >>>> to get people into things quickly, as long as they get the intellectual >>>> impetus to learn something better. But often these languages are treated >>>> with scorn and derision as teaching languages or moralistic in some way >>>> because people don't understand why more complex solutions are needed as >>>> the problems "scale up". >>>> >>>> There was an interesting viewpoint article in Communications ACM recently >>>> by Ben-Ari about "Objects Never, well hardly ever", where he advocated >>>> teaching procedural programming before OO. But I think it's the same thing >>>> as we teach kids variables and assignments and how to crash programs >>>> because "that's exciting", rather than techniques like functional >>>> programming because that requires more reasoning. >>>> >>>> So while WO might be better for complex applications, perhaps WO hasn't >>>> addressed the entry level enough so that people get their "hit" early of >>>> seeing something working. While WOnder added a lot of stuff that was >>>> needed to keep WO up-to-date, it made entry level even more difficult. >>> >>> I don't know that it did. I think what has made the entry level more >>> difficult is the lack of printed material and a tutorial. >> >> Yes, I think I had a gripe about that a month ago or so. All Apple's pages >> say is "Legacy Document". > > Yes and not likely to change. > > >> What happened to Janine's tutorial. > > She is starting to revive it. In-between bouts of life. > > >> Yes, you need a Hello World example you can get going in five minutes >> (including installing the software). (Although, about 7 years ago I had >> terrible trouble getting Heelo World to work because I had a space in the >> project name "Hello World". These little things are killers. Most of our >> students used Django this year, rather than RoR because RoR was a pain to >> install, particularly on Windows (even on a Mac if you don't have Xcode >> installed). >> >> One student in his experience report mentioned that professional programmers >> should spend extra time on making their stuff usable and easily installable >> if they are going to expect people to use their systems. Salient advice all >> around and I think he scored 100%. > > I think an important distinction here is between "expect people to use their > systems" and "allow people to use their systems". Wonder largely falls in > the second category. "I made this because I found it interesting and you can > use it if you want." Neither WO nor Wonder are now marketed products and > there is little incentive to make them appear like they are.
Wonder was marketed in the past?? > > >>> Before, you could follow the Apple tutorial and get something working >>> fairly quickly and in an understandable form. The problem was that it was >>> poor code and had a number of unmentioned bugs in it. To a large part, >>> using Wonder at the same level (vs trying to understand what it is doing or >>> fixing a problem) reduces the number of potential problem and occasions to >>> pick up poor coding practices. At present there is no good tutorial or >>> introductory level documentation. If there was, a much higher quality >>> application could be built more quickly than without. >> >> Yes, there should be a core and then add more complex, specific >> technologies, so you can go in any particular direction as needed. >>> >>> WO has become a series of learning cliffs: first WO proper, then Wonder, >>> then D2W, then the outlying parts of Wonder, then ERRest, then... >>> WebObjects all in is HUGE. Add poorly or inconsistently documented to that >>> and learning it is a problem we still struggle with. There is too much >>> legacy technology for a volunteer community to deal with. >> >> Jobs has always been good at taking a mess and rationalising it, but I think >> for WO, there is nothing forcing Apple to do it. > > > Nor any incentive to do so. > > >> Another Barton quote (about FORTRAN in 1963): "a user-cult formed which is >> now quite effectively hampering progress in the adoption of improved >> scientific languages." > > :-) > > > Chuck > > > >>>> I like Bob Barton's quote (via Alan Kay I think) that "Systems programmers >>>> are high priests of a low cult." >>>> >>>> Ian >>>> >>>> On 16 Nov 2010, at 13:29, Mike Schrag wrote: >>>> >>>>> I think "quickly" has two interpretations ... There's "quickly from >>>>> knowing nothing about the technology and starting an app from scratch" >>>>> and there's "quickly from understanding the technology and starting an >>>>> app from scratch." If you interpret "quickly" as not knowing anything at >>>>> ALL, it's probably faster to bootstrap a rails app. If you interpret >>>>> "quickly" as understanding WO and just starting a new app from scratch, >>>>> there are a lot of classes of apps that you can produce faster as a WO >>>>> app. >>>>> >>>>> Of course, the sad reality is that our industry loves to just >>>>> syntactically masturbate with different languages and pretend that we're >>>>> much better for it when the reality is that basically nothing has changed >>>>> in 30 years in terms of how we actually solve problems. >>>>> >>>>> ms >>>>> >>>>> On Nov 15, 2010, at 8:50 PM, Ian Joyner wrote: >>>>> >>>>>> I agree with this too. Problem or fixed complexity must be dealt with >>>>>> somewhere in the system, and arguments often abound as to where that >>>>>> should be done (almost always without people recognizing that fact). I >>>>>> wrote on that recently too: >>>>>> >>>>>> http://www.ianjoyner.name/Ian_Joyner/Complexity.html >>>>>> >>>>>> so am in vehement agreement. >>>>>> >>>>>> It's always a problem getting something to run quickly, like Twitter, to >>>>>> see if it succeeds or fails, before committing significant resources, >>>>>> and then like Twitter maybe rewriting your message queues in Scala for >>>>>> speed. (Something done by WO, I think?) >>>>>> >>>>>> But getting something quickly done in WO, might be a problem. Pascal's >>>>>> words about "learning cliff" still ring in my ears ;-) >>>>>> >>>>>> Ian >>>>>> >>>>>> On 16 Nov 2010, at 12:20, Mike Schrag wrote: >>>>>> >>>>>>> I think you also have to weigh the dramatically more complex security >>>>>>> and protocol required to handle state on the client. You get a huge >>>>>>> amount for free with WO in terms of state transition management that >>>>>>> you have to build yourself if you use almost any other system. You also >>>>>>> get a large amount for free with WO with respect to security because >>>>>>> you can count on "that you called this action means you were allowed to >>>>>>> see this action," whereas a traditional restful system requires >>>>>>> security enforcement for every action. Also consider that your site >>>>>>> isn't iTunes, Google, or Twitter. Most applications don't have to scale >>>>>>> all that much, and almost certainly are within the realm of a few >>>>>>> servers and dumping ram into your box. >>>>>>> >>>>>>> I also don't care what tools and frameworks you built your system with. >>>>>>> If you DO become iTunes, Google, or Twitter, your app won't scale. >>>>>>> Period. I've never seen a system that scales without investing >>>>>>> substantial engineering effort in profiling and rearchitecture after >>>>>>> deployment. If you built your app with rest, all you're doing is >>>>>>> shifting your load in other ways. Like Chuck said, you get a lot of >>>>>>> caching for free with WO that you have to figure out how to get back >>>>>>> with stateless architectures. And the most common method? Shared object >>>>>>> caches -- Memcached, Coherence, etc. WO/EOF essentially has this >>>>>>> architecture (on the persistence side), but with local caches in the >>>>>>> snapshot cache that serve whatever sessions you send to it. With a >>>>>>> little bit of work with sharding your users, you can take advantage of >>>>>>> that by routing users to appropriate instances. >>>>>>> >>>>>>> The moral of the story is that every technology sucks, so you might as >>>>>>> well just build it fast so it can suck in production faster and you can >>>>>>> move on with your life. >>>>>>> >>>>>>> ms >>>>>>> >>>>>>> On Nov 15, 2010, at 8:02 PM, Chuck Hill wrote: >>>>>>> >>>>>>>> >>>>>>>> On Nov 15, 2010, at 4:53 PM, Ian Joyner wrote: >>>>>>>> >>>>>>>>> On 16 Nov 2010, at 11:35, David LeBer wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2010-11-15, at 7:09 PM, Ian Joyner wrote: >>>>>>>>>> >>>>>>>>>>> (Not that I'm doing any WO these days, but I still like to follow.) >>>>>>>>>>> >>>>>>>>>>> One thing that has always worried me about scalability is keeping >>>>>>>>>>> the per user "application state" on the server in WOSession. >>>>>>>>>>> Knowing more about REST now, this is very unrestful and not >>>>>>>>>>> stateless, which means will not scale. >>>>>>>>>> >>>>>>>>>> I don't see why something being unrestful and not stateless >>>>>>>>>> automatically equates to not being able to scale. Perhaps you could >>>>>>>>>> explain. >>>>>>>>> >>>>>>>>> The problem is that once you get 1000s and millions of users you have >>>>>>>>> the problem of memory size storing all that session information in >>>>>>>>> memory on the server. >>>>>>>> >>>>>>>> As with any system, the number of concurrent users that can be handled >>>>>>>> on a given server depends on both the application and the technology >>>>>>>> that it is built on. I will grant you that WO probably uses more >>>>>>>> memory per user than many technologies. But memory usage is only one >>>>>>>> part of the equation. >>>>>>>> >>>>>>>> >>>>>>>>> Server must also manage all these sessions - clean them out every so >>>>>>>>> often. And (in middleware systems I worked on in the 80s) keep track >>>>>>>>> of state transitions with FSMs, etc. >>>>>>>>> >>>>>>>>> Yes you need session state, ie context, but it should be kept on the >>>>>>>>> client, which sends it along with each request. Thus user state is >>>>>>>>> kept only on the client which makes recoverability easier too, >>>>>>>>> because if the server is rebooted, client can continue oblivious to >>>>>>>>> any problem. >>>>>>>> >>>>>>>> Yes, recoverability is a nice to have feature, but really how often is >>>>>>>> it actually needed? Restarts should be planned with the instances >>>>>>>> being set to Refuse New Sessions so that there are no active sessions >>>>>>>> on a machine when it is rebooted. So recoverability is only strictly >>>>>>>> needed for accidental restarts, kernel panics and such. >>>>>>>> >>>>>>>> The problem with keeping the WO state on the client is that WO keeps a >>>>>>>> LOT of state (EO, changed attributes, page cache, etc). You would >>>>>>>> need to have a finely tuned way of getting that back and forth from >>>>>>>> the client, otherwise performance would suffer mightily. >>>>>>>> >>>>>>>> Chuck >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> >>>>>>>>>>> How is this problem dealt with these days? WOnder? >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Ian >>>>>>>>>>> >>>>>>>>>>> On 16 Nov 2010, at 03:43, Greg Lappen wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi everyone, >>>>>>>>>>>> >>>>>>>>>>>> Based on using WO for the last 7 years, I have observed a couple >>>>>>>>>>>> of things that seem to be a performance bottleneck in WebObjects. >>>>>>>>>>>> I know that Apple uses WebObjects on a large scale for iTunes and >>>>>>>>>>>> ecommerce, so there must be solutions to these. >>>>>>>>>>>> >>>>>>>>>>>> #1 - Only one thread can be processing at once. I seem to recall >>>>>>>>>>>> that this is a limit in EnterpriseObjects but it's been a while. >>>>>>>>>>>> >>>>>>>>>>>> #2 - EnterpriseObjects caches every object from the database. >>>>>>>>>>>> >>>>>>>>>>>> With that being said, how can you horizontally scale your >>>>>>>>>>>> application layer? If you setup more instances of your app, they >>>>>>>>>>>> each have their own caches, which will be out of sync with each >>>>>>>>>>>> other. Is there a commonly used framework for doing distributed >>>>>>>>>>>> cache management? And is it possible to make your applications >>>>>>>>>>>> multithreaded so page requests can be processed concurrently? >>>>>>>>>>>> >>>>>>>>>>>> Thanks! >>>>>>>>>>>> >>>>>>>>>>>> Greg >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>>>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>>>>>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/ianjoyner%40me.com >>>>>>>>>>>> >>>>>>>>>>>> This email sent to ianjoy...@me.com >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>>>>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/dleber_wodev%40codeferous.com >>>>>>>>>>> >>>>>>>>>>> This email sent to dleber_wo...@codeferous.com >>>>>>>>>> >>>>>>>>>> ;david >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> David LeBer >>>>>>>>>> Codeferous Software >>>>>>>>>> 'co-def-er-ous' adj. Literally 'code-bearing' >>>>>>>>>> site: http://codeferous.com >>>>>>>>>> blog: http://davidleber.net >>>>>>>>>> profile: http://www.linkedin.com/in/davidleber >>>>>>>>>> twitter: http://twitter.com/rebeld >>>>>>>>>> -- >>>>>>>>>> Toronto Area Cocoa / WebObjects developers group: >>>>>>>>>> http://tacow.org >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net >>>>>>>>> >>>>>>>>> This email sent to ch...@global-village.net >>>>>>>> >>>>>>>> -- >>>>>>>> Chuck Hill Senior Consultant / VP Development >>>>>>>> >>>>>>>> Practical WebObjects - for developers who want to increase their >>>>>>>> overall knowledge of WebObjects or who are trying to solve specific >>>>>>>> problems. >>>>>>>> http://www.global-village.net/products/practical_webobjects >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.com >>>>>>>> >>>>>>>> This email sent to msch...@pobox.com >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Do not post admin requests to the list. They will be ignored. >>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>>>> Help/Unsubscribe/Update your Subscription: >>>>>> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.com >>>>>> >>>>>> This email sent to msch...@pobox.com >>>>> >>>> >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>> Help/Unsubscribe/Update your Subscription: >>>> http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net >>>> >>>> This email sent to ch...@global-village.net >>> >>> -- >>> Chuck Hill Senior Consultant / VP Development >>> >>> Practical WebObjects - for developers who want to increase their overall >>> knowledge of WebObjects or who are trying to solve specific problems. >>> http://www.global-village.net/products/practical_webobjects >>> >>> >>> >>> >>> >>> >>> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net >> >> This email sent to ch...@global-village.net > > -- > Chuck Hill Senior Consultant / VP Development > > Practical WebObjects - for developers who want to increase their overall > knowledge of WebObjects or who are trying to solve specific problems. > http://www.global-village.net/products/practical_webobjects > > > > > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/probert%40macti.ca > > This email sent to prob...@macti.ca _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
