Alexander Mikhailian

A project manager plays with two major forces: Chaos and Freedom. When a project starts, nothing is clear, the previous stages like business analysis and user requirements collection have likely been a complete failure and collected input won't help much the team and the manager. At this point, the manager has to control the Chaos and reduce it to the minimum, by creating an environment where everyone know exactly what to do, how to do it and how much time would it take.

So he starts to plan, as the work moves on. The days roll out, and he slowly realizes that there is not much left of the initial planning, and the team is swirling out in different directions. This is where the Freedom control takes precedence. The manager has to give everyone enough Freedom so that every morning employees felt the urge to scratch an itch, while still working in the planned direction.

He slowly realizes that the Chaos/Freedom ratio is unique for each employee, and he has to work out a personal approach to everyone if the wants the team to work at full throttle.

By the time everything is crystal clear in his mind, and all the errors have been consumed and learned from, the project ends, and the manager moves on the next one or bails out.

For many years already, Java developers running Debian ignored the Tomcat bundled with Debian in favor of a manual installation. Nowadays, with the availability of Sun Java 1.5 in Etch, it is time to reconsider this.

Install Tomcat with aptitude install sun-java5-jdk tomcat5 tomcat5-admin tomcat5-webapps.

Edit /etc/default/tomcat5 to change the JAVA_HOME and TOMCAT5_SECURITY environment variables.

JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun
TOMCAT5_SECURITY=no

Note that you should consider reenabling the SecurityManager for production environments.

Now, you may install webapps into /var/lib/tomcat5/webapps and start tomcat with /etc/init.d/tomcat5 start

The folks at debian-administration have shown me the light, once again.

It turns out that enabling a multiuser remote console is much simpler than what I previously thought. Just login, run screen and tell the other(s) to run screen -x while being logged with the same login name.

ActiveRecord has been built straight from the Martin Fowler's Single Table Inheritance design pattern. Period. This is fine for simple applications with that can live with the database design imposed by the application framework.

Once the developer tries to think throughly the database design, he immediately hits the limits of the STI paradigm. Here's an example.

One common method to define a hierarchical relation in Object-Relational Mapping where a child can have only one parent is to put the reference to the parent in the child table. This is a common and very efficient way to map a class hierarchy into database tables in Hibernate, for instance. The resulting tables can then look as follows:

CREATE TABLE `foos` (
  `id` int(11) NOT NULL auto_increment,
  PRIMARY KEY  (`id`)
);
CREATE TABLE `bars` (
  `id` int(11) NOT NULL auto_increment,
  `foo_id` int(11) NOT NULL,
  PRIMARY KEY  (`id`)
);
CREATE TABLE `bazs` (
  `id` int(11) NOT NULL auto_increment,
  `foo_id` int(11) NOT NULL,
  PRIMARY KEY  (`id`)
);

Note that this table structure allows to efficiently retrieve bars and bazs from foos, as well as ascend to foos from bars and bazs.

If you are bound to ActiveRecord, it imposes a solution with one table having one additional id to identify the parent and a string to identify the type of the child. All fields belonging to bars and bazs will appear in the same table, intermixed.

Nearly everyone gets one surprisingly small monthly pay during his 1st year or so in a company.

In order to understand what happens, one has to know that workers earn their holidays this year for the next year. Once someone quits an employer, he gets a nifty paycheck which includes the monetization of the earned holidays that the employee did not take, yet. Now, once he decides to spend those holidays next year, he usually forgets that they have already been paid by the previous employer. That is, he actually takes an "unpaid" holiday from his current employer, instead of a paid one. Naturally, these days have already been paid before, but who cares, when the money is gone ;-)

All this is a prelude. Here is a nasty trick that makes the payslip look awfully unjustified.

The general rule is to adjust the monthly salary to take into account those "unpaid" holiday days not on a month-by-month basis, but once in a year, the month when the employee has taken more than 50% of the amount of the days off he was entitled to take.

Here's an example. You leave your old employer on December, 31. Next year, you take 5 days off during the first half of the year and then leave on vacation for 10 working days in August. Suppose this August had 20 working days. By the end of August, you will receive your salary for ~ 5 working days, as the salary calculation this month will take into account all the 15 "unpaid" days you have taken off so far.