Re: [jug-discussion] App Dev Framework choices

[Nick Lesiecki]

   here is a movie where a NASA employee compares Ruby
EJB, and a few other technologies:


Sorry, just noticed this line giggled.

Nick

On Jun 25, 2006, at 5:57 AM, Erik Hatcher wrote:



On Jun 24, 2006, at 10:02 PM, josh zeidner wrote:

  Why is it that every Ruby expert that I run into has
absolutely nothing to show?


I've never claimed to be a Ruby expert, and it'll be quite a while  
before I could claim even being close.   I barely claim expertise  
in Java, and in that realm my expertise is not across the entire  
spectrum but rather focused on the web tier and 3rd party libraries  
and frameworks.


I've had two applications online in RoR, one was a  
railsplayground.com hosted one that is currently down - it was my  
first RoR app.  It scraped our local MLS site, looked up lat/long  
coordinates with geocoder.us and plotted homes on Google Maps.   
After seeing communitywalk, its not worth seeing, but it worked  
just fine and dandy and several realtors saw it and thought it  
would make a nice product.  If I was passionate about that domain,  
I'd have pursued it, but I'd rather play with words in academia.   
My current project does have one incantation of the RoR front-end  
online, but Kowari often crashes (though my custom search server  
stays up and running no problem).  I could point you to that  
incarnation, but its not fast enough to be impressive.  The new  
system will be up in a week or so when our sysadmin/project manager  
gets back from vacation.  And it is impressive, and looks  
gorgeous.  I haven't put up, or shut up, yet, eh?   Ha!  :)



but here is my word of advice to
potential IT buyers: INVEST IN PEOPLE NOT TECHNOLOGY.


No doubt.   My job title is "java programmer" but my role is really  
to use whatever technologies are the best fit to get the job done.   
And RoR just happens to be that for the front-end currently.




   here is a movie where a NASA employee compares Ruby
EJB, and a few other technologies:

  http://oodt.jpl.nasa.gov/better-web-app.mov


"rapid turn around", "scripting languages" are best for the UI, not  
"compiled languages".


I'm still watching, but its a good presentation so far.

Erik


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jug-discussion] App Dev Framework choices

[josh zeidner]

 btw- community walk is very similar to Ning.  Have
you ever seen Ning?  jmz


--- Chad Woolley <[EMAIL PROTECTED]> wrote:

> On 6/24/06, josh zeidner <[EMAIL PROTECTED]>
> wrote:
> >   Why is it that every Ruby expert that I run into
> has
> > absolutely nothing to show?
> 
> I'm definitely not an expert, but I just showed you
> http://communitywalk.com in another post. 
> http://zubio.com is another
> one we have done.  There are a couple of others that
> are mostly
> complete, but not released publicly yet, as well as
> an internal agile
> project-management app.
> 
> There's also this page:
>
http://wiki.rubyonrails.org/rails/pages/RealWorldUsage
> 
> -- Chad
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jug-discussion] App Dev Framework choices

[Erik Hatcher]

On Jun 24, 2006, at 10:02 PM, josh zeidner wrote:

  Why is it that every Ruby expert that I run into has
absolutely nothing to show?


I've never claimed to be a Ruby expert, and it'll be quite a while  
before I could claim even being close.   I barely claim expertise in  
Java, and in that realm my expertise is not across the entire  
spectrum but rather focused on the web tier and 3rd party libraries  
and frameworks.


I've had two applications online in RoR, one was a  
railsplayground.com hosted one that is currently down - it was my  
first RoR app.  It scraped our local MLS site, looked up lat/long  
coordinates with geocoder.us and plotted homes on Google Maps.  After  
seeing communitywalk, its not worth seeing, but it worked just fine  
and dandy and several realtors saw it and thought it would make a  
nice product.  If I was passionate about that domain, I'd have  
pursued it, but I'd rather play with words in academia.  My current  
project does have one incantation of the RoR front-end online, but  
Kowari often crashes (though my custom search server stays up and  
running no problem).  I could point you to that incarnation, but its  
not fast enough to be impressive.  The new system will be up in a  
week or so when our sysadmin/project manager gets back from  
vacation.  And it is impressive, and looks gorgeous.  I haven't put  
up, or shut up, yet, eh?   Ha!  :)



but here is my word of advice to
potential IT buyers: INVEST IN PEOPLE NOT TECHNOLOGY.


No doubt.   My job title is "java programmer" but my role is really  
to use whatever technologies are the best fit to get the job done.   
And RoR just happens to be that for the front-end currently.




   here is a movie where a NASA employee compares Ruby
EJB, and a few other technologies:

  http://oodt.jpl.nasa.gov/better-web-app.mov


"rapid turn around", "scripting languages" are best for the UI, not  
"compiled languages".


I'm still watching, but its a good presentation so far.

Erik


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jug-discussion] App Dev Framework choices

[Chad Woolley]

On 6/24/06, josh zeidner <[EMAIL PROTECTED]> wrote:

  Why is it that every Ruby expert that I run into has
absolutely nothing to show?


I'm definitely not an expert, but I just showed you
http://communitywalk.com in another post.  http://zubio.com is another
one we have done.  There are a couple of others that are mostly
complete, but not released publicly yet, as well as an internal agile
project-management app.

There's also this page: http://wiki.rubyonrails.org/rails/pages/RealWorldUsage

-- Chad

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jug-discussion] App Dev Framework choices

[josh zeidner]

--- Erik Hatcher <[EMAIL PROTECTED]> wrote:

> 
> On Jun 24, 2006, at 5:15 PM, josh zeidner wrote:
> >After having worked with countless web
> frameworks
> > and dozens of languages I will say this:  What you
> > gain in development effort and 'syntactic sugar'
> you
> > lose in performance.
> 
> But Ruby is not just a sugar coating of syntax.


  I know, its a brave new world of app development...
maybe im just getting older but this stuff is really
beginning to lose its luster for me.  Why is it that
people absolutely refuse to accept the fact that there
are no silver bullet solutions?  I guess in a sales
situation it is very hard to make a sale when youre
competing against some bozo who is promising the world
for penny.  Always going for the quick buck.  BTW- I
hear the real estate market in Tucson is getting
trippy.  And so it goes...


> 
> >   As all these sites prop up I
> > just give it a year or two before people start
> > marketing themselves as experts in 'optimizing'
> RoR,
> > so they can sell the solutions to the performance
> > problems that the 'peace and contentment' caused.
> 
> Perhaps.  There will certainly be the need for
> skilled folks in the  
> RoR space in terms of deployment.  You asked what
> sites I've  
> deployed.  At this point I don't have anything
> visible in production, 


  Why is it that every Ruby expert that I run into has
absolutely nothing to show?

 
> primarily because I'm in a small academic group that
> has little  
> sysadmin skills and servers to push what I've
> developed out.  We do  
> have a previous version online using RoR interacting
> with Kowari and  
> a custom XML-RPC Lucene search server.  We'll be
> putting the new and  
> improved version with Solr replacing both the other
> two pieces  
> shortly.   Once that is up, I'll be announcing it. 
> I run the system  
> locally in development mode and it's doing quite
> well with no RoR  
> caching, but we will certainly be enabling the
> caching facilities  
> that RoR slickly offers as we need it.
> 
> > Very similar with EJB and CMP. EJB offered a
> > simplistic layer of abstaction  that made data
> > management simpler
> 
> Uh, you must have used a different EJB than I did.
 

  Well i started with EJB before Sun even used the
term j2EE.  I think it was probably '98.  Back then
EJB was being sold as a nifty 'three tiered solution'
to your web site woes( Websphere, at the time was not
even an EJB server ).  And it was simple.  At first. 
It didnt have block enumerations though and I think
that it will be block enumerations that will save RoR
from the same fate of every other app framework in
existence. :)

  So EJB got bigger and fatter, and alternatives
Sprung up, etc... but here is my word of advice to
potential IT buyers: INVEST IN PEOPLE NOT TECHNOLOGY.

   here is a movie where a NASA employee compares Ruby
EJB, and a few other technologies:

  http://oodt.jpl.nasa.gov/better-web-app.mov

> I don't have any  
> happy experiences with EJB in practice or even in
> theory.  But then  
> again, I'm not even fond of relational databases in
> practice no  
> matter how they are accessed... but ActiveRecord has
> made me smile a  
> lot lately.
> 
> >   Having witnessed the Web 2.0 sleaziness first
> hand,
> > I do not trust anything that is associated with
> that
> > world.  If you want to deliver something really
> good
> > to your client, give them standards that are
> > unencumbered by licenscing constraints( where it
> is
> > affordable of course ).
> 
> I'm not following what you mean here... how does the
> "Web 2.0" world  
> relate to licensing constraints?

  Well im not going to go that much into it, but Web
2.0 turns out to be a service mark owned by CMP Media
LLC. 



  -josh

> 
> >I still do respect Java as a language because
> the
> > semantics are well established
> 
> I'm quite happy with Java as well, and I do more
> coding in it than in  
> Ruby still.
> 
>   Erik
> 
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jug-discussion] App Dev Framework choices

[Erik Hatcher]

On Jun 24, 2006, at 5:15 PM, josh zeidner wrote:

   After having worked with countless web frameworks
and dozens of languages I will say this:  What you
gain in development effort and 'syntactic sugar' you
lose in performance.


But Ruby is not just a sugar coating of syntax.


  As all these sites prop up I
just give it a year or two before people start
marketing themselves as experts in 'optimizing' RoR,
so they can sell the solutions to the performance
problems that the 'peace and contentment' caused.


Perhaps.  There will certainly be the need for skilled folks in the  
RoR space in terms of deployment.  You asked what sites I've  
deployed.  At this point I don't have anything visible in production,  
primarily because I'm in a small academic group that has little  
sysadmin skills and servers to push what I've developed out.  We do  
have a previous version online using RoR interacting with Kowari and  
a custom XML-RPC Lucene search server.  We'll be putting the new and  
improved version with Solr replacing both the other two pieces  
shortly.   Once that is up, I'll be announcing it.  I run the system  
locally in development mode and it's doing quite well with no RoR  
caching, but we will certainly be enabling the caching facilities  
that RoR slickly offers as we need it.



Very similar with EJB and CMP. EJB offered a
simplistic layer of abstaction  that made data
management simpler


Uh, you must have used a different EJB than I did.  I don't have any  
happy experiences with EJB in practice or even in theory.  But then  
again, I'm not even fond of relational databases in practice no  
matter how they are accessed... but ActiveRecord has made me smile a  
lot lately.



  Having witnessed the Web 2.0 sleaziness first hand,
I do not trust anything that is associated with that
world.  If you want to deliver something really good
to your client, give them standards that are
unencumbered by licenscing constraints( where it is
affordable of course ).


I'm not following what you mean here... how does the "Web 2.0" world  
relate to licensing constraints?



   I still do respect Java as a language because the
semantics are well established


I'm quite happy with Java as well, and I do more coding in it than in  
Ruby still.


Erik


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jug-discussion] App Dev Framework choices

[Chad Woolley]

Well, lets be empirical.  Here's a real Rails site: http://communitywalk.com

communitywalk.com is a RoR site that was developed at my current
employer, usually by one or two pairs at a time, with most of the work
done by the site owner (who is an employee too).  I didn't work on it
much (was mostly done when I came on), but I'd say they probably spent
about 2-3 pair months of the total dev time optimizing performance.
Maybe a lot less.

It's a cool site, and it performs pretty well.  I guess you'd call it
Web 2.0, there's Google maps and lots of Javascript, but I wouldn't
call it sleazy :)

