imitatio creatio

nice collage of M.C. Escher graphics

Źródło: tutaj.

This article by Bert Scalzo has one paragraph which made me smile :)

I’ve personally served as an expert witness in several court trials where plaintiffs sued defendants for serious financial remuneration when custom database applications had performance and/or data accuracy problems. In every case, there was a failure to data model the business requirements. Thus, the data effectiveness suffered. Moreover, ad hoc database design, or database design using more programmatic-oriented techniques and tools, often resulted in inefficient database design. No amount of coding could overcome the resulting bad database design. So, in every case, the plaintiff won.

Just sue them, if nothing else works.

Jak ktoś lubi się czasem przejść po zielonym Polu Mokotowskim to zalecam  klikanie i nękanie urzędasów jak tylko się da.

Jak się ludność nie uaktywni to połowę sprzedadzą i zabudują, pośrodku zrobią arterię komunikacyjną i zostanie 100 m kw. trawy. Za szkłem.

Amerykanie odpalili http://data.gov - site ma być repozytorium danych z różnorakich agencji rządowych.

To jest dobry ruch - częściowa odpowiedź na dokładnie ten sam problem o którym mówią Hans Rosling i Tim Berners Lee.

W skrócie chodzi o to że ogromne pokłady cennych publicznych danych leżą zakopane w bazach konkretnych instytucji, agencji, departamentów… Zamiast pracować dla pożytku społeczności która za nie zapłaciła.

Czekamy na http://data.eu [Unia Europejska].
Czekamy na http://data.un.org/ [ONZ].
Czekamy na http://data.gov.pl [polskie agendy / instytucje rządowe].
Czekamy na http://data.stat.gov.pl [ GUS].

RAW DATA NOW!

This is just a warning note for people running databases inside Vmware.

The problem:

At my employers company we develop some business critical application for one of our customers. This customer decided to employ Vmware ESX host as a container for a testing farm for this application. One of servers in this farm is a PostgreSQL machine.

The Very Bad Effect that we noticed while debugging some nasty db-related problem is:

Inside a guest OS, time flows differently.

That is, one second can last 1/2 second or 3/4 second or 2 seconds - depending on the disk I/O. The higher disk I/O rates, the slower time flows.

Somehow, this has fatal impact on performance of PostgreSQL. Algorithms which rely on precise timing simply stop to work. This could be a matter of interesting analysis which I don’t have time for right now.

I am not a Vmware expert, and probably this is just a matter of bad configuration.

Probably it appears only when you run many single-core guests inside one multi-core host, but anyway - be warned.