Between reality and cyberspace
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.

Demo

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.

TL;DR

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.

Wrap-up

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] (http://geekonaut.de), 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](http://github.com/AVGP/flipAhead.js) 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.

orhedenr:

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…

Quick review: Samsung 11” Chromebook

The first impression in short (TL;DR)

The Samsung 11” Chromebook is a solid, cheap and lightweight device to get work done while being on the go.

How it all came to be

I work alot while I’m on the road - be it commuting on the bus or travelling around on a train or airplane.

During these times I am usually programming (mostly using lightweight or browser-based tools), writing blog posts (like this one) or preparing a slide deck.

I was still searching for a cheap, slightly smaller and lighter device to do those rather simple tasks and when I travelled to London, I decided to go into a store and get my hands on the 11” Chromebooks from HP and Samsung. Surprisingly the Samsung one convinced me more with its overall impression - so I bought one - and herein I give you an overview of my experience with it, sitting in an airplane heading home.

Getting started

After unwrapping it and plugging in the charger, I was suprised that it was fully uncharged but claimed to be fully charged within the next 40 minutes. And it was!

That initial plus was overthrown by the setup, that needed a WiFi connection but had trouble working with the “Sign-In” of the wireless network at London Heathrow, so I had trouble setting it up, but the guest mode allowed me to properly surf the net instantly.

The next minor quirk was the initial tour application not responding to my inputs at all - but I can live with that.

There’s an app for that!

I believe in the web as being a powerful platform, so I was looking forward to trying out the many apps from the Chrome Web Store.

I was looking for a decent Markdown editor with a live preview feature, as that’s the way I enjoy writing my blog posts the most - and I found Poe. As my IDE of choice, I picked Cloud9 and after a couple of minutes I was ready to go.

My biggest worry was, that the apps may not work without an internet connection, but flying back just now while writing this post proves that it indeed did work offline.

The great thing: I’m not missing any application and if I ever will, I could write that app using my beloved stack of web technologies;

How working on the Chromebook feels

The keyboard

The keyboard feels good and has decent spacing, sizing and feedback, the only thing that I may miss is the backlight I am used to on my Macbook.

The screen

The 11” screen is the perfect size for me, providing enough screen space to work and being comfortably sized for carrying it around. The brightness and view angle are sufficient - even this writing session along with my experients, for a bit over 2 hours now, aren’t a problem.

The rest

The case seems pretty sturdy but definitely has a plastic touch to it, the camera is pretty good and the Chromebook starts up in a couple of seconds and the battery - according to the system panel, should last for around 6 hours, maybe 5 with WiFi turned on.

Only the WiFi gave the impression to have a tendency to be a bit flaky at times.

Quick bulletin: Picking a way of developing hybrid mobile apps

Due to popular demand: A superquick guide to picking the right tools for you.

TL;DR: You may want to give my Hybrid Strategy Picker a whirl. Be careful tho, it’s far too simplistic, but a good starting point.

Warning: This is by no means complete and it may not turn out to be the right fit for you. For more details and the full story see my slides from SpainJS 2013.

With this out of the way, let’s step into this!

So you want to go hybrid..

..nice! But before you start looking at the technologies, you need to answer a couple of questions and make a couple of decisions.

This post aims at speeding this up a little for you.

Remark The following choices can be considered production ready.

Choice 1: Only Javascript

If you come from a JS world and have been working with the backend side of things a lot and you feel more comfortable with writing pure Javascript all the time (or Coffeescript, for that matter), this choice is for you.

You should have a close look at Sencha as it gives you a one-stop-solution: UI, Logic / Architecture, Packaging right out of the box.

Choice 2: HTML / CSS / JS

You’re coming from the web world and know all parts of the frontend stack? That gives you a couple of choices on it’s own:

Option A: Kendo + Cordova

This gives you the UI & Logical architecture from Kendo (MVVM) and deployability to a range of platforms, including iOS and Android.

There’s even a simple way of getting into it right from your browser, check Icenium to get up and running in no time.

Option B: LAB + Cordova

This gives you the wonderful world of Angular.js with the UI sweetness & easy prototyping Lungo.js provides. Check out our Github repository or the grunt-init task for the LAB to get started as quick as possible.

I hope you now have some pointers to go and play with things that are ready for prime time - use these powers with care and never forget

Martin’s rule of mobile app development

Don’t trust anybody, test it yourself