tfnico's blog

I was recently working with protecting some sensitive data in a typical Java application with a database underneath. We convert the data on its way out of the application using Spring Security Crypto Utilities . It "was decided" that we'd be doing AES with a key-length of 256 , and this just happens to be the kind of encryption Spring crypto does out of the box. Sweet! The big aber is that whatever JRE is running the application has to be patched with Oracle's JCE  in order to do 256 bits. It's a fascinating story , the short version being that U.S. companies are restricted from exporting various encryption algorithms to certain countries, and some countries are restricted from importing them. Once I had patched my JRE with the JCE, I found it fascinating how straight forward it was to encrypt and decrypt using the Spring Encryptors. So just for fun at the weekend, I threw together a little desktop app that will encrypt and decrypt stuff for the given password...

Disclaimer: I'm a Java developer, not a JavaScript developer. This is just what I've picked up the last years plus a little research the last days. It's just a snapshot of my current knowledge and opinions on the day of writing, apt to change over the next weeks/months. We've gone all modern in our web applications, doing MVC on the client side with AngularJS or Ember , building single-page webapps with REST backends. But how are we managing the growing amount of JavaScript in our application? Yeoman 's logo (not necessarily the conclusion of this blog post) You ain't in Kansas anymore So far we've just been doing half-random stuff. We download some version of a library and throw it into our src/main/webapp/js/lib , or we use it from a CDN , which may be down or unreachable when we want to use the application.. Some times the JS is minified, other times it's not. Some times we name the file with version number, other times without. Some ...

The other day, I needed to validate a text-field against a whitelist of characters. Actually, lots of text-fields needed lots of different sets of whitelists, but let's just stick to one for the sake of example. The text field "First name" is only allowed to contain any of these characters:   ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz°Žµ·žŒœŸÀÁÂÃÄÅÆ ÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜÝ Þßàáâãäåæçèéêëìíîï     ðñòóôõöøùúûüýþÿ .. and the user should be notified with which illegal characters she has entered in the field, if any. The knee-jerk reaction to this kind of logic is regular expressions, but my knee-jerk reaction to regexp is  to avoid it. The above character set probably doesn't fit with any of the predefined regexp notations, so it would probably be nasty anyway. Some  Guava fruits for coloring up this blog post ( image source ) So, let's put Google Guava to some use. It has some nifty utilities for working with sets   and other collect...

Recently I've done a lot of thinking about build tools, especially in regards to Maven, Grails and Gradle, and how they play into release management and versioning with Git. This is just a post to get some of those thoughts off my chest. I'll come back to Gradle in future posts, as I build some more experience with it at work. A few months ago, I wrote an article on our company blog about Grails' broken snapshot dependency mechanism . Even though Grails (up onto, and including Grails 2) support snapshot dependencies, the feature is flawed in a way that makes it unusable for us. This will be fixed in Grails 3, but we couldn't wait that long, so we ended up hacking together a workaround. This article describes why and how we did it. ( cont ) Now I've done a lot of modularization of huge builds over the years, and I've come to really like Maven's snapshot dependencies as an enabler for balancing between externalizing a library, and keeping it as part of th...

So the other day I was working away on some rather tricky rules for validating an incoming identifier code. Like 999392304II+TJAJEIAJTI901119 or EPFOOMNNVLLALOWEIITOE Now, the system where this code is going is rather picky about what these codes should look like. (For the sake of this blog-post, I'll invent some business rules here on the fly, in reality they are a bit different, but the nature of them are the same): A code cannot be null, or an empty string (of course) If there are only letters (A-Z) in the code, it must be longer than 10 characters, but fewer than 20 On the other hand, if there are letters mixed with numbers, it must be exactly 10 or 15 characters Numbers only are not allowed No other symbols are allowed, but + signs are allowed, if the code starts with 999. In this case, the max length is 10. Instead of just going straight for the if-else'ing my way through these rules, I implemented it using Predicates from Google Guava . I was pretty hap...

Torbjørn Marø recently blogged about Dependency Injection, due to  Mark Seeman visiting the Norwegian .Net User Group in Bergen. This triggered my thinking about the dreaded Service Locator. I have worked with several teams that favored a home-made ServiceLocator class, a static component referencing a set of  services , typically chunks of functionality that are singletons that interact with something external like database, filesystem, or web-service. My beef with the Service Locator is that you can put it in, and use it from anywhere: It can be used to grab services in a controller/action component, inside a service, in a domain object, inside a for-loop, anywhere. This sounds pretty powerful, but ends up bringing in a lot of maintenance problems. Now, in spite of my troublesome experiences with it, I keep finding myself being pretty lousy at explaining the disadvantages of a ServiceLocator to my peers. I therefore hunted through Seeman's blog for some better expl...

I'm dare say I'm a seasoned Hudson user (admin) and proponent. For over five years I've been introducing different kinds of CI at whichever place I worked at. When Hudson entered my radar, this work became a lot easier. I'm also a heavy Maven user, and Nexus did for Maven repositories what Hudson did for CI. The Plot Over recent weeks, the community around Hudson has been shaken by a fork: The main developers ( Koshuke and crew) have renamed Hudson to Jenkins , while Oracle have kept on developing Hudson in partnership with Sonatype . Here's a simple illustration of what happened: These are my pure external speculations about what has happened recently in the forking process, with regards to Sonatype's involvement in particular. So who is running this show? I noticed that Sonatype (usually personified by Jason) have gotten their fingers pretty deeply into the Hudson infrastructure already: Like  this tweet  noted, it appears they are controlling ...

A few days ago, Google Guava r08 was released . "This project contains several of Google's core libraries that we rely on in our Java-based projects: collections, caching, primitives support, concurrency libraries, common annotations, basic string processing, I/O, etc." I had a little look through the API changes to find some neat new details, and put together a couple of JUnit tests that show them by example here . That whole GitHub project is a Guava showcase, so if you can think of some more examples that should be in there, please fork ! Especially the IO, Net,  and Concurrency bits could need some examples. I've also taken my old blogposts about Google Guava and ported them to tfnico.com/presentations/guava . After noting this, the Guava guys honored the effort by linking the page from the Guava homepage , which gave me quite the traffic bump! Luckily, my pages are all hosted on Google servers, so it's their own bandwidth bill ;)

