Between reality and cyberspace
Webkit Remote Debugging and Phonegap Build

Debugging has been a problem in hybrid app development over the recent years.

Yes, there has been WeinRE or Ripple to ease the test and debug pains or the logs from the device if everything else did not help - but it was no substitution for the debugging tools we have for normale websites and running the application in a normal browser (vs. the embedded web view of Phonegap).

Enter Webview Debug

As explained on the Phonegap Debugging Guide there’s a new way to debug Phonegap applications on devices running Android 4.4: Webkit remote debugging.


Cordova 3.3

Cordova 3.3 has the webkit debugging enabled, if you set the debuggable flag in the AndroidManifest.xml and the targetSdkVersion to 19. On Phonegap Build you just need to enable debugging and adjust the SDK version, no modifications in the AndroidManifest.xml are needed.

Cordova 3.2

With Cordova 3.2 you’ll need to add some code to make the Web view debuggable or you use this handy plugin.

Using the dev tools

You need to connect your device via USB to the computer you want to use the Chrome Dev tools on.

Then run adb list devices to see if the device is ready for debugging. If it doesn’t show up, you need to enable USB debugging.

Open chrome://inspect in the Chrome browser and enable “discover USB devices”.

When you launch the app on the phone, it should appear in the list. By clicking on it, you can start using the full dev tools suite to debug your hybrid app now.

Ignite talks coming to Zurich!

So what’s an ignite talk?

Quoting from the ignite show website:

Imagine that you’re in front of an audience made up of your friends, family, and people from your community, about to present a 5-minute talk on the thing you’re most passionate about.  
You’ve brought 20 slides, which advance every 15 seconds whether you’re ready or not.   
You have a few last-minute butterflies, but off you go—and the crowd loves it. Welcome to Ignite.

Others have explained it, too: here or here.

While ignite started as a geek event, I found it to be a great way to share experiences and ideas with a diverse audience - any topic is welcome and the format makes you distill the juicy bits together and helps you to avoid getting sidetracked into tricky details.

Getting started with ignite talks in Zurich

With Ignite groups and events all over the world now it’s time Zurich gets a chance to spread ideas and inspire, too.

This is why I just created the Ignite Zurich community to open up this opportunity to people in and around Zurich - it doesn’t matter if you ever did an ignite talk - or any public speaking at all - before or if public speaking is part of your daily business.

I will do my best to make the community a space to explore, experiment and exchange using the ignite method.

Like the idea?

If you like what you just read, I invite you to join the community and give it a go at our meetups.

New experiment: Record screen and webcam from your browser

Thanks to an experimental feature in Google Chrome, you can use getUserMedia to capture your screen - put that together with your webcam stream and record it as a video from within the browser - et voila: An interesting experiment was born.


Take a look at my quick demo:

You can try it yourself here or take a look at the Github repository.

A rabbit hole called development

To solve n IT problems, you need to solve n^n other problems first. You know that, right? You face a challenge you want to tackle, only to find out that there’s a myriad other, related challenges to be tackled first.

This is how this experiment came to live…

How to capture your screen with web technologies

I recently stumbled upon an experimental Chrome feature for capturing your screen with getUserMedia and so I thought: Sweet, that’d give a great screencast recording tool.

Now for a screencast to be a little more personal and relatable, I find it nice to see the person talking me through something - and the web has me covered!

I just request the video stream from the web cam and put it together (picture-in-picture) with the video stream from the screen capture.

Recording from getUserMedia

Alright, now I can see myself and my screen. That’s cute but only mildly useful - I’d need to record it.
Again the web has me covered… sorta…

The StreamProcessing is including a piece for recording video and audio. But I don’t know any browser supporting it today.

There is also the MediaRecorder proposal… but documentation is rare for this.

So I had to look for some other way to get to something quickly.

Whammy.js to the rescue

For the video bit, I use whammy.js now. It allows to take frames from the canvas and put them together as WebM videos.

The next steps

