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. >> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
