Ein plass å skrive ned stuff / Somewhere to write stuff

Overview of how the Click Test DSL is implemented

2012-07-08T16:54:00.002+02:00

One of the main goals, while implementing this framework, was to make it as readable as possible, also for non-developers. Therefore most objects and methods have names which try to describe the GUI and the operations from a testers viewpoint, instead of using terms more common to developers.
Our DSL/framework has been developed as a set of Gui-object classes. They represent objects like: Button, Label, TextBox, DataGrid, DataGridCell, etc. All of these classes contain the commonly used operations and validations performed on these objects. Some of the objects also has a class whose name is pluralized; these classes return collections of the different types, like Labels, TextBoxes, etc. The pluralized classes mainly contain validations like AllShouldBeEmpty/HaveContent or AllShouldBeEnabled/Disabled.
All the object classes were created to hide away as much as possible of the MS UI Automation code and code which tries to simulate that it is a user doing these operations.
An example of an operation that simulates users waiting for the applicaion to be ready is the button click method: After actually clicking the button, the method will call Process.WaitForInputIdle() which waits for the application process to enter an idle state.
The actual MS UI Automation code is found in extension methods under AutomationCode, and it is these methods the object classes use. The MS UI Automation code is more or less just different ways to search for the correct AutomationElement, i.e. the actual element in the current application, or the correct pattern, like InvokePattern, ValuePattern or SelectionItemPattern.

Some more concrete samples:

GuiButton

The method Button("") in the superclass hides a call to a static method in the GuiButton class. That method runs the correct UI Automation searches and returns an object of the GuiButton class. This class then contains the AutomationElement for the button. The buttons have different action/validations methods:

The Click method will do a search for the stored AutomationElements InvokePattern, invoke the pattern and wait for the process to become idle.
The ShouldBeEnabled method will assert that its AutomaionElement.Current.IsEnabled property is true.
The ShouldBeVisible method will assert that its AutomaionElement.Current.IsOffscreen property is false.

GuiCheckBox

The method CheckBox("") works in the same way as the Button("") method. The GuiCheckBox class contains the AutomationElement of the checkbox and the TogglePattern for it.

IsChecked / IsUnchecked / IsIndeterminate returns the
AutomationElement.Current.ToggleState == ToggleState.On / Off / Indetermindate.
ShouldBeChecked / ShouldNotBeChecked asserts that the checkbox is in the correct state
Check and UnCheck executes the TogglePattern.Toggle method until the checkbox is in the correct state. So in practice, they cycle through all the possible states of the checkbox.

GuiComboBoxes

The pluralized version of the class for comboboxes inherits from List, and its static call will return all comboboxes whose identifier starts with a certain prefix. This class contains the following methods:

ShouldShow(params string[] values) which will assert that all the supplied values is the selected item of at least one combobox on the screen.
CountShouldBe(int expectedcount) asserts that the number of comboboxes is as expected.
SetValues(string[] selectValues) loops through the selectValues and sets them as the selected item in the different comboboxes. Note, there must be at least as many comboboxes as there are values to select.

Overview of how to use the Click Test DSL

2012-07-08T16:54:00.001+02:00

The click-test framework uses inheritance to make all methods available to the actual tests.
When starting to use the framework we recommend creating a super-class, for your project, that inherits from UiTestDslCoreCommon. This class should have property shortcuts for often used objects, and methods for UserControls created specially for your project. In our project this class has properties for the most commonly used datagrids, buttons without identifying text, some specialized usercontrols, and common operations like changing to a specific tab. This class also holds the StartApplicationAndLogin-method which is set to be the [TestInitialize] method.
The actual test classes inherit from the super class. This ensures that, when the test is about to start, the application is started and the user is logged in.
After the user is logged in, our tests then follow this pattern:

Change to the tab they are going to test
Setup of the specific test context
Perform the actions to test
Optional validation (failed validations will trigger a screenshot)
Close the application (Framework)

There is some validation built into the framework, so the tests won't always need explicit validation. These validations will detect unexpected exceptions by checking for open dialogs when the application closes. If any such dialogs are found, the framework will take a screenshot of the application and fail the test. We have set the DispatcherUnhandledException in our applications App.xaml to log the error and show a dialog with "Fatal error" for uncaught exceptions.
Another useful pattern is to start with a call to the method CreateNewUniqueIdentifier which assigns a new Guid to the property UniqueIdentifier. This text-string is then unique to the specific test run. We use this to test our automatching features, and to validate saving and retrieving of strings to our persistent data layer.
The actions and validations typically take the form <GuiObject>("<Identifier>").<Action>(...); where GuiObject is Button, Label, TextBox, etc; Identifier is the caption of the button, or name of the component; Action can be actions like Click or Type, or a validation call like ShouldBeEnabled, RowCountShouldBe or ShouldRead.
The Identifier of an object (other than captioned buttons) can be somewhat tricky to find. If you look in the code, it is most often the Name or AutomationId property of the object. Although this is not our prefered method, we prefer using the Inspect Objects-program from the Windows SDK download. Snoop will also show the AutomationProperties.AutomationId. Both of these applications allow us to find the identifier of a component in a running application.
Note: some action calls contain WaitWhileBusy and Thread.Sleep calls to allow the GUI time to respond to the simulated user interaction. This is something we quickly learned that was something we had to implement. Computer interaction is many orders of magnitude faster than human interaction, in addition to the fact that humans will normally wait for the screen to update after pushing a button. A computer will only do that if you tell it to.
Although we have implemented the most common actions and validations in the framework, others will surely miss some functionality. Since it now is a open source, anyone is invited to expand it with methods they feel should be there.
Please see my previous blog post for a code sample showing a complete test.

The framework also contains some control classes, which are used to start/stop the application, to find and run all tests if started as a command line executable, and a class that takes screenshots. Some of these classes require some setup, but after that you most likely will not look at them again. This setup mainly consists of setting path and filename for the executable, any code you would like to run before all tests, before or after each test, and adding naming options. The naming options we have added mostly consist of mappings between button captions to WPF Command Binding texts, or localized to English versions of the captions. The SampleProgram.cs in the github repository shows most of these.

