Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Grails Worst Practices

9 839 vues

Publié le

Slides from my Greach 2014 talk

Publié dans : Logiciels
  • If you are looking for trusted essay writing service I highly recommend ⇒⇒⇒WRITE-MY-PAPER.net ⇐⇐⇐ The service I received was great. I got an A on my final paper which really helped my grade. Knowing that I can count on them in the future has really helped relieve the stress, anxiety and workload. I recommend everyone to give them a try. You'll be glad you did.
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • My struggles with my dissertation were long gone since the day I contacted Emily for my dissertation help. Great assistance by guys from ⇒⇒⇒WRITE-MY-PAPER.net ⇐⇐⇐
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • Dating for everyone is here: ♥♥♥ http://bit.ly/36cXjBY ♥♥♥
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • Follow the link, new dating source: ♥♥♥ http://bit.ly/36cXjBY ♥♥♥
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici

Grails Worst Practices

  1. 1. Grails Worst Practices Burt Beckwith
  2. 2. 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. 
  3. 3. All of the topics discussed here are important, and 100% serious
  4. 4. Important Concepts: Easier is better
  5. 5. Finishing tasks faster is better Important Concepts:
  6. 6. Use the first solution that you think of Important Concepts:
  7. 7. Minimize the time you spend at work Important Concepts:
  8. 8. Get others to do your work for you Important Concepts:
  9. 9. Lazy is good Important Concepts:
  10. 10. If there's a problem, fix it if and when you have to Important Concepts:
  11. 11. Cover your tracks Important Concepts:
  12. 12. Be more like your dog Important Concepts:
  13. 13. http://cuteoverload.files.wordpress.com/2014/03/cute-smiling-animals-2.jpg
  14. 14. Grails Can Be Frustrating
  15. 15. http://www.flickr.com/photos/alexchoi/351267249/
  16. 16. Facebook uses it, and they have over 1,000,000,000 users Try to think like a PHP developer
  17. 17. Sure, we can use O-O principles, but we aren't required to, so why bother? Try to think like a PHP developer
  18. 18. Controllers
  19. 19. It's how scaffolding is generated, so it must be the best way One controller per domain class
  20. 20. Always trust generated code Corollary:
  21. 21. They're your interface between the client and the application Put most of your code in controllers
  22. 22. 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
  23. 23. Eventually you'll hit the maximum GSP size limit, but that's a problem for later Do a lot of work in GSPs
  24. 24. Don't worry that it's difficult to test code in GSPs Do a lot of work in GSPs
  25. 25. “@BurtBeckwith What is the advantage of using TagLibs over writing code on the view?” Do a lot of work in GSPs
  26. 26. “@BurtBeckwith What is the advantage of using TagLibs over writing code on the view?” Do a lot of work in GSPs
  27. 27. Luckily for us, there's a cool new @grails.transaction.Transactional annotation that can be used in controllers. ¡Genial! Transactions are important
  28. 28. Unfortunately, @Transactional cannot be used in GSPs Transactions are important
  29. 29. Someone should create a JIRA enhancement request for that. Transactions are important
  30. 30. Someone should create a JIRA enhancement request for that. Transactions are important Until then, use withTransaction
  31. 31. If all of your business logic is in controllers, who needs services? Don't waste time with services
  32. 32. Idiomatic Groovy
  33. 33. Use def everywhere. It's so easy to type. Always use optional types
  34. 34. If the Groovy runtime can figure out what's going on, so can your coworkers. Always use optional types
  35. 35. They will impress your friends who don't know Groovy Prefer closures to methods
  36. 36. Don't bother rewriting performance-critical code in Java or in Groovy with @CompileStatic Write the grooviest code possible
  37. 37. Groovy style and language feature guidelines for Java developers Don't follow these guidelines:
  38. 38. Code Reuse
  39. 39. Copy and paste
  40. 40. Copy and paste. A lot.
  41. 41. If it works, keep using it Copy and paste. A lot.
  42. 42. When you copy and paste, you don't have to deal with taglibs, templates, helper classes, etc. Copy and paste. A lot.
  43. 43. If it got a lot of votes on Stack Overflow, it belongs in your code Copy and paste. A lot.
  44. 44. 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.
  45. 45. Testing
  46. 46. I don't get paid more if I write more code, do you? Testing is not worth it
  47. 47. You spend all that time writing tests, and then something changes and they fail Testing is not worth it
  48. 48. If you don't have tests, you can't get yelled at for breaking the build Testing is not worth it
  49. 49. 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
  50. 50. If you must write tests, always use unit tests because they run the fastest. Always write unit tests
  51. 51. It is not at all important to test persistence with a real database Always write unit tests – especially for persistence
  52. 52. If that were true, then why does Grails let you unit test domain classes? Always write unit tests – especially for persistence
  53. 53. All they do is complain about failed builds, usually because of failed tests Don't bother with CI servers
  54. 54. Security
  55. 55. Don't bother with Spring Security or Shiro, just implement it yourself. It's fun and easy! Security is difficult
  56. 56. Don't bother with Spring Security or Shiro, just implement it yourself. It's fun and easy! Security is difficult
  57. 57. Always store passwords in the database without using complicated hashing algorithms Security is difficult
  58. 58. It's important to be able to email users their passwords when they forget them Security is difficult
  59. 59. And if you get hacked, it's not like they're going to steal your money, right? Security is difficult
  60. 60. Store passwords in source control
  61. 61. This is called "security by obscurity" and it always works Store passwords in source control
  62. 62. 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
  63. 63. Data Access
  64. 64. Don't bother checking hasErrors(). Let the error page handle expected user mistakes. Always use failOnError:true
  65. 65. The users will probably figure it out. And besides, all they ever do is complain. They're so negative. Always use failOnError:true
  66. 66. Exceptions aren't expensive, especially not in Groovy Always use failOnError:true “The Exceptional Performance of Lil' Exception”
  67. 67. 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 }
  68. 68. 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
  69. 69. Database transactions are difficult
  70. 70. But you've probably heard that they're important. I sure have. Database transactions are difficult
  71. 71. Is there even any helpful information available? Database transactions are difficult
  72. 72. Is there even any helpful information available? Database transactions are difficult http://2013.gr8conf.eu/Presentations /Grails-Transactions
  73. 73. 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
  74. 74. Don't use http://grails.org/plugin/ spring-security-rest If you do use REST ...
  75. 75. Always use collections for one-many and many-many relationships
  76. 76. http://www.infoq.com/presentations/GORM-Performance Always use collections for one-many and many-many relationships
  77. 77. Cache as much as possible
  78. 78. Cache Everything If a little caching is good, then a lot is great
  79. 79. But don't overthink it – just use grails.hibernate.cache.queries=true in Config.groovy Cache Everything
  80. 80. Don't worry that Hibernate query cache considered harmful? appears to contradict this advice Cache Everything
  81. 81. 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
  82. 82. 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 }
  83. 83. Don't share
  84. 84. Don't share Don't write blog posts with information that others could use
  85. 85. Don't share Don't create plugins – users will only complain about bugs and missing features
  86. 86. Don't share Let them figure things out on their own, just like you had to.
  87. 87. Don't report bugs (someone else will at some point) Don't share
  88. 88. And if you do report a bug, don't bother trying to fix it with a patch or pull request Don't share
  89. 89. Don't bother reading books
  90. 90. Don't bother reading books
  91. 91. Don't bother with the mailing lists
  92. 92. Don't bother with the mailing lists http://grails.org/Mailing%20lists
  93. 93. Don't bother with the mailing lists http://grails.org/Mailing%20lists http://grails.1312388.n4.nabble.com/
  94. 94. Don't bother with the mailing lists http://grails.org/Mailing%20lists http://grails.1312388.n4.nabble.com/ http://grails.markmail.org/search/?q=
  95. 95. Don't bother reading release notes and "What's New" pages
  96. 96. Don't bother reading release notes and "What's New" pages http://grails.org/Release+Notes What's new in Grails 2.3?
  97. 97. Don't Follow @grailsframework
  98. 98. It's mostly a bunch of Graeme's Instagram photos of his lunch Don't Follow @grailsframework
  99. 99. Some miscellaneous items:
  100. 100. Some miscellaneous items: Don't bother using packages, just put everything in the default package
  101. 101. Some miscellaneous items: Don't worry about documenting your code
  102. 102. Some miscellaneous items: Don't worry about writing self-documenting code
  103. 103. Some miscellaneous items: Prefer jar files in the lib directory to dependencies in BuildConfig.groovy
  104. 104. Some miscellaneous items: Prefer println to logging
  105. 105. Some miscellaneous items: Store whatever you want in the HTTP session, especially domain class instances and query results. Memory is inexpensive.
  106. 106. And whatever you do ...
  107. 107. Don't buy this book:
  108. 108. ¡Gracias!
  109. 109. http://cuteoverload.files.wordpress.com/2014/03/cute-smiling-animals-251.jpg

×