Date set for cfind 0.1.0

The plan is to release cfind 0.1.0 on June, 26.

It will index more file types (including html and pdf), will be more configurable, and will not depend on locate anymore.

Self management - part 0

I have a lot of `part 0' posts in my blog. Every detail tells you something about a person; and I don't like what this detail is saying about me. So it's time to take another look at how I spend my time. (Actually it's not that bad: this article should be the third in a series after this and this.)

I do more in batch mode. I get distracted too easily and in the process of multitasking I lose an enormous amount of time context switching. This is where a PhD will come in handy. It would be a great opportunity to help me focus. One reason is that `work=pleasure' will definitely be more true than it is now. Another reason is that `work=personal development' will also become true. Or at least I sincerely believe so. In the meantime I have to manage as efficiently as possible what I already have. Since I have identified context switching and lack of focus as one of the primary waste baskets of my resources I need to make an effort to correct the situation.

Let's start with a few instances of the problem and specific solutions.

First of all I lose a lot of time on the Internet. It is an ideal environment for context switching. It is as easy as clicking. In fact, almost every link click is a context switch. When a keyword triggers a memory I open a new tab and google for that keyword. Now I have links and browser tabs to help me switch contexts. It becomes so easy to do it that it's hard not to. The Dark side of the Force seduces the weak mind (please indulge me: I have just watched episode 4 of Star Wars).

A solution is to limit the time spent on the Internet. The Internet is a Great resource. One may think I am nuts to cut my access! But no. If I say that I'll use the Internet only a limited time then I'll be forced to look only at stuff that is really useful. So let's sketch a possible schedule.

The main uses of the Internet are:

• communications with other people
• reference source of informations
• bug fixing
• source of problems to solve

For Internet communications I'll use half an hour every two evenings. In that timeframe I will:

1. read email messages addressed directly to me;
2. read mailing lists and forums I watch -- no more than a few at a time;
3. scan the subjects of new mailing lists messages and of new forum threads move the really interesting ones to the `watched' list;
4. read blog posts with interesting subjects.

Anything that does not fit in half an hour is discarded. Notice that instant messaging is not included as a good use of the Internet.

I'll use the Internet as a source of information every Saturday evening for one hour. During the week I'll write down things I intend to search for. After I finish looking these up, if there is time, I will browse for interesting articles (magazine or research). The interesting informations I find will be printed (or saved localy) so that I can read them completely at my own pace during the next week.

Whenever I need to fix a bug (e.g. a gentoo package is not emerged correctly) there is no need to waste time to solve it myself: use the Internet right away. Be careful: this only applies for bugs that involve raw uninteresting work. Some bugs are well worth your time because you learn from the experience of tracking them down. But most of the bugs you will not teach you something really useful (e.g. I'm not that keen on finding out every detail of how a Linux distribution works).

The usage of Internet for finding problems, provided that I try to solve them -- not only read them, is unrestricted. This includes participation in TopCoder SRMs, solving problems on USACO or SPOJ, participating in programming competitions like those of Al Zimmerman.

That's all about Internet for now.

Another problem is how I spend my time at work. I feel I can do better. In The Mytical Man-Month Fred Brooks says that many schedules are off by a factor of two because they don't take into account the time a software developer really spends designing and writing software. Its not 8h per day but rather 4h per day. And this is entirely normal. The rest of the time is not wasted. It is spent in meetings, communicating (useful information) through email, talking with clients, or resting one's head. Sometimes I work more than 4h but sometimes (especially lately) less! I'd like to set a target of 4h per day. If I do something else in the morning it is easy to drift away. So from now on no tennis table or TopCoder practice in the morning. The interval 8:30-12:30 is reserved for design and coding. The rest of the time I can spend on emails, meetings, presentations, and... improving myself in those areas that can benefit the company (since I do use company time). Examples of good things to do after I finish designing and programming:

1. read software engineering books or articles;
2. practice on TopCoder/USACO/SPOJ problems
3. read code written by good coders (e.g. SGB by Knuth, OCaml compiler by Leroy)
4. read methodology essays (e.g. Dijkstra's EWDs)
5. read magazine artiles about the IT market

Now that I have discussed a few particular examples it's time for more general considerations.

I seem to function better when I have a rather strict daily schedule. The main problem when I don't have a daily schedule is that I can't make up my mind to discard what am I doing when no progress is made. In such a case it's better to let it rest for a while and get back to it another day. This kind of letting go is what I find hard to do without a schedule. More serious is when I don't let go to a time eater: e.g. Internet pseudo-random browser. So a schedule is a must to make me let go and focus.

Focus works better on mid-term. A few hours of focus is great. But if you want to solve a a problem you have to let it go and come back to it. That's how I got the idea of defining TODO categories. Each TODO category serves as a main focus point for two weeks. After that you switch to the next TODO category. When the list is done you reconsider the period attached to each category, maybe even reconsider the content of the list and then start again. The list for now is:

• Write article, work on research problems.
• Read textbooks and articles.
• Work on personal (programming) projects.
• Solve problems.

Each TODO category has its own list of `next actions'.

Now let me sleep on it for a while. I'll try to implement what I said here, see how it goes and then adjust.

Procrastinating apartment

You should know by now: I am not an economist.

In two weeks I worked 0 minutes for my first open source project. That's because I'm so good at procrastinating. Let me tell you the latest innovation I made in this domain. Instead of watching a movie with my girlfriend, programming, playing table tennis, solving a puzzle, etc. I spent time thinking about how credits for buying an apartment work. Talk about wasted time!

