Blurblogs
Global
Popular
Log in
aklefdal's blurblog
The one and only Alf Kåre Lefdal, living in the suburbs of Oslo, Norway with wif
70 stories
·
0 followers

F# will solve your everyday problem without a headache by Tomas Jansson
Thursday February 18th, 2016 at 2:56 PM

Tomas Jansson
1 Share

The last couple of days I had two experiences that triggered this post. The first one was a question at work regarding how to model a finite state machine (FSM) in java or a language similar to java. The second one was a tweet by Isaac Abraham:

The quote was from an interview with Eric Lippert, a former member of the C# team.

So how are these two events related? They are related because the greater community still has a misconception of functional languages, and to find better solutions to problems we need to look further than C# and java. I agree with Isaac 100 % that it is disappointing, and sad, to read and hear this misconception of F# and functional programming. At the same time I do see a change happening for everyone, with a more functional approach in the front-end with libraries like react and more functional aspects in languages like java and C#. What I don't understand is why doesn't people try harder to stay ahead of the game and learn functional programming, even though they do like it when it gets accepted by the greater community. Almost every C# developer I know is now comfortable, and like, lambda expressions. More and more developers discover that immutability isn't that bad after all, but still don't use it as much since it is so easy to use mutability in the languages we use the most. Everyone is now comfortable with the var keyword in C#, but still want to write the whole type on the other side of the equal sign.

F#, and probably scala and other functional languages that are strongly type handle all this in better ways than we are used to in java and C#. So my answer to the question was how I should define an FSM in F#. This is a problem that is not scientific and it has nothing to do with finance. This is a real problem that anyone of us could have in almost any type of application where you need to model a FSM, and model a FSM is probably something we should do more often. Before we get to my answer to the question, let's look at one of the references in one of the other answers. One colleague linked to Martin Fowler's book Domain-Specific Languages which you can read an example dealing with FSM here: http://www.informit.com/articles/article.aspx?p=1592379. Reading through the example gave me a headache and almost made my eyes bleed. The java code in the example is probably good java code, and I would probably think that all those fancy patterns where nice a couple of years back when the book was written. What is the problem with the code in the book? As I said, it is probably nice java code, but that doesn't mean it is readable. I took me a while to understand how the State Machine Model worked as described here: http://www.informit.com/articles/article.aspx?p=1592379&seqNum=2. Why was it so? The main reason it was hard for me to understand the sample code there was probably all the noise and extra syntax. The noise and extra syntax distracted me from the actual model which can never be a good thing. Let's go to the actual FSM defined on page 3: http://www.informit.com/articles/article.aspx?p=1592379&seqNum=3. The code here is definitely easier to understand since the level of noise has decreased due to the previous model, but it is still much noise. In fact, Fowler agree since he also provides multiple way to specify the model in other format than java code. There is one xml version, and two other versions. The only reason you need this is due to the fact that java is to verbose and the level of noise is too high.

F# to the rescue

The whole purpose of this post is to show you that it is possible to solve real world problem with F# in more elegant ways than you would in languages like C# and java. I'll show you my code and then explain why I think it is better. I don't say that Fowler's java code is bad, more that the language might not be right tool.

Let me walk you through this piece of code. First I define a FSM module where all the general logic for implementing the FSM is defined. I define one type that represents the FSM. In the module I have also defined a set of helper functions that helps me create a FSM and also one function that handles an event given an event and a FSM as input. All the helper functions takes a FSM as the last argument, since that allows me to pipe that argument in making it possible to have a really nice DSL in the language. The helper functions takes the provided FSM and returns a new FSM based on the provided FSM and the extra input. registerTransition takes mapping from one state to another given an event.

I defined all the valid events, commands and states on these lines: https://gist.github.com/mastoj/9dfc21848c449fadcc93#file-fowler_fsm-fsx-L54-L72. I really don't think they need any explanation.

The creation of the FSM is done here: https://gist.github.com/mastoj/9dfc21848c449fadcc93#file-fowler_fsm-fsx-L75-L88. As you can see I'm using the helper functions which defines a really nice DSL for me.

When I have the FSM defined I can actually try that it works and that is done here: https://gist.github.com/mastoj/9dfc21848c449fadcc93#file-fowler_fsm-fsx-L90-L105. First I define a helper infix operator that print the current state before calling the next function in each step.

