Fitbit Charge HR – a little review

On my birthday I got a Fitbit Charge HR. Here follows a little writeup of what I think of it.Picture of Fitbit Charge HR

I have previously tested a few quantified self devices: Fitbit Flex, Lumo Lift and Withings Body Scale and Polar S700.

The reason for me wanting a Fitbit Charge HR was that I continuously want my hart rate measured. No matter how much I’ve tried in the past I never seem to be able to remember to measure my pulse in the morning to get my resting pulse. For that it works great. I spotted my upcoming cold two days before it hit which led to me quitting cardio training and hopefully gives me a faster way back.

So here is a short review:

Pros

Wristband

The wristband has a real buckle so it doesn’t fall off accidentally , which my Fitbit Flex did.

Hart rate tracking

It measure hart rate all the time which is a killer feature for me.

Effortless sleep tracking

The Fitbit Flex you had to tap on a certain way when you where going to sleep and waking up. That did not work at all for me. The Charge HR figures it out atomically which is awesome.

Cons

Not waterproof

This is the downfall of the Fitbit Charge HR i my opinion. I know there is just a mattor of time before I accidentally will jump in a pool or shower with it still on my wrist.

Not a watch replacement

It shows time alright but you have to tap it or press the button which results in that it takes two hands to check what time it is. Not flying for me, being a watch guy.

Summary

It does things pretty good but not being waterproof and no gyro so it does not light up the display when in “watching position” makes me say it’s a fun gadget with good tracking but not worth spending $120 (or in Sweden 1499 SEK) on.

Re-installing a Mac and the Peril of the AppStore (for developers)

So my last Mac was my first Mac since the Macintosh LC II (yep that’s how old I am). So I’ve spent most of my time since then in windows land.

Started using a mac (again…) and found the App Store to be a good thing. I use it om my phone and iPads and thought it was the thing… Until now.

A couple of weeks ago I got may bag stolen with laptop and all in it. So when I got my new MacBook Pro I figured I repave it the developer way: Automate as much as possible!

So now being a little more Mac-savvy I compiled a homebrew script and a Caskroom script (coming blog post). And I went off to the races.

Thing is every app/program I installed that I bought on the App Store I have had to re-install manually using the app store to get my license. (Examples are: Acorn, Mindnode Pro, Moom, Witch and a bunch more)

Not a happy automator :(. So if you’re into automate stuff bye apps directly from the vendors homepage when applicable is my humble analysis.

Mac OS X – Pipe contents into the clipboard

Windows

On windows I used to the time when I wanted some output (from a file or command) in the clipboard.

> tracert www.dn.se | clip

or

> type data.txt | clip

And then I went of and pasted it somewhere.

Mac

Haven’t been using it on mac but today I needed it. So after googling around I found pbcopy.

> cat redis-trottle.js | pbcopy

And Bob’s your uncle!

Sticky Porperties on Azure

A while ago I wrote about Deployment Slots – A short intro on Azure. In that post I complained about that there was no way to keep some setting(s) from follow along with the deployment slot in the swap face.

Turns out I was wrong or Microsoft added it after I wrote about it. Now (and maybe then) there is a thing called sticky propterties or sticky settings.

What are Sticky Properties

Sticky Properties are properties/app settings that stick with their slot and does not follow it in the swap. Usually if properties are set on the “stage” slot when you swap the swap slot to “production” the properties/app settings follows along, so that if you add/change some new config it will be deployed with the swap.

However that might not be what you want. For example we use http://raygun.io for exception monitoring and then it’s nice to know which slot that generated the exception.

raygunClient.send(err, {SLOT: process.env.SLOT});

We have used a pattern of app settings named SLOT that has the value of “SLOT1” and “SLOT2”. When we get an exception we first have to look up which value is in production vs. stage. Not an ultimate solution but it works. With sticky properties we can get around it and see directly in the exception details where the exception origins from.

Good stuff! How do I use em?

Here is where it gets a little tricky up until a few days ago (in the time of writing this) you could only get to them using the Azure PowerShell commandlets. I have not seen anything in the Azure Cross Platform (azure-cli) tools yet but I’m sure it’s coming. Recently Microsoft announced that you can manage them through the Azure Preview Portal portal.azure.com, however not in the Azure Management Portal manage.windowsazure.com.

Azure Preview Portal

Pretty straight forward. Browse up your website, hit All Settings ->:

Then hit Application settings and you’ll see the “Slot setting” checkbox beside every application setting.

PowerShell

First off, you need to have the Azure PowerShell installed on a windows box.

In PowerShell you create application settings for a website using the Set-AzureWebSite command and the -AppSettings parameter.

Set-AzureWebsite -Name "api-web" -AppSettings @{"setting-x" = "value-x"; "setting-y" = "value-y"}

Then we can set it as “sticky” using Set-AzureWebSite again but with the -SlotStickyAppSettingNames parameter.

Set-AzureWebsite -Name "api-web" -SlotStickyAppSettingNames @("setting-y")

And if we want we can do it in one call.

Set-AzureWebsite -Name "api-web" -AppSettings @{"setting-x" = "value-x"; "setting-y" = "value-y"} -SlotStickyAppSettingNames @("setting-y")

And the effect looks like this:

commands in action

Hubot, Slack and Azure deployments – Part 2 – Getting TeamCity to Build

In the first post, Hubot, Slack and Azure deployments – Part 1, we looked at how to get Hubot up and running on Heroku and jacked into Slack chat.

In this next post we will look at how to get Hubot to fire off TeamCity builds from our commands in the chat. So it builds on the first or at least that we have a Hubut up and running.

The scripts

To get Hubot to perform stuff it uses scripts called drumroll scripts. There is a scripts folder in your project where you can put your own scripts. There is also a crapload of community scripts that we got npm installed when we ran the yeoman generator in part one (yo hubot). If you haven’t installed them you can do a npm install --save hubot-scripts. These scripts has to be in CoffeeScript or JavaScript.

In our environment at work use TeamCity from JetBrains as Build/CI Server and TeamCity deploys the code to azure (via git push) for us, so I don’t have to mock around the azure api’s just yet.

Browsing the Hubot Script Catalog I found teamcity.coffee which does pretty much what we want.

Cracking up Sublime Text I added it to hubot-sripts.josn:

[“teamcity.coffee”]

I found out while doing this that “team city.coffee” has an dependency on underscore.js which we need to add manually to get it to work.

$ npm install —save undersocre

Commited that to the repository and went to our TeamCity server and created an account for the bot user. After that we set up some config for Heroku and push it up (change the values below to fit your environment).

$ heroku config:add HUBOT_TEAMCITY_USERNAME=bot_account
$ heroku config:add HUBOT_TEAMCITY_PASSWORD=pwd
$ heroic config:add HUBOT_TEAMCITY_HOSTNAME=http://teamcity-server.cloudapp.net/
$ git push heroku master 

Wait for the deploy to roll through and Bob’s you’re uncle! In the chat we can now ask the bot user for “help” and we’ll get a few new commands. Like “tc build start ” and “show me builds”

This is what it looks like for me:
commands in action

Next up

Next up we’ll be looking at how to get TeamCity to talk back to Hubot->Slack to tell us how the build went.

Hubot, Slack and Azure deployments – Part 1

I’m aiming at doing this a multipart series (this being the first part). I will update this intro with links to the follow up posts as I publish them.

Intro

We just pulled off our first hackday with the tech-team at acast. I set out to get GitHub’s open source robot Hubot to integrate with our Slack chat (a guerrilla warfare move on my part to move us from HipChat to Slack :), next I’ll tackle the tabs vs spaces issue). This post is a step by step account for how I did it.

The Goal

Deploy our projects to azure from the chat tool to:
1. Lower the barrier of deployment
2. Increase transparency and to use the chat as a information radiator (”Niklas is now deploying the rss-service”)

Doin’ it

Enabled Hubot integration in Slack

I logged into slack.com, went to *Configure Integrations* and enabled Hubot, giving the hubot user name, in our case abot.

Getting an instance of Hubot up and running

Now Slack is ready and we need an instance of Hubot running to do our biddings. I chose to put it on Heroku because of the simplicity and the good tutorials. I will be looking at setting it up on Azure WebSites later on.

In broad strokes I followed the Getting started with Hubot tutorial.

First let’s get our local environment in order (Caveat: I did this on Mac OS X and I haven’t tested it on Windows yet). Start by installing yeoman and a hubot generator.

In the wizard I entered `slack` as adapter. I don’t think that matter in this stage. It can be configured in the Procfile (see further down in this post). But we still needed to install the adapter for slack to test it later on:

If `node_modules` is not entered in the .gitignore file, it can be wise to add it. Now we’re ready for our first commit:


If you want to you can start a local redis for dev purposes. I don’t think that is needed. Let’s try if we’ve done everything correctly. Kick it off locally.

To the Cloud

So we’re running locally. Nice! Now let’s see if we can push it up to Heroku.

First up we need to crete a Heroku app. You need Heroku Toolbelt installed and a account on Heroku to do this. Let’s get cracking creating the app:

Log in first:

Next up, create the app. The –region parameter is not needed. If we don’t enter it we end up in the US which isn’t what I wanted :). The commands below also renames the site after creating it, not necessary.

Alright, we got a repo and we got an app. Now we need to push up some configuration to the app before pushing up the code. Since we’re using the slack adapter in this post we need to add config for it. This is documenteed in the Slackbot on Heroku article. In the code below, replace the value of the HUBOT_SLACK_TOKEN with the token we got when enabling the Slack integration on Slack.com.

For Hubot to persist it needs a brain. It’s brain is a Redis instance. We need to add it if we want persistence. I opted for the Heroku Redis addon Redistogo (it’s free in the nano version).

One last thing before we’re ready to give it a spin. Heroku work using a file called a Procfile which defines how it should start the app pushed to it. We just need to make sure it looks good. Should look something like this:

Where “botname” should be same as entered in the slack integration.

Now, let’s see if it flyes:

It works! For me it did anyway. I waited a little while with my eyes pealed at my Slack client and loe and behold if the user abot (in my case) got a green dot next to it. We can the spark up a private chat with it and say “help” or “ship it” or other extremely useful stuff.

So first part done! In the next post we’ll look at how to trigger TeamCity builds from the chat.

Node.js version on Azure WebSites

When running node.js on Windows Azure there is a few black boxy things. One thing that I didn’t manage to find docs for is how the node verstions work. That doesn’t mean there is no docs, just that I haven’t found them. So I tested arount a little. To test this stuff I did a little express.js app that can be found here: https://github.com/nippe/node-versions-on-azure/. What it does is on the /versions route return te process.env.WEBSITE_NODE_DEFAULT_VERSION and process.version. Look at https://github.com/nippe/node-versions-on-azure/blob/master/routes/index.js#L5 for detail. There is two tags (appsetting-version and package-version) in the repo to illustrate different approaches.

Here is what I learned.

Available versions

To find out which versions of the node.js runtime that are available on azure I found tow ways. 

Create a Azure Website

If you create a new Azure WebSite and navigate to the configuration tab you’ll se that the provisioning process created an app setting by the name of WEBSITE_NODE_DEFAULT_VERSION which I think always get the value of the latest available version present when the site is created.

Azure Site Extensions

Another more comperahensive way to get a hold of available versions is to go to the Site Extensions site, also called Kudu.

If your website has the url http://deletemesoon.azurewebsites.net, you just insert a scm in the url http://deletemesoon.scm.azurewebsites.net

Hit the Runtime Versions link.

Which gives you a JSON representation of available versions:

Set Version

Allright, I have the version – now what? How do you set it?

Well there is two alternatives.

App Setting

You can used the atomaticly provisioned app setting WEBSITE_NODE_DEFAULT_VERSION and set it to a value of you choise.
 

package.json

You can also define it in package.json under the engine attribute


”engines”: {
   ”node”: ”0.10.32”
},
… 

Here is an example package.json file:

The thing to be alert on is that package.json overrides WEBSITE_DEFAULT_NODE_VERSION settings. So if we set node: 0.10.32 in package.json and the app setting to 0.10.29. Package.json will set the tone.

One little wierd edge case is that if we use fuzzy matching in package.json:

”engines”: {
  ”node”: “^0.10.24″
}

And we set the app setting to 0.10.29 (not the latest available version). The appsetting seems to set a cap for the version.

Adding IP-address to Windows Azure Load Balancer

Background

We’re running a cluster of linux boxes as Virtual machines on Windows Azure. They are load balanced using the Azure Load Balnacer. To keep security tight we use a white list of IP-numbers in the load balancer. This is a pretty good solution when we got azure interal resources trying to get to the cluster, such as Azure WebSites. We know the IP of our azure resouses. We also added the IP of the office. Now yesterday I was working from home and needed my code to get access to our cluster (in Windows in Prallells…).

Solutions

The one described here is a dirty solution on how to white list an IP-number in the Load Balancer. Preferably I would like to set up an ssh-tunnel or something like it. But I don’t know how to do that on windows (yet) so instead of shaving that yak I added my home IP as described below.

Old portal

Go to Virtaual machines and klick on one of the boxes in the cluster.

Go to the Endpoints tab and chose Manage ACL

Add your external IP adress (I got mine sufin’ to whatsmyip.org) and then a slash (/) 32 because the other entreis had that, it has something to do with subnets. So if my IP was 123.123.123.123 I would enter 123.123.123.123/32. Give it an explanatory name and chose Permit (if thats what you wanna do :)).

New Portal

Multiple ways as usual, this is one. And it requires a crap load of clicks and scrolls. Improvement from the “old” portal?

Browse -> Virtual Machines

Select a Virtual Machine 

Scroll down to the  Configure Section and click Load balanced sets (not “IP addresses” for some reason…)

Select your set


Scroll down to the Access control list section and enter your IP-number as described above.

Azure Deployment Slots – a short intro

We are running a lot of our API endpoints and websites running node.js hosted on Windows Azure as Azure WebSites. A while back Microsoft introduced a pretty nifty feature called deployment slots.

Deployment slots – what are they

First of a little caveat: you have to be in standard mode to use the feature, free mode woun’t fly. So let’s say you create an Azure website. From that website you can then create one or many deployment slots. These slots are like a copy of the original site but with its on config and (in our case) local git repo.

Let’s go!

Navigate to the dashboard tab of the website and locate the Add new deployment slot
Image showing where the creation link resides

Give th deployment slot a nice name.

And badabing you have your deployment slot. You can see it in the portal if you hit the little expander arrow to fold it out:

Or by using the command line tools (preferably powershell if you’re on windows, I’m on mac now so I use the cross-platform tools) and there you can see the deployment slot as well using the “azure site list” command (the first time using the tools you have to do a pubSettings-file dance).

We got a deployment slot – now what?

So what we usally do is to make sure the slot (stage in my example) has a local repository. In our case we use git.

Then set up your deploy to production push to push to that local repo on the deployment slot. We use TeamCity and have set it up so it pushes to the stage slots every production build.

Then you can surf, connect your api-client or whatever to the stage url (api-web-stage.azurewebsites.net in my example) and test it out and make sure it all works.

Config

Each slot has it’s own version of the config such as app settings. This is awesome when you want to introduce some new config of change an existing value and make sure it works in production-stage before you deploy it. When you create a deployment slot you can chose to copy the config from the original website but after that they are detatced from each other.

So config for api-web (production)

And config for the api-web-stage (the slot)

Let’s do the same thing using the cross platform command line tools. “azure site appsettings list api-web”

And to view the slot by using the —slot parameter: ”azure site appsettings list —slot stage api-web”

Awesome feature but bare in mind, it’s entierly up to you to keep the configs in sync!
A little example. You introduce a new database and add it’s connection-string to the config of the stage-slot. All is fine and you swap the stage slot into production. Then you discover a small spelling error. You decide to roll forward so you fix it, deploy to the stage slot and swap that out to production. What just happened? You just swapped back the old config, missing the new connection string, into production with the code that expects it. So keep your config in sync :).

The swap

So, we have created our deployment slot, added a repo, added conifg and pushed our latest code to the stage slot. Now what?

I touched the subject above. Then we do a undramatic swap. You can find this button in the portal.

Or you could use the command line tools once again.

But wait what happened? I didn’t work did it! So after digging around the source on github for a while i realized I was running azure-cli 0.8.3 and I updated it to 0.8.5 (using nom update -g) and viola “azure site swap api-web stage” works!

Learnings

Working with deployment slots for a little while we’ve learnt a few things that might be of balue to others.

Local repositories

First I only created a local repository for the stage-slot, the thought being that we would never deploy to the production slot. The thing that bugged me big time with that solution was that I could not see which deployment (git checkin / sha) that was running i production. I had to look in the stage slot to see which deployment was running there and not in production. So we added a local repository to the production slot just to get visibility.

DNS for stage

I found it nice to put upp DNS entries for the stageing slot as well. That’s of course only applicable if you’re running on a custom domain. So for www.mysite.com (production slot) I put up stage.mysite.com (stage slot) for easy testing an communication with the rest of the company.

Summary

All-n-all I gotta give deployment slots two thumbs up! It’s a really neat feature for drama-less deployments and rollbacks if something breaks.

Getting WebStorm to use nodemon

Another note to self post. When writing node.js projects in WebStorm one of the major upsides is the debugging story. To hook that up you just create a configuration for it. One annoying thing I’ve encountered is that it does not restart the server/app after a crach or a save of the code-files.

In the command-line I’ve done this using nodemon and supervisor. I tend to prefer nodemon, so below I will show this using nodemon but it should work without problems using supervisor or any simular tool.

First of all install nodemon globally

npm install nodemon -g

Then enter WebStorm, open your node.js project and:

1. Hit the configuration menu to edit configuration if you don’t have one otherwise chose you’re existing config
2. If you don’t have a config, create it using the plus (+) sign
3. Change the path from node to nodemon

And Bob’s you’re uncle!

UPDATE 2014-06-29

That setup did not work as well as I hope, so I changed it around a little. Seems to work better: