It’s been a while since I posted a new tutorial so I figured I was overdue. This tutorial is on Prototype’s lesser used $$() function (yes that is not a typo, it really is a double dollar sign) and CSS selectors. The combination of these two tools can lead to some very powerful results and much cleaner markup than putting id= all over the place. Check out this new tutorail here: http://www.michaelminella.com/javascript/css-selectors-and-prototype.html. Let me know what you think in the comments!

Well, it’s finally here! The JUnit and EasyMock Refcard is available at DZone. You can download it here: http://refcardz.dzone.com/refcardz/junit-and-easymock. This Refcard covers JUnit and EasyMock in detail, both in concept and at the API level. If you have never used JUnit or EasyMock or are seasoned veterans with them both, this card should be a valuable tool for you to refer to when writing unit tests. I wanted to take a minute to thank Jill Tomich for her help threw the process. This is my first formally published work and she was a big help! Let me know what you think of the new Refcard in the comments!

If you have followed my blog, you know that I am in favor of H1-B visas (my previous post on the topic is here). For those who are unfamiliar, they are visas provided by the US government to allow skilled workers to work in the US for between three and six years (learn more about H1-B’s here). Today Business Week is reporting on a report from the U.S. Citizenship & Immigration Services (USCIS) saying that 13% of all H1-B applications are fraudulent and another 7% have “technical violations”. This “news” should come as a surprise to no one.

Why should this not be a surprise? When you have software engineers that make an average of $700 a month in their home country, compared to an average of $5,000 in the US, basic math tells you that you can pay the guy from overseas double, let him take twice as long and still come out ahead by a large margin. Tie hands of regulators to investigate abuses and you have a system that is begging to be abused.

Now the H1-B program has rules to protect both US workers and recipients of H1-B’s. According to the law companies are required to pay the “prevailing wage” for the worker. However, the U.S. General Accounting Office has pointed out that the enforcement of these rules is difficult at best (see the report from the US GAO here). In the report, it points out that the Department of Labor (DOL) has only limited abilities to investigate abuses in the H1-B visa program. For example, the DOL can only question certain documentation for only for “completeness and obvious inaccuracies” and is unable to question anything else, regardless what it is. However, when a claim is made that starts an investigation, the likelihood of a violation being found is astronomically high (ranging from 75% to 92%).

The above is just one example of how the system is set up to fail. Fortunately, action is on it’s slow way through Congress. There is currently a bill sponsored by Sen. Richard Durbin [D, IL], Sen. Charles Grassley [R, IA] and Sen. Bernard Sanders [I, VT] in the Senate that is attempting to close the loopholes discussed above (see the full text of the bill here). This bill allows for the DOL to initiate investigations into H1-B issues as well as increases penalties for violations under the law. Unfortunately, it doesn’t seem to be high on anyone’s priority list given the election year.

I am a supporter of H1-B visas because they help fill an important talent void in the US. However, without loopholes being filled and the ability to enforce the law given the the appropriate parties, the system that was meant to keep the US competitive in the global economy and a leader in innovation will only serve as a program for companies to get cheap labor.

What are your thoughts on H1-B’s? Do you have an H1-B? Share your thoughts or experiences with H1-B’s in the comments.

WindySphere is the Chicago chapter of IBM’s WebSphere® user’s group. Meetings are held quarterly except summers and allow for people to get together, network and learn about what is happening in the Java and WebSphere spaces. Sessions are usually held that cover a variety of topics including Java development, Rational tools and WebSphere products.

I will be speaking at the upcoming meeting in October on JUnit and EasyMock. This is a precursor for the upcoming release of my Refcard (which is officially scheduled on http://refcardz.dzone.com). The rest of the agenda is still being worked out but should be finalized shortly (I’ll post to let you know when that occurs). I look forward to seeing many of you there!

Well life has been pretty busy as of late and is only getting more so. I have received the rough draft of my JUnit and EasyMock Refcard and am preparing to turn in my comments later today. For those who are not famaliar with the DZone Refcards, they are “Cheatsheets for Developers”. What I compare them to is the reference cards you find in bookstores on things like Calculus, Physics, Biology, etc. The one I have written is an introduction to JUnit and EasyMock. That is the first piece of writing I will have actually published, so to see my name in print is pretty weird. It is currently scheduled to be out November 3rd.

I also have agreed to be a technical reviewer for a book. I will be one of the reviewers for an upcoming book from Packt Publishing (the ones with the black and orange covers) on Struts 2 and Agile development. Judging from the outline, it looks like a good overview of the Agile process using Struts 2 for a web framework. I’m excited to be a part of that project. That book should be in bookstores sometime in November.

Finally, in association with my Refcard, I will be speaking at the October meeting of WindySphere. For those of you who are IBM WebSphere users, you may have heard of this group. WindySphere is a Chicago based group that focuses on Java and IBM products (WebSphere Application Server, WebSphere MQ, etc). I will be giving an introduction to JUnit and EasyMock. I will post a more detailed post on Monday about the details of this event.

There are many IT conferences out there. Some have the glitz and glamor of Apple’s Worldwide Developer’s Conference. Some have every vendor for a particular space like Java One or any of the Microsoft conferences. In my opinion, however, there is no better conference for learning new skills that you can use the following Monday than No Fluff Just Stuff (NFJS). I will be attending it in Chicago for the third year in a row this year and I can’t wait.

For those of you who have never been to a NFJS, it is a two and a half day conference (Friday afternoon threw Sunday) that is held in a number of locations around the country. They routinely bring the best of the best to these conferences. Think of your favorite IT author and there is a good shot at meeting him there. And yes, I said meet. The speakers are very open and available during the show. Want to talk with Neal Ford? Say hi to him in the halls. Have a question for Scott Davis? Ask him at lunch.

This is a conference I truly look forward to each year and this is no exception. Even if I come back and use nothing I learn right away. The extra tools this conference gives me makes me a better developer because I can make more informed decisions about the problems I face day to day.

Has anyone been to a NFJS this year? Is anyone planning on going to the Chicago one in November? If so, let me know in the comments!

Pardon the rant. I have recently been exposed to the build processes of a number of projects both internal and external (open source) and I am frustrated. When I download a software project and see a build.xml file in the root of the project, it is my assumption that I should be able to go to a command line, type ant from the appropriate directory and something should happen successfully. However, lately I seem to see more projects where that doesn’t happen.

The reason for this is that these build processes are written in a way that they depend on things external to the project. I can understand that if there are documented inter-project dependencies. That makes sense. What I don’t understand is when a project’s build process is dependent on a particular IDE. I realize that Eclipse has a large collection of plugins in it and within that labyrinth of directories just about any well known open source project’s jar files can be found. However, what about the people that don’t have your particular plugins installed or (gasp) they are using a different IDE (InteliJ perhaps)?

In an enterprise I can imagine the argument that since everyone in the enterprise uses the same IDE, it’s safe. However, that ties you into not only an IDE but potentially a version of IDE or plugin. This is not an ideal state. And for open source projects, there is no excuse. Build processes should be self contained. Open source has no control over the environments of their developers and so the projects should be structured as such.

So, please, if you are creating a build process for your project. Make it self contained. Please? Let’s hear how your build process pet peeves in the comments!

Superman is cool. Growing up, everyone wants to be like him. He can fly. He is super strong. He can fix anything, even the threat of nuclear war! In Hollywood, Superman is cool.

Unfortunately, in the software development world, Superman is not so cool. Being a “hero” in the our world usually means that something went wrong and someone stepped up to fix it. My issue isn’t with the person who steps up and fixes the problem. We all end up being the hero from time to time. My issue is with cultures that reward heroic behavior at the peril of behaviors that would prevent issues in the first place.

Take for example unit testing. I have worked in a number of software shops that either frown on or just don’t do automated unit testing. I’ve heard all the standard reasons not to: It takes too much time, why write more code to test your code, etc. In their eyes, unit testing is clicking around with a browser (in the case with a web application). When things end up breaking in production or in any other inopportune time, the hero comes to the rescue, fixes the issue and is praised for saving the day. In this example the issue is a symptom, not the true problem and unfortunately by rewarding the hero the underlying problem goes unfixed. The cycle continues.

A better solution would be to incorporate a retrospective. In the retrospective, the team can discuss what happened, why it happened and how to prevent it in the future. Action items can be assigned to address the true issue (automated unit testing in this case) and the hero is not needed as much.

I once worked for a manager who told me that he wanted to work on a team where “everyone was willing to be a hero”. My response was “I want to work on a team that doesn’t need heroes”. The goal shouldn’t be to be a hero. That only works in Hollywood. The goal should be to prevent their need in the first place. What are your thoughts on heroes? Let’s hear it in the comments!

Well, I have finally submitted my rough draft of the JUnit and EasyMock Refcard. Now their graphic designers work their mojo to make it look good and I’ll approve it from there. I’ll keep you posted on a release date as soon as I know when (I’m guessing sometime in the fourth quarter of this year).

The next two weeks, posting here will be sparce. I am leaving on a cruise Labor Day weekend for a week so I will be enjoying my disconnected life for that week. Once I get back, I will be starting on a few new tutorials on Spring Batch. For those of you who are unfamiliar with it, Spring Batch is a module of the Spring framework family that provides a robust framework for batch processing. Stay tuned (I am hoping to have an overview of the framework complete shortly once I get back from my cruise).

I was just reading a blog posting today entitled “I’m Not Technical” (you can find the original post here). In this entry, the author (Mike Brannan) talks about a scenario we have all heard before. Someone in IT saying “I’m not technical” to set the appropriate expectations.

I believe that it is OK to say that you are not technical if you work in the IT field. Not everyone in IT is a programmer. One of the best project managers I ever worked under was openly not technical. However she gave her technical resources the trust to do their technical jobs to the best of their ability. As a developer under her, I respected her more for being honest in her technical abilities and for putting the right people around her to give her the information she needed to make the appropriate decisions.

The post continues to say that it would be better for the person to learn to fill in those technical gaps. Once again, this depends. If you are a manager, I believe your time would be better spent on growth growing your managerial skills. Does learning Java make you a better manager of Java resources? I doubt it. What does make you a better manager are soft or people skills.

I am a technical guy. However, I use the strengths I have that are applicable to my role to help the project succeed. If I am developing, I use my technical skills; if I am leading or mentoring, I use those skills. What are your thoughts. Is it OK not to be technical in IT? Let everyone know in the comments.