Det bliver talt meget om overførselsindkomster for tiden. Og mange politikere har gennem årene udtalt at det skal kunne betale sig at arbejde, uden at gøre noget ved problemet.

Der er rigtigt mange mennesker mennesker som lever på offentlige ydelser. Og endnu flere, som lever at at administrere disse ydelser, kontrollere modtagerne eller forsøger at gøre dem arbejdsparate til de jobs som ikke er der.

Det kan gøre meget enklere.

• Afskaf kontanthjælp, su, folkepension, førtidspension, boligsikring og andre lignende socialydelser.
• Giv alle myndige danske statsborgere,  et skattefrit beløb på f.eks kr. 6000,- pr. md.
• Indfør flad skat på f.eks 50% og fjern alle fradrag.
• Tilbyd job til alle som ikke selv kan finde et arbejde. Et fuldtidsjob som giver yderligere f.eks kr. 6.000 skattefrit pr. md.

Hvad vil det betyde?

• En væsentlig offentlig besparelse på administration og kontrol af overførselsindkomster og personskat
• En højere livskvalitet, for de mennesker som ellers føler sig overflødige.
• Et højere offentligt serviceniveau, da der nu er personale til at udføre de opgaver som der ikke er råd til i dag.
• Bedre konkurrenceevne over for lavtlønslande,  da det vil kunne betale sig at tage et job til lav løn.
• Bedre forhold for iværksættere og små virksomheder i yderområderne.

Det er slet ikke så svært.

/P

Introducing PyG3T

PyG3T (Python gettext Translation Toolkit) is a very useful suite of python based command line tools for gettext translators. It’s developed by Danish translators Ask and Kenneth and it’s been a great help for me for quite some time – recently there was a new release adding even more tools to the suite.

PyG3T includes among others the following tools:

• podiff for creating diffs
• gtgrep which allows you to grep in PO files in msgid or msgstr only and ignoring accelerators
• poabc checks for common mistakes, inconsistent punctuation etc.
• gtmerge provides an alternative for msgmerge, for merging PO/POT files
• gtxml checks for ill-formed xml

Installing PyG3T on openSUSE

1) Download the tarball and uncompress it
2) Enter the resulting folder and run ‘python setup.py bdist_rpm’. This builds an RPM in the ‘dist’ subdir
3) Install the resulting RPM e.g. with ‘zypper install /path/to/pyg3t-0.3.1-1.noarch.rpm’
4) Each tool has a useful help page, try e.g. ‘gtgrep –help’
5) Enjoy

Vi har som mange andre en tæt pakket kalender med hensyn til familebesøg og spisning i julen. Foruden  juleaften og 2 familejulefrokoster mellem jul og nytår, så har vi også lige to fødselsdage mellem jul og nytår. Så der er rigeligt tid til at se familien til bords i lidt forskellige konstellationer. På min fødselsdag d. 30 december skulle det være anderledes i 2011. Jeg valgte familemiddagen fra og tog i stedet min ældste søn på knapt 8 år med til København for at se Copenhagen Suborbitals rakettest. Det blev superhyggeligt. Togturen blev brugt til at læse Harry Potter højt for min søn, og det lod til at der var flere andre der hørte med. Til selve rakettesten var der mødt omkring 150 tilskuere op. Vi stod på måske 150 meters afstand fra betonafskærmningen til de to rakettests, der blev udført med en times mellemrum. Lyden var voldsom og kunne mærkes i brystet – især LES-testen, som afbilledet. Det var godt, at jeg havde taget høreværn med til os. Især for unge ører, der jo hører væsentligt bedre end gamle og koncerthærgede ører.

Peter Madsen tog sig tid til at underholde pubklikum i pausen mellem de to rakettests. Det blev blandt andet til en historie, der sammenlignede Copenhagen Suborbitals teknologi med tyskernes V2-raketter under anden verdenskrig. Peter fik historien fortalt således, at den fængede både mig og min søn, så ingen tvivl om, at Peter er en erfaren foredragsholder. Jeg får mulighed for at gense ham allerede d. 18. hvor Crisplant hvor jeg arbejder, har inviteret ham til at holde et inspirationsforedrag. Fint at kunne være med til at støtte Copenhagen Suborbitals på den måde også.

Efter rakettestene og den opligatoriske fotosession af hele holdet foran raketten bagefter var der åbent hus i HAB. HAB er Horisontal Assembly Building – en gammel rusten uopvarmet rundbuehal. Intet fancy tværtimod. Hele miljøet på det forlængst nedlagte B&W værftområde er der hvor alle actionfilm ender. I dette tilfælde er det her hvor actionen starter.

Vi fik set rakettests med drøn på, så nytårsraketterne dagen efter virkede noget tamme i sammenligning. Så vi havde blot fejret nytåret en dag for tidligt.

Peter Toft har talt om det.
Siden har KanalTux (og Peter Lyberth) berørt emnet i deres 2. og 3. Hangoutcast.

The never ending story

… og tilbage i 2009 var der også debat og ideer.

Jeg taler selvfølgelig om organiseringen af det danske Open Source miljø.