Just a quick post to announce my new Google Guava page. My Guava blog post has gotten a relatively large amount of traffic, but the list of resources have gone a bit stale. In order to make the resources a bit more "time-agnostic", I've cleaned it up a little, and made it into it's own page: http://www.tfnico.com/presentations/google-guava

I recently did a lightning talk at the local Java User Group in Cologne. Topic was  Agile in a Year in 5 minutes , a shortened version of the talk I did earlier at FrOSCOn. I'm gonna be doing the full talk at the Cologne JUG on the 8th of November, so be there! Well, if you're in the area, anyhow.

In the newest Javamagazin , there's an article by Bastian Helfert and Steffen Hohn about CodeCity , a really interesting tool for visualizing code. I just ran it over our 300k LOC Java project, and got this model ( click to see larger version ): Buildings are classes.  Height is based on class LOC Building ground-area is based on number of attributes City blocks are packages. If you actually run the program, you can interact with the model, fly around, click to see which package is which block, etc. This is all fun and cool-looking, but does it have any practical usage, I wonder? I think we want to work in small friendly villages, where most houses are evenly-sized, nicely sized neighborhoods, no big ugly gray parking lots, and no towering sky-scrapers. Here I ran it again on a smaller, nicer project: Certainly a lot easier to find your way around this neighborhood. I know Michael Feathers has made quite a few thoughts around code aesthetics . Perhaps ...