As I hope you can see in this example there are many advantages compared to the java version:

  • No nulls
  • Impossible to represent bad states
  • The ration of noise vs. relevant code is significantly lower
  • Shorter code, so it is easier to get the full picture
  • No need for an external dsl

Wrap up

F# (and most likely Scala) is a language you can, and should use, to solve your everyday problem. It will give you more concise code, easier to read code, and easier to maintain code. This will also have the positive side effect of less bugs. I understand that it might be a little bit weird at start since it is a whole new paradigm, but the reward is high on the other side. Learning to program functionally will help you write better programs in any language and you will also be ahead of the game when the functional features comes to java and C#. Note that even though those languages get some functional features they will never be as functional as F# and Scala since the base design of the languages are different. Do your self a favor and learn you some FP :)

Read the whole story
aklefdal
2986 days ago
reply
Stabekk
Share this story
Delete

Strings with assumptions by Einar
Monday February 1st, 2016 at 3:01 AM

ample code
1 Share

TL;DR Strings always come with strings attached.

I had a little rant about strings on Twitter the other day. It started like this:

This blog post is essentially the same rant, with a bit of extra cheese.

Here’s the thing: I find that most code bases I encounter are unapologetically littered with strings. Strings are used to hold values of all kinds of kinds, from customer names to phone numbers to XML and JSON structures and what have you. As such, strings are incredibly versatile and flexible; properties we tend to think of as positive when we talk about code. So why do I hate strings?

Well, the problem is that we don’t want our types to be flexible like that – as in “accepting of all values”. In fact, the whole point of types is to avoid this flexibility! Types are about restricting the number of possible values in your program, to make it easier to reason about. You want to allow exactly the legal values, and to forbid all the illegal values. String restricts nothing! String is essentially object! But people who have the decency to refrain from using object will still gladly use string all over the place. It’s weird. And dangerous. That’s why we should never give in to the temptation to escape from the type system by submerging our values in the untyped sea of string. When that value resurfaces sometime later on, we’ll effectively be attempting a downcast from object back to the actual type. Will it succeed? Let’s hope so!

So to be very explicit about it: if you have a string in your program, it could be anything – anything! You’re communicating to the computer that you’re willing to accept any and all of the following fine string specimen as data in your program:

Your program does not distinguish between them, they’re all equally good. When you declare a string in your program, you’re literally saying that I’m willing to accept – I’m expecting! – any and all of those as a value. (I should point out that you’re expecting very big strings too, but I didn’t feel like putting any of them in here, because they’re so unwieldy. Not to mention the door is open to that mirage doppelganger of a string, null, as well – but that’s a general problem, not limited to string.) problem we tend to have.)

Of course, we never want this. This is never what the programmer intends. Instead, the programmer has assumptions in their head, that the string value should really be drawn from a very small subset of the entire domain of strings, a subset that fits the programmer’s purpose. Common assumptions include “not terribly big”, “as large as names get”, “reasonable”, “benign”, “as big as the input field in the form that should provide the value”, “similar to values we’ve seen before”, “some format parsable as a date”, “a number”, “fits the limit of the database column that’s used to persist the value”, “well-formed XML”, “matching some regular expression pattern or other” and so on and so forth. I’m sure you can come up with some additional ones as well.

The assumptions might not be explicitly articulated anywhere, but they’re still there. If the assumptions are implicit, what we have is basically a modelling issue that the programmer hasn’t bothered to tackle explicitly yet. It is modelling debt. explicitly. So whenever you see string in a program, you’re really seeing “string with assumptions”, with the caveats that the assumptions may not be terribly well defined and there may or may not be attempts to have them enforced. In other words, we can’t trust that the assumptions hold. This is a problem.

So what should we do instead? We can’t realistically eradicate strings from our programs altogether. For instance, we do need to be able to speak string at the edges of our programs. Quite often, we need to use strings to exchange data with others, or to persist values in a database. This is fine. But we can minimize the time we allow strings to be “raw”, without enforced assumptions. As soon as we can, we should make our assumptions explicit – even though that means we might need to spend a little time articulating and modelling those assumptions. (That’s a bonus by the way, not a drawback.) We should never allow a string pass unchecked through any part of our system. An unchecked string is Schrodinger’s time bomb. You don’t know if it will explode or not until you try to use it. If it turns out your string is a bomb, the impact may vary from the inconvenient to the embarrassing to the catastrophic.

Unsurprisingly, the good people who care about security (which should be all of us!) find strings with assumptions particularly interesting. Why? Because security bugs can be found precisely where assumptions are broken. In particular, since the string type allows for any string, the scene is set for “Houdini strings” to try to escape the cage where they’re held as data, and break free into the realm of code.

To make our assumptions explicit, we need to use types that are not strings. But it’s perfectly fine for them to carry strings along. Here’s a class to represent a phone number in C#:

Nothing clever, perfectly mundane. You create your PhoneNumber and use it whenever you’d use “string with assumption: valid phone number”. As you can see, the class does nothing more than hold on to a string value, but it does make sure that the string belongs to that small subset of strings that happen to be valid phone numbers as well. It will reject all the other strings. When you need to speak string (at the edges of your program, you just never do it internally), you call ToString() and shed the protection of your type – but at least at that point you know you have a valid phone number.

So it’s not difficult. So why do we keep littering our programs with strings with assumptions?

Read the whole story
aklefdal
3004 days ago
reply
Stabekk
Share this story
Delete

Sunbeam by xkcd (whatif@xkcd.com)
Sunday January 24th, 2016 at 1:34 PM

what if?
6 Comments and 15 Shares

Sunbeam

What if all of the sun's output of visible light were bundled up into a laser-like beam that had a diameter of around 1m once it reaches Earth?

—Max Schäfer

Here's the situation Max is describing:

If you were standing in the path of the beam, you would obviously die pretty quickly. You wouldn't really die of anything, in the traditional sense. You would just stop being biology and start being physics.

When the beam of light hit the atmosphere, it would heat a pocket of air to millions of degrees[1]Fahrenheit, Celsius, Rankine, or Kelvin—it doesn't really matter. in a fraction of a second. That air would turn to plasma and start dumping its heat as a flood of x-rays in all directions. Those x-rays would heat up the air around them, which would turn to plasma itself and start emitting infrared light. It would be like a hydrogen bomb going off, only much more violent.

This radiation would vaporize everything in sight, turn the surrounding atmosphere to plasma, and start stripping away the Earth's surface.

But let's imagine you were standing on the far side of the Earth. You're still definitely not going to make it—things don't turn out well for the Earth in this scenario—but what, exactly, would you die from?

The Earth is big enough to protect people on the other side—at least for a little bit—from Max's sunbeam, and the seismic waves from the destruction would take a while to propogate through the planet. But the Earth isn't a perfect shield. Those wouldn't be what killed you.

Instead, you would die from twilight.

The sky is dark at night[citation needed] because the Sun is on the other side of the Earth.[citation needed] But the night sky isn't always completely dark. There's a glow in the sky before sunrise and after sunset because, even with the Sun hidden, some of the light is bent around the surface by the atmosphere.

If the sunbeam hit the Earth, x-rays, thermal radiation, and everything in between would flood into the atmosphere, so we need to learn a little about how different kinds of light interact with air.

Normal light interacts with the atmosphere through Rayleigh scattering. You may have heard of Rayleigh scattering as the answer to "why is the sky blue." This is sort of true, but honestly, a better answer to this question might be "because air is blue." Sure, it appears blue for a bunch of physics reasons, but everything appears the color it is for a bunch of physics reasons.[2]When you ask, "Why is the statue of liberty green?" the answer is something like, "The outside of the statue is copper, so it used to be copper-colored. Over time, a layer of copper carbonate formed (through oxidation), and copper carbonate is green." You don't say "The statue is green because of frequency-specific absorption and scattering by surface molecules."

When air heats up, the electrons are stripped away from their atoms, turning it to plasma. The ongoing flood of radiation from the beam has to pass through this plasma, so we need to know how transparent plasma is to different kinds of light. At this point, I'd like to mention the 1964 paper Opacity Calculations: Past and Future, by Harris L. Mayer, which contains the single best opening paragraph to a physics paper I've ever seen:

Initial steps for this symposium began a few billion years ago. As soon as the stars were formed, opacities became one of the basic subjects determining the structure of the physical world in which we live. And more recently with the development of nuclear weapons operating at temperatures of stellar interiors, opacities become as well one of the basic subjects determining the processes by which we may all die.

Compared to air, the plasma is relatively transparent to x-rays. The x-rays would pass through the plasma, heating it through effects called Compton scattering and pair production, but would be stopped quickly when they reached the non-plasma air outside the bubble. However, the steady flow of x-rays from the growing pocket of superhot air closer to the beam would turn a steadily-growing bubble of air to plasma. The fresh plasma at the edge of the bubble would give off infrared radiation, which would head out toward the horizon (along with the infrared already on the way), heating whatever it finds there.

This bubble of heat and light would wrap around the Earth, heating the air and land as it went. As the air heated up, the scattering and emission from the plasma would cause the effects to propogate farther and farther around the horizon. Furthermore, the atmosphere around the beam's contact point would be blasted into space, where it would reflect the light back down around the horizon.

Exactly how quickly the radiation makes it around the Earth depends on many details of atmospheric scattering, but if the Moon happened to be half-full at the time, it might not even matter.

When Max's device kicked in, the Moon would go out, since the sunlight illuminating it would be captured and funneled into a beam. Slightly after the beam made contact with the atmosphere, the quarter moon would blink out.

When the beam from Max's device hit the Earth's atmosphere, the light from the contact point would illuminate the Moon. Depending on the Moon's position and where you were on the Earth, this reflected moonlight alone could be enough to burn you to death ...

... just as the twilight wrapped around the planet, bringing on one final sunrise.[3]Here's an image which is great for annoying a few specific groups of people:

There's one thing that might prevent the Earth's total destruction. Can Max's mechanism actually track a target? If not, the Earth could be saved by its own orbital motion. If the beam was restricted to aiming at a fixed point in the sky, it would only take the Earth about three minutes to move out of the way. Everyone on the surface would still be cooked, and much of the atmosphere and surface would be lost, but the bulk of the Earth's mass would probably remain as a charred husk.

The Sun's death ray would continue out into space. Years later, if it reached another planetary system, it would be too spread out to vaporize anything outright, but it would likely be bright enough to heat up the surfaces of the planets.

Max's scenario may have doomed Earth, but if it's any consolation, we wouldn't necessarily die alone.

Read the whole story
aklefdal
3011 days ago
reply
Stabekk
Share this story
Delete
6 public comments
peelman
3002 days ago
reply
Randall, I salute you.

I have got to make this book a higher priority on my reading list...
Seymour, Indiana
llucax
3006 days ago
reply
"You wouldn't really die of anything, in the traditional sense. You would just stop being biology and start being physics.".

I want to be physics when I grow up!
Berlin
jlvanderzwan
3009 days ago
reply
"Fahrenheit, Celsius, Rankine, or Kelvin—it doesn't really matter."

That's one of the nicest ways to hint something utterly horrible is going to happen.
reconbot
3012 days ago
reply
You would just stop being biology and start being physics
New York City
satadru
3011 days ago
The mathematicians might argue that you'd actually start being math at that point.
skittone
3012 days ago
reply
This one's really good (and funny):

"You wouldn't really die of anything, in the traditional sense. You would just stop being biology and start being physics."
satadru
3012 days ago
reply
Clearly the papers I read need better openings...
New York, NY
manderay
3010 days ago
I love the What Ifs so much...

Announcing IdentityServer for ASP.NET 5 and .NET Core by Dominick Baier
Tuesday January 12th, 2016 at 4:09 PM

leastprivilege.com
1 Share

Over the last couple of years, we’ve been working with the ASP.NET team on the authentication and authorization story for Web API, Katana and ASP.NET 5. This included the design around claims-based identity, authorization and token-based authentication.

In the Katana timeframe we also reviewed the OAuth 2.0 authorization server middleware (and the templates around it) and weren’t very happy with it. But as usual, there were deadlines and Web API needed a token-based security story, so it shipped the way it was.

One year ago the ASP.NET team decided to discontinue that middleware and rather focus on consuming tokens instead. They also asked us if IdentityServer can be the replacement going forward.

By that time there were many unknowns – ASP.NET was still in early betas and literally changing every day. Important features like x-plat crypto (and thus support for JWT) weren’t even existing. Nevertheless, we agreed that we will port IdentityServer to ASP.NET 5 and .NET Core once the builds are more stabilized.

With RC1 (and soon RC2), we decided that now would the right moment in time to start porting IdentityServer – and here it is: IdentityServer4 (github / nuget / samples)

