Guice & Hazelcast.... Method Caching Interceptor

A couple days back I did Spring, AspectJ, Hazelcast Method Caching Aspect and I received an anonymous question on how to do the same thing in Guice I had heard of Guice, I knew what it was, but... I have been a Spring zealot for many years now, so my first reaction was:
What??? Guice? me?? ... Not use Spring? ... why would you ever not do this is Spring?... after a bit more whining I finally found myself saying "Oh ok, let me do it in this Spring wannabe "Juice" framework, just to prove that Spring is better."

All I can say is dammit! I hate being wrong ... the Guice is sweet. It took me about an hour to go from never using it before to having this AOP Method Cache Interceptor project done. A lot of that time was me being a typical developer and playing rather than actually reading the docs. In other words, it's simple, and that is always a good thing.
Now before someone takes this the wrong way: I know Spring does a lot more, Guice is focused on DI, Spring integrates with more, most of the popular Google apps run on Guice so it is rock solid etc. etc... I am not doing this as a comparison and definitely don't want to choose sides, but rather just showing another way of doing something.

I will only be posting the interesting bits of this project here, the full source is available here :
Source Code

First thing, Guice is available in the Maven repo and they recommend using that rather than the google.code site. The POM for this project:



Guice (as they say in their documentation) takes full advantage of annotations and generics. So for this project I created a @Cacheable interface to allow me to annotate the methods I wanted cached.


To configure Guice you need to extend an AbstractModule, this is where you configure what gets injected where by what. In the example below I use a construct called a Provider to allow me to use the Hazelcast factory to inject and instance. One other important thing to note in the code below is the "requestInjection(cache)" when injecting into interceptors you need to specify that in order to that injection before actually using the interceptor.

The AbstractModule:


And lastly for the actual interceptor. Right at the bottom of the source below you will see the @CacheName interface, this is one of a number of ways to map configuration values to be injected. The interceptor implements MethodInterceptor and you get all the required information about the method execution from the MethodInvocation parameter.



So there you go Mr Anonymous, hope it helps.

Spring, AspectJ, Hazelcast Method Caching Aspect

After my recent discovery of Hazelcast, I decided to update my caching aspect project to include a Hazelcast implementation.

The source code for this project is available here

For more information please refer to the actual source or my original Ehcache post. The main difference here is that the Hazelcast implementation is by default a distributed cache, and takes advantage of all the other functionality that Hazelcast provides.
The main points of interest for this implementation are:
- The actual aspect class. See code below.
- The application context. See xml below.
- The Hazelcast configuration. I am using the default Hazelcast configuration, located in the hazelcast-version.jar. To use a custom one, you can define a hazelcast.xml and inject it via Spring.
- The CacheKeyStrategy in the code below is an interface defined to allow key generation for the cache for specific requirements. There is a default implementation that simply sorts and uses hashcodes of the values in the class. You can define a strategy per type you want to cache.

note: java docs only removed for size of post

The aspect:


The application context:


The test case:

Hazelcast - a simple distributed caching alternative

I have over the last couple years used EhCache either via Spring (with AOP) or having it configured as hibernates' cache. I have never had the time or the need to look into the whole distributed caching available with Terracotta. However I recently stumbled on to Hazelcast and read the following:

"Hazelcast is pure Java. JVMs that are running Hazelcast will dynamically cluster. Although by default Hazelcast will use multicast for discovery, it can also be configured to only use TCP/IP for environments where multicast is not available or preferred. Communication among cluster members is always TCP/IP with Java NIO beauty. Default configuration comes with 1 backup so if one node fails, no data will be lost. It is as simple as using java.util.{Queue, Set, List, Map}. Just add the hazelcast.jar into your classpath and start coding."

I was instantly intrigued. So it sounds simple enough...Open IDE...jump in... being a maven fan, I figure, why download and manually "install" when you can just use maven, so I search around a little and add the following to a pom.

Edit: 1.8.4 is now outdated check http://www.hazelcast.com/downloads.jsp for the latest.

From the online documentation, I saw there was an InstanceListener interface. I create a simple Main class, that implements that and lists the instances.



So running this just adds a listener to the Hazelcast instance. According to the documentation Hazelcast allows for the following (and lots more):
# Distributed java.util.{Queue, Set, List, Map}
# Querying distributed data

I created a couple Main classes to run these separately, so that I could see if they are usable across different JVM executions.








So within minutes... I have a distributed cache across 4 applications, that I can monitor, control, query... (and btw. Hazelcast allows you to add indexes to the caches, same as a database to optimize queries).
If I was to place these 4 applications on 4 different machines, they will by default cluster (multicast for discovery) and have built in failover, monitoring and even persistence if required.

Coming from an environment where we have dozens of servers all caching data, this has got to be one of the most exciting open source products I have come across. Now I just need to convince the powers that be to prototype this and this may be the first open source project I actually try get involved in. The possibilities I am seeing for this type of functionality and then integrating it with the Spring Framework may actually make my brain explode.

Developer / Architect interviews, looking at it from both sides. Part 2

Part 2, The Interviewer...

In Part 1, I covered things that would possibly aid you as an interviewee, now onto the other side. I will be the first to say, I still have lots to learn about interviewing people, and some of what I list below, I need to practice as well.

All companies have their general interview process, being certain technical tests, standard questionnaires and particular processes. Going beyond those -because they are a necessary evil- other things I feel important when interviewing a developer are:

1. Probably the most important thing I look for in a developer, being a developer, is a passion for development. Sadly this has also proven to be the hardest thing to find. There was only one candidate out of the 20 something interviewed that showed some passion for development and he ended up accepted an architecture role, where he probably won't get to develop. I feel if someone shows passion for what they do, they will learn faster, be more focused, be more positive and generally a much safer bet to employ. Judging a developers' passion in an interview can be difficult, the best way I can think of is to explore an area of their expertise. Taking myself as an example all you would need to say is: "So I see you worked with the Spring Frame..." and that would be the rest of the interview.

2. When you receive a candidate's CV, read it, make notes, add specific questions. Do this before the interview as once you are in the actual interview it is far more important to pay attention to the candidate. During this preparation look for discrepancies, these creep in, things like someone rates themselves 4/5 in say JavaScript or some application server for example... but then none of the jobs / projects they mention used that specific technology. Make sure to find out the detail, as this could be a miss communication somewhere between the candidate, recruiter, HR department and you, or actually something alluding to a "creative" CV. Always check for job hopping, in areas where there are large systems running it generally takes a developer 3-6 months to become really productive, if someone leaves within a year it's actually a huge loss.

3. Try get the candidate to relax, people do not show their actual personality under stress. So begin the interview with light personal questions, none that will get you in trouble with the HR department, but just enough to allow the candidate loosen up before jumping into the technical stuff.

4. Make sure everything required for the interview is available and ready. A clean whiteboard and markers or paper and pens if the candidate needs to draw or describe anything. Having both available is preferable as some people are really not comfortable drawing on a board.

5. People sometimes don't feel very comfortable asking the interviewer questions, specially in the case of panel interviews. Prepare a standard list of points that would answer questions the candidate didn't ask. I mentioned some in Part 1 and some examples as an interviewer may be:

The regular day /week in the life of a developer here looks like: weekly dev meetings, daily meetings close to deadline, multiple tasks, tech specs, code reviews and unit tests, etc etc.
We support 15 different application on a 24/7 basis every couple weeks.
The team size and structure is as follows: 12 people, 1 team lead, 1 architect, 6 developers...
The career path here is defined as follows Developer - Senior Developer - Architect - etc.
We supply you with a choice of laptop or desktop, duel monitors, 4gb RAM, IDE is up to you.

6. 'Go with your gut'; the general interview process is actually too short to be able to completely assess someones skills and compatibility. We work in a very high stress environment, with hundreds of different scenarios everyday and I don't think we can determine if the candidate will cope or excel within a 1 - 2 hour period. There are no hard and fast tests that will determine if the candidate will take responsibly for their work. If they will complete things in a timely manner under pressure. If they will boost the morale of those in the team, or will they turn out to be a complainer that will to jump ship at the earliest opportunity.

My final point to end off -something I heard from my wife's boss- which appealed to me greatly. This will probably get some reactions from people and unfortunately my current boss did not allow me to actually do this... but... In a perfect world, where you get a fair amount of high quality CVs, I would personally love to divide the large stack of applications in half and toss 1 half of them directly into recycle bin. If you are unlucky, it's probably better you find work somewhere else.

Developer / Architect interviews, looking at it from both sides. Part 1

Part 1, The Interviewee...

Firstly let me say, I am by no means an expert interviewer, I have just recently been included in the whole interview process. I originally wanted nothing to do with it actually, but now several months and 20ish interviews later I quite enjoy it. The only frustrating thing is how people actually come to an interview, in one word: Unprepared. This may be a South African thing, where the demand way out strips the supply when it comes to software developers, but sadly the quality of the candidates coming for interviews is really disappointing. I am going to try keep this technology agnostic, as it is not only limited to Java, my wife -a dev team manager in a .Net technology company- goes through the same frustrations when looking for new staff.

So out of the 20ish candidates I have interviewed in the past months only 3 potentially had the skills we required, 1 was hired, 1 accepted an architect position at another company rather than the senior developer we were offering and the other's personality was not a match for the team. The other 17-20 people were either unprepared, unskilled or incorrectly represented by a recruitment agency.

I personally have not been for an interview in about 4 years, so my own interview skills may be a little rusty. However if I had to apply some of my experiences of being the interviewer into being the interviewee. I would do the following, above and beyond the standard interview success practices of being presentable, on time, professional, confident and having a self sales pitch.

1. If you are going through a recruitment agency, make sure that they show you the CV (Curriculum Vitae / Resume) they will be sending to their clients. Make sure you are happy with it. I would say about half the CVs we get really do not accurately describe the candidate. When this happens it immediately changes the tone of the interview and your chances diminish greatly.

2. Find out upfront what kind of tests the company makes candidates do, and prepare for those.
In the case of my current employer:
2.1 There is a general "aptitude" test, which I personally don't agree with, but it generally covers classic word sum, riddle, trick and what's the next in the sequence type questions. There seems to be a lot of companies doing this kind of test these days. So it is well worth searching the web and practising this kind of test. One site I did find quickly India Bix, would be a good way to prepare.
2.2 A Tech Check, which is a scaled down version of the official certifications and as such the same preparation can be done for those.
2.3 Finally after the initial interview there is a long Psychometric Test. Which you can't really prepare for.

3. Find out who is interviewing you, and just to a quick web search on them. They may have a blog, a book, a twitter feed, public facebook account all of which can give you vital information that can drastically alter the entire interview. Take myself for example, if you knew I was interviewing you and you found my blog, you would find this article along with a whole bunch of technical stuff about the environment / company that can give you a very nice advantage in the interview.
I Google all the candidates, only fair that they do the same.

4. Stay Current, we are in a ever changing industry, companies and your current employer may not be able to keep up with the changing technology environment, but this doesn't mean we as IT professionals shouldn't. As an interviewer I often ask the questions, "how do you stay current?", "what do you read?". How I try stay current, is this blog and Google Reader, I follow and read many Java, development and architectural related websites and blogs. I also plan to get the new Kindle in the next week or so, as there are quite a number of books that I need to get through.

5. Make sure that you read and know the common interview questions for your technical specialities. There are a lot of resources online to help with that. You don't want to show up to an interview as a Hibernate, Spring, Oracle or Asp.net 'expert' and then get put on the spot by a relatively simple well known interview question.

6. Ask questions, from the interviews I have done very few people have even asked the basic questions. It is important to ask questions, firstly there are things you should know about your working environment and you to engage the interviewer. Some example questions I would ask are in no particular order:
6.1. What does a regular day in the life of a developer or architect here look like?
6.2. What applications are you supporting? What are the support hours like?
6.3. What is the team size and structure?
6.4. What is the career path and policies on training?
6.5. What IDE, and what kind of hardware will be supplied?
6.6. Why are you hiring? Is it because the team is growing? (or are people jumping ship... don't ask that :) their answer will imply that.)
6.7. What are the greatest challenges facing the new person in this position?
6.8. What is the management style of my direct manager?
6.9. Who will evaluate my performance? When? How?

On a side note:
If I was to find new employment I would firstly research companies I want to work for and see if I could directly deal with them, as I stated before recruitment agencies can sometimes do you more harm than good. Search the top 100 companies to work for in your country / city, check the technologies they use, their culture, their location. I would also use social networks, a candidate that comes recommended from a current employee already has a huge advantage to just some random Joe Smith off the street.

In Part 2, I will discuss some of my experiences on the other side of the table as a interviewer.

Chunking a List into parts.

Needed to batch up the contents of a list into groups of 4 today. Spent a little more time than I would have liked on it, but I think it's a pretty neat bit of code now, and I actually got to use java.util.concurrent.CopyOnWriteArrayList for the first time.



The result of running this:

Top level list 1 contains:
1
2
3
4
Top level list 2 contains:
5
6
7
8
Top level list 3 contains:
9