Wednesday, July 20, 2016

A Cute Trick with Generics to Avoid Unwanted Casts

I ran into a cute trick while coding a unit test on a Spring application the other day that I'd like to share.

Consider these lines of Java code.
The first line requires a cast.  the reason is that the method returns an Object.  While the cast isn't the most labor intensive construct, but it makes code less clear and is inconvenient to developers.

Note that the second line does *not* require the cast making it much more convenient for developers. the secret is that Spring's ReflectionTestUtils uses generics. take a peak at how invokeMethod is defined.


In effect, Java infers the type of the value returned by the definition of the variable it is assigned to. In this case, it's a String.

This is convenient for developers in that there's less to type, but also more easily read.

You should not that the developer is required to know what type of value is returned. The following statement will generate a ClassCastException.


This might seem like a disadvantage to using generics in this way. I don't think so. In either case, the developer needs to understand the data type that will actually be returned.


Just thought I'd pass this tid bit along. I'll certainly think more about using generics in this way in APIs I write.

Monday, June 13, 2016

Active Conference Presentation Abstracts

Speaking at conferences has become a regular activity for me. To save time for both me and conference organizers, I maintain this list of presentations I'm actively submitting to conferences and user groups. My presentations are updated frequently to reflect current industry changes and events. If you're a conference organizer, I'm always willing to discuss enhancements that will allow one of my presentations to more closely fit your upcoming event.  As always, I'm interested in suggestions for new presentation topics.  

If you're interested in more detailed information about any of these presentations, I always post presentations on my Slideshare. Keep in mind that slide decks are frequently updated, so a deck you see on a future presentation may be different than what's currently posted.


Upcoming Presentations

Note: Presentations currently in development; no slide decks yet available.

AWS Lambda Deployments:  Best Practices and Common Mistakes

(60 to 75 minutes)
"Serverless" architectures, such as AWS Lambda, Google Cloud Functions, or Azures Serverless Compute service, that relieves you of hardware and scaling set-up concerns. Large companies such as Netflix, Cmp.LY, VidRoll, and other organizations are introducing serverless technologies into their technical stacks. This presentation concentrates on the AWS Lambda product as it was the first cloud-based serverless architecture and is leading the trend. However, comparison and contrast with the Google and Azure offerings will also be included.
This presentation will provide you with an overview for AWS Lambda and the products advantages and disadvantages. I'll include an overview on how to create and deploy Lambdas providing examples along the way. I'll also include a discussion of best practices and when use of Lambda is appropriate.  This presentation is targeted for senior developers and architects.

Microservices Presentations

Microservices for Architects

(60 to 75 minutes)

Given published success stories from Netflix and Amazon, many companies are adopting microservice architecture. This session will provide you with an understanding what microservices are and what benefits they provide. You should also be made aware of pitfalls and best practices for adopting this approach. I will provide guidance on effective microservice contract design and survey the most important design patterns. I will survey cross-cutting support concerns that all microservices share and point out common mistakes along the way. 
This session is targeted at architects and team leads. This session is intended to be platform-generic.

Microservices for Java Architects 

(60 to 90 minutes)

Given published success stories from Netflix and Amazon, many companies are adopting micro service architectures. This session will provide you with an understanding what micro service architectures are and what benefits they provide. You should also be made aware of pitfalls and best practices for adopting this approach. This session is targeted at Java developers and architects; coding examples will be Java. This session will also provide an overview of tooling that supports micro service architectures such as Docker, Spring Boot, Dropwizard, and a few more.

Writing Microservices in Java: Best Practices and Common Mistakes 

(60 to 90 minutes)

Given published success stories from Netflix and Amazon, many companies are adopting microservice architectures. For organizations that are heavily invested in Java technologies, writing microservices using Java is a natural progression. This session concentrates on best practices for coding microservices using the JVM. An overview of useful coding and deployment patterns will be included that make microservices more resilient and supportable. Tooling useful with implementing these patterns will be highlighted. Along the way, I'll also note common mistakes.
This session is targeted at Java developers and architects; all examples will be Java. I will provide a short definition section about what microservices are to level set.

Cloud Technology Presentations

AWS Lambda for Architects

(60 to 75 minutes)

Lambda is a "serverless" architecture that relieves you of hardware and scaling set-up concerns. Amazon AWS introduced Lambda at AWS Re-Invent 2014. Adoption of Lambda has grown exponentially ever since. Netflix, Cmp.LY, VidRoll, and other organizations are introducing Lambda into their technical stacks. In addition, Amazon competitors are working aggressively to introduce competitors to AWS Lambda. Lambda has many uses within applications as well as in a Dev Ops world. 
This presentation will provide you with an overview for AWS Lambda and the products advantages and disadvantages. I'll include an overview on how to create and deploy Lambdas providing  examples along the way.  I'll also include a discussion of best practices and when use of Lambda is appropriate.  This presentation is targeted for senior developers and architects.

