Dungeon is Using Checkstyle

Dungeon has had a style guide for some time now. However, it was not enforced by anything other than human reading. Even if my IDEA settings were very compliant and I followed them scrupulously, I got nothing more than warnings.

In search of higher code quality, I decided to start using Checkstyle. I cannot use its latest version as it requires Java 7, and I want Dungeon to be compatible Java 6. The worst part is that the CustomImportOrder module only checks import sorting according to ASCII order instead of case-insensitive alphabetical order after version 6.5. Unfortunately, as I am using Checkstyle 6.2, I have no choice but to disable the aforementioned rule.

Not only I discovered Dungeon had about one hundred Checkstyle violations, Checkstyle made me write some important Javadoc for public methods whose purpose was not obvious to me.

Why does this matter? It is common sense that standardization of source code increases its readability and makes it substantially easier to spot problems.

Dungeon source quality is increasing, and seeing this happening is pretty fulfilling. I think I will try to introduce other checkers in the future, maybe FindBugs and a spell checker. In the end, typos in a text-based game are the equivalent of visual glitches in games that rely heavily on graphics.


This is a short post about what I learned from reading PeopleWare for the first time. Although I am not a manager I enjoyed the book and would suggest it for any software engineer that has not read it yet.

Overtime is almost never a good idea. Many managers know this but still make people work overtime as to shield themselves of the blame when a project with impossible deadlines inevitably is not finished on time.

You cannot control people, your job is simply to orient them in the right direction, clear the way and let them run. If you have the right people, the job will be finished. If you do not, you need to find the right people.

A good manager should be able to single out the ones who have the proper mix of perspective and maturity and then turn them loose.

Although good sense and order are desirable components of our workday, there should also be a place for adventure, silliness, and small amounts of constructive disorder.

Motivational accessories do harm in healthy organizations. They are but an attempt to make up for bad management.

Excessive internal competition in the same team is dangerous and increases the chance of the team as a whole to fail.

The fundamental response to change is emotional, not logical. Do not ever demean the old ways. Instead, celebrate the old as a way to help change happen. I consider this true in many places other than the workplace.

You should avoid downsizing. Companies that downsize are admitting that their management has blown it. There is a huge cost related to getting new employees up to speed that should always be taken into account before laying someone off. It is fundamental to recognize the importance of investment in human capital when it comes to knowledge workers.

What an organization learns from experiences is bound to the people that work there. Usually the learning centers of organizations are the middle management, which is severely affected by downsizings. For learning to take place, middle managers must be able to communicate with each other.

A manager should never waste people’s time. Only convoke meetings with more than one person if these people must interact with each other. Any regular meeting is suspect as likely to have a ceremonial purpose rather than a goal of consensus. Ceremonies at project milestones or for celebrating good work done by the developers are not a waste of time.

It is very common to projects to be overstaffed, mainly at the analysis and design phases.

Modern cities do not provide us with a sense of community; therefore building a community at your workspace is a great idea.

How 1080p and 1080i Differ

A few days ago I found myself talking to a colleague about the differences between 1080p and 1080i. Inspired by that conversation, I have decided to write about these differences.

Note beforehand that both these resolutions have 1080 horizontal lines. 1080p is a frame-based (or progressive-scan) video where the frame rate is expressed in terms of frames per second. 1080i is a field- based (or interlaced-scan) video whose frame rate is expressed in terms of fields per second. In this context, a field is either all the odd lines of a frame or all its even lines.

1080p most common frame rates are 24, 25, and 29.97 frames per second while 1080i most common field rates are 50 and 59.94 fields per second. 1080p at 25 frames per second would correspond to 25 full bitmaps of 1920 x 1080 pixels. 1080i at 50 fields per second, on the other hand, represent 50 bitmaps of 1920 x 540 pixels - as if you were shooting 50 pictures per second but storing only half of the bitmaps every time – sometimes you store the odd lines and sometimes the even lines.

There is a lot of difference between 25 full pictures and 50 halves, although common sense may tell you otherwise. These 50 halves are not simply 25 pictures divided in half, but 50 different pictures with half of their content thrown away. Interlacing make mundane operations on frames such as video scaling and rotating, video pausing, screenshot capturing, and reverse playback quite complicated. Video encoding is also more complicated for interlaced video because the codec does not work with full frames.

The biggest downside of 1080p is its substantially lower frame rate, but the deinterlacing problems that may arise from 1080i resolution generally make it a worse choice. Although most TV transmissions are interlaced, plasma and LCD screens are progressively scanned, making a process known as deinterlacing necessary. Bad deinterlacing - likely to occur in very fast-paced scenes - may produce undesired effects such as the one demonstrate by the image below.

Bad deinterlacing

At the end, which combination of frame resolution and scan type you use is a choice that depends on how much you can spend and which options are available. However, I don’t see any reason to opt for 1080i over 1080p if you can freely pick between them.

The Bolt Factory

This is my solution to a problem called The Bolt Factory. The problem statement follows

In a bolt factory, machines A, B, and C manufacture 25%, 35%, and 40% of the total output, and have defective rates of 5%, 4%, and 2%, respectively. A bolt is chosen at random and is found to be defective. What are the probabilities that it was manufactured by each of the three machines?

This is a simple Bayes’ theorem problem. Let P(A), P(B), and P(C) denote the probability of the bolt being produced by A, B, and C, respectively. Let also P(D) indicate the probability of the bolt being defective. I will only calculate the probability of the defective bolt being manufactured by A and B with the theorem as the defective bolt must have been produced by one of the machines and, therefore,

P(A|D) + P(B|D) +  P(C|D) = 1

what makes calculating P(C|D) with the theorem unnecessary.

P(D) will be calculated beforehand to speed things up. By the total probability theorem, it is known that

P(D) = P(D|A)P(A) + P(D|B)P(B) + P(D|C)P(C)
     = (.05)(.25) + (.04)(.35) + (.02)(.4)
     = .0345

P(A|D) = P(D|A)P(A) / P(D) = (.05)(.25) / (.0345) ~= 0.3623
P(B|D) = P(D|B)P(B) / P(D) = (.04)(.35) / (.0345) ~= 0.4058
P(C|D) ~= 1 - 0.3623 - 0.4058 = 0.2319

Why Forbid Object Cloning

These are the reasons why I chose to forbid object cloning:

  • cloning is a risky extralinguistic object creation mechanism;
  • cloning demands adherence to thinly documented conventions;
  • cloning conflicts with the proper use of final fields;
  • cloning throws unnecessary checked exceptions;
  • cloning requires casts.

How cloning conflicts with final fields

Say Foo has a final Bar field. Bar is mutable but the field is final. When cloning Foo, you would need to fix the field by doing:

// ...
Foo clone = (Foo) super.clone();
clone.bar = (Bar) bar.clone(); // Impossible !
return clone;
// ...

which is impossible.