What’s new
When we designed IdentityServer3, one of our main goals was to be able to run self-hosted. At that time MVC was tied to IIS so using it for our default views was not an option. We weren’t particularly keen on creating our own view engine/abstraction, but that’s what needed to be done. This is not an issue anymore in ASP.NET 5, and as a result we removed the view service from IdentityServer4.

In IdentityServer4 you have full control over all UI aspects – login, consent, logoff and any additional UI you want to show to your user. You also have full control over the technology you want to use to implement that UI – it will be even possible to implement the UI in a completely different web application. This would allow adding OAuth 2.0 / OpenID Connect capabilities to an existing or legacy login “application”.

There will be also a standard UI that you can simply add as a package as well as templates to get you started.

Furthermore, IdentityServer4 is a “real” ASP.NET 5 application using all the standard platform facilities like DI, Logging, configuration, data protection etc, which means you have to learn less IdentityServer specifics.

What’s not new
Everything else really – IdentityServer4 has (or will have) all the features of IdentityServer3. You still can connect to arbitrary user management back-ends and there will be out of the box support for ASP.NET Identity 3.

We still provide the same architecture focused modelling around users, clients and scopes and still shield you from the low level details to make sure no security holes are introduced.

Database artifacts like reference or refresh tokens are compatible which gives you a nice upgrade/migration story.

Next steps
We will not abandon IdentityServer3 – many people are successfully using it and are happy with it (so are we). We are also aware that not everybody wants to switch its identity platform to “the latest thing” but rather wait a little longer.

But we should also not forget that IdentityServer3 is built on a platform (Katana) which Microsoft is not investing in anymore – and that also applies to the authentication middleware we use to connect to external providers. ASP.NET 5 is the way forward.

We just published beta1 to nuget. There are still many things missing, and what’s there might change. We also started publishing samples (link) to showcase the various features. Please try them out, give us feedback, open issues.

Around the RC2 timeframe there will be also more documentation showing up in our docs as and the ASP.NET documentation site. At some point, there will be also templates for Visual Studio which will provide a starting point for common security scenarios.

IdentityServer3 was such a great success because of all the good community feedback and contributions. Let’s take this to the next level!


Filed under: ASP.NET, IdentityServer, OAuth, OpenID Connect, Uncategorized, WebAPI
Read the whole story
aklefdal
3023 days ago
reply
Stabekk
Share this story
Delete

Value Stream Map by Andrew Siemer
Thursday January 7th, 2016 at 6:31 PM

Los Techies
1 Comment
I read an article yesterday about how SoundCloud migrated their product towards microservices.  It was the business reasoning for making that decision and the steps they went through to finally get to their goal.  It wasn’t so much about the … Continue reading →
Read the whole story
aklefdal
3028 days ago
reply
We should do more Value Stream Mapping.
Stabekk
Share this story
Delete

Røde flagg og Uber-bøllete VamPus by VamPus (noreply@blogger.com)
Tuesday January 5th, 2016 at 5:22 PM

VamPus' Verden
1 Share
Jeg er glad for at myndighetene har hatt en "hands off"-policy for reguleringen av delingsøkonomimarkedet såpass lenge at tjenestene har fått vokse seg til å bli seriøse utfordrere til eksisterende bransjer og forretningsmodeller. Nå er det på tide å modernisere eksisterende regulering av de markedene og bransjene det gjelder, slik at disse er i takt med de fabelaktige, men utfordrende mulighetene teknologien har gitt oss.

Torsdag har NHO sin årskonferanse som i år handler om den digitale revolusjonen og hvordan denne påvirker arbeidslivet. Digital teknologi har allerede destruert store internasjonale bedrifter som Kodak, som nektet å gi slipp på melkekua papirfilm til fordel for digitalkameraer. Digital teknologi har destruert kjeder som VideoNova og Platekompaniet, til fordel for Netflix og Spotify. Digital teknologi utfordrer bransje etter bransje, ettersom teknologien åpner for smartere organisering av ressurser og nye tjenester. Bransje etter bransje søker da beskyttelse mot konkurranse fra myndighetene. etter beskyttelse fra myndighetene fra det nye. Dessverre har myndighetene en tendens til å beskytte gamle arbeidsplasser mot det nye og ukjente, og dermed hindre nettopp innovasjon og entreprenørskap.

Da bilen kom, hvis store fordel var å kunne tilbakelegge lengre distanser på kortere tid, innførte blant annet engelske og franske myndigheter en lov om at all motorisert transport skulle varsles ved å veive med et rødt flagg eller lanterne foran transportmiddelet. I praksis betydde dette at motorkraft og fart var helt uvesentlig, da ingen biler kunne kjøre raskere enn mannen som gikk foran og veivet med et rødt flagg for å unngå ulykker. Det blir hevdet at påbudet ble fremmet og støttet av jernbaneindustrien og hestedrosjeeiere, som naturlig nok hadde interesse av å hemme en åpenbar ny konkurrent. Det ga jo lite mening å bruke penger på innovasjon for å skape en bedre, lettere og raskere bil når det var forbudt å kjøre i mer en 6,4 km i timen. Da britiske myndigheter fjernet påbudet, begynte innovasjonen i bilindustrien å skyte fart. Dette ga britisk bilindustri et forsprang på fransk og amerikansk bilproduksjon, der reguleringen ble opprettholdt i enda noen tiår. Opphevelsen av reguleringen feires faktisk fortsatt i november hvert år i Storbritannia.

I dag diskuterer vi deleøkonomi, hvor særlig det internasjonale transportnettverksselskapet Uber skaper debatt. Selskapet formidler kjøreoppdrag via en app mellom passasjerer og Uber-tilknyttede sjåfører som benytter sine egne biler i transporten. I 2015 var selskapets tjenester tilgjengelig i 67 land og 300 byer verden over. I omtrent like mange land og byer har etablerte taxiselskaper og deres sjåfører demonstrert mot selskapet. Uber-sjåfører har blitt dratt ut av bilene sine og banket opp. I Norge stemples de som piratsjåfører, deres arbeidsgivere blir varslet om at de er lovbrytere og de blir bøtelagt og dratt for retten. Taxinæringen skyr få midler. Selv har jeg blitt kalt "bøllete" i en artikkel av Taxiforbundets kommunikasjonssjef Atle Hagtun, der han stempler alle som støtter nytenkning rundt persontransport for kunnskapsløse, doktrinære markedsideologer. I tillegg til undertegnede henges tidligere byrådsleder Stian Berger Røsland ut, samt min stortingskollega Peter Christian Frølich og daværende fagdirektør i Forbrukerrådet, Anne Haabeth Rygg. Nå kan Hagtun legge til både Konkurransetilsynet og NHOs administrerende direktør Kristin Skogen Lund på listen over kunnskapsløse, doktrinære markedsideologer. Så kaller da taxiforbundet hennes nylige Uber-tursom "skammelig", og lederen av LO, Gerd Kristiansen, kritiserer selvsagt også NHO-sjefen og Uber.

Tekst fortsetter under bildet.
Faksimile fra Norges Taxiforbunds medlemsblad Taxi nr 8/2014.
I dag kan kjentmannsprøven erstattes av Google Maps, taksameter av gps som logger rute og forhåndsavtalt pris, kvittering av en e-post med kjørerute og pris, løyve av selskapets bakgrunnssjekk, vandelsattest og dessuten kundeevaluering av oppførsel og turopplevelse. Uber-entusiaster jeg kjenner i Norge skryter av ekstraservice og servering i bilen, mine egne opplevelser i utlandet er høyst ordinære – med et ekstra pluss for problemfri betaling og kvittering på e-post. Og selvsagt – muligheten til å evaluere sjåføren. I Oslo har den kriminelle, radikale islamisten ArfanBhatti, fått drosjeløyve. Taxiforbundets Atle Hagtun kaller meg ”bøllete” i sin artikkel i Norges Taxiforbunds medlemsblad (nr 8/2014) fordi jeg i et tidligere blogginnlegg påpeker at overgrepsdømte får fortsette å kjøre drosje i Norge og at en straffedømt taxisjåfør fra Oslo fikk i 2010 lov til å kjøre videre, til tross for at han lå på klagetoppen i Oslo Taxi. Mannen 51-åringen har blant annet skallet ned passasjerer, råkjørt og kommet med rasistiske utsagn. Han har mistet retten til å kjøre drosje flere ganger, men selve drosjeløyvet får han beholde, fordi det er ikke lov å ta fra ham. Men det er altså jeg som er bøllete og dagens regulering helt perfekt.

Selv mener Atle Hagtun at det er uproblematisk å sende meg e-poster hvor han blant annet skriver at: ”For deg og andre er økonomisk liberalisme en religion, hvor kunnskap ikke biter på.” Han siterte selv fra en av mine eposter i sin artikkel i deres medlemsmagasin, der han også hadde bilder av oss som støtter det han kaller ”lovbrytere” med undertittelen ”radikal”. Så da regner jeg med at det er helt greit å sitere fra en publisert artikkel og selvsagt også eposter. Jeg har alle, om noen er interessert. Også der han vil diktere hvordan jeg skal skrive om innovasjon og regulering, og ikke er interessert i min vinkling - noe han oversetter til at jeg trakk meg fra å skrive for medlemsbladet (se til høyre i teksten på bildet over). For jeg er jo kjent for å skygge unna debatter...

Uber har også hatt problemer med sine sjåfører. De blir utestengt fra tjenesten. En Uber-sjåfør i Indiable nylig dømt til livstid i fengsel for voldtekt av en passasjer. Han var lett å finne, da all informasjon om han lå i bestillingen hennes. I tillegg har Uber samarbeidet med indiske myndigheter og lansert en panikk-knapp som automatisk sender informasjon om gps-lokasjon på bilen, informasjon om både passasjer og sjåfør til politiet. Men altså ja, Uber har også rasshøl som sjåfører - om enn ikke over så lang tid som Oslo Taxi.

Likevel handler ikke dette egentlig om selskapet Uber som sådan, men om utdaterte reguleringer som uavhengig av Uber burde være overmodne for revisjon. De er røde flagg mot innovasjon. Likevel er det verdt å nevne at Uber akkurat rekrutterte 40 forskere fra verdens ledende robotlab, NREC, som har jobbet med teknologien bak talestyring og selvstyrende biler i flere tiår. Mens Norges Taxiforbund hetser politikere og raser mot NHO, skaper Uber antakeligvis fremtidens førerløse transportteknologi som kan gi blinde, funksjonshemmede, eldre og sånne som meg (uten lappen), en trygg, trafikksikker, automatisert og lett tilgjengelig transport – forhåpentligvis på en klimavennlig måte. Jeg er relativt overbevist om at ikke Toyota, Mitsubishi, Chrysler, General Motors eller Ford kommer til å sitte rolig å se på det. Gleder meg til Norges Taxiforbund skal ta opp kampen mot dem.

Atle Hagtun er for øvrig tidligere administrativ leder for stortingsgruppa til Venstre. De som fortsatt tror på det liberale i Venstre har med andre ord ingen garanti for eventuell støtte til et forslag fra regjeringen om å deregulere taxinæringen og åpne opp for nye, kundevennlige, innovative løsninger.
Foreløpig sitter regjeringen og tvinner fingrene. Her er noen innspill:

-gi et klart politisk signal om at Oslo Tingretts tolkning av Yrkestransportloven skal ligge til grunn for Uber-sjåfører. Virksomheten er ikke organisert piratvirksomhet, men lovlig virksomhet det skal betales skatt for.
-Hjelp Uber-sjåførene å bli gode skattebetalere. Det burde være enkelt for Skatteetaten å legge ut informasjon om hvordan de skal registrere seg som enkeltpersonsforetak, MVA-registrering og når momsplikten slår inn.
-Gå i dialog med Uber om innrapportering av inntekt for Uber-sjåførene. Norge har en av verdens mest effektive skatteinnkrevinger, og inntekter fra småjobber og nettverksøkonomien vil bare blir mer og mer vanlig. Her kan Norge, og kanskje til og med en offentlig etat, vise verden vei når det gjelder håndteringen av den nye økonomien. Ikke minst er dette en mulighet for teknologiselskaper innen finans (FinTech) til å komme opp med effektive løsninger som kobler behovene til skattemyndigheter og nettverksøkonomien. 

Gir deleøkonomien og nettverksøkonomien oss utfordringer knyttet til reguleringer og arbeidsliv? 
Definitivt.
Er forbud og forfølgelse måten å løse det på?
Definitivt ikke.  

Hvis det er bøllete jeg må være for å fremme nye ideer og bedre løsninger, så er jeg gjerne det. Men det burde ikke være nødvendig i et land som snakker så mye om innovasjon og entreprenørskap som vi gjør i Norge i disse dager.
Read the whole story
aklefdal
3030 days ago
reply
Stabekk
Share this story
Delete
Next Page of Stories