Nu ser det ud til at der sker noget konkret. SSLUG, DKUUG, KLID og PROSA arrangerer et debatmøde i København på mandag d. 9. januar kl. 17. (Tilmelding og info: http://kortlink.dk/ab46.)
Som udgangspunkt ikke et møde med højtflyvende ideologiske overvejelser, men med en helt konkret problemstilling/arbejdsopgave:
Én fælles kalender for open source-aktiviteter i Danmark?

Jeg glæder mig!

Efter min henvendelse til Jens Schovsbo om afgørelsen vedrørende ergoconsulting.dk har jeg nu fået svar fra Klagenævnets Sekrætariat.

Klagenævnet har modtaget Deres e-mail af 4. januar 2012, hvori De rejser et spørgsmål til klagenævnets afgørelse af 2. januar 2012 af sag 2011-0179 (ergoconsulting.dk). Klagenævnets omtalte afgørelse er begrundet, og klagenævnet kommenterer ikke efterfølgende sine afgørelser.

Det er jo klar tale. Men jeg vil nu stadigvæk gerne vide om Klagenævnet har undersøgt hvordan Paten- og Varemærkestyrelsen betragter indsigelsen mod det relevante varemærke. Så nu prøver vi med aktindsigt.

In KDE e.V. (which is to KDE what SPI is to Debian, Jenkins and others) there is some times a need to vote. For example about accepting new members. Mostly about accepting new members. With the new vote system (ballot.kde.org), voters need to do a bit more to check their votes afterwards. basically

• Take username
• Your own secret
• The vote token

and sha256 it in the right order with the right separator chars and so on.

All sha256 sums are published together with where the vote was, so voters can verify that they are counted correctly.

After failing to construct a couple of times on the command line, I decided to write a small GUI app to help me instead.

There it is. Nice. Simple. Effective.

Sources available. http://quickgit.kde.org/?p=scratch%2Fsune%2Fkrapyl.git&a=summary – have fun, and remember to verify your votes.

I andledning af en afgørelse i Domæneklagenævnet vedrørende ergoconsulting.dk har jeg skrevet følgende email til klagenævnsmedlem Professor, dr. jur. Jens Schovsbo:

Som aktiv deltager i debatten vedrørende danske domænenavne skimmer jeg
ofte Domæneklagenævnets afgørelser. Jeg har et principielt spørgsmål
vedrørende en af sagerne afgjort den 2. januar 2012 jeg håber du kan
hjælpe mig med.

Det drejer sig om domænet ergoconsulting.dk hvor klager samtidigt
overfor Patent- og Varemærksestyrelsen har gjort indsigelser over
indklagedes varemærke.

Burde Domæneklagenævnet ikke have afventet en afgørelse fra PVS og
anerkendt indklagedes varemærke indtil det var blevet ophævet? Efter min
opfattelse må PVS være at betragte som den kompetente myndighed til at
foretage denne afgørelse og ikke Domæneklagenævnet?

Hvis jeg får et svar kunne det måske bruges som oplæg til en diskussion.

I enjoyed 2011.

My kids are growing steadily, and seem to enjoy themselves and their new social circle here in Måløv, where we’ve lived for a year and a half now. Maise (turning six next week) is starting school this fall, and is very much looking forward to it.

My team at work got some pretty cool goals under the belt during 2011. Even if stuff seems to take forever when you’re in the middle of it, you actually get somewhere when you look at the grander scheme of things. I’ve also got a lot of interesting stuff ahead of me in the year to come, so work shouldn’t get boring the first few months.

Anette’s still pregnant, and we’re expecting a boy at the end of winter - I’m keeping my fingers crossed that we’ll avoid February 29th.

I have a recurring new year’s resolution about »drinking more champagne«, which I’ve pretty much failed again last year. I’ll give it another go in 2012. It’s also occurred to me, that I’ve never seen a national football match (soccer, to you guys outside Europe) up close and personal, so a second resolution is to do that before 2013.

A third one could be to go to bed earlier…

 -module(myq).

 -export([push/2,
          empty/0,
          pop/1]).
 -type t() :: {fifo, [integer()], [integer()]}.
 -export_type([t/0]).

 -spec empty() -> t().
 -spec push(integer(), t()) -> t().
 -spec pop(t())     -> 'empty' | {'value', integer(), t()}.

 empty() -> {fifo, [], []}.

 push(E, {fifo, Front, Back}) -> {fifo, Front, [E | Back]}.

 pop({fifo, [E | N], Back}) -> {value, E, {fifo, N, Back}};
 pop({fifo, [], []})        -> empty;
 pop({fifo, [], Back})      -> pop({fifo, lists:reverse(Back), []}).

 -module(u).

 -compile(export_all).

 -spec f(myq:t()) -> myq:t().
 f(Q) ->
     case Q of
         {fifo, [], []} ->
             myq:push(7, Q);
         _Otherwise ->
             Q
     end.

 -type t() :: {fifo, [integer()], [integer()]}.

 -opaque t() :: {fifo, [integer()], [integer()]}.

 u.erl:9: The call myq:push(7,Q::{'fifo',[],[]}) does not have an
      opaque term of type myq:t() as 2nd argument

Den 31. Oktober 2006 kl 21:06 blev det første indlæg posted på det danske Ubuntu supportforum. Det var den spæde start på et forum der siden har udviklet sig meget.

Forummet har pt. over 5000 brugere, og i dag nåede de endnu en milepæl. Der er dags dato blevet skrevet ikke mindre end 100.000 indlæg! Det må jo betyde at de har gjort et eller andet rigtigt.

Tillykke til de mange aktive brugere, og ikke mindst de dygtige supportere! Godt gået, og held og lykke med de næste 100.000!

Hej alle sammen

Ja, min blog har ligget død en rum tid efterhånden, og det er jeg egentligt meget ked af, eftersom jeg har været utrolig glad for at blogge, og ikke mindst alt den feedback jeg har fået på mine indlæg.

Sagen er den, at jeg i foråret 2011 blev ansat hos tøj- og modevirksomheden BON’A PARTE, og tiltrådte 1. september som E-commerce Manager med ansvar for webafdelingen.

I løbet af sommeren fik jeg også mig et par tvillinger, så med tre små børn og et krævende job bliver der ikke meget tid til at blogge

Jeg håber på at genoptage arbejdet med bloggen så småt igen, men hvor fokus førhen lå på Ubuntu, bliver fokus fremadrettet snarere e-handel og/eller webudvikling samt online markedsføring.

Jeg mister sikkert en masse af mine gamle læsere, men håber til gengæld at kunne vinde nogle nye

So. Recently I blogged about Network status aware apps, and some time later, I got asked by a developer “How do I see if I’m online if I’m not using network manager?” and I replied with some dbus commands and he shook his head in despair. So, I ended up writing a small plasma widget targetting developers and very powerusers that can tell you the current state of the network and offers to add yet another ‘manual’ datapoint to the network status.

So. In line with another blog post of mine about getting the small utilities we all write and just let stay in a drawer (or somewhere in ~ on a local computer), I’m announcing it’s existance. That application became famous and even mentioned in Linux Weekly News, but I don’t expect that here. But anyways, here it is: http://quickgit.kde.org/?p=scratch/sune/networkstatus.git.

And a picture of it, it is not pretty but well, it’s a tool mostly for developers, not for end users.

Have fun, and I hope to see more of these small projects from various people.

Introduction

The unit test is the lowest common denominator. We can use them, but they are cumbersome and they only peek once into the fabric of our work. A better solution for many tasks, namely Property Based Testing exists for Erlang. This post is an example of how to use the statem type of test, mainly because there are so few of these out there. The outset is this: We will randomly generate operations on a priority queue and then validate that these operations are correct according to a simpler model.

The setup was that Michael Truog had a nice library of (min) priority queues which he had written (see okeuday/pqueue) He was mostly interested in how they benchmarked, but before benchmarking, you need to have some kind of knowledge that your PrioQ is correct indeed. Otherwise, you may just return the value 42 on each output and claim that this is the "right" thing to do. So the system under test (the SUT) is the various priority queue implementations by Michael. In order to test them, we need a model of a priority queue though.

The model of a SUT is some code we write which can reflect the observations of the SUT. In the case of a priority queue, there is a very simple model we can choose. We can simply base it upon a naive priority queue. The idea is then, that our PrioQ is easy to write but it may not be particularly fast. If an error shows up, it means that the SUT and our model will disagree (hopefully) and we can figure out if the problem is with our Model or the SUT.

We are going to use PropEr. The choice could equally well have been Erlang QuickCheck though, with minor changes. Both tools reflect the same interface for this kind of work, even though their real working might be slightly different in practice.

Note: All code is in Michaels repository linked above. If you want to digest the code yourself, go read it there - after having read this blog post. I've pulled out the important parts, but eh real repo has a bit more code in it.

Building the model

The model in this case is fairly simple. When constructing the model you need to have an idea of what you are going to test for. The goal is to get the model as small as possible while still being able to handle everything you may need. On the other end of the spectrum, you build up a model that is a complete specification - which can in some cases actually mean your model will be larger than the SUT. But in this case the model is way smaller and simpler than the queue it tests.

For this particular example though, we are very lucky. Essentially our example is a complex implementation (implementations) of a simple idea. So our model goes for reflecting the simple idea instead.

Let us write a priority queue to serve as the model. Our representation is [{priority(), [element()]}] that is a list of tuple-pairs where the firstelement is a priority and the second element is the list of values we are storing under that priority. We require that the list is sorted by the priorities. This makes lookup a bit faster.

Insertion is awfully simple. Just skip until we hit the right spot and inject the value:

%% A listq is a sorted list of priorities
listq_insert({P, V}, []) -> [{P, [V]}];
listq_insert({P, V}, [{P1, _} | _] = LQ) when P < P1 ->
    [{P, [V]} | LQ];
listq_insert({P, V}, [{P1, Vs} | Next]) when P == P1 ->
    [{P, Vs ++ [V]} | Next];
listq_insert({P, V}, [{P1, Vs} | Next]) when P > P1 ->
     [{P1, Vs} | listq_insert({P, V}, Next)].

Note that if we get a hit on the priority, we just add the next value in the back. This is slow, but we don't care since we only need the model to carry out tests. Now, converting a prioq to a list is easy. So is taking the length of a priority queue in the model:

listq_to_list(L) ->
    lists:concat(
      [ Vals || {_Prio, Vals} <- L]).

listq_length(L) ->
    lists:sum(
      [ length(Vs) || {_Prio, Vs} <- L]).

There! Michael have two ways to remove elements from a priority queue. The first is the common solution where you remove the next element. Note that if the queue is empty then the result is an empty queue. Also note, we don't return the removed element. This semantics seem a little odd to me, but on the other hand, it is better to make the model reflect the expected behavior here:

listq_rem([]) -> [];
listq_rem([{_P, [_V]} | Next]) -> Next;
listq_rem([{P, [_V1 | Vs]} | Next]) -> [{P, Vs} | Next].

Michael also have a variant where we remove an element of a given priority. We can simply dig through the list until we find the desired priority and then remove an element from that one. If there are no more elements left of that priority, we kill the pair:

listq_rem([], _P) -> [];
listq_rem([{P, [_]} | Next], P) -> Next;
listq_rem([{P, [_ | Vs]} | Next], P) -> [{P, Vs} | Next];
listq_rem([{P1, Vs} | Next], P) -> [{P1, Vs} | listq_rem(Next, P)].

Finally, we need to be able to peek into the queue. There are three variants. We can peek for the minimal element. We can peek for the element with a given priority, or we can peek for an element but also obtain its priority in question:

listq_peek([]) -> empty;
listq_peek([{_P, [V | _]} | _]) -> {value, V}.

listq_prio_peek([{P, [V | _]} | _], P) -> {value, V};
listq_prio_peek([{_P1, _} | Next], P) -> listq_prio_peek(Next, P);
listq_prio_peek([], _P) -> empty.

listq_ppeek([]) -> empty;
listq_ppeek([{P, [V | _]} | _]) -> {value, V, P}.

Making a gen_server to drive the SUT.

Strictly speaking, this example does not need a properstatem test. You could just build up the priority queue by using valid operations and then make tests. But to illustrate the use of statem we have built a simple driver for a priority queue. This code is in okeuday/pqueue/src/queuesrv.erl and it is not that interesting. We just have a separate process which keeps track of the internal state of the priority queue for us. This means, that we can only observe the queue_srv by means of what we prod it to do and what it answers with.

You can have a look at the code, but it is not that interesting. It merely reflects what operations are allowed on a priority queue.

Introducing the StateM behaviour

We need a bit of work in order to support the proper_statem behaviour:

-module(pqueue_proper).
-include_lib("proper/include/proper.hrl").
-behaviour(proper_statem).

-export([command/1, initial_state/0, next_state/3, postcondition/3,
    precondition/2]).

The next part is somewhat wrong, from a type perspective. I should probably change it. The state is tracked far too broadly here, but the code will still function properly.

-type value() :: integer().
-record(state, { in_queue :: [{value(), term()}] }).
-define(SERVER, queue_srv).

Now we are at the point where we need to handle the given callbacks from proper_statem. The first one we will be attacking is the command/1 which states what commands are eligible for firing. But before doing that, we need some helpers:

priority() -> integer(-20, 20).
value() -> integer().

This is a generator of priorities and one of values. Michael decided that priorities should be in the range -20 to 20, so we reflect that in our generator. The values are always integers, but they have no bound on the other hand.

priority(InQ) -> elements([P || {P, _} <- InQ]).

Given a queue, we extract all the priorities from that queue. And then we use elements to select one at random. This is a generator of existing priorites that are already in the queue. Then there is the initial state of the system, which is the empty priority queue:

initial_state() -> #state { in_queue = [] }.

Commands

Now we are ready to define the command function. It is keyed by the current state, so we can take that into consideration as well. It may be that the current state limits what commands are eligible for firing.

command(#state { in_queue = InQ }) ->
    oneof([{call, ?SERVER, in, [value()]},
           {call, ?SERVER, in, [value(), priority()]},
           {call, ?SERVER, is_empty, []},
           {call, ?SERVER, is_queue, []},
           {call, ?SERVER, len, []},
           {call, ?SERVER, out, []}] ++
          [{call, ?SERVER, out, [priority(InQ)]} || InQ =/= []] ++
          [{call, ?SERVER, pout, []},
          {call, ?SERVER, to_list, []}]).

We generate calls to ?SERVER which is our queuesrv genserver construction. We use the already given generators to generate random values and priorities where applicable. Note the trick [priority(InQ) || InQ =/= []] which is a degenerate list comprehension. The list is [] if InQ is empty. Otherwise it uses the priority/1 function from above to pick a random priority to remove among those already in the queue.

Updating our model

Now, assume we have run an operation on the SUT with the command/1 callback. Then our model needs to be updated with the same value as well. Otherwise we could not check for correctness. The function next_state(State, Ret, Call) reflects this change. The three parameters taken are the current State of the model, the return value of the operation we invoked, and Call describes the command we executed.

Note: There is one very important thing with the next_state/3 function. It is used twice internally in PropEr/QuickCheck. First it is used in an abstract mode where all values are symbolic in nature. That is you can not rely on a return value being a "real" value. Rather you must only transfer values around without discriminating on them. Secondly, the function is used concretely when you are running the test cases. The notion used is symbolic and dynamic respectively. Just keep this in mind when you write your own tests. Since you may be executing this with symbolic values, it is limited how you can discriminate values as they may be symbolic in nature.

Here is the first clause:

next_state(#state { in_queue = InQ } = S, _V, {call, _, out, []}) ->
    S#state { in_queue = listq_rem(InQ) };

This means we had a call to out/0 on the queue and we should remove an element from the queue. We can then call our own listq_rem/1 function to track this operation in our own model state. Note also that some of the clauses are not going to update the state since the calls generated does not alter the state. Also note that we sometimes look inside the call to figure out what values were generated as input so we can transition our model state accordingly:

next_state(#state { in_queue = InQ } = S, _V, {call, _, out, [Prio]}) ->
    S#state { in_queue = listq_rem(InQ, Prio) };
next_state(#state { in_queue = InQ } = S, _V, {call, _, pout, _}) ->
    S#state { in_queue = listq_rem(InQ) };
next_state(S, _V, {call, _, to_list, _}) -> S;
next_state(S, _V, {call, _, is_queue, _}) -> S;
next_state(S, _V, {call, _, is_empty, _}) -> S;
next_state(S, _V, {call, _, len, _}) -> S;
next_state(#state { in_queue = InQ } = S, _V,
               {call, _, in, [Value, Prio]}) ->
    S#state { in_queue = listq_insert({Prio, Value}, InQ) };
next_state(#state { in_queue = InQ } = S, _V,
              {call, _, in, [Value]}) ->
    S#state { in_queue = listq_insert({0, Value}, InQ) }.

Preconditions

This example does not use preconditions:

precondition(_S, _Call) -> true

Normally you use preconditions to limit what calls can be done in what state. That is, if the precondition fails, then the given transition is not allowed. One can use this as a constraining measure in some tests. But for this example, everything can always fire, so there is no reason to limit the calls in any way.

Postconditions

The postcondition is where we check that the model and SUT agrees on the observations. This is not executed symbolically, but is entirely dynamic execution. Here is the first clause:

postcondition(#state { in_queue = InQ }, {call, _, out, [Prio]}, R) ->
    R == listq_prio_peek(InQ, Prio);

it states: If we have a current state, InQ and a call to out with a specific priority, Prio and the SUT returned the value R. Then peeking in InQ for the first element at that given priority should be the same element. After this test, the state transition with next_state/3 will happen. Equally:

postcondition(#state { in_queue = InQ }, {call, _, pout, _}, R) ->
    R == listq_ppeek(InQ);
postcondition(#state { in_queue = InQ }, {call, _, out, _}, R) ->
    R == listq_peek(InQ);

handles the remaining checks for removing elements from the priority queue. Converting to a list or taking the length can also be done by calling our model variants and looking for equality:

postcondition(S, {call, _, to_list, _}, R) ->
    R == listq_to_list(S#state.in_queue);
postcondition(S, {call, _, len, _}, L) ->
    L == listq_length(S#state.in_queue);

Finally, one can ask if we have a queue, which should always be true - and we could ask if the queue is currently empty, which we can determine by discriminating on our model state. In this case they should also agree. Inserting elements into a queue always succeeds in addition:

postcondition(_S, {call, _, is_queue, _}, true) -> true;
postcondition(S, {call, _, is_empty, _}, Res) ->
    Res == (S#state.in_queue == []);
postcondition(_S, {call, _, in, _}, _) ->
    true;

All other outcomes are errors:

postcondition(_, _, _) ->
    false.

Running the test

Now, running this property test is the following property:

correct(M) ->
   ?FORALL(Cmds, commands(?MODULE),
      ?TRAPEXIT(
        begin
           ?SERVER:start_link(M),
               {History,State,Result} = run_commands(?MODULE, Cmds),
               ?SERVER:stop(),
               ?WHENFAIL(
                 io:format("History: ~w\nState: ~w\nResult: ~w\n",
                               [History,State,Result]),
                               aggregate(
                                command_names(Cmds),
                                Result =:= ok))
                end)).

Where M describes the module we wish to test. Michael wrote several and we can test them all with the same code! Then we start a queue_srv with M as the module and then we run a series of commands. The server is then stopped. Then, upon failure, we output necessary stuff to figure out what went wrong. Also, we aggregate how often the commands are hti so we are sure we have a decent coverage.

The test uncovered some errors straight away. Here is one such which was much much bigger but got minimized down by PropEr:

[{set,{var,1},{call,queue_srv,in,[-18]}},
 {set,{var,5},{call,queue_srv,in,[9]}},
 {set,{var,6},{call,queue_srv,in,[-10,-4]}},
 {set,{var,18},{call,queue_srv,in,[-29]}},
 {set,{var,22},{call,queue_srv,in,[11]}},
 {set,{var,26},{call,queue_srv,len,[]}}]

So, if you insert [-18, 9, -4 at priority -10, -29, 11] and then ask for the length of the priority queue, something failed (the pqueue code crashed).

The point here is that normal unit tests won't usually come up with examples this complex. But by starting out asking: "What can be done here?" by means of generators and then carrying out random operations uncovers nasty errors quickly. Michaels code now routinely survives 1500 PropEr test runs on all his priority queue modules. Given that it took 1-2 hours writing the test, it seems like it was worth it.

I april 2012 udkommer Ubuntu 12.04 LTS, med kælenavnet Precise Pangolin.
Da det er en LTS (Long Term Support) udgave af Ubuntu vil vi gerne markere udgivelsen lidt mere end vi gør med de almindelige halvårlige udgivelser.

Hvis vi skal nå at få stablet et (eller flere) større arrangement(er) på benene er det ikke for tidligt at komme i gang med forberedelsesarbejdet.

Derfor afholder vi et hurtigt IRC-møde mandag d. 19. december kl. 20 i #ubuntu-dk-moede på Freenode netværket.

Dagsordenen har tre primære punkter:

1. Hvad vil vi?
   Brainstorm. Hvordan har vi lyst til at markere Ubuntu 12.04 udgivelsen?
2. Hvad kan vi?
   Hvilke ressourcer har vi og hvad kan vi realistisk nå at få stablet på benene?
3. Hvad gør vi?
   Hvem gør hvad efter mødet? Uddelegering af konkrete opgaver.

Vi skal altså tale om hvilken form vi vil have for vores markering af 12.04 udgivelsen. Skal det være cd uddeling? Skal der være oplæg om Ubuntu? Skal det være på nybegynder-niveau, eller skal det være for de mere garvede brugere? Vi har jo igennem tiden prøvet lidt af det hele…

Når vi (forhåbentlig) når til enighed om hvad vi kunne tænke os at lave, så skal vi have afklaret hvad der er realistisk at få gennemført. Vi arbejder alle frivilligt, og det giver ikke mening at forsøge at lave et arrangement, som kræver at 2-3 personer arbejder fuldtid fra nu til april, hvis vi ikke er nok til at lægge det arbejde som kræves.

Til sidst skal vi have planlagt det videre forløb, og her mener jeg det er vigtigt at vi får sat navne på hvem der gør hvad. Erfaringen viser at hvis det bare bliver besluttet at noget skal gøres, så bliver det ikke gjort, fordi alle antager at det er der nok nogen andre der tager sig af…

Hvis du ikke har mulighed for at komme med til mødet mandag, så skal du være velkommen til at give din mening tilkende – enten på vores mail-liste eller på forumet (eller i kommentarerne nedenfor).

Spiir er en webservice til at skabe overblik over privatøkonomien. Ved at kategoriserer alle bevægelser fra ens webbank kan man vurdere om der er nogenlunde sammenhæng mellem størrelsen af indtægter og udgifter og få overblik over hvad ens penge bliver brugt til.

Det virker ganske fint – og webinterfacet er lækkert.

Deres hjemmeside og introvideo har mere info om konceptet.

Tidligere har man manuelt skulle eksportere alle sine overførsler fra sin webbank, og så importere dem i Spiir, men Lån og Spar Bank (som jeg er kunde hos) og Spiir har i sidste uge indgået et samarbejde, så man som kunde kan få overført data automatisk. Det er altså som kunde i Lån og Spar ikke nødvendigt at eksportere og derefter importere data – det sker (næsten) automatisk. Det er i den forbindelse jeg første gang har hørt om Spiir, da Lån og Spar har reklameret for tjenesten på forsiden af deres webbank.

Det er altid rart at få mere info og overblik over sin privatøkonomi. Personligt blev jeg måske ikke overrasket, men så i hvert fald bevidst om mit forbrug, da det blev meget tydeligt af Spiirs oversigt at 50% af mit forbrug (fraregnet udgifter til bolig) har gået til bar og restaurationsbesøg (gennemsnitligt over det sidste år).

Det kan man så tolke som man vil – om det betyder at jeg har et forholdsvis stort forbrug af mad og drikkevare ude i byen, eller om jeg bruger meget få penge på andre ting (tøj, møbler, husholdning) er vist åbent for fortolkning.

Svagheder og mangler…

Det er stadig tydeligt at samarbejdet mellem Lån og Spar og Spiir er relativt nyt. Fra d. 29. november til d. 2. december blev der f.eks. ikke opdateret data mellem de to services. Det er selvfølgelig det langsigtede gennemsnitlige overblik som er det mest interessante ved Spiir (i hvert fald for mig). Men det er da stadig sjovt at kunne sætte sine seneste indtægter og udgifter ind i en sammenhæng, og der er det surt når data ikke (som planlagt) opdateres dagligt. Men det er forhåbentlig opstartsproblemer, som der kommer styr på.

Yderligere er Spiirs kategorier meget faste. Det giver selvfølgelig god mening – både så man kan sammenligne forbrugsmønstre, men også praktisk for Spiir, således at når jeg har lært systemet hvilken kategori en ny udgift hører til, så skal den næste bruger ikke nødvendigvis gøre det samme.

Men hvis man (som jeg) har nogle lidt mærkelige overførsler[1] at holde regnskab med, så mangler der noget fleksibilitet. Det behov håber jeg deres Tags kan opfylde snarest. Det er nemlig muligt at tildele Tags til forskellige poster, men indtil videre er det ikke muligt at visualisere disse på samme måde som kategorierne. Visualiseringen af udgifter og indtægter er netop Spiirs styrke, og indtil Tags kan visualiseres har de relativt begrænsede anvendelsesmuligheder.

Der er andre småting som kan drille lidt – og hvor man godt kan mærke at det stadig er et relativt nyt produkt. F.eks. får man den samme advarsel smidt i hovedet hver eneste gang man ignorerer en ny post.
(Jeg har f.eks. valgt at ignorere både min ekstra løn-indtægt i sommer og den udgift jeg havde til at betale mit SU lån. Jeg betragter begge poster som enkeltstående begivenheder, og har derfor ikke lyst til at de skal medgå i diverse gennemsnitsberegninger.)

Jeg har haft enkelte overvejelser mht. mit privatliv og datasikkerhed (det er dog alligevel relativt følsomme oplysninger man overdrager til firmaet), men som udgangspunkt virker det som om Spiir tager deres kunders privatliv seriøst. (Det ville også være dumt andet, det vil være ødelæggende for deres forretning hvis man som kunde skulle være nervøs for at få sin privatøkonomi spredt rundt omkring når man benytter sig af Spiirs service.)
Hvis jeg tager min paranoide hat på i løbet af december kan det være jeg forfatter et indlæg om mine overvejelser i den forbindelse – men det kan også (mere sandsynligt?) være at december går med pebernødder og gløgg. Nu må vi se.

Generelt vil jeg anbefale Spiir (hvis man stoler på at de behandler ens data fornuftigt) – specielt til folk som måske har svært ved at overskue hvor deres penge forsvinder hen og gerne vil have lidt bedre overblik over om der er overskud eller underskud på regnskabet fra måned til måned.

[1] Jeg deler en lejlighed med 3 andre, dvs. der hver måned er 4 overførsler som går til husleje – de er selvfølgelig ikke en indtægt for mig, ligesom hele huslejen ikke er en personlig udgift for mig. Tilsvarende ser min udgift til f.eks. el meget stor ud når jeg betaler vores el-regning, fordi Spiir ikke kan se at jeg få (en del af) pengene overført fra de andre.

• startups (everything related to startups / small business and open source software)
• green technology (recycling, monitoring etc.)

Det er rart, at have styr på sin IT-installation ved at placere den samlet i et rack, med fælles strømforsyning, UPS og det hele, men en sådan stålkasse er ikke det bedste miljø, at placere et WIFI-accesspunkt i. Derfor er min wifi gateway fremskudt. Den er placeret på vores kontor og har sin egen sorte klods som strømforsyning. Eller rettere, det havde den indtil for nylig. WIFI accesspunktet kører nemlig kun 100 Mbit/s, så der er fire ledige ledere i cat6 kablet. Disse ledere har jeg udnyttet til Power over Ethernet (PoE). Ideen er at forsyne WIFI accesspunktet med 12V fra den UPS sikrede strømforsyning i rackskabet. Jeg tog udgangspunkt i følgende pinkonfiguration. DC+ på ben 4+5 og DC- på ben 7+8. Fødning af DC på linjen har jeg lavet via et modificeret RJ45 forlængerstik og udtaget af strøm i den anden ende, har jeg indtil nu lavet på samme måde. Her overvejer jeg dog, at modificere min router i stedet efter følgende opskrift. Lav lodningerne inde i WIFI accesspunktet frem for at bruge et modificeret forlængerstik og et DC-stik. RJ45-forlængerstikket fra DealExtreme kan iøvrigt ikke anbefales. Kvaliteten er for ringe. Skubber man til stikket, så kan man ikke være sikker på, at der er forbindelse længere. Men jeg har da fået demonstreret, at min fremskudte Linksys WRT router fungerer fint med strømforsyning hen over cirka 20 meter ethernetkabel.

I sidste uge lancere min arbejdsplads en konkurrence hvor man kan vinde en skiferie. For at sprede ordet valgte vi bl.a. at dele konkurrencen på Facebook. I forbindelse med Facebookdelen rendte jeg ind i et par problemer som jeg havde svært ved at finde dokumenteret online. Konkurrencen blev oprettet som en facebook page app, som den ses her.

Facebooksiden

Facebooksiden i sig selv var ikke et stort problem. Jeg lavede en app på Facebook Developers siden. Dette giver en række muligheder, bl.a. muligheden for at vælge hvordan din app skal integreres med Facebook.

Integrer din app med Facebook

For at kunne bruge applikationen som et element på en Facebook page, vælges “page tab”. Teknisk fungerer det ved at du selv hoster din app, som en almindelig html side, der så indlejres på din Facebook Page, i en iframe. En page tab har 4 indstillinger:

• Page Tab Name – Den navn din app skal have i page menuen
• Page Tab URL – Den side Facebook skal integrere i sin iframe
• Secure Page Tab URL – En HTTPS-version af den side der skal vises på Facebook
• Page Tab Edit URL – Link til din app’s admin modul. Jeg skippede dette, da mit projekt ikke havde behov for customization

I følge Facebook selv har mere end 9.6mio brugere valgt kun at kunne tilgå Facebook via https. Hvis du ikke har tilføjet en HTTPS-version af din app vil alle de mennesker hverken kunne se eller bruge din app.

Et af de problemer jeg kæmpede mest med, var at gøre det muligt for folk at dele appen med deres venner. Ikke fordi det var svært rent kodemæssigt, men jeg fandt ud af at det kræver at appen udover at være oprettet som ‘page tab’ som forklaret ovenfor, også kræver at den er lavet som en normal ‘app on facebook’ (se billede ovenfor). Når du vælger ‘app on facebook’ får du 2 indstillingsmuligheder. Canvas URL, og Secure Canvas URL. Et Facebook app canvas fungerer på samme måde som en Facebook page tab, bortset fra at det er en selvstændig app, og ikke tilknyttet en page. Da jeg ikke havde brug for en selvstændig app valgte jeg at lave mine canvas URLs pege på en tom side, der kun bestod af et JavaScript redirect, til min page tab.

Selve appen

Da opsætningen var på plads var der bare tilbage at lave selve appen. Det sker som nævnt tidligere vha. html, css og javascript, og der er altså ikke meget magi her. For at få adgang til Facebooks funktionalitet, skal Facebook SDK’et loades.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<div id="fb-root"></div>
<script>
	(function(d){
		var js, id = 'facebook-jssdk'; 
		if (d.getElementById(id)) {return;}
		js = d.createElement('script'); 
		js.id = id; 
		js.async = true;
		js.src = d.location.protocol + "//connect.facebook.net/en_US/all.js";
		d.getElementsByTagName('head')[0].appendChild(js);
	}(document));
 
	window.fbAsyncInit = function() {
		FB.init({
			appId: 'YOUR-APP-ID',
			status: true,
			cookie: true,
			xfbml: true,
		});
	}
</script>

Linjen:

1

js.src = d.location.protocol + "//connect.facebook.net/en_US/all.js";

kan bruges til at styre hvilket sprog Facebooks ting skal vises på. Tilgængelige sprog kan findes i Facebook’s Locale XML.

Nu er der adgang til Facebooks funktionalitet via. Javascript. I dette projekt blev det brug til 2 ting. Først skal der være mulighed for at folk kan dele appen med deres venner:

1
2
3
4
5
6
7
8
9

function tellafriend() {
	FB.ui({
		method: 'apprequests',
		message: 'Hvilken besked skal folk sende til deres venner?',
		title: 'Overskrift.'
	}, function (response) {
		poststory();
	});
}

Den sidste del:

1
2
3

function (response) {
	poststory();
}

Sørger selvfølgelig for at funktionen poststory() kaldes så snart folk har valgt hvem af deres venner de gerne vil dele appen med. Det er også muligt at trykke cancel og på den måde ikke dele med nogen, poststory() vil dog stadig blive kaldt.
Formålet med poststory() er at lade folk poste et link til appen på deres egen væg:

1
2
3
4
5
6
7
8
9
10
11
12

function poststory() {
	FB.ui({
		method: 'feed',
		name: 'Overskrift på vægopslaget',
		link: 'Link der skal deles',
		picture: 'link til billede der skal inkluderes på opslaget',
		caption: 'Billedetekst.',
		description: 'Brødtekst på indlægget'
	}, function(response) {
		redirectuser();
	});
}

Efter poststory() kaldes funktionen redirectuser(), som vha. et normalt Javascript redirect videresender brugeren til vores egen konkurrenceside.

Jeg håber indlægget kan hjælpe med at komme udenom nogen af de små fælder jeg selv rendte ind i
Husk i forbindelse med konkurrencer at overholde Facebook’s egne regler for konkurrencer. Ellers kan det blive en kort fornøjelse. Kasper Blom har skrevet en god kort opsummering af konkurrencereglerne.

Synes efterhånden at jeg gentager mig selv ret meget omrking dette emne, så hermed et forsøg på at opridse hvordan proceduren der er indarbejdet igennem mange år for nyindførelse, eller reintroducering af et TLD sker (og også lidt personlige holdninger om nogle af dem).

Først skal man bruge et nyt TLD, eller også reintroduceres et.. De sidste par år kan nævnes at dette er sket med: .eu, .tel, .me, .so, og .xxx (og sikkert også nogle jeg har glemt)

Nogle er ccTLD’er, nogle er sTLD’er, fælles for dem er at det kan give et billed af det normale der sker omkring hvordan det gøres:

TLD’et ansøges eller overdrages, eller et nyt land opstår ud af tidligere samlinger .. Faktum er at nogen beslutter at der skal være et nyt TLD (som feks du kommer til at læse meget om i 2012, især omkring 12 januar -> 12 april og 1. maj) og formentlig vil vi se de første nye gTLD’er i den forbindelse i 2013… Ud over det har de hollandske antiller fået nye ccTLD’er da de ikke længere er en “nation”.

Lad os kalde det for .tld for eksemplets skyld, så roder vi ikke opgaven om beskrivelsen sammen med for mange følelser.

.tld skal nu igennem nogle faser, dette er af flere hensyn, jeg vil prøve at forklare lidt om de forskellige fasers hensyn så godt som jeg nu kan, ellers må i spørge i kommentarene :)

Sunrise

Trademark owners bliver så sure hvis jens på 14 år samler deres domæne op førend de har fået ret og mulighed til at afværge det først. Derfor har det været en generel praksis at give en sunrise periode. I sunrise perioder har man adgang til at komme først i køen hvis man har et varemærke, typisk deles de lidt op i klasser, men kan også bare bestå af en sunrise, som er varemærker (generelt). Disse varemærke ejere har så ret til at udveksle et bevis på ret, med et domæne, ganske vist til en typisk højere pris end normalt, men der indgår også en del arbejde med IP (interlektuel property) clearinghouse eller diverse advokat hensyn, som fordyrer processen betydeligt.

Yderligere mere skal ejeren af varemærket så hvert år forny domænet til X antal kroner (normalprisen).

Gevinsten her er, at varemærkeejeren, hvis han ønsker det, kan vælge at beskytte sig imod domainers og domænehijacking, men han kan også lade være, men generelt har de muligheden, og dette er noget man har krævet at få fra diverse varemærkerettighedshavere…

Bagsiden af medajlen er at det koster typisk omkring 1000-2000 pr varemærke, + løbende udgifter for domænet pr år.. hvis en domainer fiskede domænet, så koster det nemt en advokatregning på 30000 kr og en klageprocedure (som i Danmark for .dk er ret billig, men for udenlandske TLD’er kan være meget bekostelig). Logikken er altså at det kan betale sig at få dem “lukket” i sunrise, hvis ens domænepolitik siger at man vil kontrolere bruget af ens varemærke.

Landrush

Landrush er et sjovt begreb, for der er alligevel ingen domæner der flyder i land og de står heller ikke i kø… Man har, som jeg forstår det, valgt at lave landrush perioder fordi man i visse tilfælde har ting som ikke er beskyttet af sunrise (da man ikke har, eller ikke kan opnå varemærke beskyttelse, dette er feks et stort problem herhjemme), men som man godt ville have mulighed for at kunne erhverve under andre forehold. For at begrænse hamstringen vælger man typisk en forhøjet pris, i visse tilfælde tillader man flere ansøgninger på samme domæne, med evt flere ansøger til følge hvor man så på en eller flere måder finder en ejer af domænet. Personligt er jeg ikke så superglad for at lave det til et pengeræs, da jeg personligt mener at dette kan udløse de forkerte ejere af visse domæner, jeg er langt mere til noget “bevisførelse for tidligere aktivitet under andet TLD” som argument for at få et givet .tld, og så tildele på baggrund af aktivitet.

GA

.. eller, generel availability, almindelig frigørelse til salg, er så tidspunktet hvor man lukker sluserne op for almenheden. Hvis TLD’et tillader det i deres regler, kan så alle købe et domæne under dette nye, eller reintroduceret .tld.

Her kan det være smart at spille på flere heste hvis man har et domæne man virkelig gerne vil have, da hver enkelt registrar har et begrænset antal forbindelser og adgang, og hvis de har mange kunder er du måske langt nede på listen.

Hvis vi nu levede i en lidt perfekt verden, så stoppede vi så her, men desværre er der nogen der begyndte på nogle små finlurligheder, som jeg bestemt ikke er glad for

De spærret

Visse TLD’er opretholder diverse spærrelister over domæner, dette kan være bandeord (.so) eller referencer til historiske begivenheder / personer som man ikke ønsker at tale om, eller som kan være forbudt at tale forherligende om (.de og .fr). Men det kan også bare være nogle som en regering har besluttet at man pt ikke lige ved hvad man skal gøre med (.eu) eller bare nogle som man bare ikke lige har lyst til at sælge.

Af disse hvor man effektivt forsøger at cencurerer nettet, finder jeg jævnt problematisk.. Det tager typisk år, eller årtier at få ting frigjort fra disse spærret lister, og bare fordi man forbyder et domæne betyder det ikke at folk ikke skriver om det på nettet eller stopper med at bande (!)

De reserveret

Visse domæner kan være reserveret, måske for evigt, her kan man typisk finde tobogstavs CC, feks dk.tld, se.tld osv.. Men findes der ikke en regel imod at sælge domæner under 3 bogstaver kan man senere komme ud for at domæner som er solgt pludselig bliver til landekoder. Der kan også ligge et ønske om at forhindre folk i at lave “third level tld’er”, feks co.dk og org.uk osv under vores nye .tld, så vi spærre feks gov.tld, co.tld (er også colombia..) og org.tld med flere.

Disse bliver typisk ALDRIG frigivet.

Auktionerne / specielt salg

Og her knækker filmen så, man vælger at tilbage holde domæner, med “gode navne” for senere at sælge dem til en præmium pris. Dette er noget registry’et laver for typisk at lave grundfinanciering af deres operations, feks er t.co og o.co blevet solgt på sådanne auktioner/præmium kontrakter (kan også være uden penge, men med aftale om exponering). Specielt slemt har det været under .me og .co.. Jeg er bestemt ikke en fan af at se et registry sælge “high value” domæner til højeste pris, jeg er derimod glad for at se TLD operatører som kræver en “plan” for brugen af et “high value” domæne, og hvor man indgår en kontrakt om brugen af det de første feks 3 år, hvor man ved ikke at overholde kontrakten mister domænet uden yderligere bemærkninger. TLD’er som bruger den sidstenævnte metode er typisk TLD’er som ønsker en mere positiv profil af deres TLD, og som på denne måde ønsker at fremelske gode stabile websites med meningsfyldt indhold og ikke bare sedo skrammel.

Hvad har vi så glemt?

Mange ting, feks glemmer folk at fornye deres fine sunrise domæner, og de havner så direkte i problemer ved år to. Vi har heller ikke taget specielt hensyn til om varemærkeindehavere har en domænepolitik, nogen forsvare sig med næb og klør (LEGO feks, de har en kronisk frygt for dårlig omtale, dårlig pr og salg af kopiprodukter), andre derimod, jeg mener bla BMW har, valgt at ignorer “misbrug” af deres varemærke i forbindelse med domæner med mindre der er direkte andre årsager til at interessere sig for det.

Som sagt, så vil der næste år, og i 2013 blive snakket meget om nye gTLD’er, i praksis snakker vi om et sted mellem (formentlig) 500 og 2000 nye TLD’er som introduceres, mange af dem vil være brand ejere som feks LEGO som erhverver sig .lego (du vil nok ikke kunne købe et .lego, men mindre LEGO ser noget i deres krystalkugle som de hidtil ikke har kunne finde), og byer som søger om feks .berlin og .london og .nyc, typisk igennem en privatejet virsomhed som har byens velsignelse til at drive det.

Ud over det vil vi også snakke om et .now, .shop og .site og andre generiske navne.. og debatten vil også falde omkring et .gay og .god, begge er meget problematiske, feks.. hvem skal have lov til at køre et .god? Det muslimske trossamfund,det jødiske trossamfundet eller den katolske kirke?

Fælles for denne diskution, og det som hedder nye gTLD’er er, at der bliver SÅ mange af dem, så domainers ikke kan købe det hele (rigtig god ting) værdien af et domæne vil falde (min påstand, defineret efter udbud og efterspørgelse), og domainers derfor vil se deres invisteringer skrumpe til ingenting (også en god ting), og som følge af det vil vi se det sekundære marked falde i værdi (sedo og andre landingpages pis).

Det vil også betyde at alt det som er nævnt overfor om sunrise og landrush vil blive udvandet, varemærker vil skulle vurderer om det ikke er på tide at lave en domænestrategi, som er en meget bedre løsning end at købe i blinde, og dette vil dermed også tvinge folk til at vurderer formålet af deres nuværende domænebeholdning.. Dette er også en god ting..

… i øvrigt, mit eget gæt på hvor mange ansøgerne på nye gTLD’er der bliver indsendt i perioden 12 januar til 12 april er : 5592

Dette er af mange i branchen betragtet som et meget højt tal, og folk gætter normalt vildt omkring de 3000.

Svaret på det spørgsmål kommer 1 maj 2012, når ICANN offentliggøre listen af ansøgninger, jeg håber lidt at jeg ikke vinder de 8 flasker whisky…

Many of us out there writes small tools to just solve a simple task that you need. Here, I will present a tool I needed last night.

I have a small job doing a wordpress site for some people, and I needed a image with the site title in a font matching some specific criteria (like a double story lowercase A and a small serif on lowercase L, while in general being a Sans Serif type).

So what I needed was a application that let me write a word or a phrase, and see it written with all available fonts on the system.

So, it took a little more than a effective hour and 120 lines of code to come up with this:

Click to see image

And if anyone cares, I have pushed the sources to git.kde.org.

I’m sure many of you also have various such small apps. Let’s see them. That’s also you Eike and your svgtoy app :)

Another thing I learned from this app is that the ukij fonts targetted the Uyghyr language actually is very interesting also for western europeans.

Det er ingen hemmelighed at ICANN har søsat et nyt gTLD program, og for os i branchen er der ingen speciel nyhed om de som ansøges (dem som pt er offentlige), der findes flere lister: http://www.newtlds.tv/newtlds/ er blot en af dem.

og vi er endelig ved at få en debat herhjemme, det er dejligt og sundt og jeg glæder mig rigtig meget over at debatten endelige er her. Men jeg møder, som ofte, en meget begrænset viden om nye gTLD’er, nok mest fordi det er et meget specialiseret og lille emne, og svært at overskue, men nemt at have en holdning til.

“Vi hader nye TLD’er!!!”

… synes at være en af ting som folk er enige om i diverse små kommentare på v2.dk og set i andre sammenæng.

Hvis man skal opsumere folk i denne lejre, så hører jeg:

1) gTLD’er er griske, ICANN er griske.

2) .dk (.se, .no eller whatever your flavor is) er nok til mig!

3) Vi ville gerne havde haft kategorisering, det ville havde været fedt (!!)

4) Det er for dyrt!

Der er flere af disse om er modstridende, og som bare ikke giver mening for mig når de står samlet, feks, hvordan kan man være imod gTLD’er hvis man er forkatagorisering, for i virkerheligheden er det ultimative kategorisering at du kan få din hjemmeadresse som din hjemmeside, dvs http://28.nordby-hovedgade.samsoe.jylland.dk, og ikke http://lille-bjørn.dk.

Nuvel, det vi diskutere i dag, som nogen tror, er om vi skal have gTLD’er. I tager fejl, den beslutning er allerede taget, og har gennemgået en lang periode af spørgsmål og debat, den debat stjal it og telestyrelsen og tog en beslutning på jeres vegne. De kom ikke igennem med deres holdninger (et nej) men har derimod måske nu skadet de danske muligheder og forståelse for nye gTLD’er i første runde.

Det som vi debatere lidt i dag er om Danmark skal benytte sig af den mulighed som nye gTLD’er er. Vi kommer til at se danske brands der køber gTLD’er. Lige ud af mit hoved forestiller jeg mig firmaer som house of prince, mærsk, lego, diverse fodboldklubber, teleselskaber og medicinal virksomheder.

Såh, skal vi blokere for et .cph, eller .fyn eller .jylland, hvis nogen ønsker at bruge penge på det, og lave det til et brand og markedsføre det? Vil vi bruge det? Hvordan ændre det forretningensmodellen for .dk og vores brug af browsers?

Det koster mange penge at lave et gTLD, såh, hvorfor gør det så det?

Strukturen omkring internettet er måske mere skrøbeligt end vi antager i hverdagen, men det store frivillige arbejde mellem firma’er og udveksling af data og rootservers placering og load gør at det hele er en stor matematisk opgave som skal gå op.Vi lever også i en verden hvor trademarks, og trademark owners har noget at sige, og hvor de har ret til at beskytte sig så jens på 14 ikke registrerer .coca-cola. Så ud over simpelthen at skrive 5 linier i rootfilen, så er der en frygtelig masse juridske hensyn der skal tages, disse koster simpelthen tid, og penge. Du kan vælge at lide eller ikke lide ICANN, men som løsning er der ikke opfundet bedre forslag i over et årti (at giv det til UN er en faldgruppe ud over alle grænser). ICANN er limen der holder det sammen, vi har ikke bedre, men vi har trods alt ICANN, og du kan deltage i deres møder og give din mening til kende i deres åbne fora’s

Så hvorfor vil et .basketball så blive dyrere end et .com eller et .dk ?

Det er skal ikke anderledes end prisen for et internetabbonement, et specielt kategoriseret og specialiseret produkt har merværdi. Nu tror jeg så helelr ikke der bliver mange .basketball, så driftens omkostninger skal uddeles på få registranter, og dem som invisterer og satser penge er firma’er og investors, de gør det fordi de mener de kan tjene pengene igen (jordan mener så også han vil gøre noget for basketball ved at støtte et .basketball)

Lad os lave diskutionen om, lad os sige at vi i dag havde .com, .net og .org.. og INTET ANDET at vælge imellem… nogen havde nok lavet et dk.com og se.com osv, tåber er der altid, og debatten var om vi nu skulle tillade et .dk .se, .no osv, og hver enkelt land kunne søge om deres eget tld, ville debatten så være anderledes?

Skulle vi tillade Iran, Kina eller USA at have deres eget TLD? Skulle grækenland have lov til det? Skulle grønland?

Tag så den nejhatten af, og prøv at se på nye tiltag med friske nye øjne.. Prøv at sige ja, også selvom du måske ikke helt forstår hvor langt det her kan gå, prøv at sige ja til udviklingen og nej til frygten (nogen her der ser borgen, kan i genkende mønsteret?).

Hvad er det VÆRSTE der kan ske hvis der kom et .fyn og der var 2 registreringer? Hvad er det værste der kunne ske hvis ingen gad sponsorer .fyn og de to ikke kunne købe det?