We're currently running it (MySql DB and Lighty/Rails) on a single Xen
virtual machine on a new Xeon box.  I think it's about in the 30-40
Gig/month bandwidth range - not sure on hits.  Not huge traffic, but
not tiny, considering it's all on one box.  How would you quantify an
impressive load for a site to handle and still have good performance?

-- Chad

On 6/24/06, josh zeidner <[EMAIL PROTECTED]> wrote:



  Hi Erik,

   After having worked with countless web frameworks
and dozens of languages I will say this:  What you
gain in development effort and 'syntactic sugar' you
lose in performance.  As all these sites prop up I
just give it a year or two before people start
marketing themselves as experts in 'optimizing' RoR,
so they can sell the solutions to the performance
problems that the 'peace and contentment' caused.
Very similar with EJB and CMP. EJB offered a
simplistic layer of abstaction  that made data
management simpler, but also caused a huge expense in
the management of the EJB container!  Secondly, if
Ruby can offer more to the client, then the RoR
programmer will charge more!  Aren't labor economics
fun?  EJB in the end, didnt save anyone a cent.  There
is nothing new under the sun, but there is a never
ending supply of idiots and people willing to pay
them.

  Having witnessed the Web 2.0 sleaziness first hand,
I do not trust anything that is associated with that
world.  If you want to deliver something really good
to your client, give them standards that are
unencumbered by licenscing constraints( where it is
affordable of course ).

   I still do respect Java as a language because the
semantics are well established.  The changes that it
introduced to C++ syntax were well accounted for.


  sincerely, jmz

--- Erik Hatcher <[EMAIL PROTECTED]> wrote:

>
> On Jun 21, 2006, at 9:08 PM, josh zeidner wrote:
> >   RoR: Why?  because its Web 2.0( see CMP Media
> > scandal ).  The whole Web 2.0 thing( which RoR is
> > invariably linked to  ) has turned out to be a
> very
> > stupid multi-level marketing scheme starring Tim
> > O'Reilly.  RoR offers no technological advantages
> over
> > existing scripting languages, despite the magical
> > claims of its proponents.
>
> My good (virtual) friend, Brent Ashley told me
> recently "if Jesse
> James Garret is the father of AJAX, then you and I
> are the mailmen
> that all the kids look like".  Back in the Tucson
> days, between
> getting .bombed by Running Start and starting at
> eBlox I wrote an
> article about Remote Scripting for developerWorks
> which was my first
> foray into technical writing.
>
> No technological advantage?  I disagree.  The
> brevity and
> readability... let's just say "succintness" most
> definitely is
> advantageous.   For example, to wire up a
> Google-Suggest-like drop-
> down box I put this in my template:
>
>   <%= text_field_with_auto_complete :agent, :name,
> :size => 20 %>
>
> And there is a controller method that generates the
>  that gets
> rendered.  There is a lot of convention, over
> configuration, and
> sometimes that is a bit too "magical" even for my
> tastes.
>
> But I can confidently say that RoR will be my
> preferred front-end
> technology for the foreseeable future and with
> loosely coupled back-
> end technologies, such as Solr, it's trivial to tie
> the best of breed
> pieces together, Java (or otherwise).
>
>   Erik
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jug-discussion] App Dev Framework choices

[josh zeidner]

  Hi Erik,

   After having worked with countless web frameworks
and dozens of languages I will say this:  What you
gain in development effort and 'syntactic sugar' you
lose in performance.  As all these sites prop up I
just give it a year or two before people start
marketing themselves as experts in 'optimizing' RoR,
so they can sell the solutions to the performance
problems that the 'peace and contentment' caused. 
Very similar with EJB and CMP. EJB offered a
simplistic layer of abstaction  that made data
management simpler, but also caused a huge expense in
the management of the EJB container!  Secondly, if
Ruby can offer more to the client, then the RoR
programmer will charge more!  Aren't labor economics
fun?  EJB in the end, didnt save anyone a cent.  There
is nothing new under the sun, but there is a never
ending supply of idiots and people willing to pay
them.

  Having witnessed the Web 2.0 sleaziness first hand,
I do not trust anything that is associated with that
world.  If you want to deliver something really good
to your client, give them standards that are
unencumbered by licenscing constraints( where it is
affordable of course ).

   I still do respect Java as a language because the
semantics are well established.  The changes that it
introduced to C++ syntax were well accounted for.  


  sincerely, jmz

--- Erik Hatcher <[EMAIL PROTECTED]> wrote:

> 
> On Jun 21, 2006, at 9:08 PM, josh zeidner wrote:
> >   RoR: Why?  because its Web 2.0( see CMP Media
> > scandal ).  The whole Web 2.0 thing( which RoR is
> > invariably linked to  ) has turned out to be a
> very
> > stupid multi-level marketing scheme starring Tim
> > O'Reilly.  RoR offers no technological advantages
> over
> > existing scripting languages, despite the magical
> > claims of its proponents.
> 
> My good (virtual) friend, Brent Ashley told me
> recently "if Jesse  
> James Garret is the father of AJAX, then you and I
> are the mailmen  
> that all the kids look like".  Back in the Tucson
> days, between  
> getting .bombed by Running Start and starting at
> eBlox I wrote an  
> article about Remote Scripting for developerWorks
> which was my first  
> foray into technical writing.
> 
> No technological advantage?  I disagree.  The
> brevity and  
> readability... let's just say "succintness" most
> definitely is  
> advantageous.   For example, to wire up a
> Google-Suggest-like drop- 
> down box I put this in my template:
> 
>   <%= text_field_with_auto_complete :agent, :name,
> :size => 20 %>
> 
> And there is a controller method that generates the
>  that gets  
> rendered.  There is a lot of convention, over
> configuration, and  
> sometimes that is a bit too "magical" even for my
> tastes.
> 
> But I can confidently say that RoR will be my
> preferred front-end  
> technology for the foreseeable future and with
> loosely coupled back- 
> end technologies, such as Solr, it's trivial to tie
> the best of breed  
> pieces together, Java (or otherwise).
> 
>   Erik
> 
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jug-discussion] App Dev Framework choices

[josh zeidner]

 Its no where near the level of peace and contentment
that ruby offers.  There's just something so darn cool
about Ruby I cant seem to put my finger on it.  Maybe
its the cool graphics.  Maybe its the videos and the
fact that ruby programmers use Macs.  Maybe its that
it hasent showed up on India's radar just yet.




--- Drew Davidson <[EMAIL PROTECTED]> wrote:

> And in OGNL it's similar to apply an expression to
> any collection, 
> enumeration or iterator:
> 
> parent.children.{ #this.doSomething() }
> 
> or you can filter any collection, enumeration or
> iterator using
> 
> filteredItems = parent.children.{?
> name.startsWith("foo") }
> 
> This is what Buddha would have used for an
> expression language.
> 
> - Drew
> // OGNL since 1998
> 
> josh zeidner wrote:
> 
> >Thomas,
> >
> > I was about to say practically the same thing... 
> in
> >python:
> >
> > foreach( SomeObject )
> >
> > It amazing!  Its going save us billions in
> >development costs!  Crom the Mighty, the patron
> diety
> >of Ruby on Rails is very pleased with block
> >enumerators.
> >
> > Do they pass out pills at Ruby user group
> meetings?
> >
> > -jmz
> >
> >
> >--- Thomas Hicks <[EMAIL PROTECTED]> wrote:
> >
> >  
> >
> >>At 09:44 AM 6/22/2006, Chad wrote:
> >>
> >>
> >>
> >>>Cool.  I checked out the REXML page.  This quote
> is
> >>>  
> >>>
> >>great:
> >>
> >>
> >>>
> >>>"Some of the common differences are that the Ruby
> >>>  
> >>>
> >>API relies on block
> >>
> >>
> >>>enumerations, rather than iterators. For example,
> >>>  
> >>>
> >>the Java code:
> >>
> >>
> >>>for (Enumeration e=parent.getChildren();
> >>>  
> >>>
> >>e.hasMoreElements(); ) {
> >>
> >>
> >>> Element child = (Element)e.nextElement(); // Do
> >>>  
> >>>
> >>something with child
> >>
> >>
> >>>}
> >>>
> >>>in Ruby becomes:
> >>>
> >>>parent.each_child{ |child| # Do something with
> >>>  
> >>>
> >>child }
> >>
> >>
> >>>Can't you feel the peace and contentment in this
> >>>  
> >>>
> >>block of code? Ruby
> >>
> >>
> >>>is the language Buddha would have programmed in."
> >>>---
> >>>  
> >>>
> >>Dr. Ralph Griswold (creator or SNOBOL and Icon
> >>programming languages)
> >>used to say that there's really nothing new under
> >>the sun in CS, it's all
> >>recycled. I have to note that this statement form
> >>you admire so much comes
> >>directly from Smalltalk of 20 years ago!
> >> regards,
> >> -tom
> >>
> >>
> >>
> >>
> >>
> >>
>
>-
> >  
> >
> >>To unsubscribe, e-mail:
> >>[EMAIL PROTECTED]
> >>For additional commands, e-mail:
> >>[EMAIL PROTECTED]
> >>
> >>
> >>
> >>
> >
> >
> >__
> >Do You Yahoo!?
> >Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> >http://mail.yahoo.com 
> >
>
>-
> >To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> >For additional commands, e-mail:
> [EMAIL PROTECTED]
> >
> >
> >
> >  
> >
> 
> -- 
> +-+
> < Drew Davidson | OGNL Technology >
> +-+
> |  Email: [EMAIL PROTECTED]  /
> |Web: http://www.ognl.org   /
> |Vox: (520) 531-1966   <
> |Fax: (520) 531-1965\
> | Mobile: (520) 405-2967 \
> +-+
> 
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jug-discussion] App Dev Framework choices

[josh zeidner]

  Just curious, what sites have you done using RoR?

  -jmz


--- Erik Hatcher <[EMAIL PROTECTED]> wrote:

> 
> On Jun 22, 2006, at 12:44 PM, Chad Woolley wrote:
> > Can't you feel the peace and contentment in this
> block of code? Ruby
> > is the language Buddha would have programmed in."
> 
> Yeah, being pragmatic, Buddha probably would be
> using RoR.  The more  
> idealistic of us would likely be doing Smalltalk.
> 
> > After reading several thousand blogs which argue
> the pros and cons of
> > RoR and seeing it used in a real shop, I think the
> benefit does
> > largely come down to the Ruby language itself.
> 
> Bingo.  Rails is only good *because* of Ruby.  The
> dynamic "magic"  
> that can be pulled to create very elegant looking
> DSLs (domain- 
> specific languages) is the secret sauce that makes
> Rails what is.   
> Sure, you can do wacky reflective stuff in Java and
> get close, but  
> the natures of those languages are different at a
> core layer.
> 
> > Of course there's still
> > big cons compared to Java - my main gripes are
> lack of a real
> > refactoring, intelligent code-completing IDE
> 
> Many gripe about this.  Personally I have had great
> success being  
> interactive and using IRB tab completion to explore
> and learn an  
> API.  In Rails, script/console is amazing - your
> entire Rails  
> environment immediately accessible live.
> 
> > , and lack of something as
> > nice as Maven to automatically manage your
> external and cross-project
> > dependencies.
> 
> RubyGems manages 3rd party library dependencies
> nicely, and with  
> Rails you can "freeze" it to a particular project. 
> There is also  
> Capistrano (formerly Switchtower) for project
> automation such as  
> testing and deployment.  I'm not aware of much in
> the way of  
> automated deployment tools in the Java world that
> compares to  
> Capistrano.  Its much trickier to generically deploy
> a Java  
> application because of the various ways every
> application server  
> deploys.
> 
> > Oh, and speaking of XML parsing performance - AJAX
> is now officially
> > old news.  AJAJ (Async Javascript And JSON,
> Javascript Serialized
> > Object Notation) is the wave of the future.  We
> don't need no stinking
> > XML!
> 
> Sending back XML was old news almost a decade ago.
> 
>   Erik
> 
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jug-discussion] App Dev Framework choices

[Drew Davidson]

And in OGNL it's similar to apply an _expression_ to any collection,
enumeration or iterator:

    parent.children.{ #this.doSomething() }

or you can filter any collection, enumeration or iterator using

    filteredItems = parent.children.{? name.startsWith("foo") }

This is what Buddha would have used for an _expression_ language.

- Drew
// OGNL since 1998

josh zeidner wrote:

  Thomas,

 I was about to say practically the same thing...  in
python:

 foreach( SomeObject )

 It amazing!  Its going save us billions in
development costs!  Crom the Mighty, the patron diety
of Ruby on Rails is very pleased with block
enumerators.

 Do they pass out pills at Ruby user group meetings?

 -jmz


--- Thomas Hicks <[EMAIL PROTECTED]> wrote:

  
  
At 09:44 AM 6/22/2006, Chad wrote:



  Cool.  I checked out the REXML page.  This quote is
  

great:


  
"Some of the common differences are that the Ruby
  

API relies on block


  enumerations, rather than iterators. For example,
  

the Java code:


  for (Enumeration e=parent.getChildren();
  

e.hasMoreElements(); ) {


   Element child = (Element)e.nextElement(); // Do
  

something with child


  }

in Ruby becomes:

parent.each_child{ |child| # Do something with
  

child }


  Can't you feel the peace and contentment in this
  

block of code? Ruby


  is the language Buddha would have programmed in."
---
  


Dr. Ralph Griswold (creator or SNOBOL and Icon
programming languages)
used to say that there's really nothing new under
the sun in CS, it's all
recycled. I have to note that this statement form
you admire so much comes
directly from Smalltalk of 20 years ago!
 regards,
 -tom





  
  -
  
  
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]



  
  

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



  


-- 
+-+
< Drew Davidson | OGNL Technology >
+-+
|  Email: [EMAIL PROTECTED]  /
|Web: http://www.ognl.org   /
|Vox: (520) 531-1966   <
|Fax: (520) 531-1965\
| Mobile: (520) 405-2967 \
+-+

Re: [jug-discussion] App Dev Framework choices

[Chad Woolley]

On 6/23/06, Erik Hatcher <[EMAIL PROTECTED]> wrote:


RubyGems manages 3rd party library dependencies nicely, and with
Rails you can "freeze" it to a particular project.  There is also
Capistrano (formerly Switchtower) for project automation such as
testing and deployment.  I'm not aware of much in the way of
automated deployment tools in the Java world that compares to
Capistrano.  Its much trickier to generically deploy a Java
application because of the various ways every application server
deploys.


Gems comes close, but is lacking in some important ways.  What Maven
does is give you a single standard place and format to define all your
dependencies, and *automatically* makes sure that they all exist on
every environment/machine.


There's nothing like that in Ruby/Rails that I know of.  You have to
manually install all required gems on each machine, and unless you are
disciplined, you don't know by looking at your app what gems are used,
and where.  Gems basically just gives you a way to version projects
and automatically download them.

Even worse, for some reason, the Rails folks love to "freeze" complete
directory trees of third-party projects under the vendor dir, with
plugins, engines, and such.  This is a mess waiting to be happen,
because you know you are going to modify that code and then you  have
to live with that version from then on or deal with merging.  You can
make this a little less painful using SVN externals.  However, it
still seems very cluttered and ugly, especially coming from a clean
Java/Maven environment where every version of every dependency is
nicely packaged as a zip file and automatically downloaded from a
central repository.

We've ended up using a combination of SVN externals and custom Rails
engines to abstract our our common custom code across projects.
Without auto-downloads, the Gem approach isn't worth it - SVN
externals is a lot closer to making it always automatically available
in every project.

We also use Capistrano for all our deploys.  It's a nice tool, and
with Migrations it makes deploys pretty painless.  I still miss
atomic, versioned zipfile artifacts like WARs and EARs, though.
Capistrano also doesn't do anything to help you if you want to manage
filesystem data like user photos, etc. - especially if you want to do
rollbacks in that scenario.

Anyway, Ruby and all detractors aside, they have put together a lot of
cool stuff in Rails, even if it's all been done before.  Personally, I
think Migrations is the contender for the coolest thing about Rails,
and I don't know of anywhere previously that database version
management was done as cleanly and elegantly as in Rails (and I did a
lot of looking prior to Rails coming out).

-- Chad

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jug-discussion] App Dev Framework choices

[Erik Hatcher]

And if you want to be wowed by what a difference a programming  
language makes, check out the video of DabbleDB:




Sure, you could program this same thing in Perl CGI, assembly  
language, C, Java, etc, but it was done using Seaside and the beauty  
of what is underneath shines through to the end product.


Erik


On Jun 22, 2006, at 4:08 PM, Andrew Lenards wrote:


There was a Smalltalk/Squeak web framework that got some noticed at
OOPSLA 2004 called Seaside 2.  I think there was a similar version
done for Java called Lakeshore.

On 6/22/06, Chad Woolley <[EMAIL PROTECTED]> wrote:

On 6/22/06, Thomas Hicks <[EMAIL PROTECTED]> wrote:
> Dr. Ralph Griswold (creator or SNOBOL and Icon programming  
languages)
> used to say that there's really nothing new under the sun in CS,  
it's all

> recycled.

Yep, you certainly can get a lot of mileage out of just 1's and  
0's...


>  I have to note that this statement form you admire so much comes
> directly from Smalltalk of 20 years ago!

So why hasn't anyone come up with Smalltalk On RailS (SOReS)?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jug-discussion] App Dev Framework choices

[Erik Hatcher]

On Jun 22, 2006, at 12:44 PM, Chad Woolley wrote:

Can't you feel the peace and contentment in this block of code? Ruby
is the language Buddha would have programmed in."


Yeah, being pragmatic, Buddha probably would be using RoR.  The more  
idealistic of us would likely be doing Smalltalk.



After reading several thousand blogs which argue the pros and cons of
RoR and seeing it used in a real shop, I think the benefit does
largely come down to the Ruby language itself.


Bingo.  Rails is only good *because* of Ruby.  The dynamic "magic"  
that can be pulled to create very elegant looking DSLs (domain- 
specific languages) is the secret sauce that makes Rails what is.   
Sure, you can do wacky reflective stuff in Java and get close, but  
the natures of those languages are different at a core layer.



Of course there's still
big cons compared to Java - my main gripes are lack of a real
refactoring, intelligent code-completing IDE


Many gripe about this.  Personally I have had great success being  
interactive and using IRB tab completion to explore and learn an  
API.  In Rails, script/console is amazing - your entire Rails  
environment immediately accessible live.



, and lack of something as
nice as Maven to automatically manage your external and cross-project
dependencies.


RubyGems manages 3rd party library dependencies nicely, and with  
Rails you can "freeze" it to a particular project.  There is also  
Capistrano (formerly Switchtower) for project automation such as  
testing and deployment.  I'm not aware of much in the way of  
automated deployment tools in the Java world that compares to  
Capistrano.  Its much trickier to generically deploy a Java  
application because of the various ways every application server  
deploys.



Oh, and speaking of XML parsing performance - AJAX is now officially
old news.  AJAJ (Async Javascript And JSON, Javascript Serialized
Object Notation) is the wave of the future.  We don't need no stinking
XML!


Sending back XML was old news almost a decade ago.

Erik


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jug-discussion] App Dev Framework choices

[Erik Hatcher]

On Jun 21, 2006, at 9:08 PM, josh zeidner wrote:

  RoR: Why?  because its Web 2.0( see CMP Media
scandal ).  The whole Web 2.0 thing( which RoR is
invariably linked to  ) has turned out to be a very
stupid multi-level marketing scheme starring Tim
O'Reilly.  RoR offers no technological advantages over
existing scripting languages, despite the magical
claims of its proponents.


My good (virtual) friend, Brent Ashley told me recently "if Jesse  
James Garret is the father of AJAX, then you and I are the mailmen  
that all the kids look like".  Back in the Tucson days, between  
getting .bombed by Running Start and starting at eBlox I wrote an  
article about Remote Scripting for developerWorks which was my first  
foray into technical writing.


No technological advantage?  I disagree.  The brevity and  
readability... let's just say "succintness" most definitely is  
advantageous.   For example, to wire up a Google-Suggest-like drop- 
down box I put this in my template:


<%= text_field_with_auto_complete :agent, :name, :size => 20 %>

And there is a controller method that generates the  that gets  
rendered.  There is a lot of convention, over configuration, and  
sometimes that is a bit too "magical" even for my tastes.


But I can confidently say that RoR will be my preferred front-end  
technology for the foreseeable future and with loosely coupled back- 
end technologies, such as Solr, it's trivial to tie the best of breed  
pieces together, Java (or otherwise).


Erik


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jug-discussion] App Dev Framework choices

[Andrew Lenards]

There was a Smalltalk/Squeak web framework that got some noticed at
OOPSLA 2004 called Seaside 2.  I think there was a similar version
done for Java called Lakeshore.

On 6/22/06, Chad Woolley <[EMAIL PROTECTED]> wrote:

On 6/22/06, Thomas Hicks <[EMAIL PROTECTED]> wrote:
> Dr. Ralph Griswold (creator or SNOBOL and Icon programming languages)
> used to say that there's really nothing new under the sun in CS, it's all
> recycled.

Yep, you certainly can get a lot of mileage out of just 1's and 0's...

>  I have to note that this statement form you admire so much comes
> directly from Smalltalk of 20 years ago!

So why hasn't anyone come up with Smalltalk On RailS (SOReS)?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jug-discussion] App Dev Framework choices

[Chad Woolley]

On 6/22/06, Thomas Hicks <[EMAIL PROTECTED]> wrote:

Dr. Ralph Griswold (creator or SNOBOL and Icon programming languages)
used to say that there's really nothing new under the sun in CS, it's all
recycled.


Yep, you certainly can get a lot of mileage out of just 1's and 0's...


 I have to note that this statement form you admire so much comes
directly from Smalltalk of 20 years ago!


So why hasn't anyone come up with Smalltalk On RailS (SOReS)?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jug-discussion] App Dev Framework choices

[josh zeidner]

Thomas,

 I was about to say practically the same thing...  in
python:

 foreach( SomeObject )

 It amazing!  Its going save us billions in
development costs!  Crom the Mighty, the patron diety
of Ruby on Rails is very pleased with block
enumerators.

 Do they pass out pills at Ruby user group meetings?

 -jmz


--- Thomas Hicks <[EMAIL PROTECTED]> wrote:

> At 09:44 AM 6/22/2006, Chad wrote:
> 
> >Cool.  I checked out the REXML page.  This quote is
> great:
> >
> >
> >"Some of the common differences are that the Ruby
> API relies on block
> >enumerations, rather than iterators. For example,
> the Java code:
> >
> >for (Enumeration e=parent.getChildren();
> e.hasMoreElements(); ) {
> >  Element child = (Element)e.nextElement(); // Do
> something with child
> >}
> >
> >in Ruby becomes:
> >
> >parent.each_child{ |child| # Do something with
> child }
> >
> >Can't you feel the peace and contentment in this
> block of code? Ruby
> >is the language Buddha would have programmed in."
> >---
> 
> 
> Dr. Ralph Griswold (creator or SNOBOL and Icon
> programming languages)
> used to say that there's really nothing new under
> the sun in CS, it's all
> recycled. I have to note that this statement form
> you admire so much comes
> directly from Smalltalk of 20 years ago!
>  regards,
>  -tom
> 
> 
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jug-discussion] App Dev Framework choices

[Thomas Hicks]

At 09:44 AM 6/22/2006, Chad wrote:


Cool.  I checked out the REXML page.  This quote is great:


"Some of the common differences are that the Ruby API relies on block
enumerations, rather than iterators. For example, the Java code:

for (Enumeration e=parent.getChildren(); e.hasMoreElements(); ) {
 Element child = (Element)e.nextElement(); // Do something with child
}

in Ruby becomes:

parent.each_child{ |child| # Do something with child }

Can't you feel the peace and contentment in this block of code? Ruby
is the language Buddha would have programmed in."
---



Dr. Ralph Griswold (creator or SNOBOL and Icon programming languages)
used to say that there's really nothing new under the sun in CS, it's all
recycled. I have to note that this statement form you admire so much comes
directly from Smalltalk of 20 years ago!
regards,
-tom



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jug-discussion] App Dev Framework choices

[Chad Woolley]

On 6/21/06, Erik Hatcher <[EMAIL PROTECTED]> wrote:


On Jun 21, 2006, at 12:35 PM, Chad Woolley wrote:
> "lowercase" web services?  What do you use to talk XML on the RoR
> side?   One of the Ruby SOAP implementations, something homegrown, or
> something else?

I'm currently using REXML to parse the responses, and its working
fine.  But I think REXML's performance is not quite as quick as
perhaps sending back YAML or even Ruby code to eval.  Solr has a
custom response handler hook so XML is not required, just the default.

By "lowercase" web services I mean it's a service, and it's on the
web, but it's not heavy SOAP.


Cool.  I checked out the REXML page.  This quote is great:


"Some of the common differences are that the Ruby API relies on block
enumerations, rather than iterators. For example, the Java code:

for (Enumeration e=parent.getChildren(); e.hasMoreElements(); ) {
 Element child = (Element)e.nextElement(); // Do something with child
}

in Ruby becomes:

parent.each_child{ |child| # Do something with child }

Can't you feel the peace and contentment in this block of code? Ruby
is the language Buddha would have programmed in."
---

After reading several thousand blogs which argue the pros and cons of
RoR and seeing it used in a real shop, I think the benefit does
largely come down to the Ruby language itself.  Once you learn all the
idioms, it's really easy to get stuff done.  Of course there's still
big cons compared to Java - my main gripes are lack of a real
refactoring, intelligent code-completing IDE, and lack of something as
nice as Maven to automatically manage your external and cross-project
dependencies.

Oh, and speaking of XML parsing performance - AJAX is now officially
old news.  AJAJ (Async Javascript And JSON, Javascript Serialized
Object Notation) is the wave of the future.  We don't need no stinking
XML!

-- Chad

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [jug-discussion] App Dev Framework choices

[Rick Hightower]

H... I get it now.

-Original Message-
From: Thomas Hicks [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 21, 2006 8:00 PM
To: jug-discussion@tucson-jug.org
Subject: RE: [jug-discussion] App Dev Framework choices

I believe she was applauding your inclusion of "human aspects" factors
in making a technological decision and sarcastically saying that was
blasphemy. I'm afraid Cara's getting kind of cynical after working at
her current job location. They tend to be ratherum.behind on
the technology and process management curve.
 -tom


At 12:36 PM 6/21/2006, you wrote:
>Flame bait?
>
>
>
>--
>From: cara [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, June 21, 2006 9:17 AM
>To: jug-discussion@tucson-jug.org
>Subject: Re: [jug-discussion] App Dev Framework choices
>
>On 6/20/06, Rick Hightower 
><<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> wrote:
>[snip]
>
>Injection via an abstract getter, anyone?  Shudder?
>
>shudder.
>
>I think I have grasped it (but I enjoy complex stuff), but to use it on a
>large team... YIKES! There is going to be a lot of developer body bags.
>
>
>[snip]
>
>Granted Tapestry is very powerful however that power begets complexity.
>Tapestry 5 should focus on developer productivity.
>
>Well you asked.
>
>
>Blasphemer! Blasphemer!
>
>I can't take it. Comments and opinions about the human aspects of 
>picking a technology!? How big is the project? How many developers? 
>Developer team skill levels? Will someone random have to 
>maintain/install it? How bloody much money do we have to do the 
>project? Blasphemy!



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [jug-discussion] App Dev Framework choices

[Thomas Hicks]

I believe she was applauding your inclusion of "human aspects" factors
in making a technological decision and sarcastically saying that was
blasphemy. I'm afraid Cara's getting kind of cynical after working at
her current job location. They tend to be ratherum.behind on
the technology and process management curve.
-tom


At 12:36 PM 6/21/2006, you wrote:

Flame bait?



--
From: cara [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 21, 2006 9:17 AM
To: jug-discussion@tucson-jug.org
Subject: Re: [jug-discussion] App Dev Framework choices

On 6/20/06, Rick Hightower 
<<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> wrote:

[snip]

Injection via an abstract getter, anyone?  Shudder?

shudder.

I think I have grasped it (but I enjoy complex stuff), but to use it on a
large team... YIKES! There is going to be a lot of developer body bags.


[snip]

Granted Tapestry is very powerful however that power begets complexity.
Tapestry 5 should focus on developer productivity.

Well you asked.


Blasphemer! Blasphemer!

I can't take it. Comments and opinions about the human aspects of 
picking a technology!? How big is the project? How many developers? 
Developer team skill levels? Will someone random have to 
maintain/install it? How bloody much money do we have to do the 
project? Blasphemy!




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jug-discussion] App Dev Framework choices

[Jon Thomas]

I have to step in here and clarify that Rick (I'm sure) was being  
tongue in cheek.

If he is anything he is the guy you turn to to clean out bloat.

I assume it was recognized throughout the list that he was joking,  
but in case it was not, let me clarify for anyone who doesn't know  
him...he was.


I work neither for nor with Rick but I have done both and he is on my  
one hand list of those I'd love to work with Anytime (fwiw the others  
include Nick, Erik, and Andy B., as well as Art who is lurking  
somewhere on this list).


peaceOut.
Jt


On Jun 21, 2006, at 10:14 AM, josh zeidner wrote:




--- Rick Hightower <[EMAIL PROTECTED]> wrote:


Since I am a consulting, I give advice, but will
happily work with Tapestry
or JSF.

Being a capitalist, I tend to pick the one with the
highest bill rate. :o)


  Being an engineer, I tend to pick the one with the
best value to my customer.  :)

  It would appear that the app framework world is
going through the same gyrations that the mainframe
world did in the 80s.  During this period we had
professional consultants who aimed to increase their
hourly wages by developing skills and reputation for
'big game mainframes'.  These high wages were kept
elevated by an ever increasing operative complexity,
which quickly degraded into an excess 'bloat' that, at
best was a liability to the customer rather than an
advantage.  During the late phases economic
relationships between the consultants( ala Byte
magazine and BITNET ) and the hardware providers( IBM,
etc.  ) had developed to block all but the most
esoteric and complex solutions to computing problems
from making it to market.  The mainframes were
designed for the consultants, not the customers.

  The end of this phase is referred to as the 'PC
revolution'.  The above situation resulted in a high
barrier to entry for digital business causing a high
demand for alternative solutions.  This was coupled
with the proliferation of new electronics suppliers in
Asia( specifically China ) due to changes in military
and trade policy.  Thus, what was once considered the
domain of geeky hobbyists became the stage for a phase
of new billionaires, with the likes of Steve Jobs and
Bill Gates.

  To address the question directly, which one is best?
 There is an assumed aspect to this question... best
for whom?  1) the customer, 2) the developer.
Certainly value and success involve a comparitive
advantage for both parties.  If history is to repeat
itself, and it always does... the mainframes that did
survive were the ones whose life support was the
broadest and deepest, not necessarily the ones with
the nicest trim, buttons, and knobs, etc.  Despite
this, the mainframe specialists as a species were
doomed to extinction, even the ones who worked on the
last of dinosaurs.

  Strangely, the UNIX crowd is now sitting with the
cool kids again with the proliferation of Linux.  Most
of the new Linux hackers are kids, but you do find the
occasional old senior amongst them offering up advice
and cranky remarks about the Cold War and 'them damn
camyanists'.

  As far as survival strategies go aim for standards,
not bling.-jmz









I am currently working with Scott Fau.h and
another ArcMinder in San
Diego.

We are working with JSF, Spring, Hibernate (and soon
iBatis).

At night and sometimes at lunch, I work at a project
based in New York which
is JSF based (mostly advice and guidance and helping
people out of sticky
issues). In the early morning I've been working on a
Tapestry/Spring/Hibernate project. I've been writing
Tapestry custom
components and helped them reconfigure the
Spring/Hibernate bits (they had
it configured a bit off).

BTW, We are looking for people with
JSF/Tapestry/Spring/Hibernate skills.

I am tired and busy.

