Monthly Archives: December 2014

Top Posts of 2014

It’s the end of the year, and as people are wont to do, it’s time for The Year In Review! And before I say anything else, I want to say a special thanks to my readers who are making this blog successful! I hope that everything I write about is fun and useful for you. Let’s review this blog for the year…

My most-viewed blog post of the year, weighing in at almost 3000 views, was Setting Up HTTPS For Spring Boot. At the time (almost a year ago!) Spring Boot was still relatively early in its development, and the documentation to set up HTTPS was meager at best. But I was eager to figure that configuration out, as were, apparently, many others. Fortunately the good folks working on Spring Boot recognized that need and it is way easier now. So that particular blog post probably won’t be getting a lot of traffic in the future, but it’s good to know it helped people out.

My personal favorite post of the year was Imposter Syndrome. It’s my favorite because I feel it speaks to many people at all levels. Various people told me verbally that they felt it was very helpful to them personally and appreciated it. This speaks to the need that this post really filled, and satisfying needs and helping people is really the goal of all this in the first place.

What was your favorite post of the year? What kind of post do you feel helps you the most, that you would like to see more of next year?

Leave a comment

Filed under Uncategorized

Thoughtworks Technology Radar January 2015

The Thoughtworks Technology Radar for 2015 has just been released. I’ve been playing with Java 8 a lot on the side, so was interested to see where it stood on their scale. Well I’m happy to report that Java 8 is recommended in the “Adopt” category!

According to Thoughtworks: “The Adopt Ring represents blips that we think you should be using now. We don’t say that you should use these for every project, any tool should only be used in an appropriate context. However we do think that a blip in the adopt ring represents something where there is no doubt that it’s proven and mature for use.”

So the takeaway is: don’t drop all of your technology and other languages to switch Java 8. But if you work on a Java system and are wondering if Java 8 is safe to use, at least a third party has found it ready to roll!

Leave a comment

Filed under Software Engineering

Statically Typed Clients for Spring HATEOAS Resources

Recently I was experimenting with Spring HATEOAS.

My goal was to return a Resource from a Spring controller:

@RequestMapping(value = "/user/{id}", method = GET, produces = {"application/json"})
@PreAuthorize("isAuthenticated() and (principal.id == #id or hasRole('ADMIN'))")
public @ResponseBody Resource<User> getUser(@PathVariable Long id) {
    User user = service.getUserById(id);
    return resourceAssembler.toResource(user);
}

… and be able to consume it from a Java client (not Javascript) using a RestTemplate:

String entityLink = ...
RestTemplate auth = ...
ResponseEntity<Resource> response = auth.getForEntity(entityLink, Resource.class);

(I’m using a Java client because my integration tests are in Java, and this also demonstrates how one might call the service from Android)

We’ve Got A Problem

However, on the first attempt I was getting deserialization errors. Upon observing the returned JSON, I found that the User attributes were being placed directly in the response body (along with the Resource’s links attribute) instead of in the Resource’s content attribute. The Resource class has a getContent() method, wasn’t the returned JSON supposed to have a content attribute?

Statically Typed Pain

The issue turned out to be with the out-of-the-box Resource class: upon further inspection it has @JsonUnwrapped on getContent(). This is convenient for dynamically typed clients like Javascript who might benefit from a shallower structure to navigate, and which do not have a problem with putting any attributes on any object. However, such a structure does not match any statically typed class defined on the server or the client. Resource does not have a “username” field, and User does not have a “links” field.

The Road Ahead?

One option could be for the client to retrieve it as string instead of as an object, and use the Jackson library direction to deserialize twice: each to two different classes (Resource and User) ignoring unknown fields. I don’t like this option so much because I feel like I shouldn’t have to write extra code (to do what RestTemplate should be doing for me anyway) every time I deserialize.

Another option (which is what I ended up doing) is to define my own Resource class as a copy of Spring HATEOAS’ version, but without @JsonUnwrapped on getContent(). This allows Jackson on the client to deserialize Resource into its own object, User into its own object inside the Resource, and all is well. It’s not a great option, as I’ll have to keep my copy of the Resource class up to date with Spring’s, but it’s the best I could do on short notice. 🙂 Additionally, my copy may end up morphing into a more customized DTO anyway.

What Do You Think?

What do you think of those two solutions? Are there better options?

Leave a comment

Filed under Software Engineering

Help Me, Help You

I just heard about this site: https://hackpledge.org It looks like you can give or receive help in the software development area of your choice. Besides gaining the satisfaction of helping others (or receiving help yourself), teaching can be a great way to hone your own understanding of a topic as well.

The hackpledge site is a little hazy on details so far, but initially sounds like a great idea. I signed the pledge and am looking forward to helping out my fellow developer as soon as they can pair me up, and maybe getting some help if I decide to learn a new technology for the new year.

Do you mentor people inside work or outside, formally or informally? Are there other sites like this that you’ve heard of?

Leave a comment

Filed under Software Engineering

Password Encryption Algorithms: Just Use BCrypt?

I started off researching the question “What are some common encryption algorithms and their tradeoffs?” And I came across the (more general and arguably more interesting) question of “How much should we as developers be informed before we can make informed decisions?”

Encryption Questions

Encryption topics make the rounds on the internet from time to time, and many times there is a chorus of Just Use BCrypt. Cryptography can be a very involved subject that you probably don’t have time to dedicate your life to, and you could easily make dangerous mistakes if you stray from the tried and true.

On the other hand, blindly accepting decisions made for you can also be dangerous. Is it following a cargo cult to say Just Use BCrypt?

My Take On It

So: What encryption algorithm should I use? After a couple hours of due diligence, I don’t have a problem with just using bcrypt. As far as I can tell it’s well understood and is widely accepted and used. We can use that answer instead of “the internet told me to.” 🙂

How much should I be informed before I can make that informed decision? After doing SOME research, it’s not hard to at least see what the options are and decide if there’s a consensus in the community around that specific area. I feel that as a professional, it’s my responsibility to deliver the best value. Learning the deep intricacies of cryptography does not deliver as much value towards my software as performing due diligence, making a reasonable choice, educating myself on proper usage, and moving forward.

Otherwise… disastrous hilarity ensues!

Questions

What encryption algorithm do you use for passwords in your system? How much about cryptography did you learn before making what you felt was an informed decision?

1 Comment

Filed under Software Engineering