So I can record video - but no audio. That’s pretty bad.
I will also take a look at MediaStreamRecorder which should give me access to video and audio recording.

Do you know the difference between Queue, MQ, ESB etc.?

Because I wasn’t fully aware of it until today. This whole topic in that much detail is new to me - and this is a discussion start, so feel free to engage here.


The quick rundown: - Message Queues for asynchronous communication in your system - Message Brokers for loosely coupled components - Integration frameworks if you need to make them understand each other first - ESBs if you’re facing a zoo of services and tricky requirements (e.g. governance) - Integration suites if you need BPM or MDM in the picture

If you have input - I want to learn more! If you never heard most of those words from above - read on!

Naming things is hard!

"There are 2 hard problems in computer science: caching, naming, and off-by-1 errors"

— Phil Karlton

This topic is a wonderful proof for the saying from above.
Naming things is tricky - differentiation isn’t always straight forward and there are grey areas everywhere.

I think it is fundamentally important to know what you’re talking about when the buzzwords start falling like raindrops on a rainy afternoon in autumn… and you should make sure everybody in the discussion has a cristal clear idea what you mean when you use them.
If anybody is not on the same page with you on that, solution finding is going to be horrible.

Who’s who?

We’re gonna encounter the following players in the naming game:

  • Message transports / Queues
  • Message brokers / Message queues
  • Integration frameworks
  • Enterprise Service Buses
  • Integration Suites

So if you’re thinking about using any of these terms read on!

Transports / Queues

Let’s start with the simplest thing first: The message transports and queues.

Those are relatively dumb.
In the case of transports they’re just pushing data around from A to B, generically speaking. Examples are Thrift, ICE, CORBA or ZeroMQ (0mq being a bit special, as it has some features of the next higher layer).

Queues are dumb too. You push stuff in and take stuff out eventually. That’s it. Examples are Pipes, ring-buffers, stacks or even DBs (e.g. Redis) can be used for this.

These are primitive building blocks to implement interesting services on top of them. Those services may be able to masquerade the type of data structure they operate on, but choosing the solution with the proper data structure for your use case is important.
Queues are great for asynchronous operations, where the time between pushing and removing doesn’t matter so much, but messages should never be lost (as queues can be implemented as persistent storage), while message transport are great when the delay should be minimal or you want to fan out to a large audience - guarantees for delivery may be available, too - to a certain extent.

Message queues / Message brokers

A message queue uses a queue (well, duh!) to establish asynchronous communication between different parties (services for example) while adding a few features on top of the queue implementation, such as:

  1. Durability (resilience)
  2. Policies (e.g. message TTL, terms of delivery, batching, etc)
  3. Security (access control)
  4. Routing (pub/sub, point-to-point, etc.)

Message brokers, on the other hand, provide loose coupling between components without necessarily being asynchronous or queue-based at all. They, too, provide a few additional services on top of their lower layer:

  1. Routing
  2. Multiplexing / De-multiplexing (i.e. aggregation and decomposition of messages from/into multiple messages to different receipients)
  3. Security
  4. Policies
  5. Durability (resilience)
  6. Transformation (translation of messages between formats)

Here things usually get blurry - many solutions are both (message queue and message broker) - for example RabbitMQ or QDB.
Samples for message queues are Gearman, IronMQ, JMS, SQS or MSMQ.
Message broker examples are Qpid, Open AMQ or ActiveMQ.

Again, things are hard to tell apart… especially with popular tools like RabbitMQ being citizen of both worlds it is tricky to make sure everybody is on the same page…

So now we had a look at this layer, it becomes clear that message queues are great if you’re just after making some components asynchronous - but there’s a gradient into the world of message brokers, which can also be asynchronous, but provide more sophisticated communication patterns.
Message brokers aim primarily for decoupling and help integrating different components, without having to know too much about your communication partners. For this to work, they provide the transformation functionality to make sure the peers can understand each other.

If you ever find yourself implementing message transformation on top of a message queue, you know have a way to avoid that!

Integration frameworks

