JHipster webinar

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.

Spam Comments

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.

Iron-Clad Java

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.

JHipster

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.

JHipster is built on Spring Boot, Spring Security, Node.js, Angular.js, and Yeoman. Basically it manages to boil down every trendy front end technology with every trendy back end technology and do all the integration for you so you can start ripping code. They support Maven and Gradle as well as Grunt or Gulp. I admit I had never really heard of Yeoman or looked into it, but it is amazing. You can really automate a ton of your repetitive tasks with it so you can focus on solving the real problems you are facing. This project seems like a startup companies dream since all that monotonous configuration can just be skipped and you can focus on getting your application up and running and just out there.

This also fits in with my themes for the year where I wanted to spend more time working with Spring Boot as well as learning Angular and now I can all in the context of trying to build a small project under JHipster. Anyway the technology looks amazing and I would encourage everyone to give it a look and see what you think. Oh and a pro-tip if you are a non-hipster like myself running windows, when you do yo jhipster to generate your app, do it from inside of your git-bash window as if you use a normal windows cmd prompt it seems to fail in the course of generating the app.

Project Estimation

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.

The first project I led at my current company I came up with a bunch of estimates and actually did a pretty good job of identifying the major areas of work that needed to be done. I went through and applied my time estimates and based on the features I felt I understood very well I delivered fairly tight estimates and the features I had less understanding of I added extra padding for research and learning time. Then I got into the project, and the parts I thought I had the biggest handle on was actually much bigger than I had realized. I had I think 2 weeks of work on one aspect that actually ran like 6 weeks. I believe the whole project was a 3 month project. So of course the project manager was sweating it a little bit. I told him don’t worry I always hit my dates and if I think the date is in danger I will let you know immediately. As we went on the other aspects that I didn’t feel like I understood as well turned out to be easier than expected and I made up the time there. By the end of the project I delivered on the exact date I had promised 3 months previously and I didn’t put myself into a death march so I considered that a successful project. From an estimation point though maybe it was a failure as all my estimates were off even though I delivered what they wanted when they wanted it.

So here I am again working on an estimate for a new project wherein the date is already known. I guess at this point my thinking is make sure I have a decent enough understanding of the project so that I have the resources to hit the date, and hopefully the experience of that first project will help me to not be too aggressive on the parts that I think I understand as there are probably some icebergs and also not too lax so that at the end I deliver on the date we need it or a week or 2 early and have enough resources to do so that I am not in a death march. Wish me luck.

On a positive note I resolved all the issues with our new SonarQube server instance and we transitioned to it last Friday. We are now able to use the plugin in IntelliJ to download the data and analyze our local projects which is a big step forward. Additionally running it as one unified Sonar job from the parent pom instead of invoking it on each maven module has resulted in a speedup by 10 minutes on our builds with Sonar analysis and better Sonar coverage overall (Previously some taglib libraries and a few other small things weren’t being analyzed).