
As a software engineer, I recently had the opportunity to step into the realm of medical conferences. The first-time experience at the European Society of Human Reproduction and Embryology (ESHRE) Congress, where I was honored to be invited as a speaker, is a steep departure from the typical academic or tech industry events that I’m accustomed to.

Although branded European, the event had a global reach with more than 10000 participants coming from all corners of the globe. I had the privilege to contribute my talk about the certification of artificial intelligence to the pre-congress course on Artificial Intelligence in Assisted Reproductive Technology (ART).

The course program offered a balanced blend of technical and domain-specific discussions. As anticipated in an AI-focused event, the technical sessions delved into algorithms and regulatory procedures associated with medical devices and software. However, it was the ART-related talks that truly caught me by surprise. Despite the abundance of medical terminology and copious amounts of data, which presented a challenge to comprehend fully, I was captivated by the profound mastery of the mathematical underpinnings that form the foundation of AI technology.

The speakers, primarily professionals from reproductive clinics, exhibited a remarkable expertise within their domain. However, their fluency in the AI jargon commonly used in the tech industry was limited. Consequently, the latest advancements in generative AI, particularly large language models (LLMs), appeared intimidating to them. The incorporation of AI-related technologies within clinical settings posed a significant challenge, particularly when considering the complex regulatory landscape. Surprisingly, for someone familiar with regulatory intricacies, the field of human reproduction presents even greater complexities in terms of both regulations and ethical considerations. Adding to the complexity, these issues varied substantially across jurisdictions, imposing significant limitations on practitioners and affecting their ability to collaborate on the development of novel technical solutions.

The course program concluded with an engaging panel discussion that fostered active participation from both the presenters and the audience. The conversation revolved around several overarching themes, such as the perceived gap between practitioners and technology within the field of reproductive medicine, and strategies to enhance cooperation. A notable challenge highlighted was the absence of shared reference databases, which hinders dissemination of best practices. Similarly, interoperability issues between tools lead to fragmented workflows. However, the potential solution of leveraging the Fast Healthcare Interoperability Resources (FHIR) standard was proposed as a means to address this challenge. Perhaps the most significant point of contention focused on the ethical considerations surrounding the use of AI in human reproduction. Ultimately, the consensus was reached that it is ethically unjustifiable to not harness the power of AI in this domain, emphasizing the imperative to integrate AI technologies responsibly and ethically.

Thanks [Sara Zdravka Veleva](https://www.linkedin.com/in/sara-zdravka-veleva-7a2b3517) and [José Alarcón Roldán](https://www.linkedin.com/in/alarconroldan) for inviting me to this great event! I surely enjoyed it!

A software engineer goes to ESHRE...


I had the pleasure to discuss with [Oded Assouline](https://www.linkedin.com/in/oded-assouline-29b045135/) on the [QI Podcast](https://www.youtube.com/channel/UCmnn2mgFxT2zCyyejHaLuGQ) about IEC 62304 from an agile software development perspective:

<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/nWXf6a7-Vrg" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>


QI Podcast: Introduction to IEC 62304


What was only a dream last August, has now became a real RegOps Days conference and community. With RegOps, we share an interest in integrating regulation activities into DevOps practices. It all started during a discussion over a pizza with [Tommi Mikkonen](https://www.linkedin.com/in/tommimikkonen). We talked about the state of regulatory work in today's fast pacing DevOps practicing organisations. Our first thought was to cover the topic with a guest lecture at Helsinki University, but we soon realised that that was not a good forum to approach this topic. The exposure to regulatory work is quite limited among students. The idea of having a conference was born! It would provide a venue where researchers and practitioners could meet. There, they can exchange ideas and experiences about their areas of expertise. Things were getting serious. We reached out to our friends at [Osaango](https://www.linkedin.com/company/osaango), and [Marjukka Niinioja](https://www.linkedin.com/in/marjukkaniinioja) jumped in to help.

So here we are: February 13th in Tiedekulma at [RegOps Days Helsinki 2020](https://www.regopsdays.org/). Roughly 50 participants representing more that 20 organisations with an interest in regulated medical device software development. Needless to say, excitement was high. Over the course of the morning we listened to four engaging presentations.

The first talk was held by Mauri Honkanen from Avaa. He explored the thin line that separates wellness and medical applications. Medical regulations cast a much larger shadow as they influence expectations and decision making beyond their intended target. Next, I've talked about the challenges caused by using agile development in regulated environments. A practical way to reduce these challenges is to perform RegOps during pull requests. The timing enables compliance officers to be in sync with the rest of the development team. The coffee break and the cinnamon buns gave the energy boost for the next two talks. Risto Kaikkoinen described Solita's journey into becoming a medical device manufacturer. He gave practical advice on how an experienced software organization handles regulations. The last presentation was by Ilari Richardt from Terveystalo. He described the challenges his organization faces developing in parallel several regulated products.

The conference concluded with a lively panel discussion focused around the following topics:

- The importance of RegOps
- The biggest challenges hindering RegOps adoption
- The relations of medical regulatory practices with other regulated industries
- The need for having a community of practice around RegOps

Besides these topics, we explored the role of academia in fulfilling these needs. Universities need to step up and prepare the students for a new workplace governed by regulations. The discipline required to develop regulated software products is the rule rather than the exception. Understanding that behind regulatory activities are best practices is of upmost importance. The acquired skills are applicable across many application domains, making them more valuable.

The recent evolutions in artificial intelligence and machine learning were also touched. Their use raises interesting questions from a regulatory perspective. Datasets play an important role for the development of new algorithms and models. What is their origin? How do they change over time? The consensus was that new regulatory practices will emerge to cover data lifecycle. Someone even suggested the term DataOps.

While the panelists gave interesting insights into these topics, the real heroes were the participants. They asked questions and engaged into lively conversations. The distance between the stage and the audience disappeared. This created a meetup-like vibe to the whole event.

Last but not least, an event like this does not happen without help from our emerging community. Big thanks to [Citrus](https://www.citrus.fi/) for supporting us at the beginning of this journey. Nice to have them as first RegOps Days event sponsor. [Techie Stories](https://www.techiestories.com/) filmed the talks and the panel discussion. The videos allows us to reach the community members that were not able to join us this time.

Looking forward, the feedback from this event participants looks solid. RegOps discussions will continue in community events like meet-ups. Their scope might cover other regulation intensive industries such as finance or automotive. Keep an eye on the RegOps [website](https://www.regopsdays.org/) for upcoming events and register for our newsletter.


First impressions from RegOps Days 2020 conference, topics discussed and the way forward

First RegOps Days conference!


Thanks to the disturbances in the arctic vortex, yesterday was one of the [coldest day of the winter](http://www.helsinkitimes.fi/finland/finland-news/domestic/15355-finns-told-to-brace-for-cold-weather.html) so far... What better day than to head to Helsinki to [Predict What’s Next](https://cloudplatformonline.com/2018-OnBoard-Helsinki.html) with Google.

The location of the training was [Helsinki Congress Paasitorni](https://goo.gl/maps/CaGXa4p76q42), a venue that can accomodate several hundreds of participants and is easily accessible form the main railway station. The snacks and lunch kept us inside, while the two dozens or so organizing staff were present everywhere and were assisting the participants at all times. All this attention to details just shows that the battles in the clouds are hard won on the ground by winning the hearts of the developers (and the pockets of their organizations).

The content of the training was build around <q>Big Data and Machine Learning</q> theme, although in practice it covered a wide range of items starting with an overview of the Google Cloud Platform (GCP) infrastructure and how to create compute instances there. This is quite understandable considering such a large audience that might not be familiar with the platform and its tools.

The training continued with the tools available to import and persist data, with an emphasis of choosing the storage service suitable for your data volume and usage pattern. While the basics were in place, the data being stored in [Cloud SQL](https://cloud.google.com/sql/), we moved on to transforming the data using the Hadoop services provided as part of [Cloud Dataproc](https://cloud.google.com/dataproc/). A nice surprise here were the interactive experiments performed using [Datalab](https://cloud.google.com/datalab/) notebooks, which should be very familiar to [Jupyter](http://jupyter.org) users.

The afternoon part of the training was dedicated to machine learning. We were using [BigQuery](https://cloud.google.com/bigquery/) to create a dataset for a taxi demand forecast system that used the dataset to train a model with [TensorFlow](https://www.tensorflow.org). The later part of the training was an overview of the pre-trained models that are offered as [Machine Learning APIs](https://cloud.google.com/products/machine-learning/). The very end (and very brief) was allocated for the overview of data processing architecture, including managed message queues [Cloud Pub/Sub](https://cloud.google.com/pubsub/) and stream and batch processing using [Cloud Dataflow](https://cloud.google.com/dataflow/).

During the event, the trainer even mentioned that they believe that they have the greatest machine learning _infrastructure_ in the world. Point taken, considering dedicated machine learning hardware such as [Cloud TPU](https://cloud.google.com/tpu/), although AWS or Azure cannot be far behind...

Although the content covered was quite large for one day, the trainer did a good job at emphasizing the key concepts behind each service and how to use them. This made it easy to map them to the equivalent technologies and services popular outside GCP. Secondly, as the training followed two [Qwiklabs](https://qwiklabs.com) labs, it would be pretty straight forward to go deeper and get your hands dirty with the expanded seven labs that have been delivered after the training. Again, hats off to Google for organizing this event, it was a day well spent.

I'll conclude the post with a personal perspective... as someone that [build data pipelines for analysing bio-medical signals](https://www.nokia.com/en_int/news/releases/2016/06/21/nokia-technologies-to-collaborate-with-helsinki-university-hospital-and-university-of-helsinki-to-create-innovative-solutions-for-outpatient-care), I can say that with services like these **everyone can be a data engineer** today, the open question is how long till _everyone can be a data scientist_, but there is promise there [too](https://cloud.google.com/automl/)...


Being a data engineer in 2018


During the past week I stumbled upon a blog post by [Ryan Paul](http://seg.phault.net/blog/2017/10/typescript-without-transpiling/) on getting the advantages of [TypeScript](https://www.typescriptlang.org) without transpiling. The _magic_ is made possible by TypeScript 2.3, which introduced support for [standard JavaScript](https://github.com/Microsoft/TypeScript/wiki/Type-Checking-JavaScript-Files). The type information contained in [JSDoc-like](https://github.com/Microsoft/TypeScript/wiki/JSDoc-support-in-JavaScript) annotations is analysed and used in a similar fashion as TypeScript's own type system.

Too good to be true? You bet!

## So, time to conduct my own experiment...

I'm maintaining [fsm-as-promised](https://github.com/vstirbu/fsm-as-promised), a minimalistic finite state machine library using ES6 promises. The library has a small API surface, making it ideal for conducting this experiment.

```javascript
const StateMachine = require('fsm-as-promised');

const fsm = StateMachine({
  // configuration object
});
```

As seen in the above example, creating a new state machine object is as simple as invoking the `StateMachine` function. The not so nice part is the configuration object, which actually describes the state machine using a DSL-like object literal.

```javascript
const configuration = {
  initial: 'initial',
  final: 'final',
  events: [
    {
      name: 'go',
      from: 'initial',
      to: 'final',
    },
  ],
  callbacks: {
    ongo: function () {},
  },
};
```

All properties of the configuration object are straightforward to document using JSDoc. One notable exception is `callbacks`, which is an object literal for which all properties are of type `Function`. What makes it different is that its properties are not known in advance.

A bit of try and error cycles, going through multiple stackoverflow questions, ended up with this result, which tells that the object is a map where the key is a `String` and the value is `Function`:

```javascript
/**
 * @prop {Object<String, Function>} callbacks - Callbacks
 */
```

Now that everything is [set](https://github.com/vstirbu/fsm-as-promised/blob/9197ee7eb2ff695d6014719ca21dfdfaed40149f/lib/index.js#L452-L470), lets see the results...

## IntelliSense in action

[Visual Studio Code](https://code.visualstudio.com) or VSCode is a code editor with the super powers that we need:

> Go beyond syntax highlighting and autocomplete with IntelliSense, which provides smart completions based on variable types, function definitions, and imported modules.

VSCode supports several ways to [enable](https://github.com/Microsoft/vscode/issues/25322) TypeScript checking for JavaScript files. To keep things simple, I've added `//@ts-check` to the top of the file where the state machine is defined.

Now VSCode is ready to unleash all the power of IntelliSense, among which are...

![autocompletion](autocompletion.gif)

![or type mismatch information when the property should be a Function instead of Number](type-information.gif)

The IntelliSense features are available despite both the source file and the library being plain JavaScript. Everything is enabled by VSCode which runs Typescript behind the scene.

## What about tests

Now that the library's JSDoc type declarations are accessible to IntelliSense, the next question is: _How to be sure that they do not drift from the actual implementation?_

The basic approach is to have a set of example files, using the library, with good and wrong types and validate them using the TypeScript compiler. At the time of writing, compiler cli does not provide an option to [validate typings](https://github.com/Microsoft/TypeScript/issues/7661) in JavaScript files. Luckily, the compiler can be used programmatically, and there is good [API documentation](https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API).

The primary concern, as part of an experiment, is to determine the feasibility of testing the typings rather than completeness of the test suite. Therefore, I've proceeded by testing the happy path, having a state machine definition that covers all combinations of using the types correctly. In this instance, the file is parsed by the compiler and no errors or warnings should be encountered.

The compiler must be instructed what the file to be analysed is JavaScript, written according to EcmaScript 5 standard, is using CommonJS module style, and the runtime environment is node. The result is the following:

```javascript
describe('Intellisense', function () {
  it('should not give errors', function () {
    this.timeout(5000);

    const options = {
      allowJs: true,
      noEmit: true,
      target: ts.ScriptTarget.ES5,
      module: ts.ModuleKind.CommonJS,
      moduleResolution: ts.ModuleResolutionKind.NodeJs,
    };
    const program = ts.createProgram(['/path/to/your/fsm-file.js'], options);
    const results = program.emit();

    const diagnostics = ts
      .getPreEmitDiagnostics(program)
      .concat(results.diagnostics);

    expect(diagnostics).to.have.length(0);
  });
});
```

This can be easily expanded to test for errors if wrong types are used. You just need to feed JavaScript files with errors and expect the compiler to find them.

## Conclusions

I've started this experiment with the simple goal of checking if the IntelliSense power can be derived from plain JavaScript files with JSDoc comments. The experiment's result prove that not only it is possible but you can easily build the necessary tooling to include the type checking in the test suite. As a library maintainer, this is very important as I can provide IntelliSense support, a feature that increases the developer experience of the library's users. More, IntelliSense being a feature of the code editor, the whole development process is light weight as I don't have to rely on TypeScript as development dependency.


When JSDoc gives you IntelliSense powers


Seems like yesterday, when I heard from [Miro Nieminen](https://twitter.com/mironieminen) about a new [conference](https://nordicapis.com/events/2016-platform-summit/) about APIs in Stockholm. Following the tip, I attended the conference and haven't been disappointed. One year later, I've decided to try the waters of speaking at a tech conference. So, I've submitted the talk proposal on the last day. Soon after, I got the notification that my proposal has been accepted.

Now, back at home I decided to share my thoughts about this year [edition](https://nordicapis.com/events/the-2017-api-platform-summit/)... The main topics covered by the talks have been `graphql`, `serverless`, and `tooling`, which includes both processes and products like API gateways. No surprises there as this distribution follows the general trend in the industry during the past year.

Although there have been plenty of interesting talks, I'll focus on the few that caught my attention.

[Ronnie Mitra](https://nordicapis.com/sessions/programming-people-platform-beyond-conways-law/) talked about the decisions that have to be made when moving to a microservices architecture. As time and talent are limited you need to doze the energy in the right place in the organization so accelerate the move towards Microservices Harmony.

[Travis Spencer](https://nordicapis.com/speakers/travis-spencer/) provided a comprehensive overview of the API security _soup_ which included around 50 specifications, or shall I call them ingredients... [Dynamic Client Registration](https://tools.ietf.org/html/rfc7591) and [Proof Key for Code Exchange (PKCE)](https://tools.ietf.org/html/rfc7636) improve the OAuth security for public clients as they provide Proof of Possession as well as making any instance of an application unique. [Health Relationship Trust (HEART)](http://openid.net/wg/heart/) specifications are definitely something to keep an eye on if you are working in health domain especially using [FHIR](https://www.hl7.org/fhir/).

[Gunnar Berger](https://nordicapis.com/sessions/close-gap-future-promise-open-banking/) mentioned in his talk on Open Banking that publishing APIs creates _expectations_ that are not only of technical kind. They were overwhelmed by the reaction of the parties enrolling to try the APIs. This changed their perception, as they now see the APIs as means of co-creation, which brings the traditional banks in a win-win position with fintech.

[Jason Harmon](https://nordicapis.com/sessions/api-needs-single-source-truth/) provided a deep dive into how processes build around a single source of API truth improve the developer experience. Key messages here are to create the API specification first and keep one specification for each microservice in a central repository. Merge the API into a single spec using a [merge tool](https://github.com/Typeform/openapi-micro-merge) that handles the visibility and the status of the API using extensions such as `X-Visibility` and `X-Status`. Another important note is that developers are your first _community_ as they are not aware of the API internals.

[Adrian Hornsby](https://nordicapis.com/sessions/journey-towards-scaling-application-10-million-users/) talked about how to scale fast to a large user base using AWS offerings. He emphasized the importance of having the documentation clear before even starting the first line of code:

> Documentation is for us to know what we do.

[Adam DuVander](https://nordicapis.com/sessions/full-spectrum-apis-lessons-scaling-750-apis-production/) talked about te concerns that have to be addressed to cater for great user experience but also are profitable for the provider in what he coined full spectrum APIs. What an end for this year conference.

As for myself, I've [talked](https://www.slideshare.net/VladStirbu/developing-medical-grade-iot-systems-with-microservices) about the regulations and standards that make development of medical services special. I have also described how we handled these challenges. Drop me a line if you want to hear more.

Needless to say that all talks are available on the conference YouTube [channel](https://www.youtube.com/playlist?list=PLd2MPdlXKO10RVLkvlnNz_mmqUY9QN4dj).


Fresh impressions from Nordic APIs Platform Summit


## The background

Back in 2012, I have started working on a scoring system for Taekwon-Do competitions. A key part of the project was to enable the judges to score without being distracted from watching what is really important: _the action in the ring_...

After some consideration, which dived also into exploring custom hardware, we decided to use [JDX S5110](https://en.wikipedia.org/wiki/JXD_S5110) Android gamepads for this purpose. Thanks to [Apache Cordova](http://cordova.apache.org), I can easily create the user interface using familiar web technologies, and also have the option to extend the functionality of the application with native features.

## The quick and dirty GamepadButtons plugin

These were the Ice Cream Sandwich days, when the WebView lacked support for [Gamepad API](http://www.w3.org/TR/gamepad/). I had to roll my sleeves and start looking for a solution. A quick search on Google revealed that while there were a number of polyfills for desktop browsers, none was available for mobile browsers, especially for WebViews...

Thanks to good documentation I was able to fix the issue by capturing the gamepad button press or release events, and expose them inside the JavaScript runtime using the [GamepadButtons](https://github.com/vstirbu/GamepadButtons) plugin. The key was to set up a key listener on the WebView, and initialize it on application startup:

```java
public class Gamepad extends CordovaPlugin {

  @Override
  public void initialize(CordovaInterface cordova, CordovaWebView webView) {

    this.webView.setOnKeyListener(new OnKeyListener() {

      @Override
      public boolean onKey(View v, int keyCode, KeyEvent event) {
        //send the event to JavaScript
      }

    });
  }
}
```

As I needed the buttons for recoding the scores I chose to implement a subset of the Gamepad API proposed by Mozilla, which had extra events such as `gamepadbutton`, leaving out the actual API needed for playing games.

This being done I could focus on more important issues...

## A more mature Cordova platform but still...

Fast forward to 2015 and the original gamepad was replaced with a new version: [JDX S5110B](http://www.jxd.hk/game-console/s5110b/). Despite what the name implies this is a completely new device and... surprise, surprise... the plugin does not deliver the gamepad events anymore.

Cordova ecosystem made huge progress starting with formalizing the plugin API, moving the plugin registry to `npm`, but also supporting additional web views like [crosswalk](https://crosswalk-project.org), besides the one bundled with Android.

These changes were not good news for my neglected plugin. As a result of supporting multiple web views, the API that allowed my keys to be delivered to the web engine was [removed](https://issues.apache.org/jira/browse/CB-9005). Luckily, Android documentation on handling [gamepads](http://developer.android.com/training/game-controllers/controller-input.html) has clear enough instructions.

So, I'm down to two options. The first one, which is the more frendlier for a Cordova plugin, is to implement the event handlers in the `View`, but the gamepad events were handled first by the Chromium based WebView and I'm left with nothing...

The second option is to handle the events in the `Activity`. The approach involves extending `CordovaActivity` with a handler for intercepting all key events. If the key is coming from a keypad or a joystick they are passed to the plugin, otherwise they are processed normally:

```java
public class CordovaGamepadActivity extends CordovaActivity {

  @Override
  public boolean dispatchKeyEvent(KeyEvent event) {
    if ((event.getSource() & InputDevice.SOURCE_GAMEPAD) == InputDevice.SOURCE_GAMEPAD
      || ((event.getSource() & InputDevice.SOURCE_JOYSTICK) == InputDevice.SOURCE_JOYSTICK)) {

      this.appView.getPluginManager().postMessage("gamepad-plugin", event);
      return true;
    } else {
      return super.dispatchKeyEvent(event);
    }
  }
}
```

## The missing parts

Although handling the key events works as expected, the overall experience is not as nice as it should be.

First, the approach of extending the CordovaActivity in the main application file is not liked by [`cordova-cli`](https://github.com/apache/cordova-cli) which expects the `MainActivity` class to extend **[only](https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/metadata/android_parser.js#L267)** `CordovaActivity`. This prevents building the application using command line:

```bash
$ cordova build android
Error: No Java files found which extend CordovaActivity.
```

Secondly, the Gamepad API implementation is so limited that maybe is better to change the plugin name, but this is something that can be fixed...

Thanks for reading so far, and as always... [pull requests](<(https://github.com/vstirbu/GamepadButtons)>) are welcome!!!


Bumpy ride with Cordova and Android gamepads

## Blueprint

Ideally the camera module should be exposed as one web resource that allows clients to retrieve images using a `GET`request:

```http
GET /image HTTP/1.1
Accept: image/\*

```

The obvious response, if everything goes fine, is the captured image itself:

```http
HTTP/1.1 200 OK
Content-Type: image/jpeg


```

However, the camera module being hosted by an embedded device we need to take into account the situation when the hardware is not yet initialized:

```http
HTTP/1.1 503 Service Unavailable

```

The other situation when the request cannot be completed successfully is when the camera sensor is busy due to a request originated from another client. This can be conveyed to the client by giving a hint on when it can try again. Here the value can be the observed time that was needed to provide the image, on average 10 seconds:

```http
HTTP/1.1 503 Service Unavailable
Retry-After: 10
```

The API can be bit smarter and queue the requests, but on Tessel the WiFi TI3300 chipset cannot handle more that 4 simultaneous open sockets and it is safer to just inform clients to try again rather than run into the situation where the board hangs.

## Implementation

[Regio](https://github.com/vstirbu/regio) is a [express](http://expressjs.com/)-like web framework developed specifically for Tessel. The API described in the blueprint will be implemented as a `router` so that it can be mounted easily into any Regio application later on.

```javascript
module.exports = middleware;

var states = {
  STANDBY: 0,
  BUSY: 1
};

function middleware(options) {
  var regio = require('regio'),
      tessel = require('tessel'),
      camera = require('camera-vc0706').use(tessel.port[options.port]),
      app = regio.router(),
      hwReady = false,
      current;

  camera.on('ready', function() {
    // sets the hardware ready state and sensor in stand-by when
    // camera module is initialized
    hwReady = true;
    current = states.STANDBY;
  });

  app.get('/', handler);

  ...

  return app;
}
```

The `handler` implements the three cases described in the blueprint: the image retrieval from the sensor, the sensor busy, and the case when the hardware module is not initialized.

```javascript
function handler(req, res) {
  if (hwReady) {
    if (current === states.STANDBY) {
      current = states.BUSY;
      camera.takePicture(function (err, image) {
        res.set("Content-Type", "image/jpeg");
        res.set("Content-Length", image.length);
        res.status(200).end(image);
        current = states.STANDBY;
      });
    } else {
      res.set("Retry-After", 100);
      res.status(503).end();
    }
  } else {
    res.status(503).end();
  }
}
```

## Using the middleware

All the functionality to interact with the camera is encapsulated by the middleware module, and it can be easily integrated into an existing application. You just need to indicate on which port the camera module is connected... Lets say is port `A` in this case:

```javascript
var regio = require("regio"),
  camera = require("regio-camera"),
  app = regio();

app.use(
  "/camera",
  camera({
    port: "A",
  })
);

var server = app.listen(8080, function () {
  console.log("server listening on", server.address().port);
});
```

The software is available on [github](https://github.com/vstirbu/regio-camera).

Implementing a REST API for Tessel's camera module using Regio


[Gulp.js](http://gulpjs.com/) is an awesome build system that helps with automating common [tasks](https://github.com/gulpjs/gulp/blob/master/docs/API.md) during development. Despite the benefits, there are times when the standard way of running the tasks, via the [command line interface](https://github.com/gulpjs/gulp/blob/master/docs/CLI.md), is not enough and you would want to embed gulp in another application and run the tasks programmatically... So, this raises the question _where is the Gulp API?_

Lets consider that we have the following gulp setup:

```javascript
var gulp = require("gulp");

gulp.task("dependency", function () {
  // do something before trigger
});

gulp.task("trigger", ["dependency"], function () {
  // do something
});
```

The most interesting features when building a front end, which uses gulp programmatically, is to be aware of the task execution state. A closer look at the [source](https://github.com/gulpjs/gulp/blob/master/index.js#L12) reveals that under the hood a gulp object is just an [orchestrator](https://github.com/robrich/orchestrator), and all the orchestrator's goodies are directly available to gulp as well. Therefore, gulp emits events when starting a task sequence, and on the beginning and end of each task in the respective sequence:

```javascript
gulp.on("start", function (e) {
  // task sequence started
  console.log(e);
});

gulp.on("task_start", function (e) {
  // task started
  console.log(e);
});

gulp.on("task_stop", function (e) {
  // task ended
  console.log(e);
});
```

Now with the events registered we can run the `trigger` task as follows:

```javascript
gulp.start("trigger");
```

The result contains the sequence of tasks as well as the progress information including the time required to run each task:

```bash
{ message: 'seq: dependency,trigger' }
{ task: 'dependency', message: 'dependency started' }
{ task: 'dependency',
message: 'dependency sync',
duration: 0.000072076,
hrDuration: [ 0, 72076 ] }
{ task: 'trigger', message: 'trigger started' }
{ task: 'trigger',
message: 'trigger sync',
duration: 0.000020074,
hrDuration: [ 0, 20074 ] }
```

So, the answer to _where is the Gulp API?_ is... **under the hood, in the [orchestrator](https://github.com/robrich/orchestrator)**.
