Henri Bergius - Business

Publish your data on the BIG IoT marketplace

henri.bergius@iki.fi (Henri Bergius) — Mon, 12 Feb 2018 00:00:00 +0000

When building IoT systems, it is often useful to have access to data from the outside world to amend the information your sensors give you. For example, indoor temperature and energy usage measurements will be a lot more useful if there is information on the outside weather to correlate with.

Thanks to the open data movement, there are many data sets available. However, many of these are hard to discover or available in obscure formats.

The BIG IoT marketplace

BIG IoT is an EU-funded research project to make datasets easier to share and discover between organizations. With it there is a common semantic standard for how datasets are served, and a centralized marketplace for discovering and subscribing to data offerings.

For data providers this means they can focus on providing correct information, and let the marketplace handle API tokens, discoverability, and — for commercial datasets — billing
For data consumers there is a single place and a single API to access multiple datasets. No need to handle different Terms of Usage or different API conventions

As an example, if you’re building a car navigation application, you can use BIG IoT to get access to multiple providers of routing services, traffic delay information, or parking spots. If a dataset comes online in a new city, it’ll automatically work with your application. No need for contract negotiations, just a query to find matching providers on-demand.

Flowhub and BIG IoT

Last summer Flowhub was one of the companies accepted into the BIG IoT first open call. In it, we received some funding to make it possible to publish data from Flowhub and NoFlo on the marketplace. In this video I’m talking about the project:

In the project we built three things:

BIG IoT JavaScript library – a Node.js library for publishing datasets in the BIG IoT marketplace
Flowhub BIG IoT bridge – a set of NoFlo components for creating BIG IoT providers
Deutsche Bahn and Cologne parking offerings – a set of live examples of integrating existing IoT datasets with the marketplace using Flowhub

Creating a data provider

While it is easy enough to use the BIG IoT Java library to publish datasets, the Flowhub integration we built it makes it even easier. You need your data source available on a message queue, a web API, or maybe a timeseries database. And then you need NoFlo and the flowhub-bigiot-bridge library.

The basic building block is the Provider component. This creates a Node.js application server to serve your datasets, and registers them to the BIG IoT marketplace.

What you need to do is to describe your data offering. For this, you can use the CreateOffering component. You can use IIPs to categorize the data, and then a set of CreateDatatype components to describe the input and output structure your offering uses.

Finally, the request and response ports of the Provider need to be hooked to your data source. The request outport will send packets with whatever input data your subscribers provided, and you need to send the resulting output data to the response port.

For real-world deployment, the Flowhub BIG IoT bridge repository also includes examples on how to test your offerings, and how to build and deploy them with Docker.

Here’s how a full setup with two different parking datasets looks like:

If you’re participating in the Bosch Connected World hackathon in Berlin next week, we’ll be there with the BIG IoT team to help projects to utilize the BIG IoT datasets.

This project has received funding from the European Union’s Horizon 2020 research and innovation program under grant agreement No 688038.

Building an IoT dashboard with NASA Open MCT

henri.bergius@iki.fi (Henri Bergius) — Thu, 05 Oct 2017 00:00:00 +0000

One important aspect of any Internet of Things setup is being able to collect and visualize data for analysis. Seeing trends in sensor readings over time can be useful for identifying problems, and for coming up with new ways to use the data.

We wanted an easy solution for this for the c-base IoT setup. Since the c-base backstory is that of a crashed space station, using space technology for this made sense.

NASA Open MCT is a framework for building web-based mission control tools and dashboards that they’ve released as open source. It is intended for bringing together tools and both historical and real-time data, as can be seen in their Mars Science Laboratory dashboard demo.

c-beam telemetry server

As a dashboard framework, Open MCT doesn’t really come with batteries included. You get a bunch of widgets and library functionality, but out of the box there is no integration with data sources.

However, they do provide a tutorial project for integrating data sources. We started with that, and built the cbeam-telemetry-server project which gives a very easy way to integrate Open MCT with an existing IoT setup.

With the c-beam telemetry server we combine Open MCT with the InfluxDB timeseries database and the MQTT messaging bus. This gives a “turnkey” setup for persisting and visualizing IoT information.

Getting started

The first step is to install the c-beam telemetry server. If you want to do a manual setup, first install a MQTT broker, InfluxDB and Node.js. Optionally you can also install CouchDB for sharing custom dashboard layouts between users.

Then just clone the c-beam telemetry server repo:

$ git clone https://github.com/c-base/cbeam-telemetry-server.git

Install the dependencies and build Open MCT with:

$ npm install

Now you should be able to start the service with:

$ npm start

Running with Docker

There is also an easier way to get going: we provide pre-built Docker images of the c-beam telemetry server for both x86 and ARM.

There are also docker-compose configuration files for both environments. To install and start the whole service with all its dependencies, grab the docker-compose.yml file (or the Raspberry Pi 3 version) and start with:

$ docker-compose up -d

We’re building these images as part of our continuous integration pipeline (ARM build with this recipe), so they should always be reasonably up-to-date.

Configuring your data

The next step is to create a JavaScript configuration file for your Open MCT. This is where you need to provide a “dictionary” listing all data you want your dashboard to track.

Data sets are configured like the following (configuring a temperature reading tracked for the 2nd floor):

var floor2 = new app.Dictionary('2nd floor', 'floor2');
floor2.addMeasurement('temperature', 'floor2_temperature', [
  {
    units: 'degrees',
    format: 'float'
  }
], {
  topic: 'bitraf/temperature/1'
});

You can have multiple dictionaries in the same Open MCT installation, allowing you to group related data sets. Each measurement needs to have a name and a unit.

Getting data in

In the example above we also supply a MQTT topic to read the measurement from. Now sending data to the dashboard is as easy as writing numbers to that MQTT topic. On command-line that would be done with:

$ mosquitto_pub -t bitraf/temperature/1 -m 27.3

If you were running the telemetry server when you sent that message, you should’ve seen it appear in the appropriate dashboard.

There are MQTT libraries available for most programming languages, making it easy to connect existing systems with this dashboard.

The telemetry server is also compatible with our MsgFlo framework, meaning that you can also configure the connections between your data sources and Open MCT visually in Flowhub.

This makes it possible to utilize the existing MsgFlo libraries for implementing data sources. For example, with msgflo-arduino you can transmit sensor data from Tiva-C or NodeMcu microcontrollers to the dashboard.

Status and how you can help

The c-beam telemetry server is currently in production use in a couple of hackerspaces, and seems to run quite happily.

We’d love to get feedback from other deployments!

If you’d like to help with the project, here are couple of areas that would be great:

Adding tests to the project
Implementing downsampling of historical data
Figuring out ways to control IoT devices via the dashboard (so, to write to MQTT instead of just reading)

Please file issues or make pull requests to the repository.

NoFlo: six years of JavaScript dataflow

henri.bergius@iki.fi (Henri Bergius) — Mon, 05 Jun 2017 00:00:00 +0000

Quite a bit of time has passed since my two years of NoFlo post, and it is time to take another look at the state of the NoFlo ecosystem. To start with the basics, NoFlo is a JavaScript implementation of Flow-Based Programming:

In computer programming, flow-based programming (FBP) is a programming paradigm that defines applications as networks of “black box” processes, which exchange data across predefined connections by message passing, where the connections are specified externally to the processes. These black box processes can be reconnected endlessly to form different applications without having to be changed internally. FBP is thus naturally component-oriented.

With NoFlo software is built by creating graphs that contain reusable components and define the program logic by determining how these components talk to each other.

I started the NoFlo open source project six years ago in Mountain View, California. My aim was to improve the JavaScript programming experience by bringing the FBP paradigm to the ecosystem. At the time the focus was largely on web API servers and extract, transform, load (ETL) programs, but the scope has since expanded quite a bit:

NoFlo is not a web framework or a UI toolkit. It is a way to coordinate and reorganize data flow in any JavaScript application. As such, it can be used for whatever purpose JavaScript can be used for. We know of NoFlo being used for anything from building web servers and build tools, to coordinating events inside GUI applications, driving robots, or building Internet-connected art installations.

Flowhub

Four years ago I wrote how UI was the missing part of NoFlo. Later the same year we launched a Kickstarter campaign to fix this.

Our promise was to design a new way to build software & manage complexity - a visual development environment for all.

This was wildly successful, being at the time the 5th highest funded software crowdfunding campaign. The result — Flowhub — was released to the public in 2014. Big thanks to all of our backers!

Here is how Fast Company wrote about NoFlo:

If NoFlo succeeds, it could herald a new paradigm of web programming. Imagine a world where anyone can understand and build web applications, and developers can focus on programming efficient components to be put to work by this new class of application architects. In a way, this is the same promise as the “learn to code” movement, which wants to teach everyone to be a programmer. Just without the programming.

With Flowhub you can manage full NoFlo projects in your browser. This includes writing components in JavaScript or CoffeeScript, editing graphs and subgraphs, running and introspecting the software, and creating unit tests. You can keep your project in sync with the GitHub integration.

Celebrating six years of NoFlo

Earlier this year we incorporated Flowhub in Germany. Now, to celebrate six years of NoFlo we’re offering a perpetual 30% discount on Flowhub plans. To lock in the discount, subscribe to a Flowhub plan before June 12th 2017 using the code noflo6.

Ecosystem

While NoFlo itself has by no means taken over the world yet, the overall ecosystem it is part of is looking very healthy. Sure, JavaScript fatigue is real, but at the same time it has gone through a pretty dramatic expansion.

JavaScript

As I wrote around the time I started NoFlo, JavaScript has indeed become a universal runtime. It is used on web browsers, server-side, as well as for building mobile and desktop applications. And with NoFlo you can target all those platforms with a single programming model and toolchain.

The de-facto standard for sharing JavaScript libraries — NPM has become the most popular software repository for open source modules. Apart from the hundreds of thousands of other packages, you can also get prebuild NoFlo components from NPM to cover almost any use case.

Dataflow

After a long period of semi-obscurity, our Kickstarter campaign greatly increased the awareness in FBP and dataflow programming. Several open source projects expanded the reach of FBP to other platforms, like MicroFlo to microcontroller programming, or PhpFlo to data conversion pipelines in PHP. To support more of these with common tooling, we standardized the FBP protocol that allows IDEs like Flowhub manage flow-based programs across different runtimes.

Dataflow also saw uptake in the bigger industry. Facebook’s Flux architecture brought flow-based programming to reactive web applications. Google’s TensorFlow made dataflow the way to build machine learning applications. And Google’s Cloud Dataflow uses these techniques for stream processing.

Tooling for flow-based programming

One big area of focus for us has been improving the tooling around NoFlo, as well as the other FBP systems. The FBP protocol has been a big enabler for both building better tools, and for collaboration between different FBP and dataflow systems.

Here are some of the tools currently available for NoFlo developers:

Flowhub — browser-based visual programming IDE for NoFlo and other flow-based systems
noflo-nodejs — command-line interface for running NoFlo programs on Node.js
noflo-browser-app — template for building browser applications in NoFLo
MsgFlo — for running NoFlo and other FBP runtimes as a distributed system
fbp-spec — data-driven tests for NoFlo and other FBP environments
flowtrace — tool for retroactive debugging of NoFlo programs. Supports visual replay with Flowhub

NoFlo 0.8

NoFlo 0.8, released in March this year is probably our most important release so far. It introduced a new component API and greatly clarified the component and network lifecycle.

With this release, it is easier than ever to build well-behaved NoFlo components and to deal with the mixture of asynchronous and synchronous data processing. It also brings NoFlo a lot closer to the classical FBP concepts.

As part of the release process, we also fully overhauled the NoFlo documentation and wrote a new data transformations tutorial project.

To find out more about NoFlo 0.8, watch my recent NoFlo talk from Berlin Node.js meetup:

Road to 1.0

In addition to providing lots of new APIs and functionality, NoFlo 0.8 also acts as the transitional release as we head towards the big 1.0 release. In this version we marked many old APIs as deprecated.

NoFlo 1.0 will essentially be 0.8, but with all the deprecated APIs removed. If you haven’t done so already, now is a good time to upgrade your NoFlo projects to 0.8 and make sure everything runs without deprecation warnings.

We intend to release NoFlo 1.0 later this summer once more of our open source component libraries have been updated to utilize the new features.

Forget about HTTP when building microservices

henri.bergius@iki.fi (Henri Bergius) — Thu, 13 Apr 2017 00:00:00 +0000

Microservices — an architectural pattern we recommended in our 2012 International PHP Conference keynote — is pretty popular these days. There are many benefits to consider:

Independent development and release lifecycle for each microservice
Ensuring clear API boundaries between systems
Ability to use technologies most applicable for each area of a system

In an ideal world, microservices are a realization of the Unix philosophy as applied to building internet services: writing programs that do one thing, and do it well; writing programs that work together.

Just use a message queue

However, when most people think about microservices, they think systems that communicate with each other using HTTP APIs. I think this is quite limited, and something that makes microservices a lot more fragile than they could be. Message queues provide a much better solution. This is mentioned in Martin Fowler’s Microservices article:

The second approach in common use is messaging over a lightweight message bus. The infrastructure chosen is typically dumb (dumb as in acts as a message router only) - simple implementations such as RabbitMQ or ZeroMQ don’t do much more than provide a reliable asynchronous fabric - the smarts still live in the end points that are producing and consuming messages; in the services.

When we were building The Grid, we went with an architecture heavily reliant on microservices communicating using message queues. This gave us several useful capabilities:

Asynchronous processing
If you have heavy back-end operations or peak load, a microservice might be swamped with work to be done. If your web server only needs to send work to a queue and not wait for result immediately, you have a lot more freedom on how to organize the work. Furthermore, you can split your service along different scalability characteristics — some systems may be network-bound, others CPU-bound etc
Autoscaling
Since the work to be performed by your microservices is kept in message queue, you can use the combination of the queue length and typical processing times to automatically determine how many instances of each service you need. Ideally you can use this to ensure that your processing times stay consistent regardless of how many users are on your system at a given time
Dead lettering
It is possible to configure RabbitMQ to place any failed operations into a dead letter queue. This gives you a full record of any failing operations, making it possible to inspect them manually, replay later, or produce new tests based on real-world failures
Rate limiting
Sometimes you’re dealing with external HTTP APIs that are rate limited. Once a microservice starts hitting rate limits, you can keep new requests in a queue until the limit lifts again
In-flight updates
A message queue can be configured so that non-acknowledged messages go back into the queue. This means that if one of your services crashes, or you deploy a new version of it, no work gets lost. When the service is back up again, it can pick up right where the previous instance left off

Better tooling

HTTP is something all backend developers are familiar with. With message queues you have to deal with some new concepts, and hence new tools are also needed.

MsgFlo

Client libraries for talking with common message queues exist for pretty much every language. However, this still means that you’ll have to handle things like message pre-fetch limits, acknowledging handled messages, and setting up queues yourself. And of course keeping track of what service talks to what can become a burden.

We developed the MsgFlo tool to solve these problems. MsgFlo provides open source client libraries for bunch of different programming languages, providing a simple model to handle message-related workflow.

To give you an overview of the dataflow between services, MsgFlo also provides a way to define the whole system as a flow-based programming graph. This means you’ll see the whole system visually, and can change connections between services directly from graphical tools like Flowhub.

If you’re using Heroku, MsgFlo can also generate the Procfile for you, meaning that the services you’ve defined in your graph get automatically registered with the platform.

Guv

As mentioned above, queue-based microservices make autoscaling quite easy. If you’re on Heroku, then our Guv tool can be used to automate scaling operations for all of your background dynos.

I wrote more about GuvScale in a recent blog post.

Introducing Flowhub UG - the Flow-Based Programming company

henri.bergius@iki.fi (Henri Bergius) — Wed, 22 Mar 2017 00:00:00 +0000

Flowhub — the product made possible by our successful NoFlo Kickstarter — has now its own company dedicated to supporting and improving the visual programming environment.

Last fall we bought the Flowhub and other flow-based programming assets from The Grid, and now after some paperwork we’re up and running as Flowhub UG, a company registered in Berlin, Germany.

We’re also now selling the new Pro and Supporter plans, and can also provide a dedicated on-premise version of Flowhub. Please check out our Plans for more information:

Read more in the latest Kickstarter update.

GuvScale - Autoscaling for Heroku worker dynos

henri.bergius@iki.fi (Henri Bergius) — Mon, 20 Mar 2017 00:00:00 +0000

I’m happy to announce that GuvScale — our service for autoscaling Heroku background worker dynos — is now available in a public beta.

If you’re using RabbitMQ for distributing work to background dynos hosted by Heroku, GuvScale can monitor the queues for you and scale the number of workers up and down automatically.

This gives two big benefits:

Consistent processing times by scaling dynos up to meet peak load
Cost savings by reducing idle dynos. Don’t pay for computing capacity you don’t need

We originally built the guv tool back in 2015, and it has been used since by The Grid to manage their computationally intensive AI tasks. At The Grid we’ve had GuvScale make hundreds of thousands of scaling operations per month, running background dynos at more than 90% efficiency.

This has meant being able to produce sites at a consistent, predictable throughput regardless of how many users publish things at the same time, as well as not having to pay for idle cloud machines.

Getting started

There are many frameworks for splitting computational loads out of your main web process and into background dynos. If you’re working with Ruby, you’ve probably heard of Sidekiq. For Python there is Celery. And there is our MsgFlo flow-based programming framework for a more polyglot approach.

If you’re already using one of these with RabbitMQ on Heroku (for example via the CloudAMQP service), you’re ready to start autoscaling with GuvScale!

First enable the GuvScale add-on:

$ heroku addons:create guvscale

Next you’ll need to create an OAuth token so that GuvScale can perform scaling operations for your app. Do this with the Heroku CLI tool. First install the authorization add-on:

$ heroku plugins:install heroku-cli-oauth

Then create a token:

$ heroku authorizations:create --description "GuvScale"

Copy the authentication token, and paste it to the GuvScale dashboard that you can access from your app’s Resources tab in Heroku Dashboard.

Once GuvScale has an OAuth token, it is ready to do scaling for you. You’ll have to provide some scaling rules, either in the GuvScale dashboard, or via the heroku-guvscale CLI tool.

Here is an example for scaling a process that sends emails on the background:

emailsender:          # Dyno role to scale
  queue: "send-email" # The AMQP queue name
  deadline: 180       # 3 minutes, in seconds
  minimum: 0          # Minimum number of workers
  maximum: 5          # Maximum number of workers
  concurrency: 10     # How many messages are processed concurrently
  processing: 0.300   # 300 ms, in seconds

Once GuvScale has been configured you can monitor its behavior in the dashboard.

Read more in the Heroku Dev Center GuvScale tutorial.

GuvScale is free during the public beta. Get started now!

Rescaling 3k images. From 0 servers to 25, back to 0 in <4 mins. 0 humans involved.#devops https://t.co/OSPMZtfrd9 pic.twitter.com/s7Bog4hHLZ
— Jon Nordby (@jononor) June 8, 2016

The Grid: Web Design by Artificial Intelligence

henri.bergius@iki.fi (Henri Bergius) — Wed, 17 Feb 2016 00:00:00 +0000

As mentioned last year, I’m working on a Artificial Intelligence that can do web design. It is called The Grid. Last week I gave a talk at Lift Conference explaining how it all works.

If you can’t see the video embed above, it is also available on the Livestream site and YouTube.

Nemein has a new home

henri.bergius@iki.fi (Henri Bergius) — Mon, 12 Jan 2015 00:00:00 +0000

When I flew to Tenerife to sail across the Atlantic in late November, there was excitement in the air. Nemein — the software company I started in 2001 with Henri Hovi and Johannes Hentunen, and left later to build an AI-driven web publishing tool — was about to be sold.

Today, I’m happy to tell that Nemein has been acquired by Anders Innovations, a fast-growing software company.

I had a videoconference this morning with Nemein’s and Anders Inno’s CEOs Lauri and Tomi, and it seems the team Nemein has indeed found a good home.

Technologically, the companies are a good fit. Both companies have a strong emphasis on building business systems on top of the Django framework. To this mix, Nemein will also bring its long background with Midgard CMS and mobile ecosystems like MeeGo and its successor, Sailfish.

I wish the whole team at Anders Innovation the best, and hope they will be able to continue functioning as a champion of the decoupled content management idea.

Nemein has also been a valuable contributor to the Flowhub ecosystem, which I hope will continue.

For those interested in the background of Nemein, I wrote a longish story of the company’s first ten years back in 2011. I also promise to write about The Grid soon!

Bitcoin as a Medium of Exchange

henri.bergius@iki.fi (Henri Bergius) — Thu, 28 Nov 2013 00:00:00 +0000

Bitcoin — the decentralized digital currency — has been making a lot of headlines lately. Much of this is driven by the current investment boom around it that has raised the exchange rates over the 1000 USD mark. But really, looking at Bitcoin as a medium for currency or asset speculation is a bad idea. Instead, we should see it purely as a medium of exchange.

Not a great holder of value

Much of the press stories about Bitcoin see it as a speculative investment free of currency manipulation by central banks. By its nature, it is a deflationary currency, given that the global supply of Bitcoins is capped. As long as there is interest in Bitcoin, it means the prices are bound to go up. But at the same time, this is a threat to the currency. Deflation disincentivizes people from spending their money, as tomorrow the value is likely to be higher.

This is a big difference to fiat currencies where central banks generally act to ensure that there is a little bit of inflation, giving people incentives to spend, invest, and keep the economy running.

Traditional currencies are given a value by the fact that there is a government requiring taxes to be paid in them. This creates a demand in the currency, as people have to acquire units of that currency somehow, usually by selling goods and services. So, the value of a currency is built on the power of a state to tax its subjects in that currency.

The other traditional holder of value, gold, also differs from Bitcoins in the sense that at least you can make some useful things out of it.

In contrast, the value of Bitcoin without an economy backing it up is exactly zero. Without an active network of miners, and business transactions that create a demand for them, there is not much you could do with a Bitcoin.

Given this setting, Bitcoin as a investment mechanism resembles a ponzi scheme where people make speculative investments in them in hopes of being able to pass them on to the next fool when the prices go up.

This is obviously not sustainable in the long term. But luckily there are things you can do with Bitcoin that still make them interesting if you deal with them as a medium of exchange and not a long-term holder of value.

Great tool for conducting transactions

Now that we’ve established that Bitcoins are not the best thing to put your life savings into, or to stash under your mattress, what is it exactly that makes them interesting?

Mobile money

Bitcoin is a way of making transactions quickly, safely, and without middlemen. A lot of the articles written about it compare it to gold, but in my view a much closer comparison is M-Pesa, the operator-driven mobile payment network that powers over 30% of the Kenyan economy.

M-Pesa on a phone, by Pixel Ballads

When you see people paying with their mobile phones in a African street market, you know they’ve leapfrogged us in technology.

Bitcoin has the exactly same advantages as M-Pesa: you can send it to anywhere with minimal costs and delays, you can keep it on your phone, and anybody can ask for a payment through it. Unlike M-Pesa, Bitcoin is truly decentralized and doesn’t rely on a mobile operator to act as the “central bank”.

Unlike M-Pesa, Bitcoin currently requires an internet-connected smartphone with a wallet application. This limits its usefulness in the world outside of the rich countries (though cheap Android phones are changing the situation). It would be a huge boost for mobile commerce with Bitcoins if there was a service that enabled paying and requesting Bitcoin over SMS.

The one to make Bitcoin work over SMS will be rich

Last summer I was talking with Joerg Patzer, the owner of Room 77, a restaurant in Berlin that has been one of the early adopters of Bitcoin. At the time about 10% of the his sales happened in Bitcoin, and the number has been constantly growing since. He told that he even pays some of his suppliers in Bitcoin, and only converts some of it to euros, solely because you can’t pay taxes in Bitcoin.

Patzer buys the beer for Room 77 from the nearby Rollberg brewery, owned and run by qualified brew and malt meister Wilko Bereit. He pays for the barrels with Bitcoins

Joerg also told me an interesting case where there was a group of tourists having a dinner in his restaurant. A friend of theirs that wasn’t able to make the trip insisted on paying the bill remotely from Israel. This is something that would be hard to do with the traditional credit cards or currencies. Paying in Bitcoin is quite straightforward:

He taps the amount he owes Room 77 into the virtual Bitcoin wallet on his Android phone and, aligning it with a code on the bar’s device, presses a button to process the payment. A theatrical “kerching” sound follows and Gallas is grinning from ear to ear. “It could hardly be easier,” he insisted.

Requesting a payment using Bitcoin Wallet for Android

Global currency for the internet

Map of global Bitcoin nodes

Requesting Bitcoins is as easy as providing a URL. This could be presented as a link on the web, or shared to mobile devices via QR Codes. For example, clicking this link on a device with a Bitcoin wallet would enable you to send me Bitcoins worth around 0.1 EUR (on today’s exchange rates). No need for dealing with payment gateways or complicated protocols.

