I came across this blog post on Hacker News this morning. I thought it was a great blog post so I figured I would share it. Here there is a group of people that were trying to weaken the HTTP2 standard by not requiring TLS encryption in the standard as originally proposed and Google and Mozilla are working around that by requiring it for HTTP2 standard in their browsers. I think they are taking the right stand here as there is no excuse to not be encrypting anymore, and by them taking this stand it will encourage more people to get on board with TLS while at the same time getting the performance benefits of the new protocol.

Good news this week. Our purchase of Clover was approved and we will have our license keys in a matter of days. As of tomorrow it is going into our build and Cobertura is getting ripped out. You may recall I previously wrote about my issues with Cobertura. One problem was the latest version at the time 2.0.3 didn’t work with Powermock, even though 1.9.4.1 did. And the second issue I was having with it was the lack of Java 8 support since we are close to upgrading on our project at work. Well oddly enough early in this week I saw Cobertura had a new maven plug and a new release 2.1.1. I immediately updated to the 2.7 plugin to give it a go and it promptly failed on Powermock like 2.0.3. So I didn’t feel bad at all when 2 days later I found out our Clover purchase request had been approved.

I saw this come across the Spring blog this week. They are going to be doing a webinar for JHipster. As I mentioned in a previous post I am very interested in JHipster as it combines 2 things I am interested in learning Spring Boot and Angular. If you are interested in checking it out sign up here.

Also as a completely unrelated side note, why doesn’t projects.spring.io support HTTPS? This is 2015 and all sites should really support secure access.

My blog must be getting noticed by the bots. When I first started writing I had more posts than attempted spam comments. Then for a while I was at parity. I would write something new and I would see another spamy comment in the quarantine area. Now they are starting to kick into overdrive and have greatly eclipsed the number of posts I have. Luckily the Wordpress tools and plugins are great and seem to catch them all. So there is that to be thankful for.

I am currently reading Iron-Clad Java: Building Secure Web Applications by Jim Manico and August Detlefsen. This book basically takes you from zero to doing a decent job of locking down your webapp. It starts with security basics and then covers authentication and session management, and then access control, followed by Cross-Site Scripting Defense, then Cross-Site Request Forgery Defense, and much more. I am only a couple of chapters into the book so far. What I like about it is that they include security anti-patterns as well. These are things that you commonly see people doing in the name of security, but really aren’t the way you want to go about locking down your app. Having been through a professional security audit on a project I worked on and having fixed many of these potential attacks in my career it is nice to see this all laid out in one place for newer developers. At the same time the detail is so good that even experienced web devs should probably read this book and keep it as a reference. If you have gone through the OWASP stuff there won’t be a lot of new stuff here from what I have seen, but I feel like they have made the material very accessible. Anyway long story short I recommend this book and after reading it, one really appreciates all the stuff Spring Security does for you out of the box.

I was reading the Spring Blog the other day and I came across this story. I was intrigued because I found the name funny so I read the post and watched the embedded youtube video and was completely blown away. Take all the excitement I had for Spring Boot after SpringOne and multiply it by 10. Not only does this build on top of Spring Boot it integrates in all the trendy front end technologies that are in use today. All the pain of bootstrapping and setting up a full on website is taken away while they do all the work for you.

The thing I dislike most in software development is when they ask me to estimate how long a given project will take. I am about to start a new project so of course the first thing that is asked for is to do some research and try to figure out what the high level tasks of the project will be and estimate how long they will take. This seems like a reasonable thing to do as obviously if the company is going to invest a lot of money into a project they want to have sort of a guess how much the project is going to cost. Additionally if the scope of the work is outside the time frame in which they need the feature they can decide whether or not to limit the scope of the project or add resources to the project. So all in all I can see the need and the point of it, but I think I dislike it cause I am not very good at it.

I have been upgrading our Sonar server from 4.5 to 4.5.2 and restructuring our project. I initially was planning on upgrading to SonarQube 5.0, but the upgrade process can’t seem to handle our database. After I upgraded to 4.5.2, I was restructuring. Initially we had each of our libraries setup as a separate project at work and there was a separate sonar project for each one. At one point we decided it was much better to consolidate them all under 1 git repository and make 1 maven master pom with each other project as a module in maven. When we did that we never got around to consolidating our Sonar project to 1 project with sub projects. After we upgraded to intelliJ we found that we couldn’t sue the sonar plugins to integrate with our environment as our project didn’t match our sonar project.

In my current position one of the metrics we track is code coverage for our unit tests. When I started at the company we were using JUnit with Mockito and JaCoCo. This was a pretty good setup we got good coverage reports and Mockito makes the testing writing much easier.

One of the limitations of Mockito is that you can’t mock private methods or static methods. This presented an issue for us in reaching our desired level of coverage. We initially worked around some of the private method issues using reflection, but it wasn’t always ideal. The decision was made to use PowerMock. PowerMock solved all of our Mockito issues immediately. It was compatible with Mockito but gave us some new powerful features to allow us to get much better unit test coverage. Then we ran our Jacoco reports and found that the reporting no longer worked. Due to the way PowerMock uses byte code manipulation in order to mock static methods it is not compatible with JaCoCo and there is no plan for them to support measuring that.

For all the other Dr Who fans that might come across this I am taking a Massively Open Online Course about the show that starts in a week. If you are interesting in the show you should join me. You can sign up here. A link to the Facebook page is here.