Serialization, Beans and PMD

There is a PMD rule that checks for mutators (getters and setters) on Java Beans: BeanMembersShouldSerialize. I have a lot of these violations in my code. I’d rather understand the issue than just turn it off, but I’m struggling with what it means.

What I learned is: being Serializable does not make a class a Java Bean. And, to be Serializeable, you don’t need mutators.

But PMD thinks my object is a bean. Why? Continue reading

List App

I have an idea for an online list making app. The list can be sorted on any number of attributes (or “sorts”). Attributes can be added at any time and once “activated” you can drag and drop your list to the order you want for that attribute. Then, if you go to another attribute, it again can be drag and dropped into order, but the order is remembered. So if you go back to the first attribute, the items are resorted based on that attribute.

Continue reading

Tech Lead Checklist

I recently read the article Tech Lead Checklist to Kick your Team into Gear, recommended by my tech lead. Here are some things our team does and does not do.

Daily

Require written standup reports each day Nope. We don’t do this. Once every other week I might write something up but it contains more than what I did that day. And other times when someone (one person in particular) can’t attend our scrum they will send an email.
Attend a daily chat Yup. That’s our daily scrum.
Resolve roadblocks Yes, I do this.
Look at individual detailed activity Really? I peruse Fisheye occasionally, but I don’t think I do any “detailed” investigation.
Move requests to ticket system Yea, I usually put in “issues” which can be turned into backlogs during sprint planning.
Let team members select their own tasks. We try to let our developers do that. But some ask what they should work on and I do assign tasks.
Watch for lack of commits and ask developers to break into smaller tasks I believe in atomic check ins. However, without a “quiet period” the continuous server will keep rebuilding. Plus it makes it harder to say “this commit was for feature X” when really there were 10 such commits. I’ve often wondered about using Git locally to make these atomic commits and then checking them to SVN.

Weekly

Review tickets I usually review ones that are specific to the project I’m most working on more frequently than weekly.
Ask specific developers to plan large tasks Done by me.
Post team tasks completed and what is planned for the next week I can’t say we do this.

Bi-Weekly

Find developers interested in new projects We often are asked what sounds interesting to us and we try to pass that on when talking about features of a project.
Do “onboarding” Our tech lead did a great job with this a year ago when I joined his team. I’ve tried to create Eclipse templates that others can use. We would need to work on this more if we were expecting any developer to join the team.
Evaluate trial developers We don’t have any trial developers but we look at our current developers and assess them. If we don’t think they are working out, we are willing to try other developers.

So what does this mean? It means I’m already doing a lot that a tech lead should be doing, so I’d be totally comfortable taking that position. (Hint, hint, wink, wink, nudge, nudge.)

First Scala

I was hoping for

def sayHello(name) {
  println("Hello, " + name)
}

("world", "Adam").foreach(sayHello)

but will have to settle for

def sayHello(name: String) {
  println("Hello, " + name)
}

List("world", "Adam").foreach(sayHello _)