Quickly change the case of file suffixes

for f in *.JPG; do mv $f `basename $f .JPG`.jpg; done;

Be careful to run this command in the directory containing the files.

Collective Stupidity

Thought this was quite funny article on the problems of decision-making in large groups.

Collective Stupidity

The natural tendency may be just to make decisions that are acceptable and least-common-denominator; decisions that no one disagrees with -- because it's easier and less contentious. But this doesn't seem to be the path to success.

The company that avoids collective stupidity is a statistical anomaly. Something about the way we do and think about decisions -- something so fundamental that we do it below the threshold of consciousness -- builds in this inevitable tendency towards the non-innovative, non-creative, non-fun organization.

Change management for databases

Automation for the people: Hands-free database migration

Databases are often out of sync with the applications they support, and getting the database and data into a known state is a significant challenge to manage. In this installment of Automation for the people, automation expert Paul Duvall demonstrates how the open source LiquiBase database-migration tool can reduce the pain of managing the constant of change with databases and applications.

Floating Point Math in Bash

Floating Point Math in Bash | Linux Journal

Object State

Tim Boudreau's Blog: Where's the state?

Where's the state? This is a small but useful question when deciding how a problem domain gets carved up into objects: What things have state? What things have values that can change? When and how can they change? Can the changes be observed? Who needs to observe changes in state?

Any time you find yourself writing a setter (or more generally, mutator) method, it is worth asking yourself Who does this piece of state really belong to? Am I putting state in the right place? Blindly following the beans pattern (add a getter/setter to whatever type you happen to be editing) can result in state being distributed all over objects in an application. The result will be harder to maintain, and if it has any lifespan, less and less maintainable over time. Like entropy, or the no broken windows theory, the more state is distributed all over the place, the more that will masquerade as design and make it okay for a programmer to further diffuse state throughout objects in the application. Human beings can only hold so many things in their minds at a time. The more state is diffused, the more things someone must pay attention to simultaneously to solve a problem in that code.

Another question above was Who needs to observe changes in state? There are some corollaries: Where should those changes be published? and Does the thing observing the change need a reference to the thing that changed?

While rare, the listener pattern is prone to ordering bugs which are quite painful to reproduce and fix. Additionally, in my experience, listeners are the most potent source of memory leaks in Swing applications. So it is a pattern to avoid unless you know you really need it.

Java wishlist - generics done properly, without erasure

I like generics alot, but the current implementation can be very frustrating at times, due to erasure. The are many instances where I wish I could refer to the "generic type" and use it to create an array of that type.