2015-10-20
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.
2015-09-27
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.
2015-08-02
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.
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.
2015-08-01
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
2015-07-18
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.