This is often meant when people bring “Enterprise Service Bus” to the table, but it isn’t as powerful as one, yet more powerful than message brokers.

Integration frameworks are basically specialized message brokers for integrating different pieces of software with each other.
They usually ship with a selection of connectors (e.g. FTP, HTTP, AMQP, SMTP and what not). They may also support some enterprise application integration patterns (EAI patterns).

Examples for those beasts are Spring Integration Framework or Apache Camel.

These are great if you’re going to make different systems talk to and understand each other. If you’re building something that speaks the same language anyway, you may be better off with a message queue or message broker, I guess.

Enterprise Service Buses

This is a widely-used buzzword. So what’s this thing about, then?

This is the go-to solution for service-oriented architectures - it’s basically a really smart and resilient integration framework.

In addition to the integration framework it provides:

  • Monitoring of the services and the messages passed between them
  • Deployment and service version controlling
  • Scheduling, mapping, QoS management, error handling and more
  • load balancing between services of the same type and concurrency control

The twist is, that most functionality is actually provided as a service on the bus - routing for example or transformations.

ESBs come with a host of tools for Monitoring, Auditing, managing routes and service bindings, etc. That’s really handy for critical messaging between a large number of components within one system.

Samples for ESBs are Apache ServiceMix or Synapse, BizTalk, JBoss ESB, Open ESB or Mule.

Integration Suites

Last but not least: Integration Suites.
Those add even more on top of the ESBs, such as:

  • BPM integration
  • MDM services

So the integration suites are basically ESBs with business process logic on top.


Phew. What a ride. I am pretty sure I missed something, maybe I even misunderstood bits and pieces - but one thing is clear: It’s important to figure out what exactly you want and how it’s actually called.

If you just want to decouple components of a small system, an ESB may be overkill but if you need to take data quality or governance into account, it may not even be enough for you.

I’m looking forward to hear your input :)

Debugging the mobile web on your computer with Chrome Dev Tools

Today I randomly stumbled upon an extremely useful feature in the dev tools of Chrome, that I have missed so far:

Emulating sensors, screen sizes, touch events and more in the Chrome developer tools.

To be use this feature, you need to:

  1. Open the developer tools
  2. Open the developer tools settings (little gear icon)
  3. a. On Chrome Stable, you need to check “Show ‘Emulation’ view in console drawer.” in the general section. b. On Chrome Beta, go to the “Override” panel and check the “Show ‘Emulation’ view in console drawer.” option.
  4. Press “Esc” in the developer tools and click on “Emulate”.

More details on how to use the features can be found in this article.

Flip Ahead browsing and a js polyfill

If you haven’t heard of *flip ahead browsing* you are like me a few months ago.

Have you ever read a blog post or a multi page article on a website on a mobile device and felt the urge to just swipe and get to the next or previous post or page?

No, I don’t mean navigating the browser history. I talk about coming to a website for the first time and wanting to get to the next (or previous) logical content, such as the following blog post or page two of the great article you’re reading…

I did feel that urge. It feels natural to “turn the page” by swiping.

To my surprise, the Internet Explorer has this feature, called “flip ahead browsing”. If a website, say your blog, supports it and I swipe on a page, it takes me to the URL the page author deems logically “next” or “previous”.

