Working in The Best Place to Work!

This is a non-technical post regarding being a member of a great community - Demant Technology Centre, the company I work in, has been recently awarded the 1st place in a Great Place to Work competition. If you're interested in what is like to work with us, read the whole post and get the picture :)

Our culture

We're R&D. That means, we're researching the best solutions and really care when implementing them. There's no place for imperfection and half-measures. This is a big advantage of DTC over other companies - you always have time to prepare a few concepts to present and discuss them. You can use whatever tools you like - what matters is the result.

What is more, we really like to empower people working here. In fact DTC is the first company, where I really feel that everyone trusts, that I really know what I'm doing and respects my choices. This is really inspiring and helps in my daily work.

Our workplace

We have a completely open work space - you'll see no closed boxes or separated teams. Everyone works really hard to make sure that other people feels comfortable. Additionally we have different "quiet zones", where you can go anytime and just relax(or take your laptop and focus even more on your tasks). 

The best thing is that though we're doing some really serious projects(medical devices are not something you can trifle with), we still are able to introduce a fun factor to our daily work - e.g. each team had a possibility to invent a name for itself and project a logo. Now in each team zone we have big flags representing a team working there.

Our people

In DTC you will find no random people, each one is the expert in his or her domain. Developers, HRs, QAs, BAs and other positions are occupied by people, who enjoy their work and make the whole site unique. 

You like board games? We meet each week in the evening to play. You like sport? For sure you'll find someone who would like to go and play with you. Would you like to find someone to talk about chemistry? Come to us!

The last but not least - we're recruiting! Waste no more time - just send a CV and start your journey in the best place to work in Poland :)

Useful links:

Azure Functions and Serverless - configuration and bindings

Azure Functions support in Serverless is still a fresh thing, yet it gives us plenty of different configuration options and bindings with many Azure components. In this post we'll quickly go through configuration file and compare Serverless implementation of functions with an original solution using Azure Portal or Visual Studio.

Configuration

In Serverless the file responsible for configuring a function app is named serverless.yml. If you go to the one attached to the boilerplate code, which you can using following command:

/
serverless install --url https://github.com/azure/boilerplate-azurefunctions

You'll see following structure:

/
service: azure-functions-app1234

provider:
  name: azure
  location: West US
  #armTemplate:
     #file: YourARMTemplate.json
     #parameters:
      #VariableNameToUserInArmTemplate: Value

plugins:
  - serverless-azure-functions

package:
  exclude:
    - node_modules/**
    - .gitignore
    - package.json
    - .git/**

functions:
  httpjs: 
     handler: handler.hello
     events: 
       - http: true
         x-azure-settings:
           authLevel : anonymous
           
  queuejs: 
     handler: handler.helloQueue
     events: 
       - queue: SampleQueue
         x-azure-settings:
           name: queueItem
           connection : AzureWebJobsStorage
       - blob:
         x-azure-settings:
           name: blobOut
           direction: out
           connection : AzureWebJobsStorage

As you can still you can store whole configuration and functions references in the only one file. This greatly improves manageability and helps in keeping a solution clean. Let's dive a bit deeper into it.

Bindings

There're planty of different bindings to choose from when working both with Azure Functions and Serverless. Currently you can use HTTP, Timer, Queue, Service Bus, Event Hub or Blob Storage. What is more, Serverless allows to use additional bindings like DocumentDB, Notification Hubs or Mobile Apps. In fact, because the implementation of bindings is something that you don't have to think about, whole solution is pretty flexible and straightforward. Let's compare serverless.yml with a basic C# example:

/
functions:
  example:
    handler: handler.hello
    events:
      - http: true
        x-azure-settings:
            name: req #<string>, default - "req", specifies which name it's available on `context.bindings` 
            methods: #<array> [GET, POST, PUT, DELETE], default - all
                - GET
            route: example/hello #<string>, default - <function name>
            authLevel: anonymous #<enum - anonymous|function (default)|admin>
/
{
    "disabled": false,
    "bindings": [
        {
            "name": "req",
            "type": "httpTrigger",
            "direction": "in",
            "authLevel": "function",
            "methods": [
                "post"
            ],
            "route": "example/hello"
        },
        {
            "name": "res",
            "type": "http",
            "direction": "out"
        }
    ]
}

As you can see, both configurations are quite similar. The main difference is the whole structure of a solution - when it comes to working with Serverless, you have a single file where it stores all the data.

Remember that if you'd like to use multiple bindings, each one will be available from the context.bindings array with a corresponding name. Consider this example:

/
/
functions:
  example:
    handler: handler.hello
    events:
      - http: true
        x-azure-settings:
            name: req #<string>, default - "req", specifies which name it's available on `context.bindings` 
            methods: #<array> [GET, POST, PUT, DELETE], default - all
                - GET
            route: example/hello #<string>, default - <function name>
            authLevel: anonymous #<enum - anonymous|function (default)|admin>
      - eventHub:
        x-azure-settings:
            name: item #<string>, default - "myEventHubMessage", specifies which name it's available on `context.bindings` 
            path: hello #<string>, specifies the Name of the Event Hub
            consumerGroup: $Default #<string>, default - "$Default", specifies the consumerGroup to listen with
            connection: EventHubsConnection #<string>, App Setting/environment variable which contains Event Hubs Namespace Connection String

In such case you'll have both context.bindings.req and context.bindings.item properties available and usable.

Examples for Serverless were taken from the official documentation.