Policy as focus tool

I've been working for a while for an employer whose concept of "plan", "policy" and "procedure" is not only a foggy area through which one can not tell the three apart, but are further muddled by an unwritten current practice to which you are held responsible but not told.

The two first months of the year is spend writing document after document with "plan" in the title, albeit the contents range from a list of investments to policies, not to mention the "goal plan", filled with some vague unmeasurable purposes to which you're supposed to come up with actions whose effect may not be tested beyond "completed".

While some will call this "politics as usual" in the public sector, the vague framework causes real problems with communication between departments and expectations. In order to survive the work day, everyone becomes their own boss, and many of them decide to become the boss of everyone else.

As a rememdy for my own department, I wrote up a policy framework just for us. It's not big. It's based on the purpose of our department as described in the founding document: Technical support, maintainance and development projects. I use the broad definition of the term "development", as it not only includes in-house software development, but any changes to the IT system: Installation of new software, modification to the infrastructure, etc.

I elaborate on what we do in order to follow up on each of the main points, link in procedures where needed. Writing the document up gives a deeper understanding of what we do and what needs to be done. But for the team to really benefit, they need to understand and respect The Document. For all purposes, there is only one way to do so: involve them on a regular basis.

So this is our current schedule:

• Every friday, we do a retrospect meeting over a pizza. The retrospect has several functions: 1) Status reports on the most important tickets and projects, 2) Feedback to team members, thus making them feel valued, 3) Solving unsolved puzzles by involving the entire team, 4) Lifting work off our shoulders, so that the weekend can be enjoyed better, 5) Raise awareness to other developments, meetings, system changes.
• On the first work day of new moon, we run a Kaizen session. The department's policy framework is used as the framework of the meeting. We may not be able to go through the entire policy in one sitting. Giving this time, however little, helps the team own the policy. And that makes all the difference.
• Status reports, policy changes, notes from meetings we have attended, etc, all go into a report headed for top management at the end of every month. This helps make our work more visible to top management.

It may cost us 10 hours of work per team member every month. Alas, from even the first meeting, you shall see the rise of morale. And from that comes an increase in productivity.

eKommune 2012

Monday September 24th and Tuesday 25th over 300 souls - mostly IT personell, a pinch of sales people and a handful of municipal top leaders - met in Trondheim for the annual eKommune conferance. There was a great variation of talks, as might be expected. Most notable was possibly a mismatch between the view of central government and local administration about what needs to be done to optimize IT spending in the public sector.

Municipal CTOs agreed across the board that there needs to be architectural and protocol standards to facilitate integration, intermunicipal cooperation and municipality-to-state reporting. To achive this, we need action from central government. This is in tune with my article series about consulting in the public sector.

Central government, on the other hand, were afraid to touch anything that might reduce local self governance. One claim was that the differences between municipalities may be too great.


I got to chat with the CTO of a much larger municipality (withholding name to protect the CTO), and learned that we were technically not that different. In fact, we shared the same major challenge, which is a political challenge, rather than a technical challenge: How non-IT public workers - the very ones that we support - view IT and how methods of accounting IT costs obscure the big picture within the organization.

Indeed, I have had the same chat with the CTO of a large private company, who experiences the same organizational issues. It makes me wonder if we have ourselves to blame, in that we really are technologists, not politicians. Our message gets lost in our willful haste to get things done.

Games coding

A friend, whom I usually consider well educated in IT, came with a rather unexpected comment the other day. "I would like to know how to write games." What, any programmer can do that - albeit, there are many genres of games and therefore the required arts will depend greatly on the type of game you wish to create. However, if you're looking for a place to begin, here's the basic skeleton:

while(game_is_running){
controls();
physics();
render();
sync();
}

Each of the looped stages above will be greatly different from game to game. From the beginning of time, I can no recall any game that is not a combination of object oriented and map oriented - that is, the method you use to keep track of each element in your game is picked for CPU efficiency. You want to use the least amount of processing power possible.

Typically, the user and aliens are considered objects, though environment may be a map or object oriented. Controls() include receiving user input to manipulate the user object as well as any artificial intelligence you may need for computer generated players. In MUDs (broad sense), this may also include receiving updated data about another player.

Physics() should theoretically be the same in every game, except it's not. Is it a 2D or 3D game? Do we need gravity? Do we need gravity between objects? Object collition detection? Does anyone die? Is there acceleration going on, or are things moving at linear speed?

Render() should really be the same for every game of the same kind. In a 3D world, the world should render the same way at all times. It is common to create a rendering engine that is reused in every game from the same company. Except, of course, the technology changes and the rendering engine must follow suit. And when technology doesn't change, the programmer may still find things to do in a more clever way.