When I revamped [Geekonaut] (, I implemented flip ahead browsing, so people can swipe to reach the next or previous section, according to main navigation order.

Implementing it is extremely simple and a no-brainer to me:

    <link rel=”next” href=”…” />
    <link rel=”prev” href=”…” />

I wonder why Internet Explorer is apparently the only browser that implements this.

Having tried it on a tablet my only concern is, that it clashes with the normal horizontal scrolling and that may be bad.

I agree with the idea of a colleague of mine that it would be good to establish a new convention to use a two-Finger swipe to use this form of navigation.

For this„ I built [a simple Javascript library]( that uses the same link syntax but a two-finger swipe to provide flip ahead browsing.

I am, still, not sure if the gesture is obvious or natural enough or if the education is worth the hassle.

I would love your feedback on this.

The future is hybrid… or is it?

After my talk at Future of web apps in October 2013 in London, I got interviewed by Louise from Future Insights about the future of mobile apps and why I was talking about hybrid apps.

You can find the article here - but I can’t stress enough, that hybrid isn’t the future, it’s a vehicle. A vehicle for the mobile web apps.

Right now we have to cut a few corners to deliver the best user experience on mobile with web technologies. Many users are still bound to the marketplaces (where Mozilla’s approach of “installing the web” is having the potential to change the game) and many device features are still only released as APIs for native applications.

To unlock these two, often business-relevant, features you have to either go hybrid in some way or you go native.

Native, however, locks you in whereas hybrid only does to a certain degree (depending on the strategy you chose).

So, for now, I think some sort of hybrid approach is the vehicle to help us move the app makers into the web universe and work all together towards an even-more competitive web platform.

Finding out all the licenses of your dependencies

A while ago I wondered if, with all the dependencies creeping into software I build, I’m not violating a GPL license hidden somewhere.

I turned to npm and Rubygems on the quest to fix this potential issue only to find that neither bundler nor gem or npm allow me to find out in a painless way.

So I built a small ruby script to parse Gemfiles (and recently added package.json support for npm) and tell me the licenses.

For NPM this is surprisingly boring and easy, as npm gives you the “MIT” license as the default when creating a new module - but in the Ruby world the journey is more cumbersome as there’s no default license.

After running the script against a bunch of projects I incorporated an additional mechanism to try to figure out more licenses and today I want to invite you to give it a go, too

You can find the script on the all-your-licenses Github repository and install the few dependencies it has with bundler, then run it with

$ ruby main.rb -f /path/to/Gemfile_or_package.json

Have fun and don’t violate any licenses anymore ;-)

DISCLAIMER: The tool may output invalid results and does not provide any legally binding information to you. Use it at your own risk! No legal claims shall be made as this is provided as is!

The pace of technology - a tiny review

I’d just like to give you an idea of the velocity of change in technology and how much of an impact this has on our everyday life.

When I had my first computer experience on a Commodore 64 I was learning everything from a book. A book that had a few hundred pages printed on paper.

The best I could get were a few programs written in BASIC or, later, assembly language. They could draw stuff on screen, react to keyboard or joystick input and were rather simple games.

Then I got a PC. If I wanted it to do something new I’d go to a shop, buy a bunch of CDs and install the software. After a few hours (taking the time to go to the shop until the program was running for the first time) you then had a shiny new toy.

Then I learned programming GUIs. That was a very different experience, as it is much more event-driven than the classical REPL-style programs I wrote.

Back then the only way I could exchange my software with others was a floppy disk with the CD writer just being the hottest (and pretty expensive) piece of hardware.

Then I finally came online - and it was a revolution: I could run a small website with my software on it and within weeks a few hundred people were running code that I had written.

I could exchange information within a blink of the eye, download new software, learn a new trick in software development and distribute my work worldwide - new things were minutes away.

Then I built a few tools myself to share pictures, ebooks, texts and hosted them myself as services just started to pop up throughout the net.

Back then I switched from a few megabytes shared web space to a virtual server. It would cost around 15€/month and it took a contract and a few days to set up.

Then the cloud era began.

You could now spin up and shut down servers as you went along. It took a click. No paperwork, no waiting. And with servers becoming a commodity, services became a commodity, too.

I didn’t have to host my software, my code, my pictures, music books or anything else myself anymore - it was a matter of clicks now.

And this is today - things that required knowledge of how to run a server or how to configure a whole range of pieces to get something online are now easily and readily available for almost everybody.

But as a word of warning: We need to make sure it stays that way. I highly encourage you to look at the unhosted initiative, at the indie web and interesting projects such as the indie phone.


When we started building UserApp we all agreed on one thing. Focus on the things that we did best and outsource the rest.

This played in well with our choice to go with a CDN instead of hosting our front-end ourselves. After all, our front-end is just HTML/JS, so why bother hosting it ourselves…