Ease of paying, no middle men, minimal transaction fees, and no risk of chargebacks make a lot of interesting business scenarios possible online. Consider for example micropayments for online content. This is something that would make online publishing viable without the current ad-driven models, but has been held back by the risks and costs associated with credit card payments. Wider adoption of Bitcoin would suddenly make this a very realistic way of asking for money for the things you do online.

Other clever uses

Since Bitcoins can be exchanged in miniscule amounts, and there is a public record kept on each transaction, they enable all kinds of new use cases.

One such service that I ran into yesterday is Proof of Existence, a tool for storing the fact that you were in possession of a document at a given time, and that it hasn’t been revised since based on microtransactions stored in the Bitcoin block chain. This is a mechanism known as trusted timestamping that could be useful for things we currently utilize notaries for. The Hacker News thread on this listed some interesting use cases, like verifying scientific priority on new inventions, i.e. that you had written a document describing a new invention at a given time even if you publish it only later.

We could also use Bitcoin for solving the spam problem. Emails could be “stamped” with a Bitcoin microtransaction, and email servers could be configured to reject messages that don’t have a valid payment attached to them. This would enable bringing decentralization back to the internet as we could again use distributed systems like email and XMPP without having to resort to the walled gardens like Facebook to keep them spammers away.

Another interesting approach was to use Bitcoin transactions for making bets.

How to get started

A good way to get started with Bitcoin is to read Wired’s Bitcoin survival guide or the materials available on Bitcoins.com. Install a Bitcoin wallet application on your mobile device. Then get some Bitcoin either by buying locally, from an online exchange or by selling goods or services for Bitcoin.

This is all you need to get going. Now you just need to find a way to spend them, for example in online shops, by buying domains, or in shops and restaurants that accept them, like many do in my neighborhood.

Disclaimer: I’m a programmer, not an economist. There are better people to take investment advice from. I do hold a little bit of Bitcoin, giving me some vested interest in the matter. Not the kind of amount that would make it an investment, but just the right amount for being able to buy a few nice dinners, especially at the Berlin prices. Generally, I try to keep the amount I have in BTC low enough to be equivalent of what I might be comfortable with carrying in cash.

Interview with J. Paul Morrison, the father of Flow-Based Programming

henri.bergius@iki.fi (Henri Bergius) — Fri, 06 Sep 2013 00:00:00 +0000

J. Paul Morrison invented Flow-Based Programming while at IBM in 1969.

I ran into the concept in 2011 while trying to figure out a better way to create software. I read his canonical book on the subject, and decided to try and implement it in JavaScript. Thus, NoFlo got started.

It has been an honor to have Paul as a mentor in the process. In late June 2013 we flew to Toronto to meet him. What resulted was quite a thorough code review of NoFlo’s FBP implementation, and a video interview. The interview with Paul is finally online. Enjoy!

If you want to meet Paul in person, the next opportunity will be in the Toronto Flow-Based Programming meetup on September 11th. On the same week we also have my NoFlo talk in Zurich on the 10th, and Forrest’s talk in Berlin on the 14th.

In other news, the NoFlo Kickstarter campaign just hit 96%. Please help us get it funded so we can bring better flow-based tools to designers and programmers everywhere!

Henri Bergius - Business

Publish your data on the BIG IoT marketplace

The BIG IoT marketplace

Flowhub and BIG IoT

Creating a data provider

Building an IoT dashboard with NASA Open MCT

c-beam telemetry server

Getting started

Running with Docker

Configuring your data

Getting data in

Status and how you can help

NoFlo: six years of JavaScript dataflow

Flowhub

Celebrating six years of NoFlo

Ecosystem

JavaScript

Dataflow

Tooling for flow-based programming

NoFlo 0.8

Road to 1.0

Forget about HTTP when building microservices

Just use a message queue

Better tooling

MsgFlo

Guv

Further reading

Introducing Flowhub UG - the Flow-Based Programming company

GuvScale - Autoscaling for Heroku worker dynos

Getting started

The Grid: Web Design by Artificial Intelligence

Nemein has a new home

Bitcoin as a Medium of Exchange

Not a great holder of value

Great tool for conducting transactions

Mobile money

Global currency for the internet

Other clever uses

How to get started

Interview with J. Paul Morrison, the father of Flow-Based Programming