Wednesday, December 31, 2008

Mass Zune Failure, Welcome To The Social

Gizmodo is reporting that many, if not all, of the 30 GB Zunes failed at one time. 

A software glitch is suspected, but further details are not known at this time.

Tuesday, December 23, 2008

Question for people in Operations: Does Remote System Administration Require All of That System's Resources?

It seems like every time I work with a computer that has remote system administration that the remote admin tools sporradically consume all of the system's resources.

I've had some trouble lately with my current system. We suspect that the remote administration software is to blame. It's a hard case to crack. It's not as bad as the system at my last gig, that would freeze up for 5 minutes at a time. 

It's understandable that this software makes system administration a less labor intensive way of managing computers. However, if a side effect of the software is the users are unable to use their computers to work, doesn't that lessen the value of the computer? If the computer is less valuable, doesn't that really decrease the value that operations adds?

I'd like to know whether this is a configuration issue, or if it's a problem endemic with remote system mangement software. I think a really big problem with remote administration is the people who have the power to adjust the systems aren't the ones who depend on them to do their own work.

Appropriate Holiday

I'd like to share the words of a friend from college, Tim Gleason, and wish everyone an appropriate holiday.

Monday, December 22, 2008

Am I the only person who doesn't trust an IDE for Source Control?

My current assignment uses Eclipse as the blessed IDE. Nothing new there, it works pretty well and it fits the budgetary constraints, i.e., it's free.

The team also use Eclipse's source control tools to manage source control, e.g. commits, updates, merges, and branches. I'm not such a huge fan of this. I prefer to keep some separation between the development tools and the source control tools.

For performing simple source control operations like updates, and simple commits I think that Eclipse is a perfectly capable tool.

For anything more, though, I prefer to keep my source control tools separate. As a source control interface, I just don't think that eclipse is that great. I don't think that it can be. It's a heavyweight Java application that is designed for developing Java projects.

Eclipse does get the job done, but it doesn't do it as well as other clients. Many of the available specialized tools require only a fraction of the computing power to run than Eclipse and they just do the job better. I also like the fact that most of the source code client allow their users to use their favorite diff tool instead of forcing users to use their own diff and merge tools.

Usability is a big concern. I prefer having a separate source control tool from my development environment because I trust source control tools more than I trust my development environment's ability to manage source control functionality. Eclipse, even in the Team Synchronization perspective, isn't as good at managing files as tools that are made solely for the purpose of managing files. I'll take a command line or Windows Explorer over a file viewer in Eclipse because the command line and Windows Explorer aren't trying to present anything beyond the files to me.  When it comes time to dealing with source control, I only want to know about files, versions, mod dates, etc. 

Finally, I like having separate tools as a final set of checks and balances. Ideally, I prefer to review my changes before I commit them. I'd rather do that with tools other than the ones that I use to edit those files. In a way it preserves the principle of orthogonality. Developing files on a local system and submitting changes to a centralized repository are tasks that are different enough that they deserve different tools. The chances of unintended side effects are much greater when you create a tool gap between their actions.

I find that even viewing the files in a different tool and from a different perspective gives me the ability to review my changes from a clean perspective and potentially catch mistakes before they move to the source control repository.

That's my opinion for commits. If I'm going to branch and/or merge a repository, I'd much rather do it outside of Eclipse. The performance of other tools out there is much better than Eclipse's. Consider the reputation that branching/merging can be one of the most trouble prone actions in source control management, doesn't it make sense to use the best tools for the job. I've had just enough trouble with Eclipse to cast enough doubt whether it's doing what I want it to that I trust other tools more.

Tuesday, December 16, 2008

Profiling Jboss: What I Ended Up Doing

Someone suggested I try using Netbeans' performance profiler. I gave it a shot and it got the job done. 

Netbeans' profiler was able to hook into my JBoss server, that was running through Eclipse. I thought the profiler wizard setup was helpful. It asks a few questions and produces a line to paste into the to-be-profiled-application's configuration. 

That's all there really is to it. There are a few options about filtering methods and what types of profiling, e.g., memory, threads, CPU timing, etc. 

The results we found were about what we expected. It was a good exercise to refamiliarize myself with a profiler though.

Sunday, December 14, 2008

Wikipedia's List of Common Misconceptions

This is a sweet list of common misconceptions. 
It's like every piece of unsubstantiated trivia that I thought was true is dispelled all at once.
Become enlightened and enjoy!

Friday, December 12, 2008

Java/JBoss Performance Profiler Dilemma--any good free ones?

We're at that stage in our project when we're considering the performance of our application. We believe that it could be better, but we don't have a good set of data to point to bottlenecks. One of the reasons we don't have this data is because we aren't using a performance profiling tool. We aren't using a performance profiling tool because we aren't aware of on ethat works with our application server, JBoss, that fits our budgetary constraints, i.e. free.

At one of the discussions during the fall Twin Cities No Fluff Just Stuff Software Symposium an attendee asked the expert panel and the room if anyone is using an open source performance profiler and no hands were raised. This was a group of over 300 software professionals in the region and 10 expert developers and nobody could recommend an open source profiler, and there were no outstanding recommendations for any of the commercial profilers eaither.

When we look for performance profiling tools that fit that description they're either commercial and over $500, too steep for a personal license and we don't have time to evaluate competing profilers to put a proposal together for our client to buy licenses.

I've used JProbe and Optimizeit in the past, they've produced valuable data. Most of the projects I'm on though don't have commercial profilers available.

I would think that there would be an open source profiling tool available. I thought that Java 1.5 was supposed to have features that would make getting performance information easier and someone would have taken advantage of that.

If anyone has any recommendations for profilers free or otherwise, I'd love to hear them.

Thursday, December 11, 2008

I actually want the LHC people to create a little black hole

There was quite a ruckus a few months ago when the Large Hadron Collider was going online. One of the concerns is that the collider may create a black hole on earth. They say that like it's a bad thing. Sure, there is the possibility that this little black hole will consume the entirety of the planet into a space no bigger than an atom along with the rest of the solar system. Yeah, that may not be the most considerate thing we can do as a planet, but let me throw out this possibility.

What if we were able to make the black hole consume only the things we want? How cool would that be? We would have a great waste disposal solution. Yucca Mountain? Why not just put a little black hole down there? Not only can you store all of our nuclear waste in a space that is no bigger than a pinhead, we wouldn't need to worry about any radiation shielding, the black hole waste disposal unit will keep radiation and light from escaping. That's pretty sweet!

Industrial waste is another problem that a little black hole could address. Our friends the manufacturers could become good stewards of the land by disposing of their waste in a little black hole instead of dumping chemicals and other harmful waste on the sly.

The possibilities don't stop there! We could potentially put one of these in every household. You think those fancy Dyson vacuum cleaners don't lose suction? You remember the old vacuum cleaner ad where the vacuum picks up a bowling ball? They don't have nothin' on the sucking power of a little black hole. In some regards, I think a black hole vacuum would be safer than our current models. There's no risk of electrical shock. You also don't need to worry about whether it's safe to use it on combustible liquids like gasoline. Even if there were an explosion, it would all get sucked into the abysmal void of the black hole vacuum.

I would be remiss if I didn't address some of the consumer safety issues that exist with distributing appliances that have the potential of consuming our entire galaxy should they be misused. Yes that is a problem. I'm willing to concede that. But is it any different than say electrical appliances were when they were introduced? They have the potential to electrocute and start fires, but we've learned to use them responsibly. Our automobiles carry enough gasoline to start a small explosion and nobody seems to be upset with that. So I say, what's the danger of putting the power of ripping the fabric of reality in the hands of every man, woman, and child?

Let's be honest. This wouldn't be the safest appliance on the market. I think we'd need a good set of warnings so people are aware that their little black hole might consume everyone. We would need to establish a public service announcement campaign to alert the public what to do should one of the little black holes get out of control. Something like, "Should you or a member of your family notice a slowing of observable reality, please head to the nearest black hole shelter, tune in to the Emergency Broadcast System, and await further instruction."

Another great thing about little black holes is they are perishable. They will evaporate into a cloud of neutrons, thermal radiation, protons, and electrons once they expire. This will drum up a lot of repeat business and set up a loyal customer base. We used to need to engineer small defects in our products to get our customers to come back shopping, the little black hole solves that problem for us.

So, in conclusion, scientists, please do try to create a black hole, but make it so that it doesn't consume our entire galaxy into the space of a subatomic particle.

Wednesday, December 10, 2008

Productivity Tip: Fail Quickly, Succeed Quickly

Ugh, I'm in a bad spot. We're shoring up a release and I'm helping our testers with their regression tests. We're now running all the old test cases from the earlier iterations. Expectedly, some of the older test cases are failing. My job is to provide some explanations as to why the test cases are failing. It's been going well, until today.

I hit a really bad set of tests. The thing about these tests is they take a long time to run and a long time to fail. Oh, they're brimming with NullPointerExceptions that are caused by some bad assumptions that were made about 6 months ago. Fixing the NPEs is no big deal, but finding them is taking progressively longer. When I started this morning I could get to the next NPE in a few minutes. Now we're taking a good 20 minutes. I think the whole test case should take about 25 minutes to run, so we can't be too far away.

The good news, we have excellent coverage of all our test cases. The bad news, when I start a test case I have a 15+ minute void of time where I'm waiting for the next thing to do. I'm filling the void by helping my teammates with their issues, but the voids remind me of a dangerous programming rut I've found--time voids.

Time voids are the things that regularly block a programmer from doing their work. The most dangerous ones to me are development environments that take a long time to set up and require frequent setups.

When I do development I try to iterate through a cycle of setting up a test case for what I want to do, validate that the test case doesn't currently work, writing just enough code to get the case to work, and then validating that it works.

Time voids come in when a workstation takes a long time to perform one of those steps, usually it happens when an environment is being rebuilt or a server is starting up.

Ideally, I'd love to have those necessary delays take a few seconds. Unfortunately, there are times when those delays are minutes if not tens of minutes. That's a productivity killer. The biggest problem with a regular delay is everything you do becomes very expensive. Trying out an idea doesn't take a couple of minutes, instead it might be half an hour. It might cost a day.

What do you do in the time when you're waiting for your system to catch up? You can wipe out your administrative work, clean up your documentation, read documentation, work with others. Probably the best thing you could do is figure out how to eliminate the time voids and get to an environment where failure comes quickly.

Ah, nothing prepares the pallet for the taste of success like the sweet smell of swift failure.

2 Types of Java Programmers

A friend of mine posited a theory that there are two types of programmers in the world: those who can't handle multi-threading and those who are unaware that they can't handle multi-threading.

Dale Mensch has asked that I not mention his name so I will credit this basket of wisdom to anonymous.

Thursday, December 4, 2008

Productivity Tip Trip Report: Close Your Email

I've been field testing some methods to improve my personal productivity. The first method I tried is closing my formerly ubiquitous gmail window. Those readers who know me know that they could expect to get a response from me in email within a minute. To say that I obsessively checked my email is understating a borderline compulsive disorder.

I don't keep the window open anymore. Instead, I check my gmail a few times a day at the office. In the morning before work, around lunch time, and before I leave the office. At home, I sporadically check my email.

I further enabled my compulsion by carrying an iPhone. It's wonderful how easily I could check my mail wherever I am. While I'm working, I keep the iPhone stowed.

The results: big boost in productivity and more focus on whatever I'm doing. The gmail siren isn't calling me away from the task at hand. The signal to noise ratio I get for emails is about 1:4, for every one email I get that is meaningful I get four meaningless emails that immediately get deleted. Of those signal emails, almost none of them require my immediate attention, nor do they lose any significant value if I take a few hours to read them in bunches.

Another side effect of not having the window open is my friends and I don't chat. I enjoy chatting with them, but keeping a few conversations going takes a lot of attention.

The last benefit of keeping the personal email client closed is removing a source of context switching. Context switching is expensive. By controlling and planning my contact with my email I don't run the risk of losing my train of thought or deviating from my tasks at work.

Wednesday, December 3, 2008

Cool Regex Tool: strfriend

strfriend is an awesome tool for visualizing regular expressions.



I've noticed that regexes are a tragically underused resource among my fellow Java programmers. Regular Expressions are an incredible resource for dealing with text.

If you're interested in learning how to use regular expressions, I unconditionally recommend reading Mastering Regular Expressions by Jeffrey Friedl.