Anyway, in order to keep wasted time to a minimum I'd like not to repeat the experience so I'm recording my findings here. (or maybe I'm just prolonging the procrastination state?)

The computations done here are rough estimates done on an idealized model. The monthly rate you pay to the bank is a constant R. The (monthly) interest is also a constant d-1. Even with these constraints the equations you get convey pretty useful information. To help intuition I'll use figures from an offer of BCR.

First of all the money you get from the bank is A = R (1-1/d^n) / (d-1). Here n is the number of months you pay. This number has an upper limit given by the bank. A typical value is 300. The interest is fixed by the bank: you have no choice here. You can pay the bank each month how much you like, but when the bank computes how much money it can give you it uses an upper bound on R. A typical value is half your net salary. Another constraint that is not captured in the equation above is that the money you pay `in advance' B must satisfy B/A > th, where th is a threshold fixed by the bank. A typical value is 0.2.

You can think about it in these terms. You have B EUR available and a salary. Then, by making a credit you can buy an apartment of up to A+B EUR. The value you get from the bank depends linearly on your salary. The value you pay up front must be big enough.

Let's explore a bit more the dependency of the money you can get from a bank on the three factors which appear in the equation above.

The dependency A(R) is linear. That means that if you have a salary twice as large then the bank will give you twice as much. For the BCR EUR credit the relationship is: A = 57 S. In other words the bank will give you at most 60 times your net salary.

The dependency A(n) is... exponential. This means that if you want to increase the ammount you get by a constant then you'll have multiply the period you have to give money to the bank by a constant. The function converges to A=R/(d-1) when n goes to infinity.

The dependency A(d) is also exponential... but the other way around. I.e. a constant decrease of the interest can multiply by a constant the money you can get from the bank. When the interest goes to infinity the amount of money you can get from the bank tends to 0. When the interest is 0 the amount of money you can get is A=Rn.

In terms of profitability there is of course no question: you have to pay up front as much as you can and pay back the bank as quick as you can. If you need to balance these somehow opposing forces then favour giving more up-front money.

Graph insights

I'll talk about a couple of graph properties that appear in A Course in Combinatorics as problems in the first chapter. Solving each of them was a rewarding experience for me. Knowing the answer will not make you feel good, but solving them might; unless they are too easy or too hard for you. So if you want to have a good week read the problems and then start working :)

1. The girth of a graph is the smallest length of its polygons (cycles). Show that for all d=1.. a graph with girth 5 and whose vertices have degree at least d has at least d2+1 vertices.
2. Show that a finite simple graph has at least two vertices with the same degree.
3. A graph has the property that for all pairs of vertices there is exactly one vertex joined to both vertices of the pair. Show that non-adjacent vertices have the same degree.

Now stop reading.

The first problem made me wonder what is so special about number 5. Now I know but, curiously, wondering about it didn't help solve the problem. What helped was looking at the neighbors of a vertex. Consider all nodes that can be reached in at most two steps from a certain vertex. Clearly, different paths lead to distinct nodes for otherwise we would have found a polygon of size less than 5. The number of paths of length 1 is at least d and the number of paths of length 2 is at least d(d-1). Therefore there are at least 1+d+d(d-1) vertices. In fact we can easily generalize this by considering odd girths 2k+1.

The second problem. I liked this one because of the simple way it is stated. Now I love it because of the simple way it can be solved. As usual I had quite a few false starts while trying to solve it. They were all too complicated. I should learn from this. If the solution I'm constructing starts to look too complicated then I'm on the wrong path. But let's get back to the problem. A simple graph is one with no loops and no parallel edges. The degree of a vertex is one of 0, 1, ..., N-1, where N is the number of vertices. These are exactly N possibilities and if we want to build a graph for which all degrees are distinct we must use all these values. On the other hand it is quite impossible to have in the same graph a vertex with degree 0 and one with degree N-1.

Now the last problem. This one I solved while having tea with my girlfriend. In fact I have used paper sparingly for the other problems as well. Sometimes even paper drives you away from the solution by allowing you and therefore encouraging you to try complicated approaches. A computer is simply evil for tackling such problems. We can learn from this. Even for truly complicated problems for which a computer can genuinely help we must be very careful not to use the computer to complicate more an already complicated problem. Again, back to the problem. For tackling this one we need some terminology and an intermediate step. The terminology will significantly shorten subsequent statements and therefore will make them easier to understand. I will say that vertex C is the common vertex of vertices A and B if and only if it is the only vertex joined to both A and B. The hypothesis can now be restated: "Each pair of distinct vertices has a common vertex".

We need to better understand what the hypothesis tell us about the neighborhood of a vertex V. Look at pairs formed by V with one of its neighbors: the common vertex will also be one of V's neighbors. Therefore V's neighbors come in (joined) couples. Here is the first fact we have found about the graph: all degrees are even.

Now we can attack the conclusion. Consider a pair of non-adjacent vertices (A, B). We will refer to the common vertex of this pair by the letter C. The A's neighbor that is coupled with C is baptized CA, and similarly we baptize vertex CB. The name NA denotes a neighbor of A that is different from C and CA and similarly NB denotes a neighbor of B different from C and CB. Now consider (NA, B) pairs. Their common vertex must be an NB vertex (why are C and CB not possible?). Therefore each NA is joined with exactly one NB. Because of symmetry each NB is also joined with exactly one NA. We are done: the number of NA vertices must equal the number of NB vertices.