-Original Message-
From: Jon Thomas [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 20, 2006 12:16 PM
To: jug-discussion@tucson-jug.org
Subject: Re: [jug-discussion] App Dev Framework
choices

you may have just started the next religious war

On Jun 20, 2006, at 11:30 AM, Thomas Hicks wrote:


Hey Rick,

You raise an issue I've been looking at lately:

the pros & cons

of various web app dev frameworks. I was motivated

by my lack

of knowledge about what's out there and inspired

by Matt Raible's

comparison presentation

(http://www.virtuas.com/articles/

webframework-sweetspots.html).

In the snippet below you mention JSF/Facelets and

Tapestry.

When do you choose to use Tapestry over

JSF/Facelets (or vice versa)?


(Anyone else with experience in the frameworks

area, please chime in).

regards,
-tom


At 11:00 AM 6/20/2006, Rick wrote:

.
Nick,

I was up your way working on a Tapestry project

(a few weeks ago).


I've been doing some Tapestry work on the side

while doing

JSF/Facelets/Spring/Hibernate(iBat

Re: [jug-discussion] App Dev Framework choices

[Andrew Lenards]

To Rick:

I really haven't had a chance to use either of the framework
(Spring.NET nor NHibernate) but I've tracked their progress.  I caught
a podcast from one of the devs for Spring.NET and it sounded like they
was a fair amount of interest in the project.  NHibernate hit version
1 around the beginning of the year.  I believe Spring.NET hit version
1 about 2 months ago.  I don't think either is dead -- but the .NET
community really hasn't "taken" to the open source framework quite
yet. *shrug*  I know there are products and projects using the
frameworks - I just have no clue how many.

Andy


On 6/21/06, Erik Hatcher <[EMAIL PROTECTED]> wrote:


On Jun 21, 2006, at 12:35 PM, Chad Woolley wrote:
> "lowercase" web services?  What do you use to talk XML on the RoR
> side?   One of the Ruby SOAP implementations, something homegrown, or
> something else?

Currently Solr returns back a custom XML layout and accepts a custom
format.  These are defined on the Solr wiki very nicely.

I'm currently using REXML to parse the responses, and its working
fine.  But I think REXML's performance is not quite as quick as
perhaps sending back YAML or even Ruby code to eval.  Solr has a
custom response handler hook so XML is not required, just the default.

By "lowercase" web services I mean it's a service, and it's on the
web, but it's not heavy SOAP.

Erik, the RESTful one


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [jug-discussion] App Dev Framework choices

[josh zeidner]

--- Rick Hightower <[EMAIL PROTECTED]> wrote:

> So Josh, let me get this straight if a Tapestry
> project pays $1 dollar an
> hour and a JSF project pays $100.00 an hour (or vice
> versa), you would work
> on the Tapestry project (or vice versa) because it
> is a better fit.

 Hey Rick, thanks for the response.

 I would work on Tapestry project if I thought it
would result in long term success of my client( if she
wins i win ).  As soon as you reduce development to a
labor function it tends to compress the value that a
good engineer can offer.  I usually don't get into
these kinds of situations... im more interested in
developing specific ideas.  What language they are
based in is largely irrelevant.  My interest in java
is a function of my career legacy and thats about it
these days.  Sun faces some serious problems.

> 
> The phrase "the one" refers to the project not the
> technology.

  Hey, I hope you didnt take serious offense to my
statement...

> 
> Being a low-life contractor/consultant, I tend not
> to pick the technology.

  well i would guess to some degree the technology
picks you... you cant specialize in everything!

> I really like working with Tapestry and JSF.

  Ive heard good things about Tapestry and it has LTC(
Long Term Credibility- to use the microsoft term ). 
Good luck with that!

> 
> > Since I am a consulting, I give advice, but will
> > happily work with Tapestry
> > or JSF.
> 
> I've recommended Tapestry for some projects and JSF
> for others.
> 
> I am fairly open-minded.
> 
> I would have no moral issue working on a dotNet
> project or a RoR project.

  Well im not sure if youve encountered my commentary
elsewhere, and this is a follow up on that...  but
anyway a summary on these two digital denizens:

  DOT NET: Arrg!  This is why i dont like Dot
NET:  Its like buying real estate in Columbia.  I have
no idea what will happen to my investment in time and
resources.  Microsoft has shown zero respect for thier
customers( and America in general ) in the past
despite Steve Ballmer's 'DEVELOPERS DEVELOPERS
DEVELOPERS' chant.  I don't blame them, competition is
tough...  i surely wouldnt subject myself to them and
I doubt I would subject a client to them.

  RoR: Why?  because its Web 2.0( see CMP Media
scandal ).  The whole Web 2.0 thing( which RoR is
invariably linked to  ) has turned out to be a very
stupid multi-level marketing scheme starring Tim
O'Reilly.  RoR offers no technological advantages over
existing scripting languages, despite the magical
claims of its proponents.

> 
> I prefer Java, but learning new things broadens you
> horizons and
> understanding of development in general.

  I still like Perl.  Larry Wall is the best.  Id work
for him.  Python is also cool.

  thanks,  jmz




> 
> -Original Message-
> From: josh zeidner [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, June 21, 2006 10:15 AM
> To: jug-discussion@tucson-jug.org
> Subject: RE: [jug-discussion] App Dev Framework
> choices
> 
> 
> 
> --- Rick Hightower <[EMAIL PROTECTED]> wrote:
> 
> > Since I am a consulting, I give advice, but will
> > happily work with Tapestry
> > or JSF. 
> > 
> > Being a capitalist, I tend to pick the one with
> the
> > highest bill rate. :o)
> 
>   Being an engineer, I tend to pick the one with the
> best value to my customer.  :)
> 
>   It would appear that the app framework world is
> going through the same gyrations that the mainframe
> world did in the 80s.  During this period we had
> professional consultants who aimed to increase their
> hourly wages by developing skills and reputation for
> 'big game mainframes'.  These high wages were kept
> elevated by an ever increasing operative complexity,
> which quickly degraded into an excess 'bloat' that,
> at
> best was a liability to the customer rather than an
> advantage.  During the late phases economic
> relationships between the consultants( ala Byte
> magazine and BITNET ) and the hardware providers(
> IBM,
> etc.  ) had developed to block all but the most
> esoteric and complex solutions to computing problems
> from making it to market.  The mainframes were
> designed for the consultants, not the customers.
> 
>   The end of this phase is referred to as the 'PC
> revolution'.  The above situation resulted in a high
> barrier to entry for digital business causing a high
> demand for alternative solutions.  This was coupled
> with the proliferation of new electronics suppliers
> in
> Asia( specifically China ) due to changes in
> military
> and trade policy.  Thus, what was once considered
> the
> domain of geeky hobbyists became the stag

Re: [jug-discussion] App Dev Framework choices

[Erik Hatcher]

On Jun 21, 2006, at 12:35 PM, Chad Woolley wrote:

"lowercase" web services?  What do you use to talk XML on the RoR
side?   One of the Ruby SOAP implementations, something homegrown, or
something else?


Currently Solr returns back a custom XML layout and accepts a custom  
format.  These are defined on the Solr wiki very nicely.


I'm currently using REXML to parse the responses, and its working  
fine.  But I think REXML's performance is not quite as quick as  
perhaps sending back YAML or even Ruby code to eval.  Solr has a  
custom response handler hook so XML is not required, just the default.


By "lowercase" web services I mean it's a service, and it's on the  
web, but it's not heavy SOAP.


Erik, the RESTful one


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jug-discussion] App Dev Framework choices

[Erik Hatcher]

On Jun 21, 2006, at 10:02 AM, Warner Onstine wrote:
Solr looks pretty slick! Thanks for pointing this one out Erik. Any  
idea when it's coming out of incubator status?


Solr is where it's at... hear me now, believe me later.  As for the  
incubator... who knows?  It's very mature as it is and the only thing  
really keeping it in the incubator is making sure we have a well  
rounded set of committers rather than most of them from CNET.  I'm  
officially a committer and have made a couple of minor tweaks.  There  
needs to be a bit of diversity for the incubator PMC to be satisfied.


Erik


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [jug-discussion] App Dev Framework choices

[Rick Hightower]

So Josh, let me get this straight if a Tapestry project pays $1 dollar an
hour and a JSF project pays $100.00 an hour (or vice versa), you would work
on the Tapestry project (or vice versa) because it is a better fit.

Congrats! You are a much better man than me. I am not completely motivated
by money but it is a key factor.

As I said before, the technology is usually already picked before I start
working on a project so in the sentence:

> Being a capitalist, I tend to pick the one with the
> highest bill rate. :o)

The phrase "the one" refers to the project not the technology.

Being a low-life contractor/consultant, I tend not to pick the technology.
:)

I do get to pick who I work with (and in a sense what). If a project was
doing Struts, the bill rate would have to be super nice for me to work on
it. If JSF or Tapestry, well you get the picture...

I really like working with Tapestry and JSF.

> Since I am a consulting, I give advice, but will
> happily work with Tapestry
> or JSF.

I've recommended Tapestry for some projects and JSF for others.

I am fairly open-minded.

I would have no moral issue working on a dotNet project or a RoR project.

I prefer Java, but learning new things broadens you horizons and
understanding of development in general.

-Original Message-
From: josh zeidner [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 21, 2006 10:15 AM
To: jug-discussion@tucson-jug.org
Subject: RE: [jug-discussion] App Dev Framework choices



--- Rick Hightower <[EMAIL PROTECTED]> wrote:

> Since I am a consulting, I give advice, but will
> happily work with Tapestry
> or JSF. 
> 
> Being a capitalist, I tend to pick the one with the
> highest bill rate. :o)

  Being an engineer, I tend to pick the one with the
best value to my customer.  :)

  It would appear that the app framework world is
going through the same gyrations that the mainframe
world did in the 80s.  During this period we had
professional consultants who aimed to increase their
hourly wages by developing skills and reputation for
'big game mainframes'.  These high wages were kept
elevated by an ever increasing operative complexity,
which quickly degraded into an excess 'bloat' that, at
best was a liability to the customer rather than an
advantage.  During the late phases economic
relationships between the consultants( ala Byte
magazine and BITNET ) and the hardware providers( IBM,
etc.  ) had developed to block all but the most
esoteric and complex solutions to computing problems
from making it to market.  The mainframes were
designed for the consultants, not the customers.

  The end of this phase is referred to as the 'PC
revolution'.  The above situation resulted in a high
barrier to entry for digital business causing a high
demand for alternative solutions.  This was coupled
with the proliferation of new electronics suppliers in
Asia( specifically China ) due to changes in military
and trade policy.  Thus, what was once considered the
domain of geeky hobbyists became the stage for a phase
of new billionaires, with the likes of Steve Jobs and
Bill Gates.

  To address the question directly, which one is best?
 There is an assumed aspect to this question... best
for whom?  1) the customer, 2) the developer. 
Certainly value and success involve a comparitive
advantage for both parties.  If history is to repeat
itself, and it always does... the mainframes that did
survive were the ones whose life support was the
broadest and deepest, not necessarily the ones with
the nicest trim, buttons, and knobs, etc.  Despite
this, the mainframe specialists as a species were
doomed to extinction, even the ones who worked on the
last of dinosaurs.

  Strangely, the UNIX crowd is now sitting with the
cool kids again with the proliferation of Linux.  Most
of the new Linux hackers are kids, but you do find the
occasional old senior amongst them offering up advice
and cranky remarks about the Cold War and 'them damn
camyanists'.

  As far as survival strategies go aim for standards,
not bling.-jmz



  



> 
> I am currently working with Scott Fau.h and
> another ArcMinder in San
> Diego.
> 
> We are working with JSF, Spring, Hibernate (and soon
> iBatis).
> 
> At night and sometimes at lunch, I work at a project
> based in New York which
> is JSF based (mostly advice and guidance and helping
> people out of sticky
> issues). In the early morning I've been working on a
> Tapestry/Spring/Hibernate project. I've been writing
> Tapestry custom
> components and helped them reconfigure the
> Spring/Hibernate bits (they had
> it configured a bit off).
> 
> BTW, We are looking for people with
> JSF/Tapestry/Spring/Hibernate skills.
> 
> I am tired and busy.
> 
> -----Original Message-
> From: Jon Thomas [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, June 20,

RE: [jug-discussion] App Dev Framework choices

[Rick Hightower]

Flame bait?

 

 









From: cara
[mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 21, 2006
9:17 AM
To: jug-discussion@tucson-jug.org
Subject: Re: [jug-discussion] App
Dev Framework choices



 

On 6/20/06, Rick Hightower
<[EMAIL PROTECTED]>
wrote:



[snip]


Injection via an abstract getter, anyone?  Shudder?




shudder. 





 

I think I have grasped it (but I enjoy complex stuff), but to use it on
a
large team... YIKES! There is going to be a lot of developer body bags. 






[snip] 





 

Granted Tapestry is very powerful however that power begets complexity.
Tapestry 5 should focus on developer productivity. 

Well you asked.






Blasphemer! Blasphemer! 

I can't take it. Comments and opinions about the human aspects of picking a
technology!? How big is the project? How many developers? Developer team skill
levels? Will someone random have to maintain/install it? How bloody much money
do we have to do the project? Blasphemy!

RE: [jug-discussion] App Dev Framework choices

[josh zeidner]

--- Rick Hightower <[EMAIL PROTECTED]> wrote:

> Since I am a consulting, I give advice, but will
> happily work with Tapestry
> or JSF. 
> 
> Being a capitalist, I tend to pick the one with the
> highest bill rate. :o)

  Being an engineer, I tend to pick the one with the
best value to my customer.  :)

  It would appear that the app framework world is
going through the same gyrations that the mainframe
world did in the 80s.  During this period we had
professional consultants who aimed to increase their
hourly wages by developing skills and reputation for
'big game mainframes'.  These high wages were kept
elevated by an ever increasing operative complexity,
which quickly degraded into an excess 'bloat' that, at
best was a liability to the customer rather than an
advantage.  During the late phases economic
relationships between the consultants( ala Byte
magazine and BITNET ) and the hardware providers( IBM,
etc.  ) had developed to block all but the most
esoteric and complex solutions to computing problems
from making it to market.  The mainframes were
designed for the consultants, not the customers.

  The end of this phase is referred to as the 'PC
revolution'.  The above situation resulted in a high
barrier to entry for digital business causing a high
demand for alternative solutions.  This was coupled
with the proliferation of new electronics suppliers in
Asia( specifically China ) due to changes in military
and trade policy.  Thus, what was once considered the
domain of geeky hobbyists became the stage for a phase
of new billionaires, with the likes of Steve Jobs and
Bill Gates.

  To address the question directly, which one is best?
 There is an assumed aspect to this question... best
for whom?  1) the customer, 2) the developer. 
Certainly value and success involve a comparitive
advantage for both parties.  If history is to repeat
itself, and it always does... the mainframes that did
survive were the ones whose life support was the
broadest and deepest, not necessarily the ones with
the nicest trim, buttons, and knobs, etc.  Despite
this, the mainframe specialists as a species were
doomed to extinction, even the ones who worked on the
last of dinosaurs.

  Strangely, the UNIX crowd is now sitting with the
cool kids again with the proliferation of Linux.  Most
of the new Linux hackers are kids, but you do find the
occasional old senior amongst them offering up advice
and cranky remarks about the Cold War and 'them damn
camyanists'.

  As far as survival strategies go aim for standards,
not bling.-jmz



  