Click-testing or Automatic Regression-testing

2012-06-28T12:22:00.000+02:00

Does your company test every feature of your desktop application before every release? How much time and manpower does this take?
My team develops a WPF application, that we release a new version of more or less every week. To find out more about our application, see http://www.delficert.com/. We are 3 developers, plus about a quarter of a job post for manual testing, but we still get more or less all features of the application tested. The way we manage to do this is by having an old recycled computer on which every build is deployed, and automatically regression-tested.
We have written a DSL/framework that encapsulates MS UI Automation and allows us to write readable testscripts. We are now releaseing this DSL to GitHub, so that other people can enjoy the same level of automatic testing that we now have. Check out this link: https://github.com/delfidata/clicktest
A goal of the DSL was to allow us to write tests that are hopefully just a little more detailed than the manual testscripts used by maual testers. This makes the tests more accesible to testers, who often are not developers, and it improves readability. Here is a sample of our testcode with a couple of images for context:

    ComboBox("cmbFieldList").SelectItem("PoNo");

    TextBox("txtSrcValue").Type("klikktest PoNo");

    PressEnter();

    DataGrid("SearchResult").SelectRow(0);

    Button("Edit Certificate").Click();

    // in the edit tab

    Button("Edit").Click();

    WaitWhileBusy();

    SleepIfOnTestMachine(2000);

    // actual test

    Image("ActualCertPage").RightClickMouse(-500);

    Image("ActualCertPage").LeftClickMouse(50);

    WaitWhileBusy();

This test was actually a test-driven bugfix of a bug we discovered in the gui-code, where right-clicking the mouse outside the expected points set the application in an error-state which made it crash on the next left-click inside the image boundary.
This test assumes that the test-framework/DSL opens the application, logs on, and opens the Search-tab, before running. After the test is run, the framework will verify that there is no error-dialogs showing, and that the application is not in an error-state. Last, it will kill the application, so earlier test-runs never affect the current. If it finds any errors, it will take a screenshot that we can use to pin-point the error, in conjunction with the application logs.
A nice feature is that we can start the application in Visual Studio, start the test-run, and get the exception in the debugger.
The code required to click a button in MS UI Automation looks like this:

void ClickButton(AutomationElement window, string name){
var searchConditions = new List {
    new PropertyCondition(AutomationElement.ControlTypeProperty, ControlType.Button),
    new PropertyCondition(AutomationElement.NameProperty, name),
};
var searchCond = new AndCondition(searchConditions.ToArray());
AutomationElement result = element.FindFirst(TreeScope.Descendants, searchCond);
if (result == null)
      throw new AutomationElementNotFoundException("Could not find element: ", searchConditions);
var invoker = result.GetPattern<InvokePattern>(InvokePattern.Pattern);
invoker.Invoke();
}

As of writing this post, we have 130 of these tests. The tests run in about 2 hours, doing them manually, we estimate, would take at least 2 full days. With the tests being run after every build, and a release schedule of once a week, this really saves us a lot of time.
Our tests test features like:

searching for certificates and deliveries
storing and editing all objects we handle in the application, and then verifying that they have been correctly stored in the database
compiling zip-packages of certificates and verifying that the zip-file is not empty
scanning certificates and attachments with a flatbed-scanner
drag-n-drop of files from Explorer to the application
typing strings in numeric fields
information labels show what they are supposed to show

The main huge advantage of this is that all the repetetive tests are run by a computer, and that frees our manual tester to do more constructive work. He still has to do a rough acceptance test, because we don't have a complete set automatic tests yet, and we think it is good to have some human eyes on the application before releasing it. He also does a manual test of all new features, so that all features are always tested by someone other than the developers.
Other things he is freed up to do are:

Test functionality that is not possible to test automatically, yet, like:

Visual confirmation that images are shown correctly

Exploratory testing
Find test-cases which are not automatically tested yet
Test and develop usability, workflow etc

Before anyone asks, of course we have unit tests for our code. The unit tests test the domain-layers, the web-service-layer and everywhere we can manage to use them. The tests, which this blog post is about, cover the view-layer, and through that, they also work as integration-tests for our entire system.

This was maybe a bit long for an introductory post, but I will be writing a few more blog posts about this framework and the tests we have, in the near future.

WPF, Notifications and Parallellism

2011-07-14T21:31:00.000+02:00

I'm working on getting our GUI responsive, which can be quite a challenge. We fetch a pdf or tiff over a wcf-service from the test-server running on a vm, rendering the first page and showing this to the user. We also have a strict policy on separating as much as possible into the domain-layer, and the domain-layer can not have any gui-classes. Fetching and rendering is done in the domain-layer, and the GUI is notified through the INotifiyPropertyChanged-mechanisms.
I've had several problems with the ownership of wpf-objects when a task in the domain-level sets a property which the gui subscribes to, and the gui then tries to redraw some metainformation in an overlay canvas. I've solved several situations by using TPL's ContinueWith-mechanism where the new task is run on the GUI-thread.
After working on a problem today, where images are fetched every time the user changes the selected row in a table, I started thinking if there is a better way to do this. If I could only get all notifications to run on the GUI-thread, without having to use TPL's ContinueWith...
So I've now created a small test-project that has some classes, a window showing info, and some extension methods that run all the notifications on the GUI-thread.
This is the essence of the extension methods:

public static TaskScheduler GuiContext;

public static void Notify(this PropertyChangedEventHandler self, INotifyPropertyChanged sender, string propertyName) {
if (self == null) return;
Task.Factory.StartNew(() => self(sender, new PropertyChangedEventArgs(propertyName)), CancellationToken.None, TaskCreationOptions.None, GuiContext);
}

