Grails Worst Practices
31 likes10,103 views
The document provides a list of "worst practices" to avoid when using the Grails web framework. Some of the worst practices include overusing copy and paste coding, not implementing adequate testing or security measures, putting too much logic in GSP view templates, avoiding documentation and code organization practices, and not taking advantage of available Grails resources like documentation and mailing lists. The goal is to humorously highlight practices that could negatively impact a Grails application.
![def getAverageAgePerPlan() {
def planAgeBarData = []
Insurer insurer = ...
insurer.plans.each { plan ->
int ageTotal = 0
for (Person person : plan.customers) {
ageTotal += person.age
}
int avgAge = plan.customers.isEmpty()
? 0 : ageTotal / plan.customers.size()
planAgeBarData << [plan.name, avgAge]
}
planAgeBarData
}](https://image.slidesharecdn.com/grailsworstpractices-140328162448-phpapp01/85/Grails-Worst-Practices-85-320.jpg)
Ad
More Related Content
What's hot (20)
Viewers also liked (6)
Ad
Similar to Grails Worst Practices (20)
![[GEMINI EXTERNAL DECK] Introduction to Gemini.pptx](https://cdn.slidesharecdn.com/ss_thumbnails/geminiexternaldeckintroductiontogemini-240507183804-614e2404-thumbnail.jpg?width=560&fit=bounds)
Ad
Recently uploaded (20)
![Get & Download Wondershare Filmora Crack Latest [2025]](https://cdn.slidesharecdn.com/ss_thumbnails/revolutionizingresidentialwi-fi-250422112639-60fb726f-250429170801-59e1b240-thumbnail.jpg?width=560&fit=bounds)
![Download Wondershare Filmora Crack [2025] With Latest](https://cdn.slidesharecdn.com/ss_thumbnails/neo4j-howkgsareshapingthefutureofgenerativeaiatawssummitlondonapril2024-240426125209-2d9db05d-250419-250428115407-a04afffa-thumbnail.jpg?width=560&fit=bounds)
Grails Worst Practices
- 1. Grails Worst Practices Burt Beckwith
- 3. 3 le Tex t Our Services Our services start with a foundation of planning, interaction design, and visual design. We are expert builders with a passion for protoyping, architecture and development to help bring your product to life. 
- 5. All of the topics discussed here are important, and 100% serious
- 7. Important Concepts: Easier is better
- 8. Finishing tasks faster is better Important Concepts:
- 9. Use the first solution that you think of Important Concepts:
- 10. Minimize the time you spend at work Important Concepts:
- 11. Get others to do your work for you Important Concepts:
- 12. Lazy is good Important Concepts:
- 13. If there's a problem, fix it if and when you have to Important Concepts:
- 14. Cover your tracks Important Concepts:
- 15. Be more like your dog Important Concepts:
- 17. Grails Can Be Frustrating
- 19. Facebook uses it, and they have over 1,000,000,000 users Try to think like a PHP developer
- 20. Sure, we can use O-O principles, but we aren't required to, so why bother? Try to think like a PHP developer
- 21. Controllers
- 22. It's how scaffolding is generated, so it must be the best way One controller per domain class
- 23. Always trust generated code Corollary:
- 24. They're your interface between the client and the application Put most of your code in controllers
- 25. If Grails doesn't want us to have Groovy code in scriptlets (and to call GORM, etc.) then why is it allowed? Do a lot of work in GSPs
- 26. Eventually you'll hit the maximum GSP size limit, but that's a problem for later Do a lot of work in GSPs
- 27. Don't worry that it's difficult to test code in GSPs Do a lot of work in GSPs
- 28. “@BurtBeckwith What is the advantage of using TagLibs over writing code on the view?” Do a lot of work in GSPs
- 29. “@BurtBeckwith What is the advantage of using TagLibs over writing code on the view?” Do a lot of work in GSPs
- 30. Luckily for us, there's a cool new @grails.transaction.Transactional annotation that can be used in controllers. ¡Genial! Transactions are important
- 31. Unfortunately, @Transactional cannot be used in GSPs Transactions are important
- 32. Someone should create a JIRA enhancement request for that. Transactions are important
- 33. Someone should create a JIRA enhancement request for that. Transactions are important Until then, use withTransaction
- 34. If all of your business logic is in controllers, who needs services? Don't waste time with services
- 35. Idiomatic Groovy
- 36. Use def everywhere. It's so easy to type. Always use optional types
- 37. If the Groovy runtime can figure out what's going on, so can your coworkers. Always use optional types
- 38. They will impress your friends who don't know Groovy Prefer closures to methods
- 39. Don't bother rewriting performance-critical code in Java or in Groovy with @CompileStatic Write the grooviest code possible
- 40. Groovy style and language feature guidelines for Java developers Don't follow these guidelines:
- 41. Code Reuse
- 42. Copy and paste
- 43. Copy and paste. A lot.
- 44. If it works, keep using it Copy and paste. A lot.
- 45. When you copy and paste, you don't have to deal with taglibs, templates, helper classes, etc. Copy and paste. A lot.
- 46. If it got a lot of votes on Stack Overflow, it belongs in your code Copy and paste. A lot.
- 47. If buggy code was copied and pasted in several places, be sure to try to find and fix all of them Copy and paste. A lot.
- 48. Testing
- 49. I don't get paid more if I write more code, do you? Testing is not worth it
- 50. You spend all that time writing tests, and then something changes and they fail Testing is not worth it
- 51. If you don't have tests, you can't get yelled at for breaking the build Testing is not worth it
- 52. If you must write tests, wait until the end of the project. There's always extra time for tests and documentation Delay testing where possible
- 53. If you must write tests, always use unit tests because they run the fastest. Always write unit tests
- 54. It is not at all important to test persistence with a real database Always write unit tests – especially for persistence
- 55. If that were true, then why does Grails let you unit test domain classes? Always write unit tests – especially for persistence
- 56. All they do is complain about failed builds, usually because of failed tests Don't bother with CI servers
- 57. Security
- 58. Don't bother with Spring Security or Shiro, just implement it yourself. It's fun and easy! Security is difficult
- 59. Don't bother with Spring Security or Shiro, just implement it yourself. It's fun and easy! Security is difficult
- 60. Always store passwords in the database without using complicated hashing algorithms Security is difficult
- 61. It's important to be able to email users their passwords when they forget them Security is difficult
- 62. And if you get hacked, it's not like they're going to steal your money, right? Security is difficult
- 63. Store passwords in source control
- 64. This is called "security by obscurity" and it always works Store passwords in source control
- 65. I doubt that it's true that there are ~10,000 Amazon S3 production credentials in GitHub: Store passwords in source control https://github.com/search?q=production +SECRET_ACCESS_KEY%3A+%22A&type=Code&r ef=searchresults
- 66. Data Access
- 67. Don't bother checking hasErrors(). Let the error page handle expected user mistakes. Always use failOnError:true
- 68. The users will probably figure it out. And besides, all they ever do is complain. They're so negative. Always use failOnError:true
- 69. Exceptions aren't expensive, especially not in Groovy Always use failOnError:true “The Exceptional Performance of Lil' Exception”
- 70. Always use failOnError:true def thing = new Thing(params) try { thing.save(failOnError:true) // handle success case } catch (e) { // handle error case } def thing = new Thing(params) thing.save() if (thing.hasErrors()) { // handle success case } else { // handle error case }
- 71. Always use failOnError:true def thing = new Thing(params) try { thing.save(failOnError:true) // handle success case } catch (e) { // handle error case } def thing = new Thing(params) thing.save() if (thing.hasErrors()) { // handle success case } else { // handle error case } Obviously better
- 72. Database transactions are difficult
- 73. But you've probably heard that they're important. I sure have. Database transactions are difficult
- 74. Is there even any helpful information available? Database transactions are difficult
- 75. Is there even any helpful information available? Database transactions are difficult http://2013.gr8conf.eu/Presentations /Grails-Transactions
- 76. Speaking of convenience, have you seen GORM for REST? It's almost like giving your users direct access to your database: import grails.rest.* @Resource(uri='/books') class Book { String title } GORM for REST
- 77. Don't use http://grails.org/plugin/ spring-security-rest If you do use REST ...
- 78. Always use collections for one-many and many-many relationships
- 79. http://www.infoq.com/presentations/GORM-Performance Always use collections for one-many and many-many relationships
- 80. Cache as much as possible
- 81. Cache Everything If a little caching is good, then a lot is great
- 82. But don't overthink it – just use grails.hibernate.cache.queries=true in Config.groovy Cache Everything
- 83. Don't worry that Hibernate query cache considered harmful? appears to contradict this advice Cache Everything
- 84. It's better to make several queries that are easy to understand, and sort and filter the data in your code Don't bother optimizing queries
- 85. def getAverageAgePerPlan() { def planAgeBarData = [] Insurer insurer = ... insurer.plans.each { plan -> int ageTotal = 0 for (Person person : plan.customers) { ageTotal += person.age } int avgAge = plan.customers.isEmpty() ? 0 : ageTotal / plan.customers.size() planAgeBarData << [plan.name, avgAge] } planAgeBarData }
- 86. Don't share
- 87. Don't share Don't write blog posts with information that others could use
- 88. Don't share Don't create plugins – users will only complain about bugs and missing features
- 89. Don't share Let them figure things out on their own, just like you had to.
- 90. Don't report bugs (someone else will at some point) Don't share
- 91. And if you do report a bug, don't bother trying to fix it with a patch or pull request Don't share
- 92. Don't bother reading books
- 93. Don't bother reading books
- 94. Don't bother with the mailing lists
- 95. Don't bother with the mailing lists http://grails.org/Mailing%20lists
- 96. Don't bother with the mailing lists http://grails.org/Mailing%20lists http://grails.1312388.n4.nabble.com/
- 97. Don't bother with the mailing lists http://grails.org/Mailing%20lists http://grails.1312388.n4.nabble.com/ http://grails.markmail.org/search/?q=
- 98. Don't bother reading release notes and "What's New" pages
- 99. Don't bother reading release notes and "What's New" pages http://grails.org/Release+Notes What's new in Grails 2.3?
- 101. It's mostly a bunch of Graeme's Instagram photos of his lunch Don't Follow @grailsframework
- 103. Some miscellaneous items: Don't bother using packages, just put everything in the default package
- 104. Some miscellaneous items: Don't worry about documenting your code
- 105. Some miscellaneous items: Don't worry about writing self-documenting code
- 106. Some miscellaneous items: Prefer jar files in the lib directory to dependencies in BuildConfig.groovy
- 107. Some miscellaneous items: Prefer println to logging
- 108. Some miscellaneous items: Store whatever you want in the HTTP session, especially domain class instances and query results. Memory is inexpensive.
- 109. And whatever you do ...
- 110. Don't buy this book:
- 111. ¡Gracias!