Quantcast

Grails development is really slow

classic Classic list List threaded Threaded
109 messages Options
1 ... 3456
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

rosenfeld
Em 06-01-2012 12:16, Rodrigo Rosenfeld Rosas escreveu:
Em 06-01-2012 11:03, Scott Eisenberg escreveu:
http://grails.org/doc/latest/guide/contributing.html   Section 18.4

I don't care which is the right answer (alright, I think #1 is the right answer) but it needs to be clear which to try.  Better still one option.

Corresponding Rails doc:

If you’re confident about your changes, you can push them yourself directly via docrails. docrails is a branch with an open commit policy and public write access. Commits to docrails are still reviewed, but that happens after they are pushed. docrails is merged with master regularly, so you are effectively editing the Ruby on Rails documentation.

If you are unsure of the documentation changes, you can create an issue in the Rails issues tracker on GitHub.

Simple answer there.  Use docrails.  "They are still reviewed", so nice that you (probably) can't screw up the doc.  Gives comfort to go ahead.  

One out, to use issues tracker if you are scared (given that docrails is reviewed I would remove that personally or change it to something like, if you don't use git then use the issues tracker…)

If Peter's branch the one that is reviewed more it could be stated that if you are unsure, use Peter's in that it is reviewed more, if sure go directly to #1.  If that is indeed the rationale for 2 options.


I guess the politics for the Grails documentation is about the same as for Rails.

For avoiding confusion, I think you referring to this paragraph:

"Contributing to the documentation is simpler than the core framework because there is a public fork of the http://github.com/grails/grails-doc project that anyone can request commit access to. So, if you want to submit patches to the documentation, simply request commit access to the following repository http://github.com/pledbrook/grails-doc by sending a GitHub message to 'pledbrook' and then commit your patches just as you would to any other GitHub repository."

I'm not sure if it was updated recently, but to me it seems like a single option was given. It only documents asking for commit access to the public repository and then commit the changes yourself. Maybe we could add a note that all changes will be reviewed before merging to the main repository.

Did I miss something?

Just ignore it. I should have read all messages before replying to you. It seems Peter has just updated the docs...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

rosenfeld
In reply to this post by rosenfeld
Em 06-01-2012 10:30, Rodrigo Rosenfeld Rosas escreveu:
...
Continuing, I think you missed important frameworks for the JavaScript language using Node.js:

Express: http://expressjs.com/
Geddy: http://geddyjs.org/

I've just heard about Matador: http://obvious.github.com/matador/ :)

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

Scott6666
In reply to this post by rlovtangen
Wow, I think I finally understand.

New Roadblock:  
Doc says "simply request commit access to the following repository http://github.com/pledbrook/grails-doc by sending a GitHub message to 'pledbrook' "

Go to github repo via link.  No message link on repo page.  Click on pledbrook.  The message icon is dimmed out on Peter's page.  Says "pledbrook has not provided an email address".  Is there somewhere / someway else to message Peter?  I did request earlier on this list for Peter to give me commit access.

Peter?

 
On Jan 6, 2012, at 8:23 AM, Ronny Løvtangen wrote:

>
> On Jan 6, 2012, at 1:15 PM, Scott Eisenberg wrote:
>
>> OK.  I'll take this an invitation to pair up and make things better.  By another post, I see Rodrigo is game as well.
>>
>> Why not start by a definitive answer to the question:
>>
>> Why are their 2 repositories in the description?
>>
>> Line 1 says "that anyone can request commit access to" the following:  http://github.com/grails/grails-doc
>
> No, it says that there is a public fork of http://github.com/grails/grails-doc that anyone can request commit access to. This public fork is http://github.com/pledbrook/grails-doc
> But yes, this could be rewritten to be more clear
>
>>
>> Line 2 then immediately contradicts that by saying you should submit to pledbrooks's repository.
>>
>> If #2, then give me commit access to your fork and tell me why we have 2 options.
>>
>> On Jan 6, 2012, at 4:41 AM, Peter Ledbrook wrote:
>>
>>> Scott,
>>>
>>>> I thought the point was by and large you didn't need to learn hibernate and
>>>> spring to build most grails apps.
>>>
>>> I believe you should be able to get started with Grails without
>>> knowing Hibernate or Spring, but you do need to learn them to gain the
>>> full benefits of the framework - Spring in particular.
>>>
>>> We do acknowledge that there are users coming from non-Java
>>> backgrounds and we want to encourage them. The new stack trace format
>>> introduced with Grails 2 was created in recognition that the standard
>>> Java stack traces aren't particularly readable if you haven't been
>>> working with them before. However, most active contributors have a
>>> Java background, so we rely on community feedback and (more
>>> importantly) contributions from the non-Java people.
>>>
>>> If you can identify common issues that PHP developers encounter, then
>>> please add them to a wiki page on grails.org or GitHub and point us to
>>> it. That could serve as the basis for both introductory material for
>>> non-Java developers and improvements in the documentation and the
>>> framework itself. For example, Rodrigo and yourself have mentioned
>>> that it's difficult when something goes wrong. So what are the common
>>> errors and what makes them difficult to rectify? That's information
>>> that we can work with.
>>>
>>> On the mailing list front, if we can answer a question off the top of
>>> our heads, we will. But most of those have already been answered by
>>> others. Everything else tends to be more involved than it may appear.
>>>
>>> Regards,
>>>
>>> Peter
>>>
>>> --
>>> Peter Ledbrook
>>> Grails Advocate
>>> SpringSource - A Division of VMware
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>  http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>   http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

virtualeyes
In reply to this post by tomas lin
It looks like you can get around the redis CF dependency since the mighty GL says that Caelyf falls back to localhost connection if CF-based VCAP_SERVICES environment variable is not found.

Basically, one may be able to run it anywhere; I'll give it a shot.

Would also prefer Scalate over Groovy Template, although that is a bit of a basswards approach, fast templates, slow application layer ;-)

Thanks for the tip, Tomas
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

pledbrook
In reply to this post by Scott6666
> Wow, I think I finally understand.
>
> New Roadblock:
> Doc says "simply request commit access to the following repository http://github.com/pledbrook/grails-doc by sending a GitHub message to 'pledbrook' "
>
> Go to github repo via link.  No message link on repo page.  Click on pledbrook.  The message icon is dimmed out on Peter's page.  Says "pledbrook has not provided an email address".  Is there somewhere / someway else to message Peter?  I did request earlier on this list for Peter to give me commit access.

I need your GitHub user ID, which I get automatically if you send a
GitHub message. If you're logged into GitHub, just click on the
antenna icon in the top right and then "Compose Message".

I find it very strange that the GitHub "Message" button requires an
email address and there's no easy option for internally messaging a
user from his or her profile page.

Anyway, you could email me your ID if you'd like.

Peter

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

Scott6666
Git message sent.

Now, if you think I'm bad at Grails wait to you see how I can f-up Git.  Used SVN at my last company.  Trying to change over to Git but surprises still seem to remain.

On Jan 6, 2012, at 11:03 AM, Peter Ledbrook wrote:

>> Wow, I think I finally understand.
>>
>> New Roadblock:
>> Doc says "simply request commit access to the following repository http://github.com/pledbrook/grails-doc by sending a GitHub message to 'pledbrook' "
>>
>> Go to github repo via link.  No message link on repo page.  Click on pledbrook.  The message icon is dimmed out on Peter's page.  Says "pledbrook has not provided an email address".  Is there somewhere / someway else to message Peter?  I did request earlier on this list for Peter to give me commit access.
>
> I need your GitHub user ID, which I get automatically if you send a
> GitHub message. If you're logged into GitHub, just click on the
> antenna icon in the top right and then "Compose Message".
>
> I find it very strange that the GitHub "Message" button requires an
> email address and there's no easy option for internally messaging a
> user from his or her profile page.
>
> Anyway, you could email me your ID if you'd like.
>
> Peter
>
> --
> Peter Ledbrook
> Grails Advocate
> SpringSource - A Division of VMware
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

pledbrook
> Git message sent.
>
> Now, if you think I'm bad at Grails wait to you see how I can f-up Git.  Used SVN at my last company.  Trying to change over to Git but surprises still seem to remain.

Be sure to check out this screencast:

   http://grails.org/screencast/show/21

And once you get used to git, you'll struggle to go back to
Subversion. It does have a bit of a tough learning curve, particularly
because of its esoteric terminology. Once you get past that it's fine
though. Any questions, feel free to fire them on the user mailing
list.

Thanks for offering to contribute!

Peter

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

Frank Greco
In reply to this post by Mengu
Yes, I totally agree.

Grails targets existing Java developers without a doubt.  As a matter of fact, you really should know Groovy, Hibernate and Junit... Spring and Maven are nice to haves (and with Maven, I am being kind). 

