 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
8 messages in org.codehaus.groovy.userRe: [groovy-user] HQ gets more game b...| From | Sent On | Attachments |
|---|---|---|
| Jon Travis | Mar 25, 2008 9:39 am | |
| Keith Thomas | Mar 25, 2008 9:44 am | |
| Guillaume Laforge | Mar 25, 2008 9:49 am | |
| Jon Travis | Mar 25, 2008 10:33 am | |
| jbi joe | Mar 6, 2009 4:12 am | |
| Guillaume Laforge | Mar 6, 2009 5:38 am | |
| Peter Bell | Mar 6, 2009 6:50 am | |
| Jason Smith | Mar 6, 2009 7:19 am |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: [groovy-user] HQ gets more game by being Groovy! | Actions... |
|---|---|---|
| From: | Peter Bell (lis...@pbell.com) | |
| Date: | Mar 6, 2009 6:50:55 am | |
| List: | org.codehaus.groovy.user | |
Have you programmed in a dynamic language before? Are there particular elements of the implementation of Groovy that you feel make it more bug prone than (say) Smalltalk or Ruby? Do you do Test First Development? Fundamentally, the difference with dynamically typed languages is that you get more flexibility in your code in return for less compile time checking and IDE support (you're not gonna get code completion for methods that you mixin at runtime, for instance). It's a good fit for some programmers and use cases and less good for others.
Best Wishes, Peter
On Mar 6, 2009, at 7:13 AM, jbi joe wrote:
I have been using groovy for about 9 months with FuseHQ doing a variety of tasks. I really like it alot for the simple tasks. However, IT HAS NOT been of great help in doing many of the tasks. Its like using a script language to program, except very obtuse. Here are my REASONS for NOT using it for most tasks. 1. DEBUGing is very difficult. It allows you to make MISTAKES in your code. 2. The API is very difficult and not java like. 3. There are a lot of "undocumented" features. Dont paint yourself into a corner! It lets U. 4. Most errors are only caught at run time where java would have hit them during compilation. 5. With FuseHQ, its unclear what is happening "under the covers", there is NO java API, that I found. 6. Most of the errors that you get using groovy are not very clear, like some of the exception is hidden. 7. To perform a combination of groovy/java is unwieldy cause it allows java bugs too!
Jon Travis wrote:
Ahoy, Groovy cats!
I wanted to drop a note, thanking the community and the Groovy developers for creating such a solid, important piece of software. It's enabled us to be very agile, adding new pluggable features to our Java app in minutes. I hope this letter inspires other Java based projects to consider adding Groovy to their arsenal.
We are using Groovy for a variety of things: - Creating pluggable UI screens and features - Providing web-services APIs - Templating emails sent in Alerts - Increasing visibility to diagnose issues in a running server - Giving admins the ability to script and automate HQ in an easy and obvious way
Our software (Hyperic HQ) is a very large project, able to monitor any software / hardware via a generic plugin infrastructure. This generic nature also means that our UI does not have specific screens for specific products. We've created a plugin framework (HQU) based on Groovy, which allows plugins to display entirely new screens, embedded within our application.. This means that we can now provide extremely deep, detailed information about MySQL, Apache, Cisco IOS, etc. in screens tailored exactly for that product. HQU provides a Rails/Grails style interaction between the HQ server and the plugins, providing maximum power, with minimum code.
We've used HQU to create our Alert Center, Event Center, Groovy Console, Nagios screens, and tonnes more. The code-rev time of working on a Groovy-based feature is a fraction of the time compared to compiling and redeploying Java changes. Time from change to reload is < 15 seconds.
On the web-services side, Groovy's XML integration is so seamless and easy, we are able to create interactions with JIRA or other RSS / XML based services in only a few lines. This productivity would not have been possible without the benefit of Groovy.
HQU also provides an API on top of our Java API which makes accessing our internal APIs more paletable. Since HQ was originally built on session beans, the API is generally not as object-oriented as we'd like and the APIs suffer from corosion. By using Categories and MetaClasses, we can give developers an obvious, intuitive toolkit.
Finally, we've added a Groovy Console to our administration section. This has proven to be invaluable when developing a feature (who needs to recompile to test HQL queries?), debugging a running instance, or performing advanced, scripted functions.
I'll be giving a HyperCAST on Wednesday (will be archived), discussing how Groovy fits into our development cycle.
HyperCAST information here: http://www.hyperic.com/demo/hypercasts.html
HQU Plugins can also be viewed here: - hquplugins.org (development information) - http://support.hyperic.com/confluence/display/hypcomm/HQU+Forge (plugins)
-- Jon Travis Principal Engineer, Hyperic Inc.
--------------------------------------------------------------------- To unsubscribe from this list, please visit:
--
View this message in context:
http://www.nabble.com/HQ-gets-more-game-by-being-Groovy%21-tp16282591p22371334.html
Sent from the groovy - user mailing list archive at Nabble.com.
--------------------------------------------------------------------- To unsubscribe from this list, please visit:
--------------------------------------------------------------------- To unsubscribe from this list, please visit: