jaXzin.com

So in my  previous post  I explained how to simplify your logging with Maven and SLF4J. If you haven't read it yet, please do before reading more.  Since then I've discovered an easier and cleaner way to remove the secondary frameworks from your Maven dependency tree. Here's a revised overview of the steps: Decided which logging framework will be your primary, aka who will actually write to your log file. Define the dependency scope of all the secondary frameworks to be ' provided '. Configure your project to depend on drop-in replacements of each secondary framework from SLF4J. Define secondary frameworks as provided Use the dependencyManagement section for this. Its used when you might have a dependency transitively. Add dependency on SLF4J Add the following to your pom.xml Conclusion So now in only 3 steps you can redirect all your logging to your primary logging framework without changing a line of code!

So I started using GitHub for a side project and discovered their very cool feature of service hooks. A service hook allows a repository administrator to setup a callback to another service when a commit is made to the repository. For example it can send an email, or chat a message via Jabber. Now continuous integration servers, like TeamCity , can poll source control systems every few minutes to see if any changes have been committed. But wouldn't it be more efficient to use a service hook to trigger a build? Looking at GitHub's service hooks, there wasn't one already available to callback a TeamCity server, but right on that same page was a link to the open source repository for GitHub Service Hooks . They "eat their own dogfood" so to speak and make it very easy to contribute new service hooks back to them. So I took an evening, did my first Ruby coding in a while which included more time getting Ruby setup and working on my Macbook than actually coding....

UPDATE: Ceki commented below which prompted me to rewrite the third paragraph. UPDATE 2: I have a better way of configuring Maven and SLF4J now. The mismatch between logging frameworks always seems to come up in projects I've developed over the years. Little-by-little I've learned and relearned how to navigate the nest of runtime logging that occurs in non-trivial applications. With my latest project I think I finally converged on a solution that I'll carry forward to future projects. So what am I really talking about? Have you ever been stumped, even for a short time, about where a certain log message is going and why it might not appear in your log? Often this happens when you are trying to debug an issue with a third-party library that's using a different logging implementation them your application. If you are nodding from familiarity, skip the next paragraph. Let's start from the beginning. There are several logging implementations available for Java, th...

Today I drove up to Boston for the day to attend NoSQL Live . My experience so far within the NoSQL community has been limited to what we've built in-house at Disney and ESPN over the past decade to solve our scaling issues, more recently has been ESPN's use of Websphere eXtreme Scale , and the very latest has been my own experimentation with HBase which hasn't gotten much further than setting up a four node cluster. I've read a little about Cassandra, memcached, Tokyo Cabinet and that's about it. So before the sandman wipes away most of my first impressions of the technologies discussed today, I wanted to record my thoughts for posterity or, at the very least, tomorrow. Cassandra Cassandra seems to be the hottest NoSQL solution this month with press about both Twitter and Digg running implementations. My impression, I'm wary of "eventual consistency". I don't feel I understand the risk and ramifications well enough to design a system properly...

I bought the book Java Puzzlers by Josh Bloch and Neal Gafter a few years ago and enjoyed it. If you aren't familiar with it, it covers rare, odd and usually counter-intuitive edge cases of Java in a brain-teaser style of presentation. For both a Java user and an analytical mind its a fascinating book. Well today I stumbled onto a puzzler of my own and thought I'd share. Can you tell me what the main method of this class will output? 1 : public class Parser { 2 : 3 : private static <T> T parse(String s, Class<T> type) { 4 : // Simple implementation only supports long primitive 5 : if(type == long.class) { 6 : return (T) Long.parseLong(s); 7 : } 8 : throw new UnsupportedOperationException( 9 : "parse() only supports long right now!"); 10: } 11: 12: public static void main(String[] args) { 13: System.out.println(parse("1234", long.class).equals(1234)); 14: } 15: } So what gets written to standard output? ...

Recently I've been helping a colleague introduce a dependency on a legacy project that hasn't been "Maven-ized". Often the "easy way" to add a legacy dependency is to throw the JAR into our Nexus repository and be done with it. But this legacy project was a little trickier and is my new poster child for why taking the easy way can lead to headaches and frustration. Your legacy project might have compile-time dependencies you need. Maybe your legacy project implements an external API, or maybe it uses a library and exposes that usage in its API. "So what", you say? "I'll find it at compile-time for my project and I'll add the dependency." Well, now every project that wants to use your legacy project is going to go through the same discovery and embed the dependency in their POM. The right way is to define this dependency in the pom.xml for your legacy project so all dependent projects retrieve it transitively. Your legacy pro...

In a surprising update to my post earlier this week about what REST is NOT , I just spoke with Rooly Eliezerov , the President and co-founder of Gigya. We had a nice conversation about the goals of Gigya, primarily that they want to aggregate these other social web services and their design philosophy is to mimic Facebook and Twitter's API. I expressed that using GET to change a resource isn't a REST principle either company's API breaks. He was surprised to hear it and said he'd follow-up with his team to validate that and get back to me. Whatever the outcome, I really appreciate that a company with their goals and reach is interested in what little ol' me has to say. It speaks volumes to their passion and customer support.

Update : I spoke with the president of Gigya . Having only familiarized myself with REST a few months ago, I still struggle to explain to colleagues what REST is. My best one sentence summary so far is that it's "using HTTP as it was designed". Not a perfect or even complete summary, but I think it covers the highlights. This week I've been reviewing Gigya's REST APIs for an upcoming project at work. And I've found it to be a shining example of designing an API incorrectly and calling it RESTful. It solidified a couple of REST anti-patterns for me and I wanted to capture them: REST is not RPC, though RPC can be done RESTfully. GET is not for state changes. If you're operation has side effects, don't use GET. The response body is not the only way to send the client information. Don't duplicate information in the HTTP headers in the response body. Authentication is not part of your resource. Don't create a query parameter to do authen...

So I signed up for a Google App Engine account a while ago, almost right after it's Python version was released last year. Of course, life prevented me from taking the time to learn Python, and so the learning curve prevented me from building or deploying anything. Fast-forward to two weeks ago when Google released the Java API for the Google App Engine (GAE from here on out). Being a full-time Java programmer for the past 10 years, now we're running on all cylinders! I applied for a Java account on the day it was released and my Java GAE account was approved within 24 hours, but it took a few days for me to make some time to start writing some code. After about 8 hours of development I had my first working prototype of a web application running on the GAE. My first GAE webapp is a service that connects to a set of social web sites that provide user names and profile pages for their users to see if a username you are interested is still available across those sites. My ...

So try this in Maven. Create a project A and don't install it. Create two subprojects, B and C, that have A as their parent. Make B depend on C. Install C. Try to build B. You won't be able to as Maven claims it can't download A. Huh? Why did C build then? The cause is that Maven can resolve a project's parent on the local drive using a relative path. But if a project has a dependency, it will only look up that dependency's parent through the repositories, even if that parent is available via a relative path. The solution, install A into your local repository. If another developer gets B out of your SCM and tries to build they will fail with the same problem. So I've now learned. Deploy more snapshot builds of parent POMs to keep my fellow developers happy.

My coworker asked me to describe how Maven compares and differs to Ant. I realized how hard it was for me to describe what a developer gets for moving their build process from Ant scripts to Maven. I can't make the argument that you can do X with Maven but not with Ant because I don't really have a valid example. However, I am inclined to make the argument that you can do X with both but with Maven it's easier. With Maven, you collect metadata about your project instead of writing scripts defining the steps your build will take. For example, if you look at an Ant script you'll immediately see that it is organized as targets which many developers use to define and group the steps of their build process. In a Maven POM file, you won't see similar build steps defined. This can be confusing for a new Maven user coming from the world of Ant. I know it was for me. Instead, you'll see lots of metadata about the project such as dependencies, Maven plugins to use...

So I've been meaning to get around to creating this for a while. The idea spawned from my search for a 401(k) calculator that didn't just assume one given future. By that I mean, I wanted a calculator that didn't calculate the return on my investment based on just one average annual return. I wanted a calculator that showed me lots of different futures, based on the standard deviation, a.k.a. the risk, of what I've invested my money in. I want to see the most pessimistic futures, you know the ones where all my investments bite the dust, as well as the most optimistic futures where everything is rainbows and bunny rabbits, as well as everything in between. So in that sense, I wanted a forecaster, not a calculator, similar to the hurricane landfall maps you see on the Weather Channel where the most likely landfall is that red wedge in the middle while wider is an orange wedge and even less likely is the widest yellow wedge. So last week I threw together this 401(k) ...