AWS Lambda for Java Architects

(60 to 75 minutes)

Lambda is a "serverless" architecture that relieves you of hardware and scaling set-up concerns. Amazon AWS introduced Lambda at AWS Re-Invent 2014. Adoption of Lambda has grown exponentially ever since. Netflix, Cmp.LY, VidRoll, and other organizations are introducing Lambda into their technical stacks. In addition, Amazon competitors are working aggressively to introduce competitors to AWS Lambda. Lambda has many uses within applications as well as in a Dev Ops world. 
This presentation will provide you with an overview for AWS Lambda and the products advantages and disadvantages. I'll include an overview on how to create and deploy Lambdas providing Java examples along the way. I'll also include a discussion of best practices and when use of Lambda is appropriate. This presentation is targeted for senior Java developers and architects. Please note that AWS Lambda is not to be confused with Java 8 Lambda expressions; they are different subjects entirely.


Sunday, June 5, 2016

Making Unit Testing Private Methods Easier

Earlier this year I blogged about testing private methods (here). I noted that FieldUtils utility from Apache Commons Lang product has one-line utilities to access private fields. While explaining to readers that Lang's MethodUtils utility should have a one-line utility to access private methods so that we can more easily test them directly. I explained that this is preferable to over-exposing those methods (e.g. making them protected) merely so they can be tested. 

As a result I filed LANG-1195 and contributed an enhancement for MethodUtils so that it can easily invoke private methods for testing. I'm happy to announce that my enhancement has been accepted and committed (Pull 141). Expect to see it in Commons Lang 3.5 when it's released.

Method Additions
Like FieldUtils, boolean forceAccess is true, private methods can be seen and executed through reflection. There is no need to set forceAccess to true for methods already visible (e.g. protected or public).  

These methods allow you to directly test private methods in unit tests. There's no longer a need for the common practice of making methods protected for the sole purpose of accessing them in unit test code. 

These methods really should only be used in unit test code. From an architectural perspective, production code should not be used to invoke methods that were never designed to be executed outside the context of that class. Some argue that private methods should not be tested directly as they are not exposed. As those of us with clients that have mandated 100% line, branch, and mutation coverage; we know that that's nearly impossible being restricted to testing private methods only through public or protected methods that use them.

Another argument against testing private methods is that it created a coupling between classes (the test class and the tested class) that was never meant to be. My response is that yes, it does create coupling. However, unit tests are very tightly coupled to their targets anyway. Secondly, it means that some code in private methods goes untested as testing them indirectly is too tedious and difficult.

These methods do not benefit from compile time checks. One of the reasons I don't advocate using these methods in production code is that they can't be checked by the compiler. Direct method execution can be checked as to syntax, accessibility, and correct parameter type usage. These methods bypass those two checks.

Specifically, methods added follow. If you use these, please let me know if you see issues or problems.

Invoke Private Method without Arguments
This is also patterned after the existing method invocation without the forceAccess option.

Method signature
invokeMethod(Object object, boolean forceAccess, String methodName)

This is used to invoke a private method in a class. Yes, the accessibility attribute on the method is temporarily set to true so that the invocation works, but it's set back to it's original after execution. A usage example is below.

Example 1
String result = (String)MethodUtils.invokeMethod(testBean, true, "myPrivateMethod");

Invoke Private Method with Arguments
This is also patterned after the existing method invocation without the forceAccess option.

Method signature
invokeMethod(Object object, boolean forceAccess, String methodName,Object... args);

Example 2

String result = (String)MethodUtils.invokeMethod(
    testBean, true, "privateStringStuff", "Hi There", 5, new Date());



Sunday, April 24, 2016

AWS Lambda Reading List

I'm hearing a lot about AWS Lambda these days and "serverless" architectures. By "serverless", I mean the concept, not the product (here). Basically, AWS Lambda is computing power without management. You provide your code, AWS Lambda runs it. You have minimal setup and no responsibility for maintaining servers on which to run that code.

As with all new technology fads, there's a lot of buzz and a flurry of unorganized content. My intent with this entry is to keep a current list of relevant Lambda articles and categorize them. Hopefully, this will streamline your research if you're looking at using AWS Lambda at your organization.

I intend to update this list as new material comes to my attention. If you see articles that are worthy of mention, please add a comment providing a link. I'll take a look.

Getting Started
These articles provide overview material describing what AWS Lambda is.

  • "It’s Amazon’s way of delivering a microservices framework far ahead of its competitors."
A Walk in the Cloud with AWS Lambda (Slideshare)
  • Provides detailed overview and possible use cases.

