Kenneth Auchenberg

Passion for the web platform.

Introducing ColdFront Conference

The past years I’ve been traveling to Amsterdam, London, Berlin, Brighton, London, New York and San Francisco to attend awesome conferences and to be a part of our community.

But for a long time I’ve wanted a local front-end conference in Copenhagen, because I feel we have a vibrant community of developers, designers and creatives who are doing fantastic things for the web, either in agencies or in startups. There’s no reason why we should travel to other great cities to get inspired, instead we should come together, as a community.

Over the years, CopenhagenJS, our local JavaScript community, has slowly gained more traction among people, and now is the time to take CopenhagenJS a step further – a single day conference focused around what it takes to build great front-end for the web.

ColdFront Conference

ColdFront Conference is new front-end conference in Copenhagen, and is going to take place 4th September 2014 in a cool and non-corporate venue.

When we look at the history, a lot of great web technology has been researched and developed in Denmark, like Google’s V8 engine and Ruby On Rails, but ironically we haven’t talked much about this on danish soil.

I think this is mostly because our established conferences are themed around general software development and have a rather “enterprisy” focus on established technologies like Microsoft .NET and Java.

ColdFront isn’t going to be like that.

ColdFront is a curated conferenced, with hand-picked speakers, and I’m going to put emphasis on the single-track, as I feel it’s the best way to great the best conference experience. The attendees experience the same talks and get’s on the same page, which usually spurs a lot of great conversations in the breaks.

The aim is to create a conference with a community feeling, full of great like-minded people that loves crafting for the web.

This means ColdFront won’t be ridiculously expensive as many other conferences has become over the years, and more importantly it won’t be a massive event, with too many people (I’m looking at you Google IO), where you really can’t meet and network with like-minded people.

Let’s face it, networking and having a great time is probably one of the main reasons why we are going to conferences these days, so with ColdFront we are going to be focusing on quality sessions, networking, and of course having a great time.

Who’s behind?

Running a conference is a lot of work, so I’ve joined forces with a good friend of mine, and experienced conference organizer, Daniel Frost, who has been running several events from his time at Microsoft, and more recently his own conference, TheWCDC.

If you are interested in sponsoring ColdFront, then feel free to give me a ping at

What’s next?

We already signed 5 speakers for the conference, but we are quite busy settling on the final details, so until then sign-up on our website and you will be notified as soon we are ready to announce more speakers and sell tickets.

There’s a new ColdFront Conference on it’s way to Copenhagen!

zero-config local wildcard domains/dns with .dev

A few days ago I was reminded of little script I wrote, and a domain I bought some late night back in 2012. I never took the time to wrap it up as something releasable, but today I spent a few hours building a little website and writing this blog post.

Since the very beginning of Podio we have been using subdomains extensively to provide organizations with their every own URL. Today we are no longer using subdomains for various reasons, but back then I spend a bit of time finding a good solution to get wildcard *.dev domains working in my development environment.

You should think running a development environment with wildcard *.dev domains is a no-brainer. Ignorantly, I thought I just could add a wildcard entry in my /etc/hosts, and bam it would work.

It’s not that simple.

What if you could use Chrome DevTools with Mozilla Firefox?

To many front-end developers this is a ubiquitous dream, but is it really?

About a month ago I launched an idea I’ve had for a while. The idea is called RemoteDebug, and is an initiative to unify remote debugging across browsers. As a part of my presentation at FullFrontal conference where I talked about RemoteDebug, I demoed an early prototype of using Chrome DevTools together with Mozilla Firefox.

I want to tell you a bit more about the prototype.

The messy state of Web Notifications in Blink and Webkit

Lately I’ve been working with the Web Notifications API, and while working I realized that Chrome ins’t following the specification. In this post I will take you through the messy state of Web Notifications.

Showing desktop notifications from the web, was a web-dream for many frontend-developers, until Fluid enabled it via an Growl integration in OSX and exposed it as JavaScript API in Fluid. It became quite popular, and many web2.0 cool cats like Basecamp integrated with it, either themselves or in user scripts by their users.

Soon after followed WebKit-based browsers via it’s own notification system, and exposed as an webkit-prefixed API. The Webkit notifications was available on all major platforms, but never became popular. Most likely because the of each notification wasn’t what I could call pretty.


Last year desktop notification was standardized into the Web Notifications specification, which now lives both as a W3C draft, and as a WHATWG standard. Apple was one of the first vendors to implement the specification in Safari 6, and announced it as a key-feature, when they released Safari 6 together with OSX’s Notification Center in OSX Mountain Lion.

Later along followed Chrome implementing the standardized specification, while keeping webkit-prefixed API around.

This is where the mess began.

Our web development workflow is completely broken.

I’m sitting here at Google headquaters in Mountain View, and is trying to sum up my take aways from this years Google IO 2013. At the conference I had a chat with Paul Irish and Pavel Feldman on where the Chrome developers tools are headed, which has spurred me to write this blog post.

The web development workflow has been on my mind for a while. I’ve been talking about it at a number of CopenhagenJS meet-up’s, but now is the time put my thoughts down into a blog post.

My passion is to build tools. I love building the fundamental lego-bricks that other’s can combine in ways I didn’t imagine. The past years I’ve been building Podio, a work platform where we have enabled more then 50.000 organizations to work better by enabling them to build their own tools.