As my holiday vacation winds down I decided it is time to figure out what my themes are going to be for 2016. Last year I did a fairly good job at hitting the themes I laid out for the year, so I Am curious to see how it will turn out this year.
- The first theme is going to be the same. Regular updates to the blog ideally once a week, though as I saw last year I Didn’t quite make the weekly thing but I did average it given 52 posts. Hopefully I can keep the content somewhat regular this year.
- I want to continue with reading like last year, but that number will for sure drop as we are expecting a baby in February and I know depending on my sleep situation reading may go right out the window.
- At work I would like to migrate to Spring Security 4. This is going to be a bit of an annoying upgrade for us based on some of the changes, but I think this year is the year to bite the bullet and figure it out before we are dealing with Spring 5 in 2017.
- At home I would like to play around with Swift and write my first iOS app. I have been programming Java for 17 years now and I feel like mixing it up a little bit to keep things interesting. I was actually going to work on that over my vacation, but I ended up getting Fallout 4 on the Steam winter sale and messing around with that instead.
- I would like to restructure our webapp at work from an EAR Structure to a WAR structure. If that is successful I would then like to move away from JBoss to Tomcat. And if I got really crazy I would like to end up converting our Spring App to a Spring Boot App which would be a massive restructuring our our application. I think if I could accomplish all of that we would be in a great place going forward, but this is pretty ambitious as a side project and not sure I will be able to find the hours to get us all the way there.
- I think it would be cool to contribute some sort of patch or something into the openjdk or Spring just to say I have contributed there. It just depends if I find enough time to find a small issue and work it out and do so.
At the end of the day whether or not I do any of these things doesn’t matter too much to me. It is sort of just setting some sort of milestones to track how my year is going. The main purpose of this blog is just keeping myself accountable so that I am always sort of improving a little bit each day, so if I find that I have nothing to write about then I can see I am not pushing myself hard enough to learn something new. Here is to another great year.
I was checking the Spring Blog today to see what was new after taking much of the week off. I came upon the following entry. Of course I was very interested as Spring Security 4.0 has been hyped for a few months now so I figured I would check out the migration guide from 3.2 to see what will be involved for us to upgrade. I found this is the new feature section. They have added a feature which will now automatically prepend ROLE_ to any roles you use in Spring security if your role doesn’t start with that. So if you have a role called ROLE_USER for a standard user you can now just say @PreAuthorize(“hasRole(‘USER’)”).
The problem I have with this, is it assumes that you name all your roles with ROLE_. Unfortunately we don’t. When we migrated to Spring Security for our new architecture we already had a system that had over 700 different user rights in it. We mapped our user right system into Spring Security by implementing GrantedAuthority on our UserRights. This allowed us to maintain compatibility with our legacy architecture which some of our system runs on while seamlessly migrating other parts over to the new architecture. This is one of those opinionated things about the framework that is going to cause us a lot of issues. Now we are forced to conform to what Spring Security thinks we should name things instead of it just checking our collection of granted authorities to see if we have permission to carry out an operation. This is one of those changes that risks breaking things for many people with what gain you don’t have to type 5 characters? I don’t really get it and am annoyed as it means maybe we have to do some ugly hack like have our getter prepend that so we can keep our legacy name, but still satisfy the new “feature”. If nothing else it means it will be longer before we think about making this change as why add extra pain for yourself, unless you see a big benefit which at that point I don’t see a super compelling reason why I need to upgrade right now. So maybe we will get around to upgrading in the next year time will tell.
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.
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.