What are the Business Benefits?
These articles highlight business benefits provided by AWS Lambda

  • Somewhat biased as it's an Amazon executive describing how they use Lambda internally.
  • “No more glue code. No more servers. Just run your code.”

Flies in the Ointment
These articles highlight limitations and issues with AWS Lambda.

  • "Lambda is a building block, not a tool"
  • "Lambda is not well documented"
  • "Lambda is terrible at error handling"
  • Pay attention to the discussion below. There's some resistance to the error handling points.
Vendor Lock-in
Many fear becoming relient on AWS Lambda as AWS can raise prices with just a simple edit.  The following products propose solutions to mitigate that risk.


Case Studies
This section details use of AWS Lambda in practice.

  • Embedded case study for acloud.guru, a AWS education company.
  • Also has material on the strategic reasons to consider AWS Lambda
AWS Case Study: VidRoll (VidRoll Blog)





Saturday, April 23, 2016

"Microservices for Java Architects" has been released!

Microservices for Java Architects is a companion for the Java EE Architect’s Handbook that details Microservices Architectures. This eBook will define microservices and provide an overview of costs and benefits. As with the handbook, I’ll go on to address architecture, design, and implementation concerns specific to microservices architecture.

Details

Given the published success stories from Netflix, Amazon, and many organizations; companies are increasingly adopting microservices architecture. For organizations that are heavily invested in Java technologies, writing microservices using Java is a natural progression. This book is your guide to designing and implementing microservices in Java.

As Java architects, it’s important to understand what microservices are, when to use them, and the value they provide. We need to understand the design and implementation considerations for using microservices so we can guide a development team through microservice development efforts. We also need to understand the various pitfalls of using microservices and the common implementation mistakes that can erode the benefits of adopting microservices.

While this book is a companion to the Java EE Architect’s Handbook, it is also separate and self-contained. As with the handbook, I'll guide architects through the entire development process, including how to effectively design service contracts. I cover in detail the coding patterns that are needed to make microservice libraries effective showing you examples along the way. I also provide guidance on how to refactor large, complex web applications into smaller and more manageable microservices, and how to make microservices easier to maintain and support.

What you’ll learn

  • What microservices architecture is and the advantages and disadvantages of using it.
  • How to refactor large applications into a microservice library.
  • How to design microservice contracts effectively.
  • Design patterns that make microservices efficient and maintainable.
  • Best practices and common mistakes for implementing microservices.
  • Guidance on how to manage microservice development teams.

Who this book is for

  • Java EE application and enterprise architects interested in using microservices to provide business value.
  • Java EE technical leads implementing microservices.
  • Java EE senior Java developers working on microservice teams.

Saturday, March 26, 2016

Book Review: The Art of Business Value by Mark Schwartz

I just read the book "The Art of Business Value" by Mark Schwartz. I came upon this book as I follow Adrian Cockcroft on Twitter and he tweeted about it. Mr. Cockcroft also has a blurb for the book on the back cover.  That was enough to get me to buy and read the book.  As a technical author myself, Amazon does not let me post reviews on technical books. As a result, my review is here.

Even with agile methodologies, IT has trouble delivering business value. The book starts with some typical observations of difficulties IT departments have implementing scrum/agile. Technical debt payment and non-functional requirements don't seem to be adequately prioritized by product owners. Product owners make priority decisions that perplex the people implementing them sometimes. Even though developers follow product owner direction, IT departments still get complaints about the low value IT generally delivers.

Business value has a vague definition and is difficult to objectively measure. The book very effectively argues that the objective of product owner, which is to deliver business value, is a vaguely defined concept and is far from objectively measurable using the information product owners have at hand. More to the point, business value is difficult for anyone to measure. The book takes us on a discussion of how to measure value from a financial perspective.

Product owners are guessing about business value with they prioritize stories. Effectively, the business value assigned to stories isn't really known by product owners. Consequently, story prioritization is the product owners 'guess' and isn't really objectively determined. You can argue that a product owners guess might be more educated than an IT developers guess, but it's a guess all the same. 

As a result, we see the issues and problems IT is all too familiar with.  I'm summarizing the argument, but the book provides robust support for this argument drawing on financial valuation methods taught in many MBA programs.

The book has an excellent premise, but unsatisfying solution. While Schwartz starts with a very good premise, he doesn't really provide adequate answers for the problems associated with evaluating business value. Given the rigor with which he describes the problem, I expected to get the same level of rigor in his search for a solution. His prescription of developing a robust continuous delivery pipeline is very much disconnected for the valuation problem and almost seems to be arrived at out of the blue. Schwartz doesn't connect the dots for me as to how with a badly defined concept of business value as a target, building a delivery pipeline represents enables us to meet that target.

