I started writing a chess engine. The longer I keep on writing it, the longer I see that it’s a never-ending story. There is always something, which should be improved. There is always something to make in a different way, but I’m not sure if it would be better or worse. And most of the good design decisions made at the beginning, don’t look so good later.

During the journey, I learned a lot and I hope to learn much more. This time I’m going to describe what I learned about bitboards.

I have also written a java implementation of the NQueens problem. I used bitboards there and they made the program quite fast.

I made an analysis of the Hacker News data. My main interest was about the URLs, which appeared on the website.

Here is a short explanation of the process. Links for the analysis are at the end.

I’ve Got a PDF

An insurance company used to send me a paper letter (you know, the ancient way of communication) every year, right before the anniversary. Usually they offer some kind of change, like this:

Hey, we offer that you will pay x% more money from the next month,

in return we offer you x% more for the insurance amount.

And that’s perfectly fine. Really.

This year they sent me an email, with an attached PDF file. In the email they wrote:

We attached you the anniversary documents.

The files is protected with a password, which is the birth date of the insured personed, in the format of DDMMYYY.

Yea… my first thought was…

why do they even bother to add the password.

My next thought was:

what if…

The Problem

PostgreSQL has many interesting features for building custom logic inside the database to ensure the data is correct. It is also possible to build logic for simpler processing data.

In this post I will show how to use PostgreSQL to create an easy to use custom aggregate to calculate the length of a collection of overlapping ranges.

Many Python programmers repeat that looking like a duck is much more important than if it’s really a duck. So, if you have an object passed to a function, then the class of the object is not important. The only important thing is if the passed object has a specific function, which you want to call.

If it walks like a duck and it quacks like a duck, then it must be a duck

https://en.wikipedia.org/wiki/Duck_typing

What if it’s not? In the Wikipedia there is a more historical term, a Duck Test:

If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.

https://en.wikipedia.org/wiki/Duck_test

The word must is a very bad assumption. What if it’s not? Will the program blow up on production. The word probably is a better assumption, but it’s also a very significant source of problems in many programs I observed. Sometimes something looking like a duck is not a duck at all. It’s not even similar to a duck.

A string is not a number and a number is not a rectangle. So how come that in programming people claim these are the same things? Simple things will be simple. Unfortunately, every simple program tends to go in the direction of a much more twisted beast, right after you think about adding a new feature or two. Too often after such a change the result was having twisted ducks with four legs but without a head. The program was fine in most cases. Debugging was hard. It was much easier to start writing that from scratch. And then you will need to add a feature or two…

Should you care? Well, you always should. Unless you don’t care about the programs you are writing.