Sync() is possibly the simplest stage: The three previous stages will take different amounts of CPU time for every frame of the game. In order to get a smooth game, one must wait until the next "tick" of the clock - whether it is every 50th of a second, 30th, 20th or 15th of a second. Or even every second.

Within each of the stages above, the details become a science of its own. It's not tough, though, you just need to break it down to bit sized chunks.

Image zooming

A friend of mine posed the following problem to solve for his VB-in-Excel application:

In a view of 846 x 660, an image is rendered. By clicking anywhere on the image, zoom is multiplied by 1.2. However, and this is the important part, the part of the image clicked on shall remain the center of the zoom and remain in place of the part of the view clicked - i.e. directly below the mouse.

Since I'm not a VB-coder, my reply is in C-like quasi code.

Input data


To solve the problem, we need to be absolutely clear about what the input data is, which in turn is dependent on the source of the data. We start off with the follwing information:

// STATIC DATA
int imageWidth, imageHeight;              // Size of source image
int viewWidth=846, viewHeight=660; // Size of onscreen view 

// VARIABLE DATA
// Position of view/sliders on the projected (zoomed) image
int scrollX, scrollY;
// Size of projected (zoomed) view/sliders
int scrollWidth, scrollHeight;
// Bar/slider size represents the view compared to projected image
int barWidth=viewWidth, barHeight=viewHeight;
float zoom=1; // Current zoom

Then you have the mouse click. We need to know two things from the click: Visually where in the view you clicked (viewX,viewY where top left of view is 0,0), and what position this represents in the image (imgX,imgY). The image coordinates can be calculated from viewX,viewY this way:

int imgX=(viewX+scrollX)*zoom, imgY=(viewY+scrollY)*zoom;

However, in my friend's case, the input data had the entire zoomed image as its reference, so top left of entire zoomed image represents 0,0 and bottom right (with sliders also bottom right) represents scrollWidth,scrollHeight. Hence, the parameter representing the clicked position (clickX,clickY) is the position in the view (viewX,viewY) PLUS the position of the slider bar (scrollX,scrollY).

Since we need to know the actual visual position on screen, relative to the top left corner of the view, the two coordinates must be calculated as such:

// Position unzoomed to fit zoom=1
imgX=clickX/zoom; imgY=clickY/zoom;

// Pos. shifted to visual position
viewX=clickX-scrollX; viewY=clickY-scrollY;

User control

New zoom is calculated per policy defined by my friend - basically:

int zoomstep=1.2;
if(leftClick)zoom=zoom*zoomstep;
else if(rightClick)zoom=zoom/zoomstep; 

Calculating new scroll bars


We now know the new zoom and want to render the view with (imgX,imgY) located where the mouse is on screen (viewX,viewY). First step is to tell the scroll bar control what the new sizes are:

// Size of projected image changed with zoom
scrollWidth=imageWidth*zoom; scrollHeight=imageHeight*zoom;

// Size of bar/slider doesn't really change unless you change size of view
barWidth=viewWidth; barHeight=viewHeight;

If we set scrollX to imgX*zoom (image coordinate projected to new zoom level), our point ends up in top left corner of the view. However, we want this point at viewX,viewY, so we must offset the X-coordinate to the left, i.e. subtract the viewX,viewY coordinate:

scrollX=(imgX*zoom)-viewX; scrollY=(imgY*zoom)-viewY;

Edge adjustment

Unless we want to scroll off edge, we may need to adjust:

if(scrollX<0)scrollX=0;
  else if(scrollX+viewWidth>scrollWidth)scrollX=scrollWidth-viewWidth;
if(scrollY<0)scrollY=0;
  else if(scrollY+viewHeight>scrollHeight)scrollY=scrollHeight-viewHeight;

Rendering

If you need to render the image manually, the typical approach is to find the source rectangle within the image and project it to the full view.

int left=scrollX/zoom, top=scrollY/zoom;  // Reduce position to zoom=1
int right=(scrollX+viewWidth)/zoom, bottom=(scrollY+viewHeight)/zoom;

Then complete the operation using StretchBlt (if in a Windows development environment) to stretch-copy the rectangle from the source image to your new view context.

Other

Feel free to ask for further calculations or other parameters in the comments. If the above code fails, it may be that you have other input parameters or need to calculate some other numbers than what this article has attempted to convey.

So what happened to trollsilm.com?

I was busy moving and spending time in hospital and preparing for the birth of my third child, all at the same time. So trollsilm.com renewal slipped, and soon after someone jumped on to it. I have tried to get in touch - after all, there should be a prize tag to get it back - but to no avail. Hence I have registered trollsilm.org and will be moving there soon.

If anyone has the time, determination and possibly money to bother the heck out of the squatters, feel free:

From http://www.ip-adress.com/whois/trollsilm.com
Registrant:
Above.com Domain Privacy
8 East concourse
Beaumaris
VIC
3193
AU

Tel. +61.395897946
Fax. 

The fertilizer man

I can not give this man a more fitting name. Some will call him "the devil" or "low life" or "insane" but after setting off a car full of fertilizer bomb, and knowing what that smells like, I will always think of him as "the fertilizer man" no matter how much damage he made and how many lives he took.

While most of the world seems to have arrived at logical conclusions around the entire incident, I have come across some - I'd almost say appologists - who seem to have failed miserably at their quest for logical reasoning as the perpetrator himself. From the point of view of the Fertilizer Man himself, the idea that multicultralism is destroying Norwegian culture, I beg to ask the following questions:

• If the big enemy is multiculturalism, why kill Norwegians?
• If the humongous problem is the destruction of Norwegian culture, why kill Norwegian youth?
• If the big fear is massacres performed by foreigners, why make it so blatantly obvious that the self proclaimed protector of Norwegian culture also is the greatest mass murderer of those who could bring Norwegian culture forth?
• And if protection of Norwegian culture was so important, why so much fear of the smallest group of cultural immigration, when it is so blatantly obvious that the greatest threat to Norwegian culture is Mickey Mouse and Ronald McDonald?

The idea that he blows up some government buildings - sure, I can see that happen. Happens all around the world from time to time. Many people have their secret wish to blow up the parliament every time some strange taxation law or other regulations interfere with their daily lives. The Fertilizer Man got that one down. Fine. You're angry with government, you blow up goverment, I get it.

But shooting youth who have barely reached legal age - and some of them not even that - is just an appalling act of evil. And a rediculous one at that. You first claim that non-Norwegians are a problem, and then you go shoot Norwegians.

The only logic to this is the idea is the "monoculturalist vs multiculturalist" scenario. So the monoculturalist went to war against the multiculturalist. And that's where some of foreign mass media have picked up.

Russia Today is repeatedly reporting about a "multikulti fail" in Norway:

Even the title is wrong, insisting that he turned "against his own." He did not. In his world, he was the monoculturalist against the multiculturalist. That's where the "us vs them" was.

Taken out of context is the Norwegian border closure. While they are still investigating the possibility of the Fertilizer Man not acting on his own, police want to make sure they know who leaves the country. This, however, is being portrayed as a sign that the European Union is falling apart in distrust.

To make sure everyone gets the problem with multiculturalism, Russia Today interviews the Spokesman for the Union of Russian Communities in Sweden, who apparently met the Fertilizer Man in his youth:

His opinion is clear. Multiculturalism is bad, he says. Spokesman of Russian Communities in Sweden. What are you doing in Sweden? You're not Scandinavian. You're a spokesman for the Union of Russian Communities. Preserving Russian Culture. In Sweden. Side-by-side by with Swedish communities. What do we call this, again, when several cultures live side by side? Multiculturalism?

It is obvious that Russia and Israel are vested in monoculturalism and therefore support this view. Since the Fertilizer Man was a monoculturalist, and the media of both countries blame multiculturalism, they are fairly appologetic: It wasn't the Fertilizer Man's fault, he was forced to do this by the multiculturalism that wouldn't let him sleep at night.

Again, if blowing up the government in protest was all he did, fine, it's a protest. Absurdely aggressive to be in Norway, but it's a legit target in war, and to him, this is war. Youth camp? Sure, it was a political youth camp, but still.

With all the talk of "multikulti fail" and the preservation of Norwegian culture, I can't help but think of what Norwegian culture has been for the last few thousands of years. As a friend in Atlanta once pointed out - our genes look so incredibly diverse to be such a small country.

Guess what, even our genes are multicultural, as we have been trading, importing culture, slaves and wives from large parts of the world since at least the viking age. And we traded and lived side by side with the Sámi people, even paying them local taxes whilst visiting anything north of Trondheim until Sápmi was annexed by the king of Sweden.

Multiculturalism is nothing new in Norway, it's monoculturalism that's new. The strange, suspect idea that we can preserve a culture that has been in constant change since before our written history. And people like the Fertilizer Man are trying to kill Norwegian culture by the sword - or rather by dung heap.

Who needs sticky yellow paper?

Post-its are all too often used to keep your username and password safe and secure to your monitor for everyone to see. As ICT Leader, I rip these away faster than I see them. Even if it should be at a publicly accessible airport terminal - which is probably why an airport has found a way round the "missing post-it" problem at their self service check-in terminal. (IMHO, This photo should be submitted to The Daily WTF)

Photo/observation tweeted by Per Thorsheim