Schwartz is very concise and effectively communicates his points in 131 pages, which as a busy person, I greatly appreciate. The book is also cheap for books of this type.
Bottom line: this book is worth reading for the understanding of the issues we commonly face implementing agile methodologies. Understanding a problem is necessary for finding a solution. I just wish we got a solution too.

Bottom line: Three stars. Reading the premise was enlightening and worth the reading time. Just not the same analytic rigor when discussion solutions.

Wednesday, February 24, 2016

Using Maven to produce Docker imarges

Docker is fast becoming the deployable artifact of choice. There are good reasons for this. It standardizes deployables across all technical stacks. This has the effect of streamlining work for a DevOps team working to manage large numbers of deployables. It allows developers to control the technical stack under which they deploy without and any tooling able to deploy Docker containers will just work. The reasons go on and on.

As a result, I've begun adding Docker artifacts to my standard builds for Java microservices and web applications. I begun using the Spotify Maven docker plugin.  Quite nicely done, although there were a few rough patches in getting everything to work correctly.  While the plugin itself is documented quite nicely, there's gaps in the documentation for the touch points between Docker and the Spotify Maven Docker plugin that created some headaches. This is especially true if you've a Windows development environment, which many of us have. I'm documenting this in my blog for myself as much as anybody else.

This entry uses my microservice example Moneta and its Spring Boot deployment build that can optionally produce a Docker artifact.  In fact the specific build I'm using as an example can be found here.  Pay attention to the Profiles section for id=Docker.

Using the Spotify Maven Plugin

This section guides you through adding the Spotify Maven plugin to your project.  It assumes that you've used Spring Boot, Dropwizard, or some other product to package your service into an executable jar.


Add the Spotify Maven Plugin to the build

Here's an example of the plugin include from my Moneta project.



<plugin>
 <groupId>com.spotify</groupId>
 <artifactId>docker-maven-plugin</artifactId>
 <version>0.3.258</version>
 <configuration>
  <imageName>moneta-springboot-${project.version}</imageName>
  <dockerDirectory>docker</dockerDirectory>
  <resources>
   <resource>
    <!-- <targetPath>/</targetPath> -->
    <directory>${project.build.directory}</directory>
    <include>moneta-springboot.jar</include>
   </resource>
  </resources>
 </configuration>
 <executions>
  <execution>
   <id>build-image</id>
   <phase>install</phase>
   <goals>
    <goal>build</goal>
   </goals>
  </execution>
 </executions>
</plugin>

The plugin does provide special tags so that you can effectively code the dockerfile in the POM.   I prefer to keep the dockerfile separate; more readable and easier to maintain. You do need to include all resources needed by your dockerfile.  As an example, I've incldued my Spring Boot application jar.  All resources get bundled and transmitted to the Docker host where the docker file is run. If you dockerfile has COPY statements, those resources need to be included as resources in the POM.

Create a Dockerfile

The Spotify plugin can accept your docker build information a couple ways. You can put tags in your maven build to specify your base image, exposed ports, and entry point. Or you can create a Dockerfile and specify the directory that contains it.  I prefer this method as developers already using Docker will be familiar with the Dockerfile.  Documentation for Dockerfile syntax can be found here.

Include COPY commands for any build artifacts you want to include in the Docker image. These artifacts must also be listed as a Resource in the docker plugin section of your build.  I'll talk more about that later.

Add Preparation Tasks

I have two preparation tasks.  The Dockerfile doesn't easily support Maven variables such as ${version}, hence I had to copy my Spring Boot jar artifact into a constant name without the version number.  For example, copying file moneta-springboot-${project.version}.jar to moneta-springboot.jar that's referenced in my dockerfile.

I also checked to make sure that the environment variables DOCKER_HOST and DOCKER_CERT_PATH were set. The advantage is that developers get a more meaningful error message than "connection refused" if they are not set.  Obtaining values for these variables isn't obvious if you're using a Windows environment; see section "Verifying Docker Environment" below for details on this.

Consider using Spring profiles to make production of your Docker artifact optional. Adding a docker deployable adds significantly. It might not be needed with all local development builds and integration tests. 

Verifying Docker Environment

You must set DOCKER_HOST and DOCKER_CERT_PATH environment variables for the Spotify Docker maven plugin to work.  Figuring out proper values for these variables wasn't obvious on a Windows environment. Well, it's easy once you've figured out where to look.

The Docker Quickstart Terminal is nice enough to give you the IP address of the default docker machine it creates, but not the port. To obtain the value specify in your DOCKER_HOST setting, use the command below.  My docker host setting from this output is tcp://192.168.99.100:2376
    docker-machine ls




You can obtain the DOCKER_CERT_PATH value to use by executing the command below in your Quickstart terminal.  The output is also shown below.
    echo $DOCKER_CERT_PATH