Dystopian Movies

I STUMBLED UPON an excellent Top 50 Dystopian Movies of All Time ranking list. Even though my personal views of technology and the future are definitely more utopian, I’ve always found these dystopian movies to be the most fascinating. Interestingly this list does in fact list include most of my favorite movies, even though I do not agree with the ranking order in which they are listed.

My personal top 10 dystopian movie hit list would go like this:

Learning GO

FOR A COUPLE of years now I’ve wanted to learn to play the game of Go, but I just haven’t managed to find the time. Go is a strategic game for which the saying is “easy to learn, hard [impossible] to master”.

There exists a brilliant live-cd called Hikarunix. The Hikarunix CD contains a huge set of the quality information on Go found on the internet. A great asset is also the collection of tutorials, trainers and databases over played Go games. In theory Hikarunix bundles all that is required to study, learn and play Go.

Hikarunix is definitely recommendable, but experience tells me, that if you really wanna learn a subject to depth, get a book written by experts in the field and benefit from their hard earned knowledge. Hence I have bought the book Lessons in the Fundamentals of Go.

Lessons in the Fundamentals of Go

The book comes highly recommended (e.g. from www.godiscussions.com) so I’m looking forward to reading it.

I am also very exited about playing on my Go board.

Go Board

This beautiful board is actually handmade by my mother. When wooden Go boards are generally price tagged in range of a Ariane space rocket, its nice to have a family that got talent :-)

The wood is a 48.3[cm] x 55,5[cm] leftover from a kitchen table and then drawing of the grid and cutting grooves for all the lines as well as coloring the lines and applying the sealer is handmade.

C++ Contructor/Destructor Call Order

WHEN BEGINNING C++ programming I’ve experienced people to have trouble remembering the correct construction and destruction call order. Personally I conquered this using a common memory technique – creating a story.

Here are two stories that might help in remembering. The stories might seem quite long, but don’t fear, it’s not necessary to remember the stories word by word. Btw. the storytelling does not fly 100[%], but they are good enough… at least for me ;-)

Story #1: The Skyscraper

The skyscraper story is exemplified from this simple class structure:

1
2
3
4
5
6
7
8
9
class Base
{
  Base() { cout << "Base" << endl; }
};
 
class Derived : public Base
{
  Derived() { cout << "Derived" << endl; }
};

A couple of prerequisites are necessary:

1) Imagine the UML class diagram of the above turned upside down.

Class diagram turned upside down

2) Imagine that the each class in the upside down diagram represents a floor in a skyscraper.

Class diagram is a building

The Base is the foundation and all Derived objects are floors that builds upon that foundation.

Construction
Start constructing here --->

So to construct a skyscraper the building process must be Base first, then Derived next, as buildings (usually) are build from bottom and upwards.

When destructing the destruction order is the same as dismantling a building, top to bottom.

Start destructing here --->
Destruction

So what about the special case of destruction when the object is polymorphic?

When allocated is looks like its a building with only a base level; even though we know its a building two storages high.

10
Base* pBase = new Derived;

The problem here is that the demolition team only have access to the base level and when destroying the building, disaster will happen…

11
delete pBase;

As the building is two storages high, it will collapse when the supporting foundation is removed first (allegorizing a bad situation as the Derived object would not get destroyed when only deleting the base object).

So how to fix this situation? You provide the demolition team with an elevator. The “elevator” is a special demolition model called virtual.

12
13
14
15
16
class Base
{
  Base() { cout << "Base" << endl; }
  virtual ~Base() { cout << "~Base" << endl; }  // Virtual destructor
};

As the building is equipped with an elevator the demolition team can escalate to the top of the building and begin the destruction from top to bottom and get everything removed properly.

Story #2: File Manipulation

The second story relate the base/derived situation to file contents manipulation.

A file must be opened before it can be closed, and if opened it must be closed again at some point. Thus it make sense to create a class that opens the file in the constructor, and closes the file again in the destructor.

1
2
3
4
5
class FileAccess
{
  FileAccess() { cout << "Open file..." << endl; }
  ~FileAccess() { cout << "Close file..." << endl; }
};

Read and write operations are similar functionality (transfer data, but in opposite direction) and thus it makes sense to collect this functionality in one class. As the goal is to modify the contents of a file, the reading of the existing file content can be placed in the constructor, and writing of the modified content in the destructor.

6
7
8
9
10
11
12
class FileManipulate
{
  FileManipulate() { cout << "Read from file..." << endl; }
  ~FileManipulate() { cout << "Write to file..." << endl; }
 
  // Content manipulation functions follows here...
};