Update: I've moved the list of Google Guava resources to  http://www.tfnico.com/presentations/google-guava . This page won't be updated any more, but I'll leave it the way it was. I recently blogged about the Guava Libraries taking over for Google Collections . I figured I'd add a few more pointers to documentation, as the Guava wiki seem to be a bit empty (feel free to copy in these links). Update: More resources (I think if there are any more updates, I'll move this into an editable page on tfnico.com). A four part quite extensive tutorial from Sezin Karli: http://scaramoche.blogspot.com/search/label/guava Google Guava, the easy parts. A basic tutorial that recently surfaced on DZone: http://www.copperykeenclaws.com/googles-guava-java-the-easy-parts/ Old entries: A collection of short snippets (great mini reference for Google Collections): http://blog.publicobject.com/2007/09/series-recap-coding-in-small-with.html Codemunchies' 4 part series o...

Update: There's a full list of Google Guava resources on  http://www.tfnico.com/presentations/google-guava . I recently spent some time gathering documentation for our internal use of Google Collections . No more than a few days after quickly presenting Collections at work last week, Kevin Bourrillion announced Guava Release 05 , urging all users of google-collect to replace it with Guava  ASAP, and spread the news (so here we go). If you don't know Guava or Google Collections, they're basically a nice set of Java util classes that you always wanted. I figured I'd have a look through the library's docs, and as I went along, I coded a few easy examples (mostly from the base package). The code is available as a Maven project on github , and I also made a presentation (PDF) with roughly the same examples, seen here: Google guava presentation on slideshare Feel free to extend the examples by forking them on GitHub!

I noticed via @jvanzyl that Kent R. Spillner has been taking apart Maven and some of its features in a recent rant . The twittersphere has shown support for Kent's views - and being the Maven fan I am , I figured I'd take some time to try countering his post a bit (forgive me if this post is a bit unstructured, I'm trying to squeeze it out under some time pressure). "The best build tool is the one you write yourself..." I think this first paragraph contains a lot of absolute statements that happen to be false in a lot of cases. My experience is that a lot of projects or modules are built the same way. It's a bunch of source code, and in the end you end up with a JAR-file. We've got a 25 module web application at work, and I just mavenized the whole thing from Ant. All of the modules exlucding the final web-app module itself were easily built with Maven. Nobody says that every module in the world is built this way, but it sure is a lot. Java code goes in,...

The last couple of weeks I've been spending a little effort on getting some code metrics up and running. I've blogged about measuring in software development before , and I think code is definitely one of the easiest and most important things to measure. The most important thing about metrics is that you monitor them . I am of the firm belief that if you run a static code-analysis report manually, it will give you very little. Your team will say "wow, we have 3000 FindBugs warnings", fix a couple of them, and then forget about it. Then the next time you run the report, you'll find new bugs that have crept in, with no idea of when or who did it. There are two ways to track these kind of metrics: IDE warnings Continuous integration reports IDE warnings Most of you have probably enabled the built-in warning system inside Eclipse (unused method, potential null-pointer, etc). Some of you strive to minimize these numbers of warnings, some of you have perhaps even turned...

This post is a part of a tiny series I'm doing on why we use Maven, and you should too. Previous posts: Introduction: Why you should use Maven Reason 1: Get your libs-folder out of SVN Reason 2: Clean up your JAR-files Huge projects are hard to work with Many projects that have grown over time will become too large to easily work with. The workspace gets too many classes, the IDE slows down and the build takes too long. If the developers focus on separating the concerns of the classes into packages of functionality, these packages can be organized into modules. As the contract and concern of a module becomes more defined, its rate of change will fall to a lower frequency than the rest of the project. Once a module's activity has slowed down sufficiently, you can retire it into an external project, build a JAR-file from it and use this ready-built artifact as a classpath element for building and running the software instead. If changes occur later on, you can re-build the JAR-fi...

Update: Added a summary section at the end of this post. This post is a part of a tiny series I'm doing on why we use Maven, and you should too. Previous posts: Introduction: Why you should use Maven Reason 1: Get your libs-folder out of SVN Some background Back a couple of months, I got the rewarding task of cleaning up our project's lib folder. You know the one: Crammed with JAR-files of various versions of the various dependencies your project has.. fizz-project \ fizz-core fizz-web fizz-libs \ junit.jar spring.jar common.jar lots and lots of others... ... Yup, good old fizz-libs . It needs to be regularly cleaned up to reduce software rot . Over time, the developers try out new open source libraries and remove the use of old ones, but they seldom take care to clean out the libs-folder, because they don't know if there could be any hidden effects from removing JAR files. Now, at our place we use Eclipse's . classpath file for specifying ea...

This post is a part of a tiny series I'm doing on why we use Maven, and you should too. Previous posts: Introduction: Why you should use Maven The libs folder We have a libs-module in Subversion. When you check out the source code for our main product, this is one of the modules you get. It contains a hundred-and-some JAR-files. These are the dependencies for the sum of our modules: fizz-project \ fizz-core fizz-web fizz-libs \ junit.jar spring.jar common.jar Downloading all these MB's of JAR files is something you'll have to do no matter which build system you use, so bandwith cost isn't an argument. Subversion also uses binary diffs, so copying or changing a JAR file doesn't increase repository size significantly. The problem arises when you want more than one product. As soon as you want to split your product into two applications (or services), each project needs its own libs-folder : fizz-project \ fizz-core fizz-web fizz-libs \ ...

Update: I'm doing some work to split this blog post into some more fine grained posts in a series. Please, bear with me if these changes are giving you lots of noise in your feed-reader. I used to work as a consultant. My job was to improve our clients' ways of software development. Among the most important things I tried to teach them were: o Good code style and object orientation o Practical use of good open source tools (don't re-invent the wheel) o Automating tests of their software, and continuous integration o Splitting code into modules, dependency-relationships and versions The last point is perhaps the trickiest. It's hard to understand why it's needed in an isolated project, it is hard to explain how it should be done, and most importantly, there is no de-facto way or standard for managing modules, their relationships, versions and scope . This is why me and my consultant buddies embraced Maven many years ago. After years of pushing and evangel...

Lately I've become somewhat obsessed with testing . A specific kind of testing. I'm not quite sure about the term right now, but it's close to system testing, or maybe user testing. Ye know, that kind of black-box testing that makes sure your stuff works from the user's perspective. In web applications (of which I probably do about 90% of the time) they happen to blend in with web tests . I suppose it started off with last autumn when I put some thoughts on this into my lightning talk at the Smidig 2007 conference . Well, it actually started all the way back in 2006 when I did a lightning talk about Selenium in XP-meetup based on my experiences with Selenium vs. gargantuan use-case descriptions in a project ( see slides ). A few months ago I was down visiting a friend in Bonn, Germany. He works for this CMS-vendor/host called WebFactory . I offered him to drop by their workplace and do a quick demo on Selenium, as I figured they're (a) probably doing web applicat...