> 
> I am currently working with Scott Fau.h and
> another ArcMinder in San
> Diego.
> 
> We are working with JSF, Spring, Hibernate (and soon
> iBatis).
> 
> At night and sometimes at lunch, I work at a project
> based in New York which
> is JSF based (mostly advice and guidance and helping
> people out of sticky
> issues). In the early morning I've been working on a
> Tapestry/Spring/Hibernate project. I've been writing
> Tapestry custom
> components and helped them reconfigure the
> Spring/Hibernate bits (they had
> it configured a bit off).
> 
> BTW, We are looking for people with
> JSF/Tapestry/Spring/Hibernate skills.
> 
> I am tired and busy.
> 
> -Original Message-
> From: Jon Thomas [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, June 20, 2006 12:16 PM
> To: jug-discussion@tucson-jug.org
> Subject: Re: [jug-discussion] App Dev Framework
> choices
> 
> you may have just started the next religious war
> 
> On Jun 20, 2006, at 11:30 AM, Thomas Hicks wrote:
> 
> > Hey Rick,
> >
> > You raise an issue I've been looking at lately:
> the pros & cons
> > of various web app dev frameworks. I was motivated
> by my lack
> > of knowledge about what's out there and inspired
> by Matt Raible's
> > comparison presentation
> (http://www.virtuas.com/articles/ 
> > webframework-sweetspots.html).
> >
> > In the snippet below you mention JSF/Facelets and
> Tapestry.
> > When do you choose to use Tapestry over
> JSF/Facelets (or vice versa)?
> >
> > (Anyone else with experience in the frameworks
> area, please chime in).
> > regards,
> > -tom
> >
> >
> > At 11:00 AM 6/20/2006, Rick wrote:
> >> .
> >> Nick,
> >>
> >> I was up your way working on a Tapestry project
> (a few weeks ago).
> >>
> >> I've been doing some Tapestry work on the side
> while doing
> >> JSF/Facelets/Spring/Hibernate(iBatis too) for my
> regular gig. I  
> >> also updated
> >> our Tapestry course to Tapestry

RE: [jug-discussion] App Dev Framework choices

[Rick Hightower]

Erik,

Good to hear from you. No one has asked me to work on a RoR project yet.

I pretty much work on whatever the client wants (except for Struts; I won't
do Struts).

We are creating our own version of RoR called Presto.

Presto is based on Spring, Hibernate, Facelets and JSF.

It is similar to Trails.

I just got a call this morning about a dotNet project using NHibernate and
Spring.Net.

Does anyone know if these frameworks are alive?

I may do some NHibernate/Spring.Net work this year.

Has anyone used these before?

-Original Message-
From: Erik Hatcher [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 21, 2006 3:29 AM
To: jug-discussion@tucson-jug.org
Subject: Re: [jug-discussion] App Dev Framework choices

Yeah, but what about Ruby on Rails?!  ;)

My current projects (yes, more than one) consist of a RoR front-end  
and a Solr (http://incubator.apache.org/solr) as a major backend  
piece via XML over HTTP (lowercase "web services").

Erik


On Jun 20, 2006, at 4:15 PM, Rick Hightower wrote:

> H
>
> I find Tapestry to be powerful and robust.
> It seems to handle resources better than JSF.
> It is also really easy to create Tapestry components (out of other  
> Tapestry
> components no less). JSF component creation (true components not  
> composition
> components ala Facelets) is lacking.
>
> Many things in Tapestry just work the way they should. Many things  
> in JSF
> don't just work the way they should. For example, in Tapestry when  
> you get
> an error with a field, that field is automatically highlighted, in  
> JSF you
> have to do it yourself. There is not reason why h:form could not do  
> it for
> you. It just doesn't.
>
> However
>
> Tapestry takes a lot more effort to grasp and it takes a lot more  
> effort to
> learn. It is complicated. It did not get simpler in Tapestry 4.
>
> Injection via an abstract getter, anyone?  Shudder?
>
> I think I have grasped it (but I enjoy complex stuff), but to use  
> it on a
> large team... YIKES! There is going to be a lot of developer body  
> bags.
>
> JSF is far easier to learn and grasp.
>
>
> Back to your original question:
>
> "When would you choose to use Tapestry over JSF/Facelets"?
>
> I don't get to pick. The pick is usually done before I get there and I
> merely assist with the choice. I am thankful for this. Both have their
> issues.
>
> However as I breathe, I have an opinion:
>
> I think JSF is far superior for internal apps where the look and  
> feel is not
> extremely important. The main criterion is developer productivity.
>
> I think Tapestry is far superior for external apps where the look  
> and feel
> is critical. The main criterion is look and feel.
>
> Also if you are going to create a lot of custom components,  
> Tapestry is a
> better choice as well.
>
> Facelets closes the gap (quite a bit) between Tapestry and JSF, but  
> Tapestry
> is still a better platform for building components.
>
> On the other hand, there are more OTS components available for JSF.
>
> The docs for Tapestry are lacking. The amount of information about  
> Tapestry
> pails in comparison to JSF
>
> I feel I am qualified to make the above statements having used  
> both. I have
> not bias towards either. I can make money doing either. I enjoy  
> working with
> both.
>
> "Rick helped us to get our arms around Tapestry, Hibernate, and  
> Spring. We
> are implementing all new J2EE applications in these technologies. Rick
> showed us how to pull all of these things together." Wayne
>
> Having taught both JSF and Tapestry workshops, I can tell you this.
> Developers get JSF quickly. Developers stumble with Tapestry. It  
> takes twice
> as long to do the equiv CRUD lab in Tapestry versus the other. (It  
> takes
> another two times as long to do it in classic Struts so...).
>
> Granted Tapestry is very powerful however that power begets  
> complexity.
> Tapestry 5 should focus on developer productivity.
>
> Well you asked.
>
>
>
> -Original Message-
> From: Thomas Hicks [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 20, 2006 12:29 PM
> To: jug-discussion@tucson-jug.org
> Subject: Re: [jug-discussion] App Dev Framework choices
>
> Hopefully not.
>
> I didn't ask "which app framework is better"?
>
> I asked a specific question of Rick (and others) from his experience
> "When would you choose to use Tapestry over JSF/Facelets"?
>
> I was hoping for a summary based on his experiences with various  
> frameworks.
>  cheers,
>  -tom
>
>
>
> At 12:16 PM 6/20/2006, you wrote:
>>

Re: [jug-discussion] App Dev Framework choices

[Chad Woolley]

Erik,

"lowercase" web services?  What do you use to talk XML on the RoR
side?   One of the Ruby SOAP implementations, something homegrown, or
something else?

I work for a Rails shop, and we've done SOAP in one app.  The one
thing I noticed it had in common with Java (Axis) was that it NEVER
"just works", especially if you are talking to Microsoft on the other
end.  Even though it's a "platform independent" protocol, you always
end up having to work around bugs or write some hacks to deal with
type/array mismatches or something.

-- Chad

On 6/21/06, Erik Hatcher <[EMAIL PROTECTED]> wrote:

Yeah, but what about Ruby on Rails?!  ;)

My current projects (yes, more than one) consist of a RoR front-end
and a Solr (http://incubator.apache.org/solr) as a major backend
piece via XML over HTTP (lowercase "web services").

Erik


On Jun 20, 2006, at 4:15 PM, Rick Hightower wrote:

> H
>
> I find Tapestry to be powerful and robust.
> It seems to handle resources better than JSF.
> It is also really easy to create Tapestry components (out of other
> Tapestry
> components no less). JSF component creation (true components not
> composition
> components ala Facelets) is lacking.
>
> Many things in Tapestry just work the way they should. Many things
> in JSF
> don't just work the way they should. For example, in Tapestry when
> you get
> an error with a field, that field is automatically highlighted, in
> JSF you
> have to do it yourself. There is not reason why h:form could not do
> it for
> you. It just doesn't.
>
> However
>
> Tapestry takes a lot more effort to grasp and it takes a lot more
> effort to
> learn. It is complicated. It did not get simpler in Tapestry 4.
>
> Injection via an abstract getter, anyone?  Shudder?
>
> I think I have grasped it (but I enjoy complex stuff), but to use
> it on a
> large team... YIKES! There is going to be a lot of developer body
> bags.
>
> JSF is far easier to learn and grasp.
>
>
> Back to your original question:
>
> "When would you choose to use Tapestry over JSF/Facelets"?
>
> I don't get to pick. The pick is usually done before I get there and I
> merely assist with the choice. I am thankful for this. Both have their
> issues.
>
> However as I breathe, I have an opinion:
>
> I think JSF is far superior for internal apps where the look and
> feel is not
> extremely important. The main criterion is developer productivity.
>
> I think Tapestry is far superior for external apps where the look
> and feel
> is critical. The main criterion is look and feel.
>
> Also if you are going to create a lot of custom components,
> Tapestry is a
> better choice as well.
>
> Facelets closes the gap (quite a bit) between Tapestry and JSF, but
> Tapestry
> is still a better platform for building components.
>
> On the other hand, there are more OTS components available for JSF.
>
> The docs for Tapestry are lacking. The amount of information about
> Tapestry
> pails in comparison to JSF
>
> I feel I am qualified to make the above statements having used
> both. I have
> not bias towards either. I can make money doing either. I enjoy
> working with
> both.
>
> "Rick helped us to get our arms around Tapestry, Hibernate, and
> Spring. We
> are implementing all new J2EE applications in these technologies. Rick
> showed us how to pull all of these things together." Wayne
>
> Having taught both JSF and Tapestry workshops, I can tell you this.
> Developers get JSF quickly. Developers stumble with Tapestry. It
> takes twice
> as long to do the equiv CRUD lab in Tapestry versus the other. (It
> takes
> another two times as long to do it in classic Struts so...).
>
> Granted Tapestry is very powerful however that power begets
> complexity.
> Tapestry 5 should focus on developer productivity.
>
> Well you asked.
>
>
>
> -Original Message-
> From: Thomas Hicks [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 20, 2006 12:29 PM
> To: jug-discussion@tucson-jug.org
> Subject: Re: [jug-discussion] App Dev Framework choices
>
> Hopefully not.
>
> I didn't ask "which app framework is better"?
>
> I asked a specific question of Rick (and others) from his experience
> "When would you choose to use Tapestry over JSF/Facelets"?
>
> I was hoping for a summary based on his experiences with various
> frameworks.
>  cheers,
>  -tom
>
>
>
> At 12:16 PM 6/20/2006, you wrote:
>> you may have just started the next religious war
>>
>> On Jun 20, 2006, at 11:30 AM, Thomas Hicks wrote:
>>
>&

Re: [jug-discussion] App Dev Framework choices

[cara]

On 6/20/06, Rick Hightower <[EMAIL PROTECTED]> wrote:[snip]
Injection via an abstract getter, anyone?  Shudder?
shudder. 
I think I have grasped it (but I enjoy complex stuff), but to use it on alarge team... YIKES! There is going to be a lot of developer body bags.

[snip] 

Granted Tapestry is very powerful however that power begets complexity.Tapestry 5 should focus on developer productivity.
Well you asked.
Blasphemer! Blasphemer! 

I can't take it. Comments and opinions about the human aspects of
picking a technology!? How big is the project? How many developers?
Developer team skill levels? Will someone random have to
maintain/install it? How bloody much money do we have to do the
project? Blasphemy!

Re: [jug-discussion] App Dev Framework choices

[Warner Onstine]

Solr looks pretty slick! Thanks for pointing this one out Erik. Any  
idea when it's coming out of incubator status?


-warner

On Jun 21, 2006, at 3:28 AM, Erik Hatcher wrote:


Yeah, but what about Ruby on Rails?!  ;)

My current projects (yes, more than one) consist of a RoR front-end  
and a Solr (http://incubator.apache.org/solr) as a major backend  
piece via XML over HTTP (lowercase "web services").


Erik


On Jun 20, 2006, at 4:15 PM, Rick Hightower wrote:


H

I find Tapestry to be powerful and robust.
It seems to handle resources better than JSF.
It is also really easy to create Tapestry components (out of other  
Tapestry
components no less). JSF component creation (true components not  
composition

components ala Facelets) is lacking.

Many things in Tapestry just work the way they should. Many things  
in JSF
don't just work the way they should. For example, in Tapestry when  
you get
an error with a field, that field is automatically highlighted, in  
JSF you
have to do it yourself. There is not reason why h:form could not  
do it for

you. It just doesn't.

However

Tapestry takes a lot more effort to grasp and it takes a lot more  
effort to

learn. It is complicated. It did not get simpler in Tapestry 4.

Injection via an abstract getter, anyone?  Shudder?

I think I have grasped it (but I enjoy complex stuff), but to use  
it on a
large team... YIKES! There is going to be a lot of developer body  
bags.


JSF is far easier to learn and grasp.


Back to your original question:

"When would you choose to use Tapestry over JSF/Facelets"?

I don't get to pick. The pick is usually done before I get there  
and I
merely assist with the choice. I am thankful for this. Both have  
their

issues.

However as I breathe, I have an opinion:

I think JSF is far superior for internal apps where the look and  
feel is not

extremely important. The main criterion is developer productivity.

I think Tapestry is far superior for external apps where the look  
and feel

is critical. The main criterion is look and feel.

Also if you are going to create a lot of custom components,  
Tapestry is a

better choice as well.

Facelets closes the gap (quite a bit) between Tapestry and JSF,  
but Tapestry

is still a better platform for building components.

On the other hand, there are more OTS components available for JSF.

The docs for Tapestry are lacking. The amount of information about  
Tapestry

pails in comparison to JSF

I feel I am qualified to make the above statements having used  
both. I have
not bias towards either. I can make money doing either. I enjoy  
working with

both.

"Rick helped us to get our arms around Tapestry, Hibernate, and  
Spring. We
are implementing all new J2EE applications in these technologies.  
Rick

showed us how to pull all of these things together." Wayne

Having taught both JSF and Tapestry workshops, I can tell you this.
Developers get JSF quickly. Developers stumble with Tapestry. It  
takes twice
as long to do the equiv CRUD lab in Tapestry versus the other. (It  
takes

another two times as long to do it in classic Struts so...).

Granted Tapestry is very powerful however that power begets  
complexity.

Tapestry 5 should focus on developer productivity.

Well you asked.



-Original Message-
From: Thomas Hicks [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 20, 2006 12:29 PM
To: jug-discussion@tucson-jug.org
Subject: Re: [jug-discussion] App Dev Framework choices

Hopefully not.

I didn't ask "which app framework is better"?

I asked a specific question of Rick (and others) from his experience
"When would you choose to use Tapestry over JSF/Facelets"?

I was hoping for a summary based on his experiences with various  
frameworks.

 cheers,
 -tom



At 12:16 PM 6/20/2006, you wrote:

you may have just started the next religious war

On Jun 20, 2006, at 11:30 AM, Thomas Hicks wrote:


Hey Rick,

You raise an issue I've been looking at lately: the pros & cons
of various web app dev frameworks. I was motivated by my lack
of knowledge about what's out there and inspired by Matt Raible's
comparison presentation (http://www.virtuas.com/articles/
webframework-sweetspots.html).

In the snippet below you mention JSF/Facelets and Tapestry.
When do you choose to use Tapestry over JSF/Facelets (or vice  
versa)?


(Anyone else with experience in the frameworks area, please  
chime in).

regards,
-tom


At 11:00 AM 6/20/2006, Rick wrote:

.
Nick,

I was up your way working on a Tapestry project (a few weeks ago).

I've been doing some Tapestry work on the side while doing
JSF/Facelets/Spring/Hibernate(iBatis too) for my regular gig. I
also updated
our Tapestry course to Tapestry 4.0.

TTYL

--Rick




-

Re: [jug-discussion] App Dev Framework choices

[Erik Hatcher]

Yeah, but what about Ruby on Rails?!  ;)

My current projects (yes, more than one) consist of a RoR front-end  
and a Solr (http://incubator.apache.org/solr) as a major backend  
piece via XML over HTTP (lowercase "web services").


Erik


On Jun 20, 2006, at 4:15 PM, Rick Hightower wrote:


H

I find Tapestry to be powerful and robust.
It seems to handle resources better than JSF.
It is also really easy to create Tapestry components (out of other  
Tapestry
components no less). JSF component creation (true components not  
composition

components ala Facelets) is lacking.

Many things in Tapestry just work the way they should. Many things  
in JSF
don't just work the way they should. For example, in Tapestry when  
you get
an error with a field, that field is automatically highlighted, in  
JSF you
have to do it yourself. There is not reason why h:form could not do  
it for

you. It just doesn't.

However

Tapestry takes a lot more effort to grasp and it takes a lot more  
effort to

learn. It is complicated. It did not get simpler in Tapestry 4.

Injection via an abstract getter, anyone?  Shudder?

I think I have grasped it (but I enjoy complex stuff), but to use  
it on a
large team... YIKES! There is going to be a lot of developer body  
bags.


JSF is far easier to learn and grasp.


Back to your original question:

"When would you choose to use Tapestry over JSF/Facelets"?

I don't get to pick. The pick is usually done before I get there and I
merely assist with the choice. I am thankful for this. Both have their
issues.

However as I breathe, I have an opinion:

I think JSF is far superior for internal apps where the look and  
feel is not

extremely important. The main criterion is developer productivity.

I think Tapestry is far superior for external apps where the look  
and feel

is critical. The main criterion is look and feel.

Also if you are going to create a lot of custom components,  
Tapestry is a

better choice as well.

Facelets closes the gap (quite a bit) between Tapestry and JSF, but  
Tapestry

is still a better platform for building components.

On the other hand, there are more OTS components available for JSF.

The docs for Tapestry are lacking. The amount of information about  
Tapestry

pails in comparison to JSF

I feel I am qualified to make the above statements having used  
both. I have
not bias towards either. I can make money doing either. I enjoy  
working with

both.

"Rick helped us to get our arms around Tapestry, Hibernate, and  
Spring. We

are implementing all new J2EE applications in these technologies. Rick
showed us how to pull all of these things together." Wayne

Having taught both JSF and Tapestry workshops, I can tell you this.
Developers get JSF quickly. Developers stumble with Tapestry. It  
takes twice
as long to do the equiv CRUD lab in Tapestry versus the other. (It  
takes

another two times as long to do it in classic Struts so...).

Granted Tapestry is very powerful however that power begets  
complexity.

Tapestry 5 should focus on developer productivity.

Well you asked.



-Original Message-
From: Thomas Hicks [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 20, 2006 12:29 PM
To: jug-discussion@tucson-jug.org
Subject: Re: [jug-discussion] App Dev Framework choices

Hopefully not.

I didn't ask "which app framework is better"?

I asked a specific question of Rick (and others) from his experience
"When would you choose to use Tapestry over JSF/Facelets"?

I was hoping for a summary based on his experiences with various  
frameworks.

 cheers,
 -tom



At 12:16 PM 6/20/2006, you wrote:

you may have just started the next religious war

On Jun 20, 2006, at 11:30 AM, Thomas Hicks wrote:


Hey Rick,

You raise an issue I've been looking at lately: the pros & cons
of various web app dev frameworks. I was motivated by my lack
of knowledge about what's out there and inspired by Matt Raible's
comparison presentation (http://www.virtuas.com/articles/
webframework-sweetspots.html).

In the snippet below you mention JSF/Facelets and Tapestry.
When do you choose to use Tapestry over JSF/Facelets (or vice  
versa)?


(Anyone else with experience in the frameworks area, please chime  
in).

regards,
-tom


At 11:00 AM 6/20/2006, Rick wrote:

.
Nick,

I was up your way working on a Tapestry project (a few weeks ago).

I've been doing some Tapestry work on the side while doing
JSF/Facelets/Spring/Hibernate(iBatis too) for my regular gig. I
also updated
our Tapestry course to Tapestry 4.0.

TTYL

--Rick




 
-

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---

RE: [jug-discussion] App Dev Framework choices

[Rick Hightower]

Since I am a consulting, I give advice, but will happily work with Tapestry
or JSF. 

Being a capitalist, I tend to pick the one with the highest bill rate. :o)

I am currently working with Scott Fau.h and another ArcMinder in San
Diego.

We are working with JSF, Spring, Hibernate (and soon iBatis).

At night and sometimes at lunch, I work at a project based in New York which
is JSF based (mostly advice and guidance and helping people out of sticky
issues). In the early morning I've been working on a
Tapestry/Spring/Hibernate project. I've been writing Tapestry custom
components and helped them reconfigure the Spring/Hibernate bits (they had
it configured a bit off).

BTW, We are looking for people with JSF/Tapestry/Spring/Hibernate skills.

I am tired and busy.

-Original Message-
From: Jon Thomas [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, June 20, 2006 12:16 PM
To: jug-discussion@tucson-jug.org
Subject: Re: [jug-discussion] App Dev Framework choices

you may have just started the next religious war

On Jun 20, 2006, at 11:30 AM, Thomas Hicks wrote:

> Hey Rick,
>
> You raise an issue I've been looking at lately: the pros & cons
> of various web app dev frameworks. I was motivated by my lack
> of knowledge about what's out there and inspired by Matt Raible's
> comparison presentation (http://www.virtuas.com/articles/ 
> webframework-sweetspots.html).
>
> In the snippet below you mention JSF/Facelets and Tapestry.
> When do you choose to use Tapestry over JSF/Facelets (or vice versa)?
>
> (Anyone else with experience in the frameworks area, please chime in).
> regards,
> -tom
>
>
> At 11:00 AM 6/20/2006, Rick wrote:
>> .
>> Nick,
>>
>> I was up your way working on a Tapestry project (a few weeks ago).
>>
>> I've been doing some Tapestry work on the side while doing
>> JSF/Facelets/Spring/Hibernate(iBatis too) for my regular gig. I  
>> also updated
>> our Tapestry course to Tapestry 4.0.
>>
>> TTYL
>>
>> --Rick
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [jug-discussion] App Dev Framework choices

[Thomas Hicks]

Thanks Rick! Your response was exactly what I was seeking,
and I appreciate the detail and justification.

And your comment:


I don't get to pick. The pick is usually done before I get there and I
merely assist with the choice.


reminds us that many of these kinds of decisions are not made on
a strictly technical basis. I have several horror stories (as I'm sure many
other JUG members do) where political decisions (or fear, or ignorance, etc.)
crippled a project.

Thanks again,
-tom


At 01:15 PM 6/20/2006, Rick wrote:

H

I find Tapestry to be powerful and robust.
It seems to handle resources better than JSF.
It is also really easy to create Tapestry components (out of other Tapestry
components no less). JSF component creation (true components not composition
components ala Facelets) is lacking.

Many things in Tapestry just work the way they should. Many things in JSF
don't just work the way they should. For example, in Tapestry when you get
an error with a field, that field is automatically highlighted, in JSF you
have to do it yourself. There is not reason why h:form could not do it for
you. It just doesn't.

However

Tapestry takes a lot more effort to grasp and it takes a lot more effort to
learn. It is complicated. It did not get simpler in Tapestry 4.

Injection via an abstract getter, anyone?  Shudder?

I think I have grasped it (but I enjoy complex stuff), but to use it on a
large team... YIKES! There is going to be a lot of developer body bags.

JSF is far easier to learn and grasp.


Back to your original question:

"When would you choose to use Tapestry over JSF/Facelets"?

I don't get to pick. The pick is usually done before I get there and I
merely assist with the choice. I am thankful for this. Both have their
issues.

However as I breathe, I have an opinion:

I think JSF is far superior for internal apps where the look and feel is not
extremely important. The main criterion is developer productivity.

I think Tapestry is far superior for external apps where the look and feel
is critical. The main criterion is look and feel.

Also if you are going to create a lot of custom components, Tapestry is a
better choice as well.

Facelets closes the gap (quite a bit) between Tapestry and JSF, but Tapestry
is still a better platform for building components.

On the other hand, there are more OTS components available for JSF.

The docs for Tapestry are lacking. The amount of information about Tapestry
pails in comparison to JSF

I feel I am qualified to make the above statements having used both. I have
not bias towards either. I can make money doing either. I enjoy working with
both.

"Rick helped us to get our arms around Tapestry, Hibernate, and Spring. We
are implementing all new J2EE applications in these technologies. Rick
showed us how to pull all of these things together." Wayne

Having taught both JSF and Tapestry workshops, I can tell you this.
Developers get JSF quickly. Developers stumble with Tapestry. It takes twice
as long to do the equiv CRUD lab in Tapestry versus the other. (It takes
another two times as long to do it in classic Struts so...).

Granted Tapestry is very powerful however that power begets complexity.
Tapestry 5 should focus on developer productivity.

Well you asked.



-Original Message-
From: Thomas Hicks [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 20, 2006 12:29 PM
To: jug-discussion@tucson-jug.org
Subject: Re: [jug-discussion] App Dev Framework choices

Hopefully not.

I didn't ask "which app framework is better"?

I asked a specific question of Rick (and others) from his experience
"When would you choose to use Tapestry over JSF/Facelets"?

I was hoping for a summary based on his experiences with various frameworks.
 cheers,
 -tom



At 12:16 PM 6/20/2006, you wrote:
>you may have just started the next religious war
>
>On Jun 20, 2006, at 11:30 AM, Thomas Hicks wrote:
>
>>Hey Rick,
>>
>>You raise an issue I've been looking at lately: the pros & cons
>>of various web app dev frameworks. I was motivated by my lack
>>of knowledge about what's out there and inspired by Matt Raible's
>>comparison presentation 
(<http://www.virtuas.com/articles/>http://www.virtuas.com/articles/

>>webframework-sweetspots.html).
>>
>>In the snippet below you mention JSF/Facelets and Tapestry.
>>When do you choose to use Tapestry over JSF/Facelets (or vice versa)?
>>
>>(Anyone else with experience in the frameworks area, please chime in).
>> regards,
>> -tom
>>
>>
>>At 11:00 AM 6/20/2006, Rick wrote:
>>>.
>>>Nick,
>>>
>>>I was up your way working on a Tapestry project (a few weeks ago).
>>>
>>>I've been doing some Tapestry work on the side 

RE: [jug-discussion] App Dev Framework choices

[Rick Hightower]

H

I find Tapestry to be powerful and robust. 
It seems to handle resources better than JSF.
It is also really easy to create Tapestry components (out of other Tapestry
components no less). JSF component creation (true components not composition
components ala Facelets) is lacking.

Many things in Tapestry just work the way they should. Many things in JSF
don't just work the way they should. For example, in Tapestry when you get
an error with a field, that field is automatically highlighted, in JSF you
have to do it yourself. There is not reason why h:form could not do it for
you. It just doesn't.

However

Tapestry takes a lot more effort to grasp and it takes a lot more effort to
learn. It is complicated. It did not get simpler in Tapestry 4. 

Injection via an abstract getter, anyone?  Shudder?

I think I have grasped it (but I enjoy complex stuff), but to use it on a
large team... YIKES! There is going to be a lot of developer body bags.

JSF is far easier to learn and grasp.


Back to your original question:

"When would you choose to use Tapestry over JSF/Facelets"?

I don't get to pick. The pick is usually done before I get there and I
merely assist with the choice. I am thankful for this. Both have their
issues. 

However as I breathe, I have an opinion:

I think JSF is far superior for internal apps where the look and feel is not
extremely important. The main criterion is developer productivity.

I think Tapestry is far superior for external apps where the look and feel
is critical. The main criterion is look and feel. 

Also if you are going to create a lot of custom components, Tapestry is a
better choice as well.

Facelets closes the gap (quite a bit) between Tapestry and JSF, but Tapestry
is still a better platform for building components.

On the other hand, there are more OTS components available for JSF.

The docs for Tapestry are lacking. The amount of information about Tapestry
pails in comparison to JSF

I feel I am qualified to make the above statements having used both. I have
not bias towards either. I can make money doing either. I enjoy working with
both.

"Rick helped us to get our arms around Tapestry, Hibernate, and Spring. We
are implementing all new J2EE applications in these technologies. Rick
showed us how to pull all of these things together." Wayne

Having taught both JSF and Tapestry workshops, I can tell you this.
Developers get JSF quickly. Developers stumble with Tapestry. It takes twice
as long to do the equiv CRUD lab in Tapestry versus the other. (It takes
another two times as long to do it in classic Struts so...).

Granted Tapestry is very powerful however that power begets complexity.
Tapestry 5 should focus on developer productivity.

Well you asked.



-Original Message-
From: Thomas Hicks [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, June 20, 2006 12:29 PM
To: jug-discussion@tucson-jug.org
Subject: Re: [jug-discussion] App Dev Framework choices

Hopefully not.

I didn't ask "which app framework is better"?

I asked a specific question of Rick (and others) from his experience
"When would you choose to use Tapestry over JSF/Facelets"?

I was hoping for a summary based on his experiences with various frameworks.
 cheers,
 -tom



At 12:16 PM 6/20/2006, you wrote:
>you may have just started the next religious war
>
>On Jun 20, 2006, at 11:30 AM, Thomas Hicks wrote:
>
>>Hey Rick,
>>
>>You raise an issue I've been looking at lately: the pros & cons
>>of various web app dev frameworks. I was motivated by my lack
>>of knowledge about what's out there and inspired by Matt Raible's
>>comparison presentation (http://www.virtuas.com/articles/ 
>>webframework-sweetspots.html).
>>
>>In the snippet below you mention JSF/Facelets and Tapestry.
>>When do you choose to use Tapestry over JSF/Facelets (or vice versa)?
>>
>>(Anyone else with experience in the frameworks area, please chime in).
>> regards,
>> -tom
>>
>>
>>At 11:00 AM 6/20/2006, Rick wrote:
>>>.
>>>Nick,
>>>
>>>I was up your way working on a Tapestry project (a few weeks ago).
>>>
>>>I've been doing some Tapestry work on the side while doing
>>>JSF/Facelets/Spring/Hibernate(iBatis too) for my regular gig. I
>>>also updated
>>>our Tapestry course to Tapestry 4.0.
>>>
>>>TTYL
>>>
>>>--Rick
>>
>>
>>
>>-
>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For 

Re: [jug-discussion] App Dev Framework choices

[Thomas Hicks]

Hopefully not.

I didn't ask "which app framework is better"?

I asked a specific question of Rick (and others) from his experience
"When would you choose to use Tapestry over JSF/Facelets"?

I was hoping for a summary based on his experiences with various frameworks.
cheers,
-tom



At 12:16 PM 6/20/2006, you wrote:

you may have just started the next religious war

On Jun 20, 2006, at 11:30 AM, Thomas Hicks wrote:


Hey Rick,

You raise an issue I've been looking at lately: the pros & cons
of various web app dev frameworks. I was motivated by my lack
of knowledge about what's out there and inspired by Matt Raible's
comparison presentation (http://www.virtuas.com/articles/ 
webframework-sweetspots.html).


In the snippet below you mention JSF/Facelets and Tapestry.
When do you choose to use Tapestry over JSF/Facelets (or vice versa)?

(Anyone else with experience in the frameworks area, please chime in).
regards,
-tom


At 11:00 AM 6/20/2006, Rick wrote:

.
Nick,

I was up your way working on a Tapestry project (a few weeks ago).

I've been doing some Tapestry work on the side while doing
JSF/Facelets/Spring/Hibernate(iBatis too) for my regular gig. I
also updated
our Tapestry course to Tapestry 4.0.

TTYL

--Rick




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jug-discussion] App Dev Framework choices

[Jon Thomas]

you may have just started the next religious war

On Jun 20, 2006, at 11:30 AM, Thomas Hicks wrote:


Hey Rick,

You raise an issue I've been looking at lately: the pros & cons
of various web app dev frameworks. I was motivated by my lack
of knowledge about what's out there and inspired by Matt Raible's
comparison presentation (http://www.virtuas.com/articles/ 
webframework-sweetspots.html).


In the snippet below you mention JSF/Facelets and Tapestry.
When do you choose to use Tapestry over JSF/Facelets (or vice versa)?

(Anyone else with experience in the frameworks area, please chime in).
regards,
-tom


At 11:00 AM 6/20/2006, Rick wrote:

.
Nick,

I was up your way working on a Tapestry project (a few weeks ago).

I've been doing some Tapestry work on the side while doing
JSF/Facelets/Spring/Hibernate(iBatis too) for my regular gig. I  
also updated

our Tapestry course to Tapestry 4.0.

TTYL

--Rick




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]