The GuiContext field needs to be set on startup from the MainWindow, e.g. in the Loaded-event. It appears as though the extension-methods works like a charm.
I made the test-app start several threads that updates the objects in the controller several times, and as long as I allow the gui some cpu-time(put in some small sleeps in the threads), the gui is responsive and it updates the textboxes with values from the different threads.
I'm aware that just updating the same values from several threads is not a good idea, but for showing data in the gui I'm really just interested in showing the latest values, and I have control over cancellelation on the background tasks in the real application. So for the purpose of the test-app I don't think this is important.

I'm writing this post in the hopes that someone will take a poke at my project and tell me if they find any flaws or large weaknesses that I've overlooked. Here is a link to the project file.

Memory leaks while converting from bitmap to bitmapsource

2011-02-10T16:40:00.000+01:00

One project I'm working on is using TwainDotNet. It has been some work to get to work "exactly" like we want it to, but it's overall been a nice library to play with.
But today, I've been working on a memory leak... These bugs are really annoying to work on, but anyhow here is what I found out:
The problem is that the sample code and samples I've found on the internet for converting Bitmap to BitmapSource. The code usually looks something like this:

    image1.Source = Imaging.CreateBitmapSourceFromHBitmap(
        new System.Drawing.Bitmap(args.Image).GetHbitmap(),
        IntPtr.Zero,
        Int32Rect.Empty,
        BitmapSizeOptions.FromEmptyOptions());

This works fine, but it also creates a HBitmap in unmanaged memory that it doesn't free.
A better way to solve this is to store the HBitmap in a variable and call DeleteObject on it. DeleteObject is a function from gdi32.dll:

    [System.Runtime.InteropServices.DllImport("gdi32.dll")]
    public static extern bool DeleteObject(IntPtr hObject);

Here is the code I ended up with in our production code:

    private void TwainOnTransferImage(Object sender, TransferImageEventArgs e) {
        if (e.Image != null) {
            var bmp = new System.Drawing.Bitmap(e.Image);
            IntPtr hBitmap = bmp.GetHbitmap();
            image1.BeginInit();
            image1.Source = Imaging.CreateBitmapSourceFromHBitmap(
                hBitmap,
                IntPtr.Zero,
                Int32Rect.Empty,
                BitmapSizeOptions.FromEmptyOptions());
            image1.EndInit();
            image1.Source.Freeze();
            DeleteObject(hBitmap);
            bmp.Dispose();
            e.Image.Dispose();
        }
    }

Spotify Playlist Folders

2010-09-19T13:14:00.000+02:00

Eller kanskje egentlig: koffor har eg tømt Swing-spelelista mi på Spotify.
Spotify kom med ein ny funksjon for litt siden, "Playlist folders", tanken her er at du lager ein folder der du legger inn andre spelelister og får slik hierarkiske spelelister. Så istedetfor å ha ei speleliste som inneholder all swingmusikken min har eg nå fleire, og desse ligger i ein folder. Og vil eg høre på all swingmusikken så velger eg folderen som nåværende speleliste og får slik ein grei variasjon i ka swingmusikk som speles. I tillegg kan eg då ha spelelister som eg kan bruke når eg ska undervise, ei med sakte swing musikk, ei med rask, osb. :) I tillegg har eg endra navn på den gamle lista mi te å nå vere "Swing forslag" i håp om at nogen vil legge inn sangforslag der til meg, som eg igjen kan flytte over i dei spelelistene der eg synes dei passer. ;)

Oppdelingen eg nå har gjort blei for det meste gjort på bussen(offline lister) til Karmøy, og eg hørte for d meste bare kjapt på sangene før eg flytta dei, så eg rekner med at det blir litt meir rydding etterkvart. ;)

Her er linker til spelelistene mine slik eg har laga dei pr.nå:
Lister eg kommer te å bruke på kurs:
Swing Sakte, Swing Mellomtempo, Swing Rask, Swing Diverse, Hip-Hop-Swing, Blues
Andre lister:
For rask, Sakte ikkje kurs, Mellomtempo ikkje kurs, Rask ikkje kurs, Lindy Sakte, Lindy Mellomtempo, Lindy Rask, Charleston

Og eg har som sagt ei liste der eg håper folk vil legge inn forslag til meg: Swing forslag ;)

ConcurrentQueueWithWait

2010-07-21T00:05:00.005+02:00

For the time beeing, I'm working on a rather heavy computing problem at work. A normal case scenario has a computing time of about 1 hour, and a not unlikely, but bad scenario, has a computing time of about 7 hours. One "problem" is that I'm already using a pretty powerful computer:

Core i7 930 @ 2.80GHz (WEP 7.5)
2 striped Intel 160GB X25M 2.gen Disks (WEP 7.9)
12GB RAM (Operations WEP 7.5)

I've created several producers and consumers, and though I've done a lot of code optimizing I've got more to go on. My main clog on performance was the SQLite connection. SQLite is an embedded single-connection database, and I have some constraints on the interpretation of the data that forces me to write data more or less sequentially. This limits me too using one thread to execute the SQLiteCommands, and using the phx-lib, the SQLiteCommands is prepared only when execution is called. Preparing the commands is quite time consuming, so I've limited the queue of commands to avoid using more time than necessary on preparations. When a command is prepared I can change the values of the parameters without having to do the complete preparation step over again. I use the ObjectPool to generate and store the SQLiteCommands.
Have you ever worked with the Producer/Consumer pattern on several threads? If you have your code might haved looked something like this (pseudoocode):

Producer 1 and 2 (2 separate threads that I create several of)

