mandag 19. august 2013

Personal Information Security; Baby Monitor

A video baby monitor in Texas was hacked via the Internet and abused by a very bad man:

If I connected security cameras at work to the Internet, authorities would come at me with full force. Surveillance is sensitive information and must be treated as such. One of the problems, then, is that most people are not trained to think of information security in their daily lives.

As a trained professional, I would look at the package saying "over the Internet", shake my head in disgust and put it back on the shelf - unless I was looking for a public web camera for Runde. Blinded by the convenience, however, a lot of people will cheer with joy for this invention, not realizing that they are opening themselves wide open to a malicious hacker ready to subvert their children.

The formula is fairly simple: Identify what is sensitive information (or sensitive access to your loud speaker as well, as in this case), identify who needs the information and the shortest route there, make sure you do everything you can to protect that channel in all nine aspects: Confidentiality, Integrity and Availability of Storage, Transit and Processing.

I will leave it for the reader as an exercise, before I reveal my own analysis of this system. 

mandag 22. juli 2013

Reflections on a Lean Hospital

Norwegian National TV recently broadcast a documentary about "The Health Factory" (film available to the world until August 19th 2013) where the first question was whether Toyota car manufacturing is the right ideal for healthcare.

Well into the program, former health care minister Bjarne Håkon Hansen presents the following scenario: He goes to Toyota, orders a specific model car he wants, colours, accessories. He is given a time he can pick up the car, and the car is ready at the time given. On his way out of Toyota, he calls the hospital, because he needs a knee operation. When he asks when he can have his operation, the hospital is not able to give him an accurate estimate. His conclusion: Norwegian hospitals have problems with logistics.

While I do not see any problems applying Lean principles in health care, one must keep in mind that there is a distinct difference between manufacturing and health care. And it is the same difference I experience between manufacturing and running a municipal IT department: It is not a production environment.

Manufacturing is a known process. It does not require diagnosis, and the risk of unexpected events are low. In contrast, a hospital will have a varying amount of emergencies, and many operations have a great risk of complications.

There is still value to be taken from Lean also in hospitals: Known procedures can be simplified. Quality can be increased. More things can be taken into consideration. Communication can be improved. However, it is important to understand that one must look at this holistically. The problems presented in the documentary seem to be what happens if top management attempts to implement Lean with a single focus on short term savings.

mandag 18. februar 2013

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.

fredag 28. september 2012

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.

søndag 10. juni 2012

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:
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.

mandag 21. mai 2012

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:
int imageWidth, imageHeight;              // Size of source image
int viewWidth=846, viewHeight=660; // Size of onscreen view 

// 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;
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:
  else if(scrollX+viewWidth>scrollWidth)scrollX=scrollWidth-viewWidth;
  else if(scrollY+viewHeight>scrollHeight)scrollY=scrollHeight-viewHeight;

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.


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.

lørdag 10. desember 2011

So what happened to

I was busy moving and spending time in hospital and preparing for the birth of my third child, all at the same time. So 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 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:

Registrant: Domain Privacy
8 East concourse

Tel. +61.395897946