If you are a reservoir engineer, you need money to do your job. Your financial managers don’t understand much about your work, and it’s difficult for them to prioritize the budgets; so they occasionally ask you to quantify the value of your work in financial terms. If this gives you headaches, this webinar is for you.
The Plastiras Lake in Greece is a typical example where everyone wants something different. The electricity company wants to use it to produce energy. The farmers want to use it to water their fields. The nearby city is supplied with water from it, and therefore wants the water to be of good quality. The tourist resorts around the lake would prefer it if the others didn’t take any water at all, because drawing water makes the lake less beautiful. So fifteen years ago we were given the task of studying these conflicting objectives and proposing a way to manage the lake better.
Although my subject is Enhydris, we will only take a short look at it towards the end. We will first talk about development methodologies and about good and bad uses of technology.
Developing a great project
I am under the impression that unit testing is still considered something exotic by many developers. I think that this has to do with a certain kind of provincialism that we have. I’m not talking about Greece, but about many developers all over the planet who don’t work on great projects like Python and Django. Continue reading
(A presentation I made at an open source conference in Greece, 13 March 2010, at TEI of Piraeus.)
Getting involved with software patents seems boring, and, unfortunately, it is, at least for me. I’m a computer professional and I like writing code. I’m a Python/Django fan, and I’m involved in a couple of free software projects. One of them is a state project (and it’s free because I took the opportunity to move it towards the right direction when I saw that the right people were in the right positions). I don’t like politics and legal issues much. However, I do occasionally mess around with copyrights and patents; not because I like it, but because I like being free, and it is a price I pay to defend my freedom.
In this concise introduction, I explain essential things you need to know when working with geographical co-ordinate systems. I explain why many geographical co-ordinate systems are being used and how to use the free Proj software to convert between them, and I make recommendations on how to store co-ordinates in your database. I assume you already know what latitude and longitude means and what cartesian (x-y) co-ordinates are, and that you have some understanding of the geometrical term “projection”, notably what we mean by “project a 3d shape to a plane”. The last section is intended for programmers.
I have been one of the two Greek delegates to the OOXML Ballot Resolution Meeting (BRM). Lots of things have already been written about the meeting. I will not repeat them here, but will only make a few clarifications on things that I think are not well understood. If you want a general account, I think that Tim Bray’s is the best so far.
The opinion of the BRM
First, it is important to clarify that the BRM did not say either that the specification is OK, or that it is not OK, because it is not within its competence to say such a thing. There was good co-operation, and, to a large extent, good will, from all sides, because the BRM has a single purpose: make the specification better. Let me repeat that: the BRM has the single purpose of making the specification better, so that if it is accepted, it is the best possible. Or, the same thing viewed from another viewpoint, the BRM attempts to make it better, to maximize its chances of going through. Continue reading