while (work to do){

Do some calculations on obj

Lock (FirstLevelQueue(s)) { // one queue for both or 1 queue for each

FirstLevelQueue(s).Enqueue(obj)

}

Producer 3 and 4, that Consumes 1 and 2's queue(s)(2 separate threads)

while (producer 1 and 2 not done){

dequeued = true

while (dequeued) {

Lock (FirstLevelQueue(s)) { dequeued = FirstLevelQueue(s).Dequeue(obj) }

if (dequeued) {

Do some work on obj

while (SecondLevelQueue(s).Count > sizeLimit) Thread.Sleep(100)

Lock (SecondLevelQueue(s)) { SecondLevelQueue(s).Enqueue(obj) }

    } else if (some complex criterion) {
      Thread.Sleep(100)
    }

}

Consumer (5. thread)

while (producers 3 and 4 not done) {

dequeued = true

while (dequeued) {

Lock (SecondLevelQueue(s)) { dequeued = SecondLevelQueue(s).Dequeue(obj) }

if (dequeued) {

Do some work

    } else if (some complex criterion) {
      Thread.Sleep(100)
    }

}

I feel this code has a few weak points. First of all, locking is newer good since it takes time and it hinders consumers to dequeue for as long as anyone is queueing. Also in this code there is going to be a lot locks since all access uses this mechanism. Locking can also cause huge problems if you forget one or end up locking for too long, e.g. while sleeping. Second, the sleep statements are going to take a lot of time. In the code, on which I am working, I discovered that even a sleep as short as 10ms was way too long. Furthermore, since the sleep is so short the threads are going to wake up and consume quite a bit of resources while checking if there is any more work to do. Using .Net 4.0 and TPL(Task Parallell Library) you get a somewhat better and nicer code by using the ConcurrentQueue, which is thread-safe:

Producer 1 and 2 (2 separate tasks that I create several of)

while (work to do){

Do some calculations on obj

FirstLevelConcurrentQueue(s).Enqueue(obj) // one queue for both or 1 queue for each

}

Producer 3 and 4, that Consumes 1 and 2's queue(s)(2 separate tasks)

while (producer 1 and 2 not done){

dequeued = true

while (dequeued) {

dequeued = FirstLevelConcurrentQueue(s).TryDequeue(obj)

if (dequeued) {

Do some work on obj

while (SecondLevelConcurrentQueue(s).Count > sizeLimit) Thread.Sleep(100)

SecondLevelConcurrentQueue(s).Enqueue(obj)

    } else if (some complex criterion) {
      Thread.Sleep(100)
    }

}

Consumer(5. task)

while (producers 3 and 4 not done) {

dequeued = true

while (dequeued) {

dequeued = SecondLevelConcurrentQueue(s).TryDequeue(obj)

if (dequeued) {

Do some work

} else if (some complex criterion) { Thread.Sleep(100)
}

}

Now, this code looks a lot better since I'm rid of the locks. This reduces some common error points and the consumers do not stop the producers from enqueueing. But there is still a lot of sleep statements, and the threads often wake up to check if there is more work to do, and as stated, for my part, even a 10ms sleep were to long.
I decided that I really wanted code that looked somewhat more like this:

Producer 1 and 2 (2 separate tasks that I create several of)
while (work to do){
Do some calculations on obj
FirstLevelConcurrentQueue(s).EnqueueWithEvent(obj) // one queue for both or 1 queue for each
}

Producer 3 and 4, that Consumes 1 and 2's queue(s)(2 separate tasks)
while (producer 1 and 2 not done){
FirstLevelConcurrentQueue(s).TryWaitUntilDequeued(obj)
Do some work on obj
SecondLevelConcurrentQueue(s).EnqueueUpToLimit(obj)
}

Consumer(5. task)
while (producers 3 and 4 not done) {
SecondLevelConcurrentQueue(s).TryWaitUntilDequeued(obj)
Do some work
}

In my mind, this code is shorter and way more readable. In addition, the threads do not wake up all the time to check if there is some work to do. This actually makes the code more cpu efficient and gives you more cpu resources to do your other computing.

It didn't take me much googling to discover the AutoResetEvent, an easy-to-use, thread-safe event mechanism. Using the AutoResetEvent and the ConcurrentQueue I implemented a class I called ConcurrentQueueWithWait. I included this in the dll for ParallellExtensionsExtras, which we use at work, and after some tweaking and testing I ended up with this class:

public class ConcurrentQueueWithWait : ConcurrentQueue {
private AutoResetEvent _enqueuedEvent = new AutoResetEvent(false);
private AutoResetEvent _dequeuedEvent = new AutoResetEvent(false);

/// The size limit of the ConcurrentQueue, if you use EnqueueUpToLimit for enqueueing
public int QueueLimit { get; set; }

/// The timeout for Dequeue-events, and EnqueueUpToLimit-events
public int TimeOut { get { return _timeOut; } set { _timeOut = value; } }
private int _timeOut = 5000;

/// Sets both the Enqueue and Dequeue events twice to try to avoid any deadlocks
public void ProducerFinished() {
    _enqueuedEvent.Set();
    _dequeuedEvent.Set();
    Thread.Sleep(10);
    _enqueuedEvent.Set();
    _dequeuedEvent.Set();
}

/// Enqueues the item if the queue limit is not reached. If limit is reached it will wait until an item is

/// dequeued, and then enqueue.
/// Note: on a timeout it will enqueue wether or not the limit has been reached.
public void EnqueueUpToLimit(T item) {
    if (QueueLimit > 0 && base.Count > QueueLimit)
      _dequeuedEvent.WaitOne(TimeOut);
    base.Enqueue(item);
    _enqueuedEvent.Set();
}

/// Adds an object to the end of the ConcurrentQueue, and sends an event to anyone waiting to dequeue.
public void EnqueueWithEvent(T item) {
    base.Enqueue(item);
    _enqueuedEvent.Set();
}

/// Attempts to remove and return the object at the beginning of the queue. If none is found it will wait for

/// an enqueued signal, or timeout.
/// Should be used as a regular TryDequeue, but without the while(...) Thread.Sleep(xx)
/// Returns wether or not a dequeue was successful
public bool TryWaitUntilDequeued(out T result) {
    bool res = true;
    if (base.IsEmpty)
      res = _enqueuedEvent.WaitOne(TimeOut);
    if (!res) {
      result = default(T);
      return false;
    }
    res = TryDequeue(out result);
    _dequeuedEvent.Set(); //I do not need to check result here, since a false should equal an empty queue

//and therefore any pending enqueues should be fired
return res;
}

/// Attempts to return the object at the beginning of the queue. If none is found it will wait for an

/// enqueued signal, or timeout.
/// Should be used as a regular TryPeek, but without the while(...) Thread.Sleep(xx)
/// Returns wether or not a peek was successful
public bool TryWaitUntilPeeked(out T result) {
    bool res = true;
    if (base.IsEmpty)
      res = _enqueuedEvent.WaitOne(TimeOut);
    if (!res) {
      result = default(T);
      return false;
    }
    res = TryPeek(out result);
    return res;
}
}

I had to put in a timeout to avoid deadlocks both on enqueue and dequeue. In tests, which I've run on a small test-set(2 seconds run-time), I get the extra 5 seconds in about 1 out of 6 runthroughs, and I figure that 5 seconds extra don't matter much with run-times normally from 20 minutes and up.

This class meant that I ended up with this implementation of my tasks:

Producer 1 and 2 (2 separate tasks that I create several of)

while (work to do){

Do some calculations on obj

FirstLevelConcurrentQueue(s).EnqueueWithEvent(obj) // one queue for both or 1 queue for each

}

Producer 3 and 4, that Consumes 1 and 2's queue(s)(2 separate tasks)

while (producer 1 and 2 not done){

while (FirstLevelConcurrentQueue(s).TryWaitUntilDequeued(obj)) {

Do some work on obj

SecondLevelConcurrentQueue(s).EnqueueUpToLimit(obj)

}

Consumer(5th task)

while (producers 3 and 4 not done) {

while (SecondLevelConcurrentQueue(s).TryWaitUntilDequeued(obj)) {

Do some work

}

Not quite the easy and nice code I was hoping for, but really close enough to make me happy. My threads now only come out of sleep every 5 seconds or when there actually is some work to do.
Some minor problems with this implementation:

If I get a timeout on EnqueueUpToLimit I've set it to just enqueue anyway; so the limit I set on the queue is not absolute. My tests show that this is not a problem for my program, so I'm pleased with it.
I do get the timeout as an extra runtime in about 1 out of 6 times.
I still have to use the try-pattern.
If a bug finishes the 5th task before the 3rd and 4th, my program gets an extreme runtime since the 3rd and 4th constantly waits for the enqueue-timeout. This appeared to be a Heisenbug when I encountered it.
There is still some plumbing code needed, but way less than before.

Herlig påske og "ministoltzen"

2010-04-05T21:27:00.005+02:00

Då nærmer ein ganske så herlig påske seg slutten... Eg har fått spelt 1,5 dag med Army of two 40th day i lag m venner, eit par-tre dager med Dante's Inferno, eg fullførte siste. Og eg har til og med klart å få gjort ein del fornuftig i tillegg:
Rydda i ein haug m papirer, deriblant kikka gjennom sjølvangivelsen.
Gjort unna litt småting i leiligheten.
Fått lagt ut nogen ting me ikkje trenger lenger på Finn.no og faktisk fått solgt 1 ting allerede første dagen.
Rydda begge bodene, d e virkelig mye bedre når bodene e halvfulle i bredden ut frå alle veggene, istedetfor halvfulle i høyden. Før og etter bilder frå boden oppe:

I dag var me ute og gjekk tur, noge som me har fått gjort eit par-tre-fire gonger eller noge sånt i påsken, og i dag oppdaga me ei ny favorittrute. "Ministoltzen", ei rute som går ganske bra oppøve rett frå over veien. Me må gå opp på asfaltert vei te rett ovenfor Frode og Marianne, og videre derifrå kommer me over på ein natursti som e ganske bratt te å begynne med. Me gjekk eit stykke oppøve og bestemte oss for at der skulle me ha endepunktet på d som blir vår "vanlige" trimtur nå. Turen blir noge kortare og mindre bratt enn Stoltzen, men eg satser på at me kommer oss opp den løypa mye oftare enn Stoltzen, siden turen opp Stoltzen innebærer ein bortimot 7km sykkeltur kvar vei.
Utsikt frå Ministoltzen:

Helvetesøvelsen(Dans)

2010-03-07T22:01:00.000+01:00

Eg fekk ein mail frå Per for altfor lenge siden(3 veker) med sps om eg kunne sende han ein beskrivelse av helvetesøvelsen. Eg hadde bare ein kortvariant liggande men her ska eg prøve å skrive ein skikkelig beskrivelse av den.

Helvetesøvelse

I denne øvelsen skal G føre J i kryssteg/crossovers. G vil føre stega i forskjellig tempo, lengde, framover/bakover og føre spesielle figurar som bryter opp desse stega.
Dette er ein føringsøvelse som trener hovudsaklig ramme. Til å begynne med vil den ende opp med å trene opp noget stive armer, men etter kvart som ein blir meir avansert skal ein stå mest mulig i egenbalanse, og slappe mest mulig av mellom punktene der sjølve føringa skjer. Slik at ein trener kor lang tid det tar følger å reagere når fører begynner å føre. I tillegg gjer det fører bevisst på at dei faktisk må følgje med på kor følger er i sine bevegelsar når dei fører.
Ein kraftig forenkling av denne er at J lener seg litt mot G. Siden dei då automagisk må spenne opp armane for å ikkje falle på G.
Delen som går på å bryte ramme trener reaksjonsevnen, samt at den prøver å få folk frå å bruke denne øvelsen til å trene seg inn i fastlåste mønstre.

Variasjoner som kan gjeres i lukka

    * Crossovers tempo og lengde
    * Lukka med spinn
    * Til musikken – kan taes samtidig i åpen og lukka
    * Legge inn i dansen(veldig korte og kjappe steg) – kan taes samtidig i åpen og lukka
    * Halve steg
    * Bakover, husk halve òg her – mye d samme om denne taes i åpen eller lukka

Variasjoner som kan gjeres i åpen

    * Crossovers tempo og lengde
    * Til musikken – kan taes samtidig i åpen og lukka
    * Legge inn i dansen(veldig korte og kjappe steg) – kan taes samtidig i åpen og lukka
    * Halve steg
    * Bakover, husk halve òg her – mye d samme om denne taes i åpen eller lukka

Variasjoner som bryter ramme

    * Lukka: Få foten te å ”sveve” i lufta
    * Åpen/Lukka: Få til J til å ”sveve” og krysse bak G kne. Kan i lukka brukes som inngang til Sweep the floor
    * Lukka: Bakover til J ned
    * Lukka: Ned til sveip(J har foten i lufta bakover, G går rundt)
    * Åpen: Ned til J foten ut direkte bakover. Føring m tilbake og ut. Kan òg taes videre til sveip.

Tide busser i utide

2010-02-25T22:00:00.000+01:00

Med alt snøfallet i Bergen som nå har vart så altfor lenge så har eg nå ein periode prøvd å ta bussen te og frå jobben. Eg tok den ein kort periode før jul, og kjøpte meg eit månedskort etter jul. Når månedskortet gjekk ut så begynte eg å lure på kva alternativer som fantes te buss... 20min til jobb(buss+gange) gjekk forsåvidt greit, men det forutsatte at eg tok ein arbeidsrute-bussane som går til Haukeland. Desse går 0457, 0625, 0626, 0655 og 0725, som i lengden blir litt småtidlig. Dei var som regel ikkje meir enn 2-3min for tidlig eller mye over 5min for sein, så det å stå ute i eit drygt kvarter på det verste var vel kanskje det verste med den bussen.
Så var det him igjen då... Å gå tar 55min med snøen som ligger for tida. Den kortaste tida eg har klart med buss kombinert med gange er 40min, vanlig tid var sannsynligvis 1t10min. Dei lengste tok vel noge sånt som 1t45min... Dei to gongene som virkelig gjorde meg forbanna var fredag 8/1 der bussen som skulle ha starta å kjøre frå Bystasjonen kl 1740 ikkje dukka opp. 1745 fekk eg vite frå ei av dei andre som stod og venta på samme buss at ei venninne av henne hadde gått på bussen me venta på i Olav Kyrresgt. Venninna gjekk fram og spurte busssjåføren om koffor han ikkje hadde vore innom Bystasjonen, og fekk til svar at han hadde droppa det stoppet fordi han ikkje hadde hatt tid. Eg tok ein taxi den gongen og fekk igjen penger, mandag 1/2 derimot kom heller ikkje bussen til bystasjonen, eg meiner det var i 17-tida eg venta på den dagen òg. Den gongen stod vel eg og 15-20 andre og venta på den bussen som aldri dukka opp. I kundegarantien til Tide står det at du får dekka taxi om du blir 20min forsinka, når er du 20min forsinka? Er det når neste buss kommer 20min etter den du egentlig venta på, eller må du vente ein ekstra 5min for å sjå om denne dukker opp? Ei av dei som skulle tatt den bussen endte opp med å ta neste fordi det var ingen ledige taxier på bystasjonen mens me venta på neste buss. Eg må virkelig sei at det frister utrolig lite å ta buss når du ikkje eingong kan stole på at dei kommer til det bussstoppet dei skal starte å kjøre frå.

Det eg nå har endt opp med er å kjøpe meg piggdekk til sykkelen og sykle til jobb. Eg kan då for det meste sykle på fortauene eller sykkelstiane, men må bruke veien ein del. Har det nylig komt snø, så kan eg derimot bare glemme å sykle nogen aen plass enn på veien. Men, men eg bruker nå bare 20min til og frå jobb. Så eg sparer opptil eit par timer kvar dag. Litt fakta: sykkelturen e ca 4,3km, og eg har klart den på 10min på tørt føre med min gode sykkel.

Men nok om det å ta buss til jobb, det å ta buss generelt sett her frå Laksevåg er det jo massevis ein kan sei om. Dei kommer sjelden på den tida dei skal komme, og forundrande ofte så kommer dei 2 bussar samtidig, den på rute 70 som skulle gått for 10min siden og den rute 70 som skal gå nå, evnt rute 71 på begge eller ein av dei i tillegg til dei 2 70'ane.
Så var det rutetabellen frå Laksevåg, man-fre (-A: arbeidsrute, -7 rute 70, -1 rute 71):
Kl 04: 57-A   = Klokka 04:57 Arbeidsruta
Kl 05: 59-7
Kl 06: 13-7, 25-A, 30-7, 10-1, 26-A(1), 27-7, 55-A, 45-1, 57-7 (ja, dei står sånn i ruta frå Laksevåg/Fergeveien)
Kl 07: 10-1, 32-7, 26-A, 25-7, 37-1, 55-7, 52-7
Kl 08: 07-1, 25-7, 20-1, 37-7, 40-1, 50-1
Kl 09: 00-7,       10-1, 22-7, 40-1
Kl 10: 00-7, 00-1, 10-1, 22-7, 40-1, 55-1
Kl 11: 00-7,       10-1, 22-7, 40-1
Kl 12: 00-7,       10-1, 22-7, 40-1, 55-1
Kl 13: 00-7,       10-1, 22-7, 40-1, 55-A
Kl 14: 07-1, 08-1(1),    22-7, 38-1
Kl 15: 00-7, 05-A, 02-1, 08-1, 30-7, 38-1, 52-1
Kl 16: 00-7, 08-1, 30-7, 38-1
Kl 17: 02-1, 08-1, 30-7, 27-1, 38-1
Kl 18:            10-1,       40-7
Kl 19: 00-7,       10-1,       42-7
Kl 20: 00-7,       10-1,       42-7
Kl 21:              10-1, 27-7
Kl 22:            10-1, 50-7
Kl 23: 20-1
Kl 00: 20-1
Wow, når eg nå skreiv ned alle tidene så fant eg faktisk system i tidene på deler av dagen... Såklart dei delene av dagen det absolitt minst sannsynlig at eg tar buss, men dog... Eg liker spesielt å finne 2punkter(1) der faktisk samme ruten går med 1 minutts mellomrom. Og det er jo virkelig dei to tidspunktene på dagen det virkelig er mye folk som tar dei bussane, sikkert spesielt 14.07 og 14.08...
Ellers så er det jo ein ganske vanlig trend her at 2 busser går innenfor 5 eller 10 minutt av kvarandre, og så er det 20-30minutt te neste... Og det er ca det samme him igjen... Gåturen frå byen tar drygt 30min, så er været greit og bussen ikkje kommer innen kort tid frå me kommer til bussstoppet så ender det ofte med at me går.

Nei, eg må virkelig sei at busstilbudet må forbedres kraftig om eg ska ta buss på noge fast basis. Første krav er at bussane kjører frå alle stoppa dei ska kjøre frå, andre at dei er så godt som i tide, og eg skulle gjerne hatt eit lett system å forholde meg til for når dei går. At det går ein buss kvart kvarter frå 3minutt over heil, mellom kl 6 og 22 er tider det er lett å forholde seg til.
Men uansett så lenge eg ferdes i Bergen og det ikkje ligger snø overalt så kommer eg nok te å bruke sykkelen, det går MYE fortare enn noge anna. Du kan sykle nesten frå dør til dør, har lite problemer med å finne parkering, parkeringa er gratis og du trenger ikkje å gå langt frå parkeringsplassen til der du skal.

Gratis treningssentre åpnet i Bergen

2010-02-25T20:54:00.000+01:00

For eit par måneder siden åpnet værgudene gratis treningssentre over heile bergensområdet. Det er faktisk så mange av desse sentrene at du trenger maks å gå 10m frå døra di for å få deg ei solid treningsøkt.
Bare ta på deg dei varme klærne du allerede har handla inn for å overleve denne lange kuldeperioden, ta med deg snøskuffa som du sikkert har i kjellaren og gå ut og begynn å måke vekk snø... Dette trener armer, rygg og sikkert ein del kondisjon, trenger du å trene meir kondisjon og bein så er det bare å ta ein løpetur i den djupe snøen. Garantert kjempegod trening. Vil du trene mye styrke i beina i tillegg så lesser du opp eit akebrett eller ein aen form for slede med ein stor mengde snø eller is og løper i snøen med den på slep...
Begynner du å sleppe opp for snø å måke i nabolaget så trenger du sikkert ikkje vente veldig lenge før det kommer meir frå oven, og dei kommer og måker enten frå veien opp på sykkelstien, eller frå sykkelstien og opp på fortauet.

Serverkottet

2010-02-13T17:57:00.003+01:00

Disker bråker, mange disker bråker mye, mange disker som kjøles tilstrekkelig ned bråker veldig mye... Eg har nå komt sålangt at eg har installert Windows Home Server(WHS), tidlegare har eg hatt Windows XP på serveren, som eg hadde hacket til å kunne kjøre Software RAID5. Eg hadde tenkt å kjøre RAID5 når eg oppgraderte serveren, så eg kjøpte inn 7 1,5TB disker siden eg syntes d var eit greit antall i forhold til risk og størrelsestap når ein kjører RAID5. Mens eg holdt på å herje med WHS kom eg fram te at eg heller ville bruke WHS sin Drive Extender, dette gjorde at eg kunne bruke alle gamle disker eg hadde liggande og har nå endt opp med 16 disker i serveren.
Kabinettet hadde plass te 8, eg har satt inn ei Lian Li Drevramme som tar opp 3 5-1/4-toms plasser og gir meg 4 3-1/2-toms plasser, ei Sunbeam Wherever PCI-rack som eg bruker til ein disk, og i tillegg har eg montert ei ramme på utsiden med 4 disker. Den eine av dei 8 originale plassene har eg latt stå åpen for å få bedre luftgjennomstrømming.

Så var det det eg virkelig har brukt MYE tid på i d siste: Kjøling... Problemet blei hovedsaklig å få dytta ut nok varmluft samtidig som det ikkje bråkte som eit helvete.
Mine første forsøk var å prøve å få kobla sammen eit par lufterør og koble desse på rett utenfor viftene eg kjøpte. Viftene eg kjøpte var ganske så kraftige 228m3/t, 2x136m3/t og den siste som drar luft inni kabinettet på 149m3/t. Tanken min er at desse viftene skal sammen skubbe ut den varme lufta og hente inn kald luft frå slissa nederst i kottdøra, altså veldig nærme golvet.

Her har eg klipt eit hull i røret øverst og teipa det andre fast i d første. Dette gav ganske langt frå nok effekt, i tillegg til at det bråker ein del meir enn løsningen eg endte opp med.
Det eg tror var grunnane til at dette ikkje fungerte skikkelig er for det første at eg ikkje lagte koblingene mellom røret og viftene tett nok, for det andre så tror eg at lufta delvis sirkulerte i røret meir enn den blei skubba ut.

For å dempe lyden(vibrasjonsstøy og vifteulyder) ut frå kottet så har eg kledd alle hulrom i døra med 2cm motoromsisolasjonsplater, og lagt dempepapp utenpå ein del av dette igjen. Eg kjøpte i tillegg ei 1cm tjukk motorromsisolasjonsplate frå biltema, siden denne har lim på eine sida og ergo fint kan brukes til å festes ein del knotete plasser. Eg har lagt litt inni røret øverst, festa noge under gummiføttene til kabinettet og festa litt på utenpå røret heilt ytterst mot døra. Dei siste bildene her til høyre viser òg koss eg løste problemet med at lufta sirkulerte. Eg satte inn ein T-kobling på røra og strakk 2 "lange" rør for å få flytta lufta. I tillegg har eg fått laga det til slik at det er ganske tett rundt viftene. Eg har brukt borrelåsteip for å lage fester og brukt sølvteip til å lage bevegelige "tøystykker" som er lette å feste rundt viftene. Takk og lov for at Clas Ohlson har billig sølvteip.

T'en eg satte opp her eg laga ein "vegg" inni for å få lufta te ikkje ha ein lettare vei inn i d andre røret + til å ha støypapp på for å drepe litt av lyden som går gjennom røret.
Andre ting eg har prøvd er å legge i biter av svamp i røret nær utblåsingen, lagt i høytalerisolasjon for å dempe støyen gjennom røret. Eg la inn eit tynt lag med svamp og høytalerisolasjon for å dempe luftsuset, men desse sperra rett og slett for mye for luftstrømmen.

Ytterst i døra har eg satt inn ein ventil som på bildet her. Eg prøvde først å ha ein ventil med riller, men eg syns at luftsuset gjennom denne blei for mye, den typen eg har endt opp med synes eg er mye stillere.
Nå har eg fått alle klærne tilbake til kottet og dei tar òg av noge støy, så nå er eg egentlig komt så langt at det er bare luftsuset som står tilbake som støyen frå serveren. Luftsuset er heldigvis ikkje verre enn at ein må lytte litt for å høre det om ein er i eit anna rom enn gangen, og lukker ein døra inn til rommet der du sitter så er lyden så godt som heilt borte.

Om nogen har tips til koss eg skal få fjerna luftsuset uten å sperre for all lufta sånn at ting bare blir varmt inni der så kom gjerne med dei. Det hadde vore heilt konge å fått dette heilt stille, uten at det blir kokvarmt inni der...

"Trying to drink from the firehose"

2009-11-05T14:49:00.000+01:00

http://www.dotnetrocks.com/default.aspx?showNum=476
Denne podcasten var utrolig interressant. Det blir her stilt mange "store" spørsmål som går direkte på oss som programmere, og industrien generelt. Sjølv om mange av problemstillingane og eksempla er .Net-sentriske betyr ikkje dette at spørsmåla ikkje er relevante for programmerere uansett kva språk dei jobber med.
Det var òg her eg hørte sitatet som er overskriften her. Betydningen av uttrykket kommer frå det å prøve å klare å følge med på absolutt alt som kommer av ny teknologi innen programmeringsverdenen, innenfor "alt" eller innenfor ein spesifikk bit med basis i ein spesifikk teknologi, som f.eks .Net-verdenen.

http://www.dotnetrocks.com/default.aspx?showNum=300

Richard Campbell forteller mye rart frå han starta å mekke på elektronikk som 10-åring og oppover til i dag. "Computers are amplifiers, they can amplify your intelligence or your stupidity, which do you prefer?"

http://www.hanselminutes.com/default.aspx?showID=200
Her får ein høre ein del tanker og ideér frå ei av dei som var med og utvikla web'en til det den er i dag. Eg synes ofte det er ganske interressant å høre kva tanker som gjekk gjennom hodet på folk som var med og utvikla ting på eit så tidlig tidspunkt.

http://www.hanselminutes.com/default.aspx?showID=193
StackOverflow tenker tydeligvis mye nytt i korleis ein skal lage forumsider som fungerer, og dei har jo fått ganske bra suksess med det. Her forteller ein av utviklerane om ein del av dei problemstillingane dei har jobba med.

Fotomesse Bergen

2009-10-18T13:43:00.002+02:00

Eg var på fotomessen i Bergen i går og var der på eit foredrag av Ole Jørgen Liodden, han hadde nogen virkelig gode naturbilder, så eg fant ut at eg måtte rote fram eit par av dei og legge dei her sånn at andre kan få gleden av å oppdage dei. ;)
http://www.naturfokus.info/index.php?option=com_content&view=article&id=31&Itemid=61
Bloggen hans:
http://naturfokus.info/wordpress/
Her var det enda fleire bilder, velg logg inn som Guest. Det var MYE bilder her dog, så eg lista opp eit par eg likte godt under hovedlinken her.
http://bildeweb.naturfokus.no/wshowb.aspx?
http://bildeweb.naturfokus.no/kikkebilder/2009030269.jpg
http://bildeweb.naturfokus.no/kikkebilder/2008070915.jpg
http://bildeweb.naturfokus.no/kikkebilder/2008070648.jpg

ZeroConf / Bonjour

2009-10-18T13:25:00.003+02:00

Eg har kikka litt på ZeroConf / Bonjour for .Net i d siste. Eg lurte litt på om det var passande å bruke i eit prosjekt på jobb, men eg har nok komt fram til at d blir litt overkill for det prosjektet...
ZeroConf er eit bibliotek som legger eit lag over dns'en for å få programmer til å "finne kvarandre". Såvidt eg har forstått det skal ein definere ein servicetype som f.eks. serversoftwaren din annonserer at den har, og så vil du på klientsiden lett kunne få opp alle servere som annonserer at dei har den servicetypen. Eit eksempel på kor dette er brukt er i iTunes der programmet skal oppdage delte bibliotek frå instanser av iTunes som kjører på andre maskiner i ditt lokale nettverk.
Der eg har komt fram te at eg synes dette er mest nyttig er om me i framtida skal lage eit sett med servere der redundans og oppetid er veldig viktige tema. Muligheten til å sette inn ein ekstra server som automatisk blir oppdaga og synkronisert er ein veldig interressant strategi. Det vil gjere det veldig enkelt å få opp ekstra servere både for redundans og lastbelastning.

Her er eit par linker for interresserte:
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/NetServices/Introduction.html
http://developer.apple.com/networking/bonjour/index.html
http://zeroconf.codeplex.com/
http://developer.apple.com/networking/bonjour/download/
http://code.google.com/p/zeroconfignetservices/

Koffor lage ein blogg?

2009-10-18T13:15:00.001+02:00

Eg har fundert litt på om eg skal lage ein blogg ei stund, og siden eg har dreve og satt meg inn i mye ny teknologi i det siste så fant eg ut at ein blogg var ein grei plass å skrive ned ting eg driver og kikker på.
Så denne bloggen blir eit sammensurium av ting eg driver og kikker på, både på jobb og innenfor mine (altfor)mange hobbyar. ;)