Best practice adoption (and lack there of)


Published on

This is a short presentation I created some time ago that details some of the developmental, procedural, and infrastructure best practices that I discovered while working with various customers.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Add “need to develop development standards governance model”
  • Add “suffer only once” Add “not doing maintenance cleanup – old stuff still out there causes confusion”
  • Best practice adoption (and lack there of)

    1. 1. Best Practice Adoption (and lack there-of) John Pape, WebSphere SWAT IBM Software Group Confidential | Date | Other Information, if necessary
    2. 2. Agenda <ul><li>What is a best practice?
    3. 3. Why do we care about them?
    4. 4. Best Practices </li></ul><ul><ul><li>Development
    5. 5. Infrastructure
    6. 6. Procedural </li></ul></ul><ul><li>Anti-Practices </li></ul>
    7. 7. Agenda <ul><li>What is a best practice?
    8. 8. Why do we care about them?
    9. 9. Best Practices </li></ul><ul><ul><li>Development
    10. 10. Infrastructure
    11. 11. Procedural </li></ul></ul><ul><li>Anti-Practices </li></ul>
    12. 12. What is a “best practice”? “ Best Practice is a management idea which asserts that there is a technique , method, process, activity, incentive or reward that is more effective at delivering a particular outcome than any other technique, method, process, etc. “ –
    13. 13. Agenda <ul><li>What is a best practice?
    14. 14. Why do we care about them?
    15. 15. Best Practices </li></ul><ul><ul><li>Development
    16. 16. Infrastructure
    17. 17. Procedural </li></ul></ul><ul><li>Anti-Practices </li></ul>
    18. 18. Why do we care about them? <ul><li>Simple, doing things the best, most advantageous way results in less work and re-work for all parties
    19. 19. Secondly, it provides a standard way of accomplishing a task successfully and with known measuring points. </li></ul>
    20. 20. Agenda <ul><li>What is a best practice?
    21. 21. Why do we care about them?
    22. 22. Best Practices </li></ul><ul><ul><li>Development
    23. 23. Infrastructure
    24. 24. Procedural </li></ul></ul><ul><li>Anti-Practices </li></ul>
    25. 25. Development Best Practices <ul><li>Keep applications as stateless as possible </li></ul><ul><ul><li>The HTTP Session is NOT a place to cache data. </li><ul><li>If you must place data in the HTTP session, make sure it is serializable </li></ul><li>Most things that are stuffed into the session could be put in the request instead.
    26. 26. Remember to invalidate your sessions when done.
    27. 27. Stay away from stateful session beans unless you have to use them.
    28. 28. If your JSP’s don’t use the “session” object, use <%@page session=“false” %> for a performance boost
    29. 29. Design all applications to be wholly distributed </li><ul><li>Ready for session persistence
    30. 30. Capable of rapid scaling
    31. 31. Minimal dependencies on the environment </li></ul></ul></ul><ul><li>Utilize transaction management wherever possible </li></ul><ul><ul><li>Do transactional logic in stateless session beans
    32. 32. Use an EJB Façade Pattern, combine with a Delegate Pattern </li><ul><li>Don’t expose Entity Beans directly to the client </li></ul><li>Utilize the declarative methods of transaction management via J2EE deployment descriptors (isolation levels, access intents, transaction requirements)
    33. 33. Cache your EJB Home interfaces, they are costly to create over and over again
    34. 34. JDBC activity inside a servlet keeps a connection out of the free pool for the length of the doPost() or doGet() method </li><ul><li>Results in short SQL query times, but long JDBS use times and possibly exhaustion of connection pool resources. </li></ul></ul></ul>
    35. 35. Development Best Practices (cont.) <ul><li>MVC is a good thing, use it </li></ul><ul><ul><li>Cleanly separate model from view.
    36. 36. JSP’s should not contain business logic!!! </li><ul><li>Limit scriptlets to presentation logic and formatting only
    37. 37. Tags are a good thing </li></ul><li>Unit testing is good </li></ul></ul><ul><li>Write code to J2EE and industry specifications, not to the application server implementation </li></ul><ul><ul><li>Open standards provide the highest levels of flexibility and interoperability </li></ul></ul><ul><li>Utilize the security implementations of your platform and server infrastructure </li></ul><ul><ul><li>To attain true SSO environments you must stop using application defined security measures and start using the stuff that comes with your products (WebSphere security, LTPA, CSIv2, SAS, etc) </li></ul></ul><ul><li>Stay away from string concatenation </li></ul><ul><ul><li>String x = “Bob” + “,” + “John” + “Nate”
    38. 38. Use Stringbuffers, they cost less.. StringBuilders, even better. </li></ul></ul><ul><li>Use DataSources, preferably from the application server
    39. 39. Don’t spawn threads in the web or EJB container </li></ul><ul><ul><li>There are better ways to do this (AsyncBeans, SchedulerBeans) </li></ul></ul><ul><li>Don’t override the finalize() method, at all…..ever….
    40. 40. Don’t use System.out.println() as your logging mechanism </li></ul>
    41. 41. Development Best Practices (cont.) <ul><li>Use proven J2EE design patterns and stick with them </li></ul><ul><ul><li>Standardize on design patterns
    42. 42. Standardize on common libraries, stop mashing new things together
    43. 43. Consolidate programming frameworks </li><ul><li>Be unified in the solution approach – use the same frameworks (the tried and true) </li></ul></ul></ul><ul><li>Utilize UML modeling </li></ul><ul><ul><li>Generating good documentation and modeling will help out when things go wrong </li></ul></ul><ul><li>Unify and consolidate source control systems </li></ul><ul><ul><li>Pick a source control method and standardize on it </li><ul><li>Helps to improve automation around building and deploying applications </li></ul></ul></ul>
    44. 44. Agenda <ul><li>What is a best practice?
    45. 45. Why do we care about them?
    46. 46. Best Practices </li></ul><ul><ul><li>Development
    47. 47. Infrastructure
    48. 48. Procedural </li></ul></ul><ul><li>Anti-Practices </li></ul>
    49. 49. Infrastructure Best Practices <ul><li>Automate, automate, automate </li></ul><ul><ul><li>Use your scripting interfaces instead of the GUIs for your changes </li><ul><li>Scripts are artifacts that can be put in change controls
    50. 50. Scripts assure that the activity is performed the same way, every time
    51. 51. Scripts help reduce repetition and tedious work </li></ul></ul></ul><ul><li>Establish a naming standard for WebSphere resources </li></ul><ul><ul><li>Server names
    52. 52. Application names
    53. 53. Resource names </li></ul></ul><ul><li>Utilize shared libraries for common application libraries </li></ul><ul><ul><li>You still need to propagate the files out to the hosts
    54. 54. DON’T ADD LIBRARIES TO THE SERVER CLASSPATH </li><ul><li>That is, unless, that is the only way or IBM tells you to. </li></ul></ul></ul><ul><li>Don’t arbitrarily put JVM arguments on new servers because they worked somewhere else </li></ul><ul><ul><li>Every application is unique and the runtime must be tuned to the application behavior for optimal performance </li></ul></ul><ul><li>If you need to cache something, use DynaCache or WebSphere eXtreme Scale </li></ul><ul><ul><li>Don’t grow your own – unless you like to support it </li></ul></ul>
    55. 55. Infrastructure Best Practices (cont.) <ul><li>Enable security on your deployment managers </li></ul><ul><ul><li>This should be common sense </li></ul></ul><ul><li>Keep Core Groups down to <=50 JVMS </li></ul><ul><ul><li>Lower the better </li></ul></ul><ul><li>Determine the amount of sessions that you will encounter and set the max in-memory session count to that number + 20% (growth). </li></ul><ul><ul><li>Don’t leave growable checked unless you have no concern for OOM or memory usage </li></ul></ul><ul><li>Be considerate of your backend resources </li></ul><ul><ul><li>Just because you can setup the connection pool at 999 does not mean you should! </li></ul></ul><ul><li>Use hostnames on your profiles and cell configuration </li></ul><ul><ul><li>They rarely need to be changed, using IP addresses is bound for failure somewhere down the road. </li></ul></ul><ul><li>Enable verbose GC </li></ul><ul><ul><li>Probably the single most effective tool for diagnosing JVM heath
    56. 56. Very cheap to implement, costs some disk space (but you can rotate the files!) </li></ul></ul><ul><li>Make sure your box is setup to produce good system cores
    57. 57. Use InstallFactory to do new installs and maintenance </li></ul><ul><ul><li>Very handy tool – eliminates complexity of upgrading products </li></ul></ul>
    58. 58. Infrastructure Best Practices (cont.) <ul><li>Utilize Type 4 (network-based) database drivers where possible </li></ul><ul><ul><li>Allows the greatest flexibility
    59. 59. Lowers licensing requirements (does not require DB client to be installed) </li></ul></ul><ul><li>Take advantage of dynamic runtime logging operations </li></ul><ul><ul><li>You CAN enable/disable tracing while the server is running
    60. 60. Possible through scripting and admin console access </li></ul></ul><ul><li>Don’t create JMX client applications that register for ALL JMX events </li></ul><ul><ul><li>You’ll kill the deployment manager </li></ul></ul><ul><li>When your cell gets large (maybe <= 200 JVM’s), consider turning off automatic synchronization on the node agent. </li></ul><ul><ul><li>200 is not the published limit as there is no published limit. HOWEVER, if automatic synchronization is occuring too frequently, that is, not all nodes can complete a sync before the process kicks off again, consider disabling auto sync or lengthening the interval. </li></ul></ul>
    61. 61. Agenda <ul><li>What is a best practice?
    62. 62. Why do we care about them?
    63. 63. Best Practices </li></ul><ul><ul><li>Development
    64. 64. Infrastructure
    65. 65. Procedural </li></ul></ul><ul><li>Anti-Practices </li></ul>
    66. 66. Procedural Best Practices <ul><li>Planning for infrastructure </li></ul><ul><ul><li>Begin with capacity plans, detail flows in-out of application </li><ul><li>Know when the load will come
    67. 67. Know where it will come from
    68. 68. Know how much load will come
    69. 69. Know how long the load will last </li></ul><li>Stress test applications in a test environment that will resemble the production system as closely as possible </li><ul><li>Document the load test findings, including response times and other metrics </li><ul><li>Baseline data is invaluable 1 year down the road. </li></ul></ul><li>Have a clearly defined promotion plan/path for moving apps between stage-gate systems (test into stage/pre-prod into production)
    70. 70. Educate all parties on the technologies that will be required for a system or application </li></ul></ul>
    71. 71. Procedural Best Practices (cont.) <ul><li>Planning for development </li></ul><ul><ul><li>Agree on the standards and frameworks to be used in the application </li><ul><li>Conform to the company standard </li><ul><li>If one does not exist, invest time in creating one </li></ul><li>Make sure the infrastructure teams are involved in the design phase </li><ul><li>They may have experience or products at their disposal that can change the way the application may be designed (simplification of design) </li></ul><li>Construct and execute formal design and code review procedures </li><ul><li>Minimizes defect introduction into the code stream
    72. 72. Keeps everyone on the same page – align the vision </li></ul></ul></ul></ul>
    73. 73. Procedural Best Practices (cont.) <ul><li>Planning for deployment </li></ul><ul><ul><li>Set the expectation for deployment timelines early in the project timeline </li><ul><li>Prevent springing a new deployment on the infrastructure team 1-2 days before target date
    74. 74. Determine application dependencies and communicate these things to the infrastructure team(s) </li><ul><li>They have to set it up – let them know!!
    75. 75. Package library requirements into shared libraries in WebSphere </li></ul></ul><li>Determine if the application EAR file contains any resource definitions (databases, J2C resources, etc..) </li><ul><li>This is also called an enhanced EAR </li></ul><li>Determine if the EAR file contains settings for session timeouts and other parameters that might override the server level configuration settings
    76. 76. Application updates should be done either using a whole EAR file or the partial update capabilities provided in the WebSphere administration console. </li><ul><li>Don’t get into the business of copying JSP’s and property files into the installedApps directory </li></ul></ul></ul>
    77. 77. Agenda <ul><li>What is a best practice?
    78. 78. Why do we care about them?
    79. 79. Best Practices </li></ul><ul><ul><li>Development
    80. 80. Infrastructure
    81. 81. Procedural </li></ul></ul><ul><li>Anti-Practices </li></ul>
    82. 82. Anti-Practices <ul><li>Where do we do things wrong/inefficiently? </li></ul><ul><ul><li>Lets look at it (case study format) </li></ul></ul><ul><li>If we bring out our pain points and discuss them, we can determine how we can avoid or repair the situation. </li></ul><ul><ul><li>First step to fixing a problem is to realize that a problem exists! </li></ul></ul>The following anti-practices were observed while working with customers at various locations....
    83. 83. Anti-Practices (cont.) <ul><li>Using finalize() method to ensure database connections get closed </li></ul><ul><ul><li>Developers did not trust each other to code to standards
    84. 84. Caused impact on several applications due to sharing of the defective code base </li></ul></ul><ul><li>Using JDBC from a servlet </li></ul><ul><ul><li>Developers either did not understand EJB’s or JPA or chose not to use them/it
    85. 85. Even after connection is released, it is not returned to free pool until the doGet() or doPost() method completes (shared connections)
    86. 86. Causes database connection pool to be 100% utilized </li></ul></ul><ul><li>Not load testing a new application before production deployment </li></ul><ul><ul><li>Failure to follow testing guidelines – process was known, yet not executed </li></ul></ul>
    87. 87. Anti-Practices (cont.) <ul><li>Failure to set retry values on MDB Listener Ports </li></ul><ul><ul><li>Impact is that application is up, server is up, but no work is being done, queues are filling up
    88. 88. No reason why this should happen – no one took ownership for ensuring that the changes were made </li></ul></ul><ul><li>OutOfMemory due to large HTTP Session objects in heap </li></ul><ul><ul><li>Impact was outage to application due to consistent heap dumps
    89. 89. Development team was told to change but no one enforced the required changes </li></ul></ul><ul><li>Not using indirect JNDI lookups for JNDI resources </li></ul><ul><ul><li>Direct JNDI lookups were deprecated starting with WebSphere 6.0
    90. 90. Using resource references assures optimal flexibility for resource behavior configuration. </li></ul></ul>
    91. 91. <ul><li>Thanks for your time!! </li></ul>