A Very Nice Summary of the Best Haskell Features

Learning Haskell is hard, but it is really profitable. Haskell is not another boring functional thing. Yea, I know, you can write functional code in Python too. Haskell is just different.

The main great thing about Haskell is that it is so different from the rest of the languages I use, that it really affects the code I write, and the way I think about writing and structuring programs.

Below is a very nice summary of why Haskell is worth using.

Haskell gets static typing right

Statically typed languages are often seen as a relic of the past – old and clunky. Looking at languages such as C and Java, we’re used to writing down a lot of information in a program that just declares certain variables to be of certain types. And what do we get in return? Not all that much. Yes, granted, some errors are caught at compile time. But the price is high: we’ve cluttered up the code with noisy declarations. Often, code has to be duplicated or written in a more complicated way, just to satisfy the type checker. And then, we still have a significant risk of run-time type errors, because type casting is common-place and can fail at unexpected moments.

So it isn’t a big surprise that dynamically typed languages are now very fashionable. They promise to achieve much more in less time, simply by getting rid of static type checking.

However, I want to argue that we shouldn’t be too keen on giving up the advantages of static types, and instead start using programming languages that get static typing right. Many functional languages such as Scala, F#, OCaml and in particular Haskell are examples of programming languages with strong static type systems that try not to get in the way, but instead guide and help the programmer.

Haskell gets static typing right.

How Not To Build Community

I’ve been working on a Postgres patch. I’ve created that, there were many errors of course. Some of them were made due to my bad knowledge of the Postgres internals; some because of not knowing some internal Postgres conventions; some just because I made an error.

That’s why I asked a lot of questions, and that patch had almost ten versions. I couldn’t do anything with that if the more experienced people wouldn’t help me. When I asked a question, they just answered me. When I made a mistake, they just informed me, showed me the problem, described it and showed some examples of how this should be done.

Yea, this is the way it should be done. This way I really like those people, and I will be working on some more things for the Postgres project. I think it will attract more and more people who wouldn’t be afraid of showing there not too perfect patches.

On the other hand they could react like Linus did. I’m sure that if a new commiter would get such a welcome reply, then he would never show up again. Instead of saying ‘goodbye’, he will be looking for some other community. This could be a huge loss for the project.

Postgres as NoSQL Database With Validation

I’ve written a blog post about PostgreSQL used as NoSQL database with serious data consistency checks. To my big surprise, this simple blog post has drawn huge attention, and has been cited in many places.

This is a kind of another reason why I’m getting back to my idea of writing a book. I stopped thinking about that, as many things are too simple and too obvious for me, so I think they are not worth writing about. The above blog post is also about some obvious things, but I see that many people are interested in that.

I need to rethink my book ideas. Any help is wellcomed.

Current Writing

As you might notice, I don’t write here too much. There is a couple of reasons for that.

A couple of months ago I started working for a great company End Point and now all my new technical writings are on the company’s blog where you can find many interesting things.

Personally I have much less time, so I cannot write often enough.

I work on a book from time to time. I hope to publish it next year.

I work on redesigning the whole blog, I will remove WordPress and do some more things.

As my technical writing is on the End Point’s blog, I will place here some longer essays about programming, but I need to finish them first.

My two blog entries on End Point’s blog:

I will be updating the list as new posts are published.

The Importance of Database Testing

Basic Mistakes in Database Testing

There is a huge number of books about TDD. Those books usually concentrate on using test for units of work. Units of work are understood in many different ways, usually it means a class. So the books say: write a lot of tests, make code in such a way the the tests pass. All external resources should be mocked so you can test only this unit.

That’s cool, but unfortunately in many cases all of the testing stops at this moment. There are some queries (written by hand or generated by some ORMs) but they are not tested, usually. Some programmers test those using integration tests – tests which connect to a real database and perform real queries. This usually means testing the happy path – I’ve got my ORM so it takes care of everything, I don’t need to think.

Database is usually the most valuable asset a company owns. Applications are rewritten from time to time. Old applications are thrown away, new applications are installed. Nobody throws away the database full of data when changing the applications. The database is carefully migrated. There are systems where many different applications use the same database at the same time. That’s why it is important to have good database model full of constraints and why database should be treated with care. You really don’t want to destroy the data consistency as this could cost your company too much.

This article is about often forgotten database testing. Integration tests using real databases. It really doesn’t matter what kind of database engine you are using. You can use PostgreSQL, MySQL, Oracle or even those funny noSQL databases like MongoDB. Below rules can be applied to all kinds of databases and all kinds of applications. Maybe not all of them, as noSQL databases cannot enforce data integrity.

Your application usually consists of many different parts. There is some <put here any language you like> code, some configuration files, some SQL queries, some external systems. Testing an application means testing each part separately (only because that makes finding bugs easier) and testing how all the parts cooperate. Database is one of suchs parts, and you should test it thoroughly. Continue reading

PostgreSQL Versioning Policy

I was explaining the PostgreSQL version naming convention to my colleague a couple of days ago. The differences between e.g. 8.3 and 8.4 and what is different between 8.4 and 9.0 and what should be used during database migration to another version. I knew all that just because somebody told me that many years ago (I think it was depesz – thanks).

However I was unaware that there is documentation of the whole versioning issue. All you can find here.

Another reason why love this project. And yes, you should have that versioning policy in you project too (it really doesn’t matter if it looks different – better to have a convention than not).

Unit Test Your Database.

I observe the endless war about TDD. On one side there are those who claim that TDD is the best thing since sliced bread. On the other side there are those who claim that TDD is just a waste of time and is too slow.

But what about databases? Nobody writes about them too seriously.

In some books there are some wise words like:

  • we should use TDD for DAO
  • we should use TDD for ORM objects
  • we should use TDD for queries

This is very good for testing unique, foreign and primary keys. Very good for all checks. What is missing here? Continue reading