What are our thoughts on putting all the letters after your name in a CV/resume?
Pretentious? Or the only reasonable time to use all those letters?
After the acquisition of a company with offices in New York, I pestered my company outrageously until they got fed up and finally relented – they agreed to send me to the US.
To ease the transition, I chose to move onto a project which would allow me to start working in London and continue on the same team after I had moved to New York.
In the extreme over-excitement that followed my relocation, it took me a little while to realise that effectively I was an offshore resource, no different really from any of our Indian test team, and the team needed to manage this appropriately.
I learnt a number of lessons whilst playing this game. Some of these points are also valid for teams with remote resources (e.g. people working from home).
Continue reading "Tales from the Other Side: Confessions of an Offshore Resource"
This is a great example of what happens when you try to incentivise intelligent people on very simple metrics.
They cheat.
This was well described in Freakonomics, and something Mr On Software bangs on about regularly. It's clear that there isn't really a good answer to the problem - actually that's not true. The answer to the problem is to have everyone working in a job they are happy in and proud of, one where they are intrinsically motivated, and give them enough information to allow them to make the correct calls when it comes to prioritising work. But I'm guessing that a large portion of the working world does not fall into this category.
I know there are arguments against certification, and I definitely think that using certifiction to determine whether to interview or recruit people is downright daft, because frankly learning a bunch of answers isn't all that difficult. But I personally find that completing a certification really helps to round out my knowledge in an area. I guess my thoughts are that a fairly recent certification combined with the work experience to back it up is something that would make your CV more interesting to recruiters.
Today I would like to document my experiences implementing caching with Aspect Oriented Programming (AOP) and annotations.
Hmm. I have been so busy trying to think of "good" things to write here, and not having the time to actually write, that I see it's been 6 months since the last post.
If anyone is still out there though, I need help. I need a good Certified Scrum Master course in New York or London, preferably in April or May. Any suggestions? The one I wanted to go on was vetoed and now I find it's not running in NY again until Autumn.
PS Do you think it would be inappropriate to use the term "Scrum Mistress" on my CV?
So if java generics slightly disappointed me lately, what have I found cool?
I'm currently working on a web application using Spring MVC, which probably doesn't come as a big surprise, it seems to be all the rage these days. Since this is my baby, I got to call the shots as to a lot of the framework choices. When it came to looking at implementing validation, I refused to believe I'd have to go through the primitive process of looking at all the values on the request and deciding if they pass muster, with some huge if
statement. Even with Spring's rather marvelous binding and validation mechanisms to take the worst of the tasks off you, it still looked like it would be a bit of a chore. Given all the cool things you can do with AOP etc I figured someone somewhere must've implemented an annotations-based validation plugin for Spring.
And they have. And there's actually a reasonable amount of information about how to set it up and get it working. The problem is that it's pretty flexible and has a lot of different options, so when you are running Java 1.5 and Spring 2.0, and actually want to use the validation in a simple, straightfoward fashion, the setup instructions get lost.
So here's my record so I don't forget in future how I did it.
As a brief summary for those who may not be familiar with Spring, or for those who need reminding (no doubt me in a few months when I've completely forgetten what I was working on), Spring provides a Validator
interface that you can use to easily plug validation into your application. In the context of web applications, you create your various Validators
and in your application context XML file you tell your Controllers to use those validators on form submission (for example).
Spring Modules validation provides a bunch of generic validation out of the box for all the tedious, standard stuff - length validation, mandatory fields, valid e-mail addresses etc (details here). And you can plug this straight into your application by using annotations. How? Easy.
This is my outline application context file:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns=" http://www.springframework.org/schema/beans"
xmlns_xsi="http://www.w3.org/2001/XMLSchema-instance "
xmlns_vld="http://www.springmodules.org/validation/bean/validator "
xsi_schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.springmodules.org/validation/bean/validator http://www.springmodules.org/validation/bean/validator.xsd">
<vld:annotation-based-validator id="validator" />
<!– Load messages –>
<bean id="messageSource"
class="org.springframework.context.support.ResourceBundleMessageSource">
<property name="basenames" value="messages,errors" />
</bean>
<!– Bean initialisation for validation. You can put these explicitly into your controllers or set to autowire by name or type –>
<bean id="messageCodesResolver"
class="org.springmodules.validation.bean.converter.ModelAwareMessageCodesResolver" />
</beans>
Really all you're interested in is the addition of the validation namespace and schema at the top of the file, and the <vld:annotation-based-validator id="validator" >
line which is your actual validator. The other sections are a message source so your error codes can have meaningful messages and a MessageCodeResolver to make use of these.
Eclipse does seem to moan about the way the springmodules schema is referenced, but when you actually start Tomcat up it seems happy enough.
I've chosen to give the validator the ID validator
because I turned autowire by name on so that all my controllers picked up this validation by default. Note: autowire can be a little bit dangerous and I've actually turned it off now because I had a validator
bean and a validators
list in the context file and my poor SimpleFormController controllers were getting a bit confused over which one to use (in truth, the single validator was overwriting the list, which was not what I was after at all).
Anyway. Now what? We have a validator and we've probably wired it into the relevant controllers, either by autowiring them or poking it specifically into our controllers like this:
<bean id="somePersonController"
class="com.mechanitis.examples.validation.controller.MyPersonController">
<property name="commandClass"
value="com.mechanitis.examples.validation.command.PersonCommand" />
<property name="formView" value="person" />
<property name="successView" value="success" />
<property name="validator" ref="validator"/>
</bean>
Next step is to add some validation rules. The documentation will show you how to do this using an XML file, which you're perfectly welcome to do. However, what I wanted to show is how to use annotations on your command object to declare your validation. So here you are:
import org.springmodules.validation.bean.conf.loader.annotation.handler.CascadeValidation;
import org.springmodules.validation.bean.conf.loader.annotation.handler.Email;
import org.springmodules.validation.bean.conf.loader.annotation.handler.Length;
import org.springmodules.validation.bean.conf.loader.annotation.handler.Min;
import org.springmodules.validation.bean.conf.loader.annotation.handler.NotNull;
public class PersonCommand {
private static final int NAME_MAX_LENGTH = 50;
@NotNull
@Length(min = 1, max = NAME_MAX_LENGTH)
private String name;
@Min(value=1)
private Long age;
@Email
private String eMail;
@CascadeValidation
private RelationshipCommand relationship = new RelationshipCommand();
private String action;
//insert getters and setters etc
}
Note that @CascadeValidation
tells the validator to run validation on the enclosed secondary Command.
This is just a simple example obviously. But hopefully you can see that now you've got the validator set up correctly in your application context file, all you need to cover 90% of your validation needs is to tag the relevant fields with the type of validation you want. If you want to get really clever, the validator supports Valang which allows you to write simple rules. For example, if I only want to validate the name when I'm saving the person rather than passing the command around for some other purpose, I might change the annotations on the name field:
@NotNull(applyIf="action EQUALS ‘savePerson’")
@Length(min = 1, max = NAME_MAX_LENGTH, applyIf="action EQUALS ‘savePerson’")
private String name;
That's the basics. Before I let you go off and play though, a word about error messages. As usual with Spring validators, you can specify pretty messages to be displayed to the user when things go wrong. In my application context file above you should see that I've specified a properties file called errors. In this file you can map your error codes to the message to display. When using the spring modules validation I found the error codes generated were like the ones below so you might have an errors.properties
file that looks like this:
# *** Errors for the Person screens
PersonCommand.age[min]=An age should be entered
PersonCommand.name[length]=Person name should be between 1 and 50 characters
# etc etc
# *** General errors
not.null=This field cannot be empty
Go play.
When I first started playing with Java 1.5, I thought generics were the best thing since sliced bread. No more untidy casting, lovely type-safe Collections, and when combined with the new for loop, a lot of the tedious tasks associated with Collections became easier and, most importantly, aesthetically pleasing.
This is a bloody good idea. It builds upon my own Virgoen tendancies to write lists and tick things off, but what the list model lacks is the "in progress" state. Plus occasionally my lists get confused. See today's notebook page: