Home arrow Blog

Where the heck has Michael been?

Wow. As I type this I am embarassed by the fact that I haven’t posted a blog post in 20 months. When I look back, I hope you can understand why I’ve been MIA and hopefully there are many exciting things to come in the coming year.

TrustwaveLet’s start with the simple. From a timing perspective, shortly after my last blog post in March of last year, I decided to leave my position as a Senior Software Engineer at CME Group and go to a company called Trustwave. Why did I move? A couple reasons. First of all, Trustwave being in the security domain is hard to pass up. I can honestly say that this is the first domain I have worked in that I am actually interested in. I have worked on many interesting technologies over my career, but all of those have been to solve business problems that were not as exciting to me as the business problems I’m solving today. Second was because of opportunity. Coming to a company that is growing their engineering footprint and product offerings allows me to make a bigger impact more immediately.

Besides changing my day job, I have also updated my after hours activities as well. To start, I have been teaching some of DePaul University’s Professional Development programs. Specifically I’ve been teaching the Hibernate section of the Lightweight Java Web Development program and the Prototype/script.aculo.us section of the Web Development with Ajax Technologies program. I have been enjoying them immensely and look forward to continuing to teach at DePaul.

Pro Spring BatchFinally, and by far the biggest news on where I have been since I last posted is that my first book will be coming out next week. I†w was fortunate enough to use Spring Batch back in my CME Group days and have since explored the framework further. It has always been a dream of mine to write a book and am looking forward to helping others with the framework. Pro Spring Batch is currently available for preorder on Amazon’s
and Apress’s websites.

So what happens now? There are a couple things I’m currently working on that will have an affect on this site. The first is that I’m in progress of redoing this site. In the next month I’ll be moving to a new design that will not only make things easier to find but also allow me to post items of other areas of interest to me (specifically woodworking and photography). The second is that with the new design, I’ll be dropping the ads from the blog. Not a big change,but in the end this blog is about sharing information and not making a buck. Finally, I’ll be posting a couple tutorials about Spring Batch as well as some other new technology areas I’ve been able to explore over the past 20 months.

Thanks for your continued support and I look forward to an exciting time ahead!

vargs and arrays in java

vargs are a cool feature in java that has gained some traction since their availability in JDK 1.5. However, there are some nuances when working with them that if you don’t keep straight, can require quite a bit of Googling to figure out. Since I keep tripping up on this one myself, I figured I would write a quick post as a reminder for myself. In java, when dealing with a method that accepts a variable number of parameters (vargs), if you pass an array in as the parameter, it will be parsed as a list of parameters. Take this example:

public class VargsExample {
    public static void vargMethod(String... names) {
        for(String name:names) {

    public static void main(String [] args) {
        vargMethod("Michael", "Minella");
        vargMethod("Michael", "T", "Minella");

Both of the above method calls to vargMethod work fine. However, what if we have something like this:

public class VargsExample {
    public static void vargMethod(Object... arrays) {

        for(Object array:arrays) {
        	Object [] curArray = (Object []) array;

    public static void main(String [] args) {
        vargMethod(new String [] {"Michael", "Minella"});
        vargMethod(new String [] {"Michael", "T", "Minella"});

This time that won’t work. Java will parse our array as a list of parameters and essentially call vargMethod the same way we did in the first example. To fix this, we need to cast our arrays to Object. Essentially we want to trick the JVM into thinking that we are only sending a single object over instead of an array. Below is the code as it should be:

public class VargsExample {
    public static void vargMethod(Object... arrays) {
        for(Object array:arrays) {
        	Object [] curArray = (Object []) array;

    public static void main(String [] args) {
        vargMethod((Object) new String [] {"Michael", "Minella"});
        vargMethod((Object) new String [] {"Michael", "T", "Minella"});

New tutorial! Mocking static methods with PowerMock

“Static methods are the death to testability”. I’m sure you’ve all heard someone say something along those lines. Heck, even Google has blogged about it (http://bit.ly/4mk3fP). And yet, it just doesn’t make sense to me. Static methods were added to the Java language for a reason. Just because most toolsets do not support testing of them doesn’t mean that static methods are bad. I think it means we need new toolsets. With that in mind, I want to introduce you to PowerMock. In this tutorial, you can read about how to mock static methods with an EasyMock like API using this great open source framework. Read more about it here.

Day 3 of No Fluff Just Stuff

Well another year at No Fluff Just Stuff is in the books. Anyone who has been following my blog lately knows my two cents so once again, I’ll stick to the sessions I attended: Flex for Java Developers by David Geary, Tacking Concurrency on the JVM and Building External DSLs by Venkat Subramanian and finally Communication Skills for Knowledge Workers by Neal Ford.

You’ll notice right away that this last day, I stuck with heavy hitters. Geary is huge in the front end/web space and Venkat and Ford are both general gurus. The first talk was Flex for Java Developers. This was the first time I had attended a David Geary talk and to be honest, will probably be my last. It was disappointing that he had packed the session with so much material that he basically had to code “heads down” the entire time to get it all in. He wasn’t very receptive to questions (many hands raised were quietly lowered after waiting too long) and frankly I would have expected a better looking demo than the one he did.

The next two talks I attended were by Venkat. Venkat is a great speaker. He is charismatic, funny and knows his stuff. It’s hard for me not to recommend any of his talks. The concurrency in Java talk was no surprise. The message was: “Since you need to be God to write correct concurrent code in Java, write it in Scala instead”. No arguments there and after watching his demo on how easy it was to do safe concurrent code in Scala (and a bit in Closure at the end), I’m convinced that if I had to write concurrent code, Java would not be my language of choice.

Next was external DSLs. This was basically an xText tutorial. xText was very impressive both on the ability to write the parser for the language but that you would be able to validate it as well (a major disadvantage of writing DSLs in languages like Groovy). Once again, Venkat rocked and I recommend the talk.

Finally I went to Neal Ford’s communication talk. I love listening to Neal Ford. He’s a geek’s geek. He knows his stuff, can communicate well and understands why things work (not only how). In this talk he explored the different communication channels we use in IT and proceeded to tell us how to use them better. Unfortunately, I felt that most of this talk was repeated from his other talks (which goes back to my previous rants on no new topics). Neal was entertaining as always, but I left the talk wanting to have heard things I hadn’t heard before and that wasn’t the case.

So that’s it. NFJS 2009 Chicago is done. Unfortunately I didn’t get a chance to pin Jay down to ask about the topics presented, but I did send my feedback to them. If I hear anything back, I’ll be sure to post it. Did you go to NFJS this year? What were your thoughts? Let us know in the comments!

Day 2 No Fluff Just Stuff

Day two is officially in the books. And I’m sorry to say, I was disappointed. I won’t repeat my rant from yesterday (you can read that here: http://www.michaelminella.com/blog/54.html). I’ll talk specifically about the three talks I went to: Open Source Java Debugging Tools, Connecting Companies with Acceptance Testing, Git.

The first session I attended was Open Source Debugging Tools by Matthew McCullough. I’d give this talk a 7 out of 10. Most of the talk was a tutorial of the tools provided by Sun in the JVM, tools like jps, jmap, etc. There was one tool that really stood out to me…TOD. This tool essentially records the entire execution of a JVM and allows you to replay and inspect the execution at amazing levels. I’ll definitely be checking this tool out later.

The second session I went to was Connecting Companies with Acceptance Testing by David Hussman. Hussman rocks. If you’ve never seen a talk by him, I highly recommend it. This talk focused on acceptance testing…not so much the tools of it (we listed them but that’s about it), but the actual politics around it and how to get people involved. Overall this was a great talk.

Finally, I went to hear Matt talk about Git. I have to admit, I went to the Git talk with an ulterior motive. I was familiar with Git before the talk. However, I have never been able to grasp the benefits of Git in an enterprise environment. Unfortunately, Matt was only able to confirm my understanding of Git and it’s lack of benefit for a standard corporate environment (let the flame wars begin).

If you’re wondering why I didn’t talk about the fourth session I attended, there is a good reason for that. I didn’t go to one. There was nothing in that slot that interested me which goes back to the issue I mentioned yesterday. I hope to get some time to talk to Jay and ask him about this issue and I’ll let you know what he says.

Day 1 of No Fluff Just Stuff

Yes, it’s that time of the year again. I’m spending this weekend at No Fluff Just Stuff to improve myself. When I reviewed the speakers and topics for this year, I’ll be honest, I was disappointed. I’ve been going to the show now for the past four years and learn something new every time. However, over the past four years, the topics haven’t changed much. Groovy, check. Some form of code smell talk. Yup. GWT and JSF, got those too. But those topics have all been there for the past four years. The really only new topic for this year was a track on semantic web. And I’ll be honest, I’m even more disappointed about that track (albeit for a different reason). The reason for that disappointment is because I know where that track came from. We were doing semantic web when I was at Sears over two years ago. Yes, we were writing SPARQL, we were using OWL, etc. Back then some of my coworkers thought it would be cool to hear someone talk about those topics. I tried to convince them that instead of listening to others, we have the experience and we should be the ones up there doing the talking. Alas, that entire group will be in attendance of a talk that they should have been giving last year instead of someone else doing it this year.

In any case, yesterday I went to talks by two legends: Ted Neward and Brian Goetz. I’m sure I don’t need to give either any form of introduction (and if I do, leave my blog now, go do some Googling, learn a bit and come back ;) ). I listened to Brian talk about concurrency and memory models and I heard Ted talk about classloaders and give the keynote called Iconoclasm. I’ll spare you reading many paragraphs. They were all excellent. When you go to a Brian Goetz talk, it’s like being back in college. You have the expert on concurrency and how Java works at a low level geeking out on topics he loves. Even though his topics cover hard stuff, he does them with passion. Ted is just an all around cool guy who is a great speaker and also incredibly knowledgable about languages in general (He also does Microsoft stuff…no one’s perfect). Overall, I was pleased with the sessions yesterday.

With that being said, looking ahead to today, I’m honestly lost. After going through the slides for some talks with potential, they seem to have less potential. We’ll see what happens. As always, let’s hear from you! Questions about sessions or speakers, let me know in the comments!

Agile in the real world part I - The personal card wall

The first item we are going to tackle in the adoption of agile principals is the card wall. What is it? What problem does it solve? How do I get my organization to use it?

Let’s take a step back. How do you currently track the status of a project? Microsoft Project or some related piece of software? Excel (*gasp*)? There are a number of issues with this approach:

  1. Project status is not publicly available.
    When the progress of a project is stored in a software product like Project or Excel, it is easily hidden or is at least difficult to access. This encourages things to be hidden. Things to be changed.
  2. It’s hard to use
    The implementation of project planning is, in essence, a very simple process. It is the alignment of resources and tasks against time (the hard part is the alignment piece). Why do project management tools need to be so complex to essentially display timelines?
  3. Developers can’t take ownership of what they work on.
    Typically when projects are tracked using software products as stated above, they are maintained by a lead or manager cutting the developer out of the process of delegation of tasks.
  4. Collaboration across tasks doesn’t occur.
    Developers don’t use Project. Developers despise Excel. Because of that, they usually don’t look at it. So they don’t get a big picture of the project flow and prevents the implementation of operational efficiencies that could occur with simple reordering of tasks.

Card walls attempt to address the above issues.

Project status is not publicly available

A card wall is the ultimate way to communicate project status to the entire team. You have a wall of cards divided into three or four categories: Ready for development, in development, in QA and in production (with the fourth one optional. There are some other nuance options that you can add in, but we won’t go into that here.). To obtain project status, all a person needs to do is look at the wall. If the card isn’t in the ready for development yet, the story has not yet been written (it’s in the BA’s hands). If it’s in development, typically you’ll have a picture or name associated with the card. This makes it quite clear who is working on the functionality. If it’s in QA, development is complete and it’s being tested. If it’s in production…well, I’ll let you figure that one out.

Project software is hard to use

Well you could go to Excel or Project training and spend thousands of dollars. However, I prefer spending that money on better things, like high quality developers. Instead of paying for licenses for Project and training, etc. Cards are intuitive. People get the card wall. When the BA has completed a story for development, they put a card on the wall with the name of the story. When a developer is prepared for a new story, they choose the card to take and move it into development under their name or picture. When they are complete with the story they turn the story over to QA by moving the card to in QA. Once it moves to production, typically the project manager will move the card to production. Developers don’t need to worry tabout what drive the Project file is on or if someone else is in the Excel file. Cards, scotch tape and a wall. If you can’t figure that out, you probably can’t write the code to implement it anyways.

Developers can’t take ownership of what they work on

This is one of the most important in my opinion. The traditional way to assign tasks was exactly that. A project manager assigned tasks to developers and they worked on them. However, which are you more likely to work your hardest on:

  • A list of things your spouse gives you to do.
  • Something on the list that you created that needs to be done.

You are more likely to put your all into things you choose. By allowing developers to work on things that they choose as they complete tasks empowers them to learn more about the application. This prevents the funnel problem. The funnel problem is when there is one person that knows how to work on a particular part of a system. Developers tend to spread their knowledge around the application which benefits everyone. Finally, there is an empowering psychological event that occurs when someone take a card they were working on and moves it. The job well done. The beginning of a new endeavor. We don’t experience this enough at work and this is a simple way to do so.

Collaboration across tasks doesn’t occur

I consider this reason a tie with the previous one with regards to importance. When we use Project or Excel or most other project management tools, the people in the trenches loose site of the big picture. If you are a project manager that is working on a project that is expected to last a year with 30 developers, you may pass out copies of the project plan to each developer. But what I’ve seen in most cases is that project managers pass out the piece of the task list that pertains to the person you are giving it to. By doing this, blinders are being put on the team with each person being forced to focus on their own small corner of the world. But what if developer A worked on something that developer B will be working on in two weeks and developer A knows that he had to do something unusual to get things to work. If he knows that B is going to be working in his old code, he can share the knowledge he gained when working on it the first time. This cross task collaboration has huge productivity benefits that should not be ignored.

So how do I do it where I work?

So now that you have an understanding on why you would want to use a card wall, how do you get one past the IKEA Police on your team? You don’t have a wall you are allowed to use. You don’t run the project so you can’t get others to maintain cards. As with anything in life, work with what you can control. In this case, you can control how you work.

A little background. I work for a large IT organization (about 1000 employees out of about 2000 total for the company) in a very old school, risk adverse company. Until very recently the word Agile might as well have been a four letter word. It was crazyness. I work in a cube. The typical cubical with a desk on two sides, a tall cabinent for hanging my jacket and a cabinet above my desk along one side.

So with Agile and any of it’s practices viewed as insanity, I decided to change what I could and that was how I worked. I had a list of tasks that I knew I had to complete. I purchased a deck of index cards and setup a makeshift card wall on the doors of the over desk cabinet. Since I was the only person the cards were for, I didn’t need a large amount of real-estate. I put my tasks into the ready for dev section. The card I was working on moved to the in dev section and any cards I completed were moved to complete.

So I worked like this for the life of a three month project. It didn’t take long for managers to notice the wall of index cards hanging in my cube. Some of my co workers made fun (I was out of the office one day due to food poisoning….I came back to a card in the complete section that said “food poisoning”). Managers, however noticed. Anytime they asked what my status was, I directed them to my card wall. I made sure to point out that any time they wanted to know exactly where I was on the project, all they had to do was take a look. You know what happened? They stopped asking.

They stopped asking me what I was working on or where I was on something because they already knew. They knew how fast I was moving cards, they knew how many and which cards I had moved. They knew exactly where the project was in a glance.

The manager I directly report to loved the idea. We started expanding it by creating a tech debt wall. Now, I have to come clean here. We still are not 100% past the IKEA Police. Our building operations staff still doesn’t want the cards to be visible in the office. So instead of putting them on a wall, we have ours on a window. In fact, if you stand outside our building and look up, you can see my boss’s cube because the window in his cube is covered in index cards.

From the tech debt wall, we have finally expanded it to full project management. The project I am currently working on is scheduled to go live in April. The card wall is not the only reason for this success, but it has contributed to it, but we are months ahead of schedule. Many months (5 to be exact). The agile principals discussed here and what I will covered in the future posts are the primary reason for that.


So that’s it. Over this post, I covered why a card wall is useful for project management as well as how I took a small amount of rebellion and harassment and proved that it can be a very valuable resource management tool. What are your experiences with card walls? Do you have your own version of the IKEA Police? Share your experiences in the comments!

Agile in the real world - Introduction

Agile adoption in the real world. Not many people can fathom walking up to their manager and saying “I want to completely change everything we do about software development. I want to write almost twice as much code as I currently do with no more functionality. I want to pair program. I want to take away cubicles and make everyone work at conference tables. I want to demo what we’ve done for the business every week.” However, in many companies, proposing that you want to begin developing software using Agile processes sounds exactly like what I said. My intent over the next few posts is to show you a way to introduce the concepts of Agile without having to look like the nut job on the team or move mountains.

I’m sure you’re thinking, “Yeah, right. I’ve read tons of those articles before and they work about as well as something I would buy from Billy Mays.” Everything we will talk about over the coming weeks are things I have seen be effective in a large, Fortune 500 corporations. However, before we dive into the specifics, I wanted to spend this post defining what I said we were going to talk about…agile practices in the real world.

“Agile practices”. That means paired programming and writing on the walls and stuff, right? Wrong. For this blog, agile stands for four main principals (from the Agile Manifesto):

  • Individuals and interactions over process and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

This blog will discuss how to implement the above four tenants in a large corporation.

“in the real world”. This means that the CIO has not come down from on high and decreed that agile is the new required practice and all projects shall be agile going forward. This rarely happens (and would make adoption much more easy) so let’s assume it hasn’t happened for you (if it had, you wouldn’t be reading this anyways). No, instead we are going to assume that you, Joe dev or other lower level employee can see where agile can be useful and want to apply it to make your life and your customer’s lives better.

I have gone both routes. I have had buy in from the very top and I’ve had management that disdained the word “agile” much less supported a test project. In both cases, you can be successful with agile. I’ve also seen the same approaches fail horribly because those implementing the process didn’t know the why behind what they were implementing. I will be sure to cover this as well. Please note, implementing practices without knowing why you are implementing them is a recipe for disaster. Any practice you implement should start with “What problem is this change attempting to solve?”.

A word of caution. Change the way I will describe is slow. However, with each step, the next becomes easier. I look forward to sharing my experiences with you. I also look forward to the comments you leave.

COBOL Flashbacks

Ahhh, COBOL. So for those of you who don’t know me personally, I went to Northern Illinois University for my undergrad. NIU is a mainframe school. Yes, I spent most of my days sitting in front of a PC running MVS Batch submitting COBOL and Assembler jobs to the school mainframe (as a side note, my first programming language was mainframe Assembler at College of DuPage).

I’m currently working on a project to move batch processing from the mainframe to Java. I’m actually very excited about it. We’re playing with some very cool technologies (Spring Batch, Terracotta for some grid computing, etc). However, I currently am a bit ahead of schedule so I don’t have specs (*gasp). Since I spent my former years working in COBOL (including my internship at ComEd), I asked for the program that I will be converting first so I could sift through it myself. 303 dead trees later, I have alot of reading ahead of myself.

Printing out the program made me a bit nostalgic for the days of college so I did some quick Googling to see if they still use MVS Batch. They do and I found the documentation for it. Very impressive. It starts with turning on the computer! Check it out: http://www.cs.niu.edu/mvs/mvsbat.html.

Apache Struts 2 Web Application Development is out!

Struts 2I am pleased to announce that the book I was a reviewer for, Apache Struts 2 Web Application Development by Dave Newton is finally out! It is available on amazon here: http://www.amazon.com. Published by Packt Publishing, it is a good overview of the Struts 2 web framework. One thing that Dave did better than any author of other web framework books I’ve read is the coverage of JavaScript. He covers JavaScript very thuroughly. Not only covering what the framework provides (which actually isn’t much) but core JavaScript concepts and jQuery. Overall, this is a solid Struts 2 book with the advantage of being a good JavaScript book. I encourage you to check it out!


    Twitter Button from twitbuttons.com