Grails is *NOT* for Java beginners.  Most, if not all the tutorials and books out there make these assumptions.  I also would not recommend it to a python or php developer, ie, a typical web programmer.

Error handling is awful.  Simple mistakes generate tons of not-very-helpful messages.  I know that much of this is due to the dynamic nature of Groovy, but the error msgs are just awful and most of the time does not point the programmer in the right direction to fix their issues.

Clearly it is powerful and there is a lot of flexibility.  But imo, Grails needs tools that address the average web developer, not the experienced Java developer, which honestly is not a typical web programmer.

Frank G


On 1/5/12 8:35 PM, Muhammet S. AYDIN wrote:
i have written many times about this issue. grails is targeting existing java developers. even a java beginner will get frustrated let alone a php, python or ruby developer. i am a developer who uses php and python in his daily job, built a start-up with ruby. grails disappointed me too many times but i have not stopped trying and learning it. for example, when building an application with turbogears/django/rails, if i need to dive in the source i just browse their source codes in my browser but whenever i wanted to dive in grails source i always got stuck. because i don't know what is doing what. i fire up an ide and after tens of clicks and i get frustrated. i stopped doing that. 

how i stopped worrying and loved grails?

grails in my opinion is the next generation jvm web framework. it will dominate the scene. imho, its only competitor is play framework. even though i am not java developer, play was very easy for me to get started and dive into its source. heck, i loved grails more. i just felt that way and found more value in grails than anything else for the jvm. 

here is the methodology i followed some years ago. i assume that you already know the basic concepts of web programming and mvc. go ahead and read in eric cartman's voice. :)

- fear do not.

- install grails and start a sample project.

- the goal is porting an existing app to grails from php/python/ruby.

- watch grails screencasts. (back in my time, this was only 1 page, now it's 3 pages.)




- problem, programmer? 
    - search stackoverflow, grails ml and google.
    - look at the docs.
    - ask in #grails in irc.freenode.net

- do not freak out, errors are your guide.





- do not freak out, you are doing great.

- how do i access session? i need to build a simple authentication. spring-security is overkill.

- how do i change content type? i just want to change it.

- how do i render json? i want my response to be json.

- how do i deploy this? 

as you see in the flow, porting an existing application from a similar tool is a great way to learn grails. you already have the idea, you know the concepts and you know your requirements. all you need to do is to ask the right questions and find answers to them. learning as you go instead of reading the docs from beginning to end is better. this is not where you stop. when you develop another application, you will ask a lot more different questions. you will face other challenges but you will be learning as you go.

hope this helps to someone. do not fight grails. embrace it. love it. use it. on something that has more memory than 512 mb. :)

2012/1/6 Octavian Covalschi <[hidden email]>
"  PHP without frameworks is easy to get things done " - this might be true, however how easy si to maintain those "done things" ? What about quality? 

I think some folks switching between technologies tend to think and code as they're used to and from there are a lot of complaints... 

No one has forbidden buying Grails books, there are plenty of good ones and even more sample web apps... 

When someone is coming to Grails world, he is coming to Java world... which basically means:
- junit
- spring (not a must for grails, but helps a lot)
- hibernate
- ivy/maven/other dependency 




On Thu, Jan 5, 2012 at 4:20 PM, Scott Eisenberg <[hidden email]> wrote:
I just think that Rails is the main competition (and to some degree inspiration) to Grails.  I want Grails to be the preferred framework.  To do that it must beat the competition.  Therefore, it must be compared to know where it needs to improved.

Nothing is absolute, it's all relative.

PS  I think all PHP frameworks are crap.  That's why anyone wanting to grow beyond PHP will naturally look to Rails or Grails as a higher evolution.  PHP without frameworks is easy to get things done; just typically doesn't really become OO type code.

On Jan 5, 2012, at 5:10 PM, Jason Davis wrote:

> I come from an almost exclusive java/swing background. No web apps at
> all. So I don't know much about spring or hibernate to be honest. I
> found grails really easy to get started with. I really don't
> understand the complaints. I tried some web dev with php, using
> CakePHP and no framwork at all. I hate PHP so no point in discussing
> it anymore. I didnt find in anymore welcoming.
>
> IRT unanswered posts... I wish our community was bigger and more
> active in this regard. I have had good luck using stackoverflow.com.
> I feel that grails allows really new people to get further than they
> normally would. This makes for some wild, unintelligible questions on
> the mailing list sometimes lol. Just knowing what the user is actually
> asking is no easy task.
>
> In the end I don't see where all this comparison helps anything. I'm
> on this list to learn/help with grails/groovy. I really could care
> less about how awesome rails/ruby is.
>
> $.02
>
> On Thu, Jan 5, 2012 at 2:49 PM, Scott Eisenberg <[hidden email]> wrote:
>> I have to say as a PHP developer trying to move to Grails that I can sympathize with his various feelings.
>>
>> 1) I watch the list every day and see a number of questions - not just his - that go unanswered.  Sometimes some round and round but they they just drop.  It seems to me like a lot of the questions are simple answers that are just not documented well with another lot of questions being some serious grails voodoo that experts know about but kills newbies.
>>
>> I can only assume that the Grails team is busy but I've often thought "they (Graeme, Peter, Burt) must know the answer off the top of their heads, why don't they just respond?"  I would respond but most are beyond my knowledge.
>>
>> 2) The answer that you need to know Spring / Hibernate / etc to me is just crap.  If you want to bring in experienced Java programmers to something rad-ier, then fine.  If you want the PHP, .net and Rails people to come over, big mistake.
>>
>> 3) Every 6 months I try Grails again and within 5 hours of starting a project I hit some error that stops me cold.  I have read the documentation about 10 times.  I read the Gorm Gotchas.  Now, I'm only moderately stupid (Ivy league degree in engineering + MBA from a top level school + 20 years development experience) so I know I should not be able to make this stuff work.  But I managed to code a bunch of systems for my companies using Fortran, Java + JSP, Java + Generics + Frontman, & PHP but after 3 years of looking at Grails I'm still trying faces and noses, and books and authors just trying to get anything to work.
>>
>> IM<not so>HO, the Grails team REALLY needs to respond to the pains of the newbies via doc and code simplification.  The lack of attention to this is solely the reason why Grails remains so far back in the what's hot Google listings.
>>
>> Seems to me like you have a few rabid perpetual newbies who are trying to let you all know that getting Grail to work is way too frustrating for us PHP'ers and we are implicitly offering to show you our pain.  You'd we wiser to form some kind of on-line working group of newbies and keep fixing what roadblocks they run into (and iterating again with another round of newbies) until the roadblocks are but minor bumps in the road.
>>
>> There's a LOT of doc written.  It's a shame that the little bits missing, mess up the experience despite all that's been done.
>>
>> Answering EVERY open question on the mailing list that someone else can't solve would be a GREAT first step.
>>
>> I'm pretty convinced it's not the newbie's fault why grails is so hard get started with.
>>
>> I've seen threads like this every few months or so.  I know I'm pissing in the wind but what the hell.
>>
>> PS Grails 2.0 is much better than the 1.x versions.  There is always hope.
>>
>> PPS  I'm progressing down the path of learning Rails as a back-up.  I have thoughts on what they do better.
>>
>> Action Plan:
>> * Grails team dedicates one member (or all members) to make sure that every question asked on the listserv is answered.  EVERY answer question drives a review of the doc to see what could be added to avoid the questions coming forward.
>> * Grails tram makes a committee of newbies who are actively trying to develop something real and have a real time dialog as to where they get stuck and immediately fixing the stuck-ness, particularly the documentation issues.
>> * Group actively tries to compare Rails v Grails and fix competitive disadvantages found.  Rather than dismissing rails vs grails discussions, encourage them so long as they lead to Grails improvements.  Designate a "Beat-Rails" evangelist from Spring to lead the effort.
>>
>> On Jan 5, 2012, at 8:17 AM, Rodrigo Rosenfeld Rosas wrote:
>>
>>> Hi virtualeyes,
>>>
>>> Em 04-01-2012 19:51, virtualeyes escreveu:
>>>> ...  The reality is that Grails
>>>> is in fact absurdly fast to restart, faster than or as fast as, cough-cough,
>>>> Rails.
>>>
>>> I have no idea where you did take your estimates from. In my PC, Grails takes from 36 to 40s to boot an empty app, while JRuby on Rails takes about 16s and Rails itself (on CRuby) takes a single second. I guess you were talking about using the interactive console for booting the Grails app. In that case, for an empty app, it takes about 2 seconds here, which is still a bit slower than vanilla Rails, but certainly much faster than JRuby on Rails.
>>>
>>> But anyway, I'm not really much concerned about the time required to boot the application as long as I only have to do it once. My main gripe with Grails 1.3.7 is that it would reboot after each little change to my domain classes and other source files, and that took a huge time.
>>>
>>> Now, with Grails 2, even without the interactive console, the user experience is much better as I don't need to often reboot the application. The interactive console just makes Grails even more responsive. But in the expense of subtle bugs that will show up when using the interactive console that wouldn't be present otherwise...
>>>
>>> The main disadvantage of a slow bootup time (in any framework/environment) is that it makes running your integration tests slower. While using Rspec for writing tests for Rails, one can use Spork that will take a similar approach to the one taken from Grails interactive console, that will make tests run much faster.
>>>
>>> So, that article that you mentioned is certainly out-of-date and I need to rewrite it when I find some time. I'll write a new one and add a deprecation note on that one when I'm done for keeping the old comments.
>>>
>>> My main gripe with Grails currently is that I find it very hard to debug and find what is causing troubles in my application setup. I often have to create a fresh Grails app and gradually copy my files to there until I find the source of the problem.
>>>
>>> The Grails error messages don't give me a single clue about the problem most of the times. That is not to say that I have no more issues with Grails. I don't like it in many ways, but I find the over-complex black magic behind Grails the one that takes be most of the time when I'm trying to identify some issues.
>>>
>>> Also, I find that the Grails community has poor support when compared with the Rails and Ruby one. I have lots of unanswered messages in this list where I point to buggy scenarios or plugins.
>>>
>>> For, example, I've filled two bugs in the Rails issues system last year, and both were fixed and commited in less than an hour:
>>>
>>> https://github.com/rails/rails/issues/4054
>>> https://github.com/rails/rails/issues/4067
>>>
>>> In the other side, here are some bugs (or feature requests) I've reported to the Grails JIRA:
>>>
>>> http://jira.grails.org/browse/GRAILS-8568
>>> http://jira.grails.org/browse/GRAILS-8567
>>> http://jira.grails.org/browse/GPCONSOLE-3
>>> http://jira.grails.org/browse/GRAILS-8539 (I'm the only one participating on this one, for example)
>>> http://jira.grails.org/browse/GRAILS-8485
>>> http://jira.grails.org/browse/GRAILS-7792 (feature request)
>>> http://jira.grails.org/browse/GRAILS-3303 (closed as won't fix, although I think it could be fixed...)
>>> https://github.com/SpringSource/grails-data-mapping/issues/18
>>>
>>> Unanswered messages in this list:
>>>
>>> http://grails.1312388.n4.nabble.com/Strange-issue-with-Grails-2-and-find-with-closure-td4222761.html
>>> http://grails.1312388.n4.nabble.com/mongodb-and-hibernate-are-not-playing-well-together-td4222229.html this wasn't answered. It was just told me to not report bugs in the dev mailing list, but I didn't get any reply in the user's list too
>>> http://grails.1312388.n4.nabble.com/MongoDB-and-multiple-databases-not-talking-about-replication-td4210794.html just a minor part of the message was answered
>>> http://grails.1312388.n4.nabble.com/Is-there-an-easy-way-to-set-default-mapping-options-to-all-columns-of-some-GORM-class-td4210934.html
>>> http://grails.1312388.n4.nabble.com/mongodb-plugin-and-quot-static-mapping-version-false-quot-why-does-the-quot-version-quot-key-is-adde-td4210920.html
>>> http://grails.1312388.n4.nabble.com/Grails-resources-plugin-still-uses-deprecated-ConfigurationHolder-td4208027.html
>>> http://grails.1312388.n4.nabble.com/grails-shell-will-raise-an-exception-while-trying-to-autocomplete-a-Map-td4205530.html
>>> http://grails.1312388.n4.nabble.com/Can-t-upgrade-to-Grails-2-from-1-3-7-and-have-no-clue-all-requests-yields-to-404-status-td4178489.html
>>> http://www.digipedia.pl/usenet/thread/14352/30474/
>>> http://grails.1312388.n4.nabble.com/How-to-write-scripts-using-GORM-enabled-domain-classes-td3868599.html (I've got only a suggestion to use another testing framework, but didn't get a real answer to what I was asking for)
>>> http://grails.1312388.n4.nabble.com/Grails-scripts-help-td3867976.html
>>>
>>>
>>> Also, besides free time, I still need some more time experimenting with Grails 2 before I can write the new article on the subject...
>>>
>>> Best,
>>>
>>> Rodrigo.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>   http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email






--
Muhammet S. AYDIN

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails development is really slow

Frank Greco
In reply to this post by Scott6666
This is definitely not true.

Hibernate idioms are used throughout Grails.  Books on Grails mention Hibernate.  GORM docs mention Hibernate.
And... simple runtime errors generate a flood of Spring exceptions.  Adding advanced features talk about including Spring classes.  A missing relationship method in a domain class causes pages of java.util.concurrent.FutureTask$Sync exceptions/errors.

Most of the books are *way* out of date.  Yes, the basics are correct, but after the first few chapters, its not useful to follow them anymore due to 2.0 features.  No offense to the book authors, but I have not seen a top-notch Grails book for beginners to recommend to the NY Java community.  There are excellent Groovy books, but the Grails books could be much, much better.

Here's a challenge:  write a tutorial/book or a video that does not mention Hibernate, Spring, Maven, Ivy, the SpringSource tools, etc... just Groovy (and maybe junit).

There's no doubt Grails is powerful and a leading web framework (along with Play!), but the big chunk of devs in the middle of the gaussian curve of java devs is still not adopting Grails.

Imo there needs to be an opaque black box (not a translucent one) around it to get a larger adoption beyond the experienced Java crowd.

Frank

On 1/5/12 11:44 PM, Scott Eisenberg wrote:
I thought the point was by and large you didn't need to learn hibernate and spring to build most grails apps. 

That's also NOT where newbies get stuck, except perhaps for the Gorman Gotchas. 

It's often where the black box blows up and you get an ungodly stack trace that the newbie dies. Hmmm, black box explosions. Sounds dangerous. (I'm copyrighting that expression.)


On Jan 5, 2012, at 11:28 PM, Gavin Yue <[hidden email]> wrote:

For the newbies, maybe spring and hibernate are too complex. 
And it is a blackbox that how grails integrates them. 

On Thu, Jan 5, 2012 at 11:14 PM, Scott Eisenberg <[hidden email]> w! rote:
I think to some degree you all are missing the point.  IF you want a mass adoption framework, you need to make it easier for newbies.  If you want to remain a niche framework, the you're right.

Frankly, what's missing in Grails is not a requirement to learn the underpinnings (Grails is good at hiding that) but to explain better and not hit stupid - and typically trivial - roadblocks.

I haven't seen anyone jump back with the response:  "Great, let's do whatever we can to make the learning curve easier" so I can only assume that the community does not see this as any sort of priority.  That's cool.  Wrong, but cool.

PS  I own at least 3 Grails books printed and 2 Kindle.  Any Grails book is at least 2 years out of date.  You gotta wonder why no one's written a Grails book since 2009.  It's 'cause the framework is losing the battle for newbies!

If I were a VP of Product Management at Spring, I would be all over this adoption curve stuff.  Who's running SpringSource anyway?



On Jan 5, 2012, at 5:43 PM, Octavian Covalschi wrote:

"  PHP without frameworks is easy to get things done " - this might be true, however how easy si to maintain those "done things" ? What about quality? 

I think some folks switching between technologies tend to think and code as they're used to and from there are a lot of complaints... 

No one has forbidden buying Grails books, there are plenty of good ones and even more sample web apps... 

When someone is coming to Grails world, he is coming to Java world... which basically means:
- junit
- spring (not a must for grails, but helps a lot)
- hibernate
- ivy/maven/other dependency 




On Thu, Jan 5, 2012 at 4:20 PM, Scott Eisenberg <[hidden email]> wrote:
I just think that Rails is the main competition (and to some degree inspiration) to Grails.  I want Grails to be the preferred framework.  To do that it must beat the competition.  Therefore, it must be compared to know where it needs to improved.

Nothing is absolute, it's all relative.

PS  I think all PHP frameworks are crap.  That's why anyone wanting to grow beyond PHP will naturally look to Rails or Grails as a higher evolution.  PHP without frameworks is easy to get things done; just typically doesn't really become OO type code.

On Jan 5, 2012, at 5:10 PM, Jason Davis wrote:

> I come from an almost exclusive java/swing background. No web apps at
> all. So I don't know much about spring or hibernate to be honest. I
> found grails really easy to get started with. I really don't
> understand the complaints. I tried some web dev with php, using
> CakePHP and no framwork at all. I hate PHP so no point in discussing
> it anymore. I didnt find in anymore welcoming.
>
> IRT unanswered posts... I wish our community was bigger and more
> active in this regard. I have had good luck using stackoverflow.com.
> I feel that grails allows really new people to get further than they
> normally would. This makes for some wild, unintelligible questions on
> the mailing list sometimes lol. Just knowing what the user is actually
> asking is no easy task.
>
> In the end I don't see where all this comparison helps anything. I'm
> on this list to learn/help with grails/groovy. I really could care
> less about how awesome rails/ruby is.
>
> $.02
>
> On Thu, Jan 5, 2012 at 2:49 PM, Scott Eisenberg <[hidden email]> wrote:
>> I have to say as a PHP developer trying to move to Grails that I can sympathize with his various feelings.
>>
>> 1) I watch the list every day and see a number of questions - not just his - that go unanswered.  Sometimes some round and round but they they just drop.  It seems to me like a lot of the questions are simple answers that are just not documented well with another lot of questions being some serious grails voodoo that experts know about but kills newbies.
>>
>> I can only assume that the Grails team is busy but I've often thought "they (Graeme, Peter, Burt) must know the answer off the top of their heads, why don't they just respond?"  I would respond but most are beyond my knowledge.
>>
>> 2) The answer that you need to know Spring / Hibernate / etc to me is just crap.  If you want to bring in experienced Java programmers to something rad-ier, then fine.  If you want the PHP, .net and Rails people to come over, big mistake.
>>
>> 3) Every 6 months I try Grails again and within 5 hours of starting a project I hit some error that stops me cold.  I have read the documentation about 10 times.  I read the Gorm Gotchas.  Now, I'm only moderately stupid (Ivy league degree in engineering + MBA from a top level school + 20 years development experience) so I know I should not be able to make this stuff work.  But I managed to code a bunch of systems for my companies using Fortran, Java + JSP, Java + Generics + Frontman, & PHP but after 3 years of looking at Grails I'm still trying faces and noses, and books and authors just trying to get anything to work.
>>
>> IM<not so>HO, the Grails team REALLY needs to respond to the pains of the newbies via doc and code simplification.  The lack of attention to this is solely the reason why Grails remains so far back in the what's hot Google listings.
>>
>> Seems to me like you have a few rabid perpetual newbies who are trying to let you all know that getting Grail to work is way too frustrating for us PHP'ers and we are implicitly offering to show you our pain.  You'd we wiser to form some kind of on-line working group of newbies and keep fixing what roadblocks they run into (and iterating again with another round of newbies) until the roadblocks are but minor bumps in the road.
>>
>> There's a LOT of doc written.  It's a shame that the little bits missing, mess up the experience despite all that's been done.
>>
>> Answering EVERY open question on the mailing list that someone else can't solve would be a GREAT first step.
>>
>> I'm pretty convinced it's not the newbie's fault why grails is so hard get started with.
>>
>> I've seen threads like this every few months or so.  I know I'm pissing in the wind but what the hell.
>>
>> PS Grails 2.0 is much better than the 1.x versions.  There is always hope.
>>
>> PPS  I'm progressing down the path of learning Rails as a back-up.  I have thoughts on what they do better.
>>
>> Action Plan:
>> * Grails team dedicates one member (or all members) to make sure that every question asked on the listserv is answered.  EVERY answer question drives a review of the doc to see what could be added to avoid the questions coming forward.
>> * Grails tram makes a committee of newbies who are actively trying to develop something real and have a real time dialog as to where they get stuck and immediately fixing the stuck-ness, particularly the documentation issues.
>> * Group actively tries to compare Rails v Grails and fix competitive disadvantages found.  Rather than dismissing rails vs grails discussions, encourage them so long as they lead to Grails improvements.  Designate a "Beat-Rails" evangelist from Spring to lead the effort.
>>
>> On Jan 5, 2012, at 8:17 AM, Rodrigo Rosenfeld Rosas wrote:
>>
>>> Hi virtualeyes,
>>>
>>> Em 04-01-2012 19:51, virtualeyes escreveu:
>>>> ...  The reality is that Grails
>>>> is in fact absurdly fast to restart, faster than or as fast as, cough-cough,
>>>> Rails.
>>>
>>> I have no idea where you did take your estimates from. In my PC, Grails takes from 36 to 40s to boot an empty app, while JRuby on Rails takes about 16s and Rails itself (on CRuby) takes a single second. I guess you were talking about using the interactive console for booting the Grails app. In that case, for an empty app, it takes about 2 seconds here, which is still a bit slower than vanilla Rails, but certainly much faster than JRuby on Rails.
>>>
>>> But anyway, I'm not really much concerned about the time required to boot the application as long as I only have to do it once. My main gripe with Grails 1.3.7 is that it would reboot after each little change to my domain classes and other source files, and that took a huge time.
>>>
>>> Now, with Grails 2, even without the interactive console, the user experience is much better as I don't need to often reboot the application. The interactive console just makes Grails even more responsive. But in the expense of subtle bugs that will show up when using the interactive console that wouldn't be present otherwise...
>>>
>>> The main disadvantage of a slow bootup time (in any framework/environment) is that it makes running your integration tests slower. While using Rspec for writing tests for Rails, one can use Spork that will take a similar approach to the one taken from Grails interactive console, that will make tests run much faster.
>>>
>>> So, that article that you mentioned is certainly out-of-date and I need to rewrite it when I find some time. I'll write a new one and add a deprecation note on that one when I'm done for keeping the old comments.
>>>
>>> My main gripe with Grails currently is that I find it very hard to debug and find what is causing troubles in my application setup. I often have to create a fresh Grails app and gradually copy my files to there until I find the source of the problem.
>>>
>>> The Grails error messages don't give me a single clue about the problem most of the times. That is not to say that I have no more issues with Grails. I don't like it in many ways, but I find the over-complex black magic behind Grails the one that takes be most of the time when I'm trying to identify some issues.
>>>
>>> Also, I find that the Grails community has poor support when compared with the Rails and Ruby one. I have lots of unanswered messages in this list where I point to buggy scenarios or plugins.
>>>
>>> For, example, I've filled two bugs in the Rails issues system last year, and both were fixed and commited in less than an hour:
>>>
>>> https://github.com/rails/rails/issues/4054
>>> https://github.com/rails/rails/issues/4067
>>>
>>> In the other side, here are some bugs (or feature requests) I've reported to the Grails JIRA:
>>>
>>> http://jira.grails.org/browse/GRAILS-8568
>>> http://jira.grails.org/browse/GRAILS-8567
>>> http://jira.grails.org/browse/GPCONSOLE-3
>>> http://jira.grails.org/browse/GRAILS-8539 (I'm the only one participating on this one, for example)
>>> http://jira.grails.org/browse/GRAILS-8485
>>> http://jira.grails.org/browse/GRAILS-7792 (feature request)
>>> http://jira.grails.org/browse/GRAILS-3303 (closed as won't fix, although I think it could be fixed...)
>>> https://github.com/SpringSource/grails-data-mapping/issues/18
>>>
>>> Unanswered messages in this list:
>>>
>>> http://grails.1312388.n4.nabble.com/Strange-issue-with-Grails-2-and-find-with-closure-td4222761.html
>>> http://grails.1312388.n4.nabble.com/mongodb-and-hibernate-are-not-playing-well-together-td4222229.html this wasn't answered. It was just told me to not report bugs in the dev mailing list, but I didn't get any reply in the user's list too
>>> http://grails.1312388.n4.nabble.com/MongoDB-and-multiple-databases-not-talking-about-replication-td4210794.html just a minor part of the message was answered
>>> http://grails.1312388.n4.nabble.com/Is-there-an-easy-way-to-set-default-mapping-options-to-all-columns-of-some-GORM-class-td4210934.html
>>> http://grails.1312388.n4.nabble.com/mongodb-plugin-and-quot-static-mapping-version-false-quot-why-does-the-quot-version-quot-key-is-adde-td4210920.html
>>> http://grails.1312388.n4.nabble.com/Grails-resources-plugin-still-uses-deprecated-ConfigurationHolder-td4208027.html
>>> http://grails.1312388.n4.nabble.com/grails-shell-will-raise-an-exception-while-trying-to-autocomplete-a-Map-td4205530.html
>>> http://grails.1312388.n4.nabble.com/Can-t-upgrade-to-Grails-2-from-1-3-7-and-have-no-clue-all-requests-yields-to-404-status-td4178489.html
>>> http://www.digipedia.pl/usenet/thread/14352/30474/
>>> http://grails.1312388.n4.nabble.com/How-to-write-scripts-using-GORM-enabled-domain-classes-td3868599.html (I've got only a suggestion to use another testing framework, but didn't get a real answer to what I was asking for)
>>> http://grails.1312388.n4.nabble.com/Grails-scripts-help-td3867976.html
>>>
>>>
>>> Also, besides free time, I still need some more time experimenting with Grails 2 before I can write the new article on the subject...
>>>
>>> Best,
>>>
>>> Rodrigo.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>   http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email






1 ... 3456
Loading...