Local Sublime Text via remote SSH

Initially, for myself, and quite ashamedly as with many other facets .. I created an alias to access my SSH .. as a way to avoid lookup of the IP address you know? I cringe now, believe you me.

Well, then I needed to have access to Sublime Text in my remote environment as a way to make life a wee more convenient (i.e. in this case WAY more convenient), and figured to let you know how I did in case it may help.

---

There are good articles about how to configure your local and SSH environments with Sublime Text, such as this one written by Limina Studio and this one written by Daniel Demmel.

One other key piece of information is the function of the ~/.ssh/config file itself. There's a great writeup available from Nerderati available from this link.

The workflow is as follows:

1. Install the rsub plugin from the Package Control of Sublime or instructions provided from the public Github repository,

2. In your local environment edit your ~/.ssh/config file and specify your SSH IP address and User:

Host yourAlias
    HostName "$IP"
    User "$USER"
    RemoteForward 52698 127.0.0.1:52698

3. In your SSH environment, as root, do:

# wget -O /usr/local/bin/rsub https://raw.github.com/aurora/rmate/master/rmate
# chmod +x /usr/local/bin/rsub
# shutdown -r now

4. Henceforth, you may now access your SSH similar to what would be an alias:

$ ssh yourAlias

5. Restart Sublime, SSH in, and there will be an added advantage of being able to edit files via your local environment's Sublime Text editor.

Guidelines for clinicians

Pleased to announce Guidelines a resource for clinicians.

This was a project long overdue.

1) Single site access to gold standard guidelines is surprisingly still not addressed

The purpose of Guidelines is very pure and simple: frequently or semi-frequently the world leading associations issue recommended guidelines that clinicians utilize on a daily basis to treat medically compromised patients.

The variety and scope of these publications may be wide, however, there are a number of well defined sources that are pre-selected as the authority or gold standard of care. Therefore, curation of these Guidelines is not as labor intensive or time consuming to warrant an establishment for their organization; and thus, remain neglected.

2) Clinicians should conveniently be able to access Guidelines

Of anyone with their plate already full, the clinician will foreseeably be too consumed in other activities to maintain a dedicated, and convenient, point of entry towards their access to the most current, and relevant, standards.

The clinician may not even have convenient access to a list of gold standard resources they once may have had. Once a clinician enters private practice, they risk becoming isolated and sandboxed out of such resources that may often go unnoticed or unappreciated.

As a result, the clinician may compromise their ability to receive a thorough, and up to date, criteria or list of standards they may study. Subsequently, patients are the population who bear the results of this risk.

3) When clinicians have access to resources, patients benefit

The sole purpose of a clinical practice, and hence Guidelines, is to benefit the patient.

There should not be an issue that exists today caused by a barrier of access to information that is readily available over the wire. Therefore, instruments such as Guidelines exist to facilitate the transfer of information to maintain a peer reviewed, updated, thorough, and accessible list of resources available to clinicians via a multitude of avenues.

OPEN CALL FOR CLINICAL SCIENCE CONTRIBUTORS

ALL DISCIPLINES OF HEALTH CARE

PROJECT AVAILABLE ON GITHUB FOR IMMEDIATE CONTRIBUTION

---

Step by step breakdown of IBM Bluemix image deploy

Step by step breakdown of IBM Bluemix

1) Creating local image

$ ice --local build -t $IMAGE_NAME:$TAG $DIR

The first step of working with Bluemix is to create a local image. This step is analogous to creating an image in Docker. The main difference is that the build produced here can be pushed to the IBM Bluemix cloud repository. Bluemix can connect to Dockerhub, however, it can also host your images privately out of the box, and sync with your local Docker daemon images.

SUPPORT

2) Tag and Push

$ ice --local tag $IMAGE_NAME $REGISTRY_URL/$NAMESPACE/$IMAGE_NAME:$TAG

$ ice --local push$REGISTRY_URL/$NAMESPACE/$IMAGE_NAME:$TAG

The local image is now tagged, and pushed to the IBM Bluemix cloud repository for use to add to a container in the following step.

SUPPORT

3) Create and run container

$ ice run --name $UNIQUE_CONTAINER_NAME $EXPOSED_PORTS $NAMESPACE/$IMAGE_NAME:$TAG

This piece may throw some people off base, and for good reason: "How come is it when I delete a container that I can no longer use that container's name?". Indeed, each time you apply an image to a cloud container, the cloud container needs a unique name that was never used before. Otherwise, you'll soon find that there will be an exception that the container already exists. It's a cloud repository after all. Therefore, assign a new name for a container each time you decide to run this command.

After this step you're done! You can of course, continue either by having access to a public IP address or by making code edits, and having to handle changes thereof.

SUPPORT

4) Access your public IP address if you don't have one already

$ ice ip request

The next step is self-explanatory. I hope you can foresee that you'll then have to assign this IP address to your cloud container for it to do anything useful. You may also derive a public IP address by utilizing the IBM Bluemix GUI instead of the CLI.

5) Bind/unbind IP address to a cloud container

$ ice ip unbind $PUBLIC_IP_ADDR $OLD_CONTAINER_NAME

$ ice ip bind $PUBLIC_IP_ADDR $UNIQUE_CONTAINER_NAME

In case you'd like to bind a public IP address, for instance to access various ports inside your application, you will have to bind them. I have been avoiding to run this step if another container is using the public IP address my clients utilize. This is preceded by unbind or stopping and removing the other container running the application. Of course, be careful when removing your container as it can no longer start. You may keep previous container(s) to revert in case your new adjustments have corrupted your code.

6) Logging

$ ice logs $UNIQUE_CONTAINER_NAME

The ability to log was a paramount concern. In addition to options such as SSH to your container, you can login to your IBM Bluemix from a Docker VM environment, and view your logs in real time.

7) Cleanup

$ ice rm $OLD_CONTAINER_NAME

Let's get rid of the previous, inactive, and unbound container for good measure and housekeeping.

To remove previous images, simply get rid of them from local and cloud

$ ice --local rmi $REGISTRY_URL/$NAMESPACE/$IMAGE_NAME:$TAG

$ ice --local rmi $NAMESPACE/$IMAGE_NAME:$TAG

$ ice --cloud rmi $NAMESPACE/$IMAGE_NAME:$TAG

Check out the BlueImage script for automation of simple deployments outlined above

Reset Docker Connection to Wifi

Sometimes when you change your position, and hop on to a different wifi, Docker returns a TimeOut exception. The following series has worked for me:

$ docker-machine restart default      # Restart the environment
$ eval $(docker-machine env default)  # Refresh your environment settings

It's from a Stack Overflow post, and made for a nifty bash command in case I go somewhere different, and I need to connect to the Docker VM/environment.

Configuring EC2 CLI on OSX

Make sure you have Java installed on your box.

Download and install EC2:

$ wget http://s3.amazonaws.com/ec2-downloads/ec2-api-tools.zip
$ sudo mkdir /usr/local/ec2
$ sudo unzip ec2-api-tools.zip -d /usr/local/ec2

Drill in to your ec2 directory to see version number

$ /usr/local/ec2/ec2-api-tools-1.7.5.0

Here, it's 1.7.5.0;

Go to https://console.aws.amazon.com/iam/home
There you will find or create your AWS credentials in the section "Security Credentials".
You will also have to assign permissions in the section "Permissions".

In your .bash_profile, add the following:

export JAVA_HOME=$(/usr/libexec/java_home)
export EC2_HOME=/usr/local/ec2/ec2-api-tools-1.7.5.0
export PATH=$PATH:$EC2_HOME/bin
export AWS_ACCESS_KEY=[KEY]
export AWS_SECRET_KEY=[SECRET]

You can test your EC2 configuration in a new Terminal window

$ ec2-describe-regions

This should generate an output of values similar to the following:

REGION eu-west-1 ec2.eu-west-1.amazonaws.com
REGION ap-southeast-1 ec2.ap-southeast-1.amazonaws.com
REGION ap-southeast-2 ec2.ap-southeast-2.amazonaws.com
REGION eu-central-1 ec2.eu-central-1.amazonaws.com
REGION ap-northeast-1 ec2.ap-northeast-1.amazonaws.com
REGION us-east-1 ec2.us-east-1.amazonaws.com
REGION sa-east-1 ec2.sa-east-1.amazonaws.com
REGION us-west-1 ec2.us-west-1.amazonaws.com
REGION us-west-2 ec2.us-west-2.amazonaws.com

Reminiscences of a Docker Operator

Docker takes a while to get used to.
I suggest you use the official node image.
Maybe make a Dockerfile that installs nodemon for live reload of your code
and use a volume to mount your code directly in it.
Use docker exec <container> bash to get a shell to your dev env
and you have yourself a fully isolated node env.
npm install to install all depencies.
As long as you keep that container around, it will keep the stuff you installed with npm, but if you destroy the container, it will go back to the state of the image.

NodeMCU ADC dependency matrix

ADC required the RC module, and were added to the remainder of dependencies in the following list:

node,file,gpio,wifi,net,tmr,adc,uart,mqtt,cjson,rc,dht