Two classes are now at hand. One that opens and closes a file, and one that reads the contents of the file and writes it back to the file.

A prerequisite of reading from a file or writing to a file is that the file is open. Therefore the basic but essential functionality of opening and closing is made the base class (FileAccess). The more advanced and flexible functionality of reading and writing is then made in the derived class (FileManipulate).

11
12
13
14
15
16
17
18
19
20
21
class Base /* FileAccess */
{
  Base() { cout << "Open file..." << endl; }
  ~Base() { cout << "Close file..." << endl; }
};
 
class Derived /* FileManipulate */ : public Base /* FileAccess */
{
  Derived() { cout << "Read from file..." << endl; }
  ~Derived() { cout << "Write to file..." << endl; }
};

Thus every time an object is created of the derived class for modifying a files contents, it automagically also inherits the capabilities of opening and closing files. And as a file cannot be read from before the file is opened, it can be remembered that the base constructor must be called before the derived constructor. Equally it cannot be written to the file after the file is closed, thus is can be remembered that the derived destructor is called before the base destructor.

Formula 1 Trip 2007

CIRCUIT DE SPA-FRANCORCHAMPS is a famous Formula 1 track in Belgium, and this year I, along with two of my Formula 1 enthusiast friends, spend three days watching the race from the the Silver tribune.

One spectacular section on the Circuit de Spa-Francorchamps is the Eau Rouge and Raidillon combination. This is a quit left turn in to an unbelievable steep hill that arcs to the right. Preceding this section is a long downhill stretch, making an excellent overview of a great part of the track. This viewable piece of track made it all worth the money for the Silver tribune seat. The F1 racers will blaze past you so close that its almost frightening, and then they continues up the steep hill so fast you just wouldn’t believe it wasn’t a cheap sped-up driving movie, if you didn’t see it with your own eyes.

Here I have the Eau Rouge / Raidillon combination in the background. Jan at Eau Rouge / Raidillon section

With my Canon IXUS 50 digital camera I recorded a video of a Toro Rosso in the second practice round. This might give some idea of the speed involved (the digital camera is not really suitable for this kind of video recording, so the video quality is not so great).

Wikipedia has extensive information on the technical details of Circuit de Spa-Francorchamps track.

It was lots of great racing watching in three sunny days in 20-something degrees Celsius and low wind with lots of waffles of all sorts and plenty of cold Jupiler beer – sweet :-)

However, everything is not perfect at the old Circuit de Spa-Francorchamps stadium, at least at the Silver tribune. A Silver ticket cost around 350€ and include a numbered seat. Sadly the seats are only a plastic platform with no back support. This makes it pretty tough on your back to sit watching racing from 9:00 to 17:00. Further more the track owners made some stupid decisions that limits the view from most of the Silver tribune. The lowest seats sits so low that one almost cannot see above the crash fence. Also the lower seats sits to close to the cross-wired safety fence running in parallel between the tribune and the track, that only a narrow viewpoint straight ahead is available. If looking to the left or right you will see nothing but fence. The middle seats has an important part of their view blocked by a (Vodafone) bill-board, making it impossible to see the cars come out of the La Source corner. Last but not least, the tribune for the Gold tickets is placed after the Silver tribune and blocks the view of Eau Rouge for most Silver seats placed in the section closest to Eau Rouge – all some hard forgivable stupidities. In comparison I was at Hockenheim in 2006 and there the stadium offers perfect view and back supported seats for all spectators; actually the surrounding facilities like toilets, shops and exhibitions were better at Hockenheim too :-/

To be fair then its not all bad. In fact most of the middle and top Silver seats have a great view of the track section. I maneuvered my self to a position behind the top row of seats, and had probably the best view imaginable.

All in all it was a great trip and I will probably return there one day for more racing and beer and perhaps some waffles :-).

Selection of a Source Revision Control System

AFTER SOME TIME of using tarballing as a source revision control system, I thought it was about time getting back to using a real tool for managing my source code.

I’ve then used Perforce as my VCS for some time now. At work we are using ClearCase and from what I could gather form the Perforce documentation it seemed that Perforce would operate very much like ClearCase. However its clear now, that I’m not Perforce “compatible”. I find Perforce very unintuitive, and after a second time of having to resort to clearing my repository, after another fine [workspace] mess I’ve gotten my self into, Its clear that its time to try another system.

My new requirements to a VCS is that it must be FOSS and run on Linux, MAC OS X, OpenSolaris and Windows (I don’t use Windows but I can’t exclude that the need won’t come up some day). I also want to be able to work on the source without being connected to the repository server.

As this comparison chart on Wikipedia shows; one thing is sure: The world is not in lack of source revisioning systems.

After a lot of googling it seems that the hot contenders of the time are: Bazaar, Git, darcs and Mercurial.

Choosing the one over the other is extremely difficult as not much differentiate them from each other. They all have their niches where they excel compared to the others, but from what I can understand from their feature list, they will all be more than enough for my VCS needs.
Two candidates I could eliminate quite easy. The FOSS requirement is because I want to have the possibility to look around, and perhaps poke a bit, in the code. Git is primarily written in C, but my patience just don’t stretch enough to look into another C project written by a bunch of kernel hackers. Darcs is written in Haskell, and regardless of the “hotness” of Haskell I don’t have any intentions of learning that language. Thus candidates remaining are Bazaar and Mercurial.

Bazaar and Mercurial are so alike that its hard to believe that one did not just fork from the other. Searching the internet gave no reason to believe that the one is inferior to the other. So which is better? I think that is impossible to determine without hands on experience from both systems – and from what I can read on the internet, even this is not always enough to prefer the one over the other. Actually this makes me question the rationale of having two projects so similar. Competition is good, but if the one does not stand out from the other, why not join forces?

Lots of people talk of Bazaar and/or Marcurial. Here’s a page that’s pro Bazaar: My merry five minutes with Bazaar. And here’s a page that’s pro Mercurial: Distributed SCMs: Be Smart, Use the Bleeding Edge

To summarize my internet readings (here is a dedicated on-topic site), then I didn’t find any clearcut arguments for Mercurial over Bazaar other than perhaps speed and maturity level. Bazaar on the other hand seems to be regarded as having slightly more user friendly use-cases.

Mercurial have support from prominent projects like OpenSolaris, Mozilla, Plan 9 and Xen. Bazaar have Ubuntu. Not sure the merits actually mean anything though.

This site gave a good comparison of some high profiled VCS. Of my two candidates it only included Mercurial, but the comparison did include ClearCase which made it clear that Mercurial offered more or less the same feature set as provided by ClearCase.

The options seems clear. Keep tarballing, roll the dices or give both Bazaar and Mercurial a try… hmm I better give them a try ;-)

WP-Syntax and GeShi Color Tweaking

SOURCE CODE COLORING in WordPress is thankfully a pretty simple task, thanks to the WordPress plugin system. This allows for installing filters to do the coloring and formatting automatic. Several plugins exists for WordPress to do source code coloring, but (for now?) I’ve settled on the Wp-Syntax plugin. Not that its necessary better that the other options, but it does a pretty fine job, and I like the layout it presents.

However the default coloring scheme in Wp-Syntax is not to my taste, so I had to do some tweaking. Wp-Syntax uses the popular GeShi Highlighter as backend, and GeShi is highly customizable.

Wp-Syntax splits the source area on two columns with one optional column for line numbering and one for the source code. The formatting of the line numbering column and the boxes surrounding both columns are both configured separate from GeShi. The only thing required to style the non-GeShi things is to apply the desired formatting in the main css file (note that the Wp-Syntax css may override the GeShi css, e.g. color). All classes are documented on the Wp-Syntax notes page. Below is a snippet from this site configuration.

.wp_syntax {
  color: #404040;
  background-color: #F9F9F9;
  border: 1px solid silver;
  overflow: auto;
  margin-top: 10px;
  margin-bottom: 10px;
}
 
.wp_syntax .line_numbers {
  text-align: right;
  background-color: #46555D;
  color: orange;
  overflow: visible;
}

The GeShi part that formats the actual source code, requires a few more simple steps. The Wp-Syntax notes page, explains how to modify changes to the default GeShi color settings. I don’t find the method descriped that optimal. I would rather configure the coloring in sites css file. The steps required for this is described in the GeShi documentation. First step is to enable the use of css classes. The documentation states that this should be enabled right after instantiation of the GeShi object. This can be done by adding lines 2 and 3 in the Wp-Syntax file wp-syntax.php.

1
2
3
4
    $geshi = new GeSHi($code, $language);
    $geshi->enable_classes();
    $geshi->get_stylesheet();
    $geshi->enable_keyword_links(false);

Remaining is the actual css contents for defining the colors. Here the team behind GeShi excell by supplying a php script for generating the css code. If downloading the GeShi source the script is available as /geshi/contrib/cssgen.php. Following the three easy steps in the script generates the css ready to paste in the main css file.

Thats it! Colors tweaked.

Copyright © All Rights Reserved · Green Hope Theme by Sivan & schiy · Proudly powered by WordPress