Not that long ago I wanted to write a test for an endpoint that takes your uploaded files and sends it over to another service. I needed to test the initial upload and we already had some testing infrastructure in place, so I just needed to add new test cases. However, we were using PyTest which I haven't used before, as almost all of my testing experience was done in unittest. We were also working with the latest Flask 1.1.x. I had some issues coming up with code that would be suitable for our tests and the initial Google search did not yield satisfying results so I decided to write this short article about how to properly test file uploads in Flask.

All the code I will be describing is available on my Github, feel free to check it out, and run it yourself. I have started to work with Makefiles and I like it a lot, so I will be running tests and Flask app with "make" command.

Simple upload endpoint

Let's consider some basic endpoint implementation which can receive images and stores them in local "upload" folder:

@app.route('/upload', methods=['POST'])
def upload():
    try:
        logging.info(request.files)
        uploaded_file = request.files['image']
    except:
        raise InvalidUsage("Please provide image to upload", status_code=400)

    if uploaded_file.content_type != 'image/jpeg':
        raise InvalidUsage("Only JPEG images are allowed", status_code=400)

    try:
        filename = secure_filename(uploaded_file.filename)
        destination_file = os.path.join(app.config['UPLOAD_FOLDER'], filename)
        uploaded_file.save(destination_file)
        return {"file": filename}, 201
    except:
        raise
        raise InvalidUsage('Failed to upload image', status_code=500)

I want to explain pieces of this function, just in case you are not familiar with all of the functionalities.

First of all, we access files from form-data upload and pick out the field named "image":

uploaded_file = request.files['image']

Then we can perform a MIME-type check on that file to see if it's an image or something else (if you are not sure what is a MIME-type, you can read about it here):

if uploaded_file.content_type != 'image/jpeg':
        raise InvalidUsage("Only JPEG images are allowed", status_code=400)

Please note that this particular check is extremely naive as it decides Mime-type based only on the file extension. If you want to have true MIME-type detection, you can use Python-Magic. But this naive approach will be good for now as we will exploit later on in testing examples.

Now after we can be somewhat sure that we have an image that is being uploaded, we can process it, but first, we might want to find out the name of the file, because I want to keep the filename the same in my upload folder:

filename = secure_filename(uploaded_file.filename)

This secure_filename function is a part of Werkzeug's utils package, it strips all unnecessary and dangerous characters from the uploaded file's name.

Then we want to construct a path where our uploaded file will be stored:

destination_file = os.path.join(app.config['UPLOAD_FOLDER'], filename)

The upload folder value is set at the top of app.py and we are using os.path.join function to construct a system-compatible path to the file.

You can also construct a file path manually by doing something like this:

destination_file = app.config['UPLOAD_FOLDER'] + '/' + filename

And I bet some of you reading this article are doing just that in your programs and apps. If you are developing on a Windows machine you have to use backslashes, but you are probably deploying your app on a Linux server, and that requires forwards slashes. Those system differences in paths can cause errors and bugs and this is why you should use os.path.join(path, *paths), which will solve those problems for you automatically.

After that we can finally save this image to the disk:

uploaded_file.save(destination_file)

And we want to return the clean filename along with the status code of 201 (Created). Here we can use new Flask's syntax where we return a tuple of dictionary and integer, the dictionary will get converted to JSON and integer will be our response status code:

return {"file": filename}, 201

The test

Let's now set up our testing infrastructure. First of all, we want to create a folder named "tests" in our project and convert it to a package by creating an __init__.py file inside.

As we will be using Flask's test client to test our endpoint, we want to configure as a fixture so it can be easily accessed in our tests. We can do that if we create a file named conftest.py:

import pytest
import app

@pytest.fixture(scope='module')
def test_client():
    flask_app = app.app
    testing_client = flask_app.test_client()
    ctx = flask_app.app_context()
    ctx.push()
    yield testing_client
    ctx.pop()

Now we can start writing some tests! Here where I have stumbled from the beginning, it seemed like everyone on the face of the Earth was writing tests with dummy streams of data, something like this:

def test_upload_text_stream(test_client):
    file_name = "fake-text-stream.txt"
    data = {
        'image': (io.BytesIO(b"some initial text data"), file_name)
    }
    response = test_client.post('/upload', data=data)
    assert response.status_code == 400

In this test, we define a file_name with .txt extension, because we want to make sure our naive MIME-type checked does not allow text files to be uploaded, we only want images.

Then we create a data dictionary payload with the field 'image' in which we will store a tuple with 2 values:

• a byte stream of data
• name of the file we are uploading

Note that we can name the file with anything we want, we don't have to send the real name of the file.

After we have everything ready, we POST the data to our test client and we check for a status code of 400 to check that server has rejected the payload.

If we want to do the same dummy data stream upload, but make sure we succeed, we can do this:

def test_upload_image_stream(test_client):
    image_name = "fake-image-stream.jpg"
    data = {
        'image': (io.BytesIO(b"some random data"), image_name)
    }
    response = test_client.post('/upload', data=data)
    assert response.status_code == 201
    assert response.json['file'] == image_name

This test is sending virtually the same data as the one above, but we have a different filename with a different extension (jpg instead of txt), so we "fool" our MIME-type detector, and the server will save the file, respond with status code 201 (Created) and return the name of the file.

But I wanted to run these tests with files I already had in my repository. I did not want to use any dummy data streams, because I was also testing integration with other services and dummy data would interfere with test results.

To use real files inside your project, you will create tests that do this:

def test_upload_textfile(test_client):
    file = "random-file.txt"
    data = {
        'image': (open(file, 'rb'), file)
    }
    response = test_client.post('/upload', data=data)
    assert response.status_code == 400

What you have to do, is provide a byte stream of a real file, you have to use the open() function and set the mode to 'rb' (read+binary). This will read the file as a binary and provide the correct data for the upload.

To check our upload with a nice picture, I picked this picture:

I want to upload this cute picture of a Pizza-Cat to my endpoint and make sure it works correctly:

def test_upload_image_file(test_client):
    image = "pizza-cat.jpg"
    data = {
        'image': (open(image, 'rb'), image)
    }
    response = test_client.post('/upload', data=data)
    assert response.status_code == 201
    assert response.json['file'] == image

You can run all the tests in the project by running "make test".

After I have found out how easy it was to create tests that use real files for upload I immediately wanted to write an article about it. I think we all should write tests for the code we write because tested code is more reliable than untested code and if you know more about how to create proper tests for something harder, like file uploads, you will get faster in a habit of writing tests along with your code.

Good luck with your tests!

M.

I took the title of this article directly from the documentation of Pipenv because it is amazingly accurate. If you have ever used package managers available for other languages, such as NPM or CocoaPods, and came to Python, you might have noticed that our Pip is not so sophisticated. It can also be a good thing since the barrier for entry is lowered, it's easier, but it also encourages filling our requirements.txt file with a bunch of dependencies from other libraries. Pipenv is here to help us manage our dependencies, it makes working with virtual environments more seamless and ensures that we are always using correct packages when developing our code. Want to know more? Read on!

Example App

Let's say we want to make an app that uploads a file to an S3 bucket. I picked this example because Amazon's Boto3 library has quite a few dependencies, and I think something like this is a prime example of how to optimize our requirements file. This app should be pretty straightforward and I didn't want to just pick a lot of arbitrary dependencies just to show you how full can your requirements file get. I will be doing everything in a virtual environment so we can get an accurate picture of our project dependencies. This example code was taken from https://boto3.amazonaws.com/v1/documentation/api/latest/guide/s3-uploading-files.html.

import logging
import boto3
from botocore.exceptions import ClientError

def upload_file(file_name, bucket, object_name=None):
    """Upload a file to an S3 bucket

    :param file_name: File to upload
    :param bucket: Bucket to upload to
    :param object_name: S3 object name. If not specified then file_name is used
    :return: True if file was uploaded, else False
    """

    # If S3 object_name was not specified, use file_name
    if object_name is None:
        object_name = file_name

    # Upload the file
    s3_client = boto3.client('s3')
    try:
        response = s3_client.upload_file(file_name, bucket, object_name)
    except ClientError as e:
        logging.error(e)
        return False
    return True

upload_file("requirements.txt", "test-bucket")

Everything you are about to see was executed inside this repository. You can clone it and follow along, I highly recommend you see it for yourself. If you want to make your life easier, also use Pyenv (read about it here) and Python 3.8.2 which was used to create examples for this article.

Basic Pip usage

Let's see how we would use Pip to build this app. First, we would create a virtual environment and activate it:

cd pip-example
python -m venv venv
. venv/bin/activate

Let's now check our Pip freeze command to make sure we don't have any packages installed:

pip freeze

Let's now install boto3 library and check our "pip freeze":

pip install boto3
pip freeze

boto3==1.14.28
botocore==1.17.28
docutils==0.15.2
jmespath==0.10.0
python-dateutil==2.8.1
s3transfer==0.3.3
six==1.15.0
urllib3==1.25.10

The reason why we are checking "pip freeze" is that a lot of people, when working on a project, install packages first and add them to requirements later, and they often use the command "pip freeze" and forward that output to requirements.txt. But this list of dependencies is not something we want to save and version in our repository as the only real dependency from this list is boto3.

Right now it's quite easy to pick out our dependency and copy it to the requirements file, but how about when you introduce a couple more libraries? Once your list of dependencies gets longer, your willingness to pick out correct dependencies from a list gets lower and you start flooding your requirements with unnecessary libraries, which will inevitably produce clashes among their dependencies.

Let's now deactivate our virtual environment to check out Pipenv:

deactivate

Basic Pipenv usage

First, we need to install Pipenv, which is pretty easy on a macOS with Homebrew installed:

brew install pipenv

Otherwise you should follow installation steps from Pipenv documentation.

Let's now do the same thing, but with Pipenv:

cd pipenv-example
pipenv --three
pipenv shell

If you are using pyenv (you should be) and you have specified a local version of Python, you can just use Pipenv shell and everything will be set up for you. You can read about pyenv in my previous article.

Once we are inside our virtual environment, we can install our dependency:

pipenv install boto3

You will see some output from that command, something similar to this:

Installing boto3…
Adding boto3 to Pipfile's [packages]…
✔ Installation Succeeded 
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Building requirements...
Resolving dependencies...
✔ Success! 
Updated Pipfile.lock (dfb424)!
Installing dependencies from Pipfile.lock (dfb424)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 0/0 — 00:00:00

"That's a lot of new things, it mentions Pipfile, Pipfile.lock, what are these things?" you might ask. Let's look at the contents of Pipfile first:

[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[dev-packages]

[packages]
boto3 = "*"

[requires]
python_version = "3.8"

Pipfile is the basis of our dependency list, it holds all of our main dependencies that we have installed and nothing more. It only has boto3 in the packages section, the version is specified as *, which means it should install the latest version (we should probably change that to fixed version). To install the same version as in Pip example (1.14.28) we can simply run:

pipenv install boto3==1.14.28

And that will update our Pipfile to this:

[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[dev-packages]

[packages]
boto3 = "==1.14.28"

[requires]
python_version = "3.8"

This file is the reason we want to use Pipenv, it provides a source of truth for dependencies for our project, and we can be certain that the packages it lists are the true dependencies.

You can look at the contents of Pipfile.lock here (file is pure JSON and it's quite large and hard to read inside this article). You can see all the dependencies that the boto3 library requires, it contains versions, hashes, markers, all the goodies that package managers require.

To deactivate our virtual environment when using Pipenv it's as simple as this:

exit

I must say I prefer the activation and deactivation of virtual environments in Pipenv over regular venvs, as it closer tracks the behavior of regular shells.

"Pip freeze" problem

Consider this scenario (which happened to me not that long ago): You will start working on a new project, you clone the repo to your machine, you create your virtual environment, you run "pip install -r requirements.txt", and you'll get an error message like this:

ERROR: zappa 0.51.0 has requirement python-dateutil<2.7.0,
but you'll have python-dateutil 2.8.1 which is incompatible.

This is caused by storing the output of "pip freeze" directly, instead of creating it carefully line by line, dependency by dependency. It's just a pile of libraries, their dependencies, and dependencies of dependencies.

How do you resolve that kind of mess now? The easiest thing is to go to the requirements file and just remove a specific row for python-dateutil, run it again, and then it works with no errors. But how can we know that we don't need that 2.8.1 version? After all, it was specified as a dependency, so it should stay at 2.8.1, right?

You can never be 100% certain unless you go over the entire codebase and make sure. Some pieces of code somewhere might be reliant on that specific version and it might cause a crash later on. In my case, I went over the codebase as it was relatively small, and after I made sure it's not used anywhere I removed it and reinstalled the packages.

Pipenv does not have the "freeze issue"

Since Pipenv updates it's Pipfile during the installation of a new package, it does not have the same above-mentioned problem. It keeps its list of dependencies clean and tidy, however, there can always be issues with clashing sub-dependencies, but at least you will get notified about it when you install a new package that is causing the clash, and you have a chance to correct it yourself, and not push it on the next person who downloads and installs dependencies for your code.

Migrating to Pipenv

If you want to start using Pipenv today, you don't have to do anything special, but you might encounter "pip freeze" issues on your projects. When you activate the virtual environment from Pipenv and it detects a requirements.txt file, it will try to install all the dependencies from it, however, it does not know which are the actual dependencies, so it just adds all of them to Pipfile as packages. You can try it out yourself:

cd migrate-example
pipenv shell
---
✔ Successfully created virtual environment! 
Virtualenv location: /Users/martin/.local/share/virtualenvs/migrate-example-aEf2PuZd
requirements.txt found, instead of Pipfile! Converting…
✔ Success! 

Our new Pipfile after migration:

[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[dev-packages]

[packages]
boto3 = "==1.14.28"
botocore = "==1.17.28"
docutils = "==0.15.2"
jmespath = "==0.10.0"
python-dateutil = "==2.8.1"
s3transfer = "==0.3.3"
six = "==1.15.0"
urllib3 = "==1.25.10"

[requires]
python_version = "3.8"

You can clean packages that you know are not essential for your code and are just sub-dependencies. After that simply create a lock file and you can commit both Pipfile and Pipfile.lock to your repo:

pipenv lock
---
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Building requirements...
Resolving dependencies...
✔ Success! 
Updated Pipfile.lock (dc9747)!

Specific version of library in Pipfile

When I started working with Pipenv, I had one question for which it was a bit difficult to find an answer, at least at that time: "How can I specify the exact version of a library to use in my Pipfile?".

I was trying many combinations in Pipfile, all of them incorrect:

boto3 = 1.14.28
boto3 = "1.14.28"
boto3==1.14.28
boto3=="1.14.28"

As you can see from example Pipfile above, the correct usage is:

boto3 = "==1.14.28"

I hope this article showed you how useful it can be to use Pipenv as a package manager for your project. It does not matter if your team or project is small, medium, or large, all of them could benefit from a properly defined dependency list that is well maintained and Pipenv helps you with that immensely. It helps to prevent errors and bugs, and I am really glad that we already have a tool like this at our disposal in Python. It's time to start using it!

If you work with Python long enough, you will find yourself in a pickle. You might want to have multiple versions of Python installed on your computer at the same time, because your OS requires one version, different version is required for your project, and another one is a requirement for that one weird library you need for whatever reason and there is no compatibility with newer version of Python.

What you can do is install all the versions you need and reference them by their version, let's say you have python 2.7, 3.6 and 3.8:

python2.7 hello.py
python3.6 hello.py
python3.8 hello.py

I would say that this kind of usage is pretty common. But there is a way to make our lives easier and simpler. No more remembering which version is required for which project, making sure you and your team use the same one, having issues while running your code because you have selected the wrong version to run.

Welcome to pyenv

This interesting library allows us to have multiple Python versions installed on the system, allows us to configure Python versions per folder and also set single global version. Sounds too good to be true? Let's take a look.

Installation

This article was be written for MacOS, since it is the system I'm using (and I think it's really good for developers). You should install tools (like pyenv) and libraries using Homebrew. Homebrew is a package manager, something similar to Ubuntu's apt-get, which makes it easy to install almost everything on your system even if it requires configuration and compilation.

So we will install pyenv with Homebrew:

brew install pyenv

Yes, it is that easy. Everything is being installed and being taken care of, just sit back, relax and let brew do its thing.

Once we have pyenv installed, let's install multiple Python versions! In this example I will be showing how to install version 3.6 and 3.8, but you can list all available versions for installation with following command:

pyenv install --list

We will install version  3.8 first by running the install command:

pyenv install 3.8

And we should see something like this:

python-build: definition not found: 3.8

The following versions contain `3.8' in the name:
  3.8.0
  3.8-dev
  3.8.1
  3.8.2
  miniconda-3.8.3
  miniconda3-3.8.3

See all available versions with `pyenv install --list'.

It appears that we  have to also specify patch version number we want to install. I would argue that this is a good thing because you have to pick the exact version you want to install and use, you are in total control of your Python, however that also means no automatic update to the latest version.

Ok then, install version 3.8.2 and check if it's registered in pyenv:

pyenv install 3.8.2

You should see a list similar to this one (note I have used pyenv before and my output might differ from yours as it's fresh installation of pyenv):

pyenv versions
* system (set by /Users/martin/.pyenv/version)
  3.8.2

Let's install also version 3.6.9 and check versions again:

pyenv install 3.6.9
pyenv versions
* system (set by /Users/martin/.pyenv/version)
  3.6.9
  3.8.2

Now we can set different Python versions for different folders, and we can also switch global version (default version when there is no specific local version in a folder). Let's do that now, let's make 2 new folders and set different python version for each one of them:

cd ~
mkdir version1 && cd $_
pyenv local 3.6.9
python

Python 3.6.9 (default, Jun 10 2020, 01:11:21) 
[GCC 4.2.1 Compatible Apple LLVM 11.0.3 (clang-1103.0.32.62)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 

cd ~
mkdir version2 && cd $_
pyenv local 3.8.2
python

Python 3.8.2 (default, Jul 18 2020, 20:10:28) 
[Clang 11.0.3 (clang-1103.0.32.62)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 

You can see that with command "pyenv local VERSION" you can set any arbitrary installed Python version in a folder. It actually creates invisible file named ".python-version" in that folder, so if you want you can include it in your repository and your entire team will now be using the same python version when executing code in that folder (they have to have pyenv installed as well of course).

I want to quickly mention that you can also set your default global Python interpreter version with this command:

pyenv global 3.6.9

Also you can set version for your current shell instance:

pyenv shell 3.6.9

As you can see pyenv is really good at managing Python versions. If you want to know how it does it in the background, you can read more about it here. It is very powerful tool for Python development and really useful one if you need to have multiple versions installed at once and switch seamlessly between them. I personally use it everywhere, but it is kind of configure-once-and-forget-about-it type of tool, which is the best kind I think. Simple, powerful and yet unobtrusive. It does its thing and let's me do my work effectively.

How do you like pyenv? How do you manage your Python version installations? Let me know in the comment section below!

M.

In this day and age it is nice to deploy your services in containers. It takes most of the headache of configuring servers and environments away. But sometimes things just don't work the way you expect them to and sometimes it's hard to find answers to the questions you have.

That's what happened to me when I was trying to deploy one small web service built on Flask to AWS ECS service. It just would not work in a way I wanted it to. So, let's talk about it!

All the code I'm showing is available on GitHub here.

Let's assume some basic Hello World Flask app like this:

from flask import Flask
app = Flask(__name__)

app.config['DEBUG'] = True

@app.route("/")
def hello_world():
    return "Hello, World!"

if __name__ == "__main__":
    # use 0.0.0.0 to use it in container
    app.run(host='0.0.0.0')

flask==1.0.2

It's simple enough. For fast and easy development we can use built-in development server from Flask, however it is not production-ready server. Let's see how we can make a Dockerfile that would use this built-in server:

FROM python:3.8-slim
RUN mkdir /app
WORKDIR /app
ADD requirements.txt /app
RUN pip3 install -r requirements.txt
ADD . /app
EXPOSE 5000
ENTRYPOINT ["python", "app/app.py"]

You can see the code for this here. If we run the container and send requests to it, we can see it is working:

docker build --tag flask-app .
docker run -p 5000:5000 flask-app
curl http://localhost:5000

This is good enough for development purposes, but let's say you need to take this app to production. This server simply cannot handle the workload, it works on just one thread and multiple users using application that is a bit more complicated, for example accesses a database, will be extremely slow, will hang and eventually might crash.

What you want to use in this case is WSGI server. You can read more about WSGI servers here. We will be using Gunicorn as our WSGI server for this example. Let's rework out application now to use it.

First suggestion I have is to make a separate file where we will load our application and prepare it for running in production. That way it's detached from your app and it avoids name space confusion, since almost everything is named "app" 😄. Let's make new file named "wsgi.py":

from .app import app

# do some production specific things to the app
app.config['DEBUG'] = False

And we should also add Gunicorn to our requirements.txt, create Gunicorn config file and update Dockerfile to  run the app on Gunicorn.

flask==1.0.2
gunicorn==20.0.4

bind = "0.0.0.0:5000"
workers = 4
threads = 4
timeout = 120

FROM python:3.8-slim
RUN mkdir /app
WORKDIR /app
ADD requirements.txt /app
RUN pip3 install -r requirements.txt
ADD . /app
EXPOSE 5000
ENTRYPOINT ["gunicorn", "--config", "gunicorn_config.py", "app.wsgi:app"]

You can get the code for this right here. We will build it and will run it the same way as before. Now we have python application that is much sturdier in production environment, it's much faster  serving responses when there are more users using your app since it is using more threads and has multiple workers to serve those requests.

However this is not perfect solution and it has some issues that will have to be solved:

No SSL support

This is a big issue in day of modern web development. Everything should be encrypted. Everything. It is no one's business to see unencrypted data traversing The Net. Gunicorn supports SSL, but what I like to do is to use NGINX as a reverse proxy in front of Gunicorn. This way Nginx can handle web server tasks and Gunicorn can handle application tasks. You will have to configure Nginx to use SSL, but Nginx gives you so much more freedom and much more configuration options to configure everything the way you want it. Keep an eye on this blog, I have an article in the works about how to configure Nginx with Let's Encrypt certificates in Docker to make it easy to deploy.

Weird issues with running Gunicorn in Docker

When I was deploying my last app, I found some inconsistent behavior in my Docker container. That was what has prompted this article. I just could not for the life of me get Gunicorn working in the container. It just would not start. After hours of trying almost everything and googling around, I found a way to fix it.

We need to put the command of starting Gunicorn to separate script file and then just invoke that script. It seems to solve all the issues. Let's make entrypoint.sh:

#!/bin/bash
exec gunicorn --config /app/gunicorn_config.py app.wsgi:app

And update our Dockerfile:

FROM python:3.8-slim
RUN mkdir /app
WORKDIR /app
ADD requirements.txt /app
RUN pip3 install -r requirements.txt
ADD . /app
EXPOSE 5000
RUN chmod +x ./entrypoint.sh
ENTRYPOINT ["sh", "entrypoint.sh"]

You can see the code for this here. After this change, Gunicorn now works properly and without any issues.

If you know why this is helping with running Gunicorn in Docker container, feel free to leave comment down below!

M.

Update: Redditor skiutoss pointed out some awesome ready-mage images from tiangolo on GitHub, specifically image meinheld-gunicorn-flask-docker could be a great starting point for porting your Flask app into Docker container.

How many times did you forget where is your key to login to AWS EC2 instance? How many times did you have to search in Slack or in your email history to get the IP address you needed to access client's remote server?

Tired of using ssh like this?

ssh -i ~/Downloads/example-dev-key.pem ubuntu@example.com

No more!

You need to learn how to properly use config file for SSH. You can specify all the necessary details once and then just forget it. And let's be honest, we will forget it.

Only one thing is required: you need to have your private key, as the config does not support password authentication.

First we need to create our config file and set correct permissions.

touch ~/.ssh/config
chmod 600 ~/.ssh/config

We will be editing this file from now on.

How to configure access to AWS EC2 instance

First of all, you should copy your key somewhere safe, I have decided to copy it to my .ssh folder so I can keep everything together as it makes it easier for me.

Example config entry:

host ec2-example-dev
 Hostname example.com
 Port 22
 IdentityFile ~/.ssh/example-dev.pem
 User ubuntu

Lets break it down:

• host: this is the name you choose for your server. You will use it to ssh to it.
• Hostname: this is the hostname or IP address of the server
• Port: port where the SSH server is running, defaults to 22
• IdentityFile: this is why we are doing this, it allows us to specify key for our ssh connection
• User: name of the user which will be connection to the server

To connect to our server, we simply call ssh like this:

ssh ec2-example-dev

Isn't it easier? Easy to remember. Now I just have to make sure I don't forget how I named my servers 😅.

How to configure access to servers with your key

If you are using your regular ssh key (id_rsa) to access servers, you can make use of this configuration as well. You can set up custom names for different servers, set up ports and usernames for them.

How I ssh'd before:

ssh martin@example.com

or if you are using custom port (which you should be using):

ssh martin@example.com -p 2233

We can simplify it with our config like this:

host example
 Hostname example.com
 Port 2233
 User martin

And we can ssh

ssh example

This shows the power of config file for SSH. It really helped me to manage all the servers I need to access on regular basis and honestly, EC2 instances with custom keys were the biggest pain to access, but now with well defined config file, it is a breeze to connect to them to manage and monitor them.

Learn more how to use ssh config files here.

M.

The backtick ` in Swift can be used in variety of ways. It allows you to create identifiers from language keywords.

One of the most important uses is the interaction with other languages that have different reserved keywords.

From Swift you can call C and Objective-C functions directly, but imagine you want to call C function that is named guard. You cannot call it without a backtick:

`guard`()

Perhaps better showcase would be an enum. You might want to create an enum with following values:

enum Foo {
    case `var`
    case `let`
    case `class`
    case `func`
}

let items = [Foo.class, Foo.let, .var]

Using backticks enables you to use reserved language keywords as you see fit.

If you want to replicate Apple's API design in your codebase and use the default keyword as a property name, you'll have to use a backtick. For example NotificationCenter uses singleton called default, but default is also a keyword used in switch statements. To implement your own property with name default, you can use something like this:

class MyOwnNotificationCenter {
    static let `default` = MyOwnNotificationCenter()
    ...
}

Have you ever used [weak self] in a closure? If not, you should! But once you make weak reference to self, self becomes optional and sometimes it can be a pain to work with it. Before Swift 4.2 you had to do something like this to keep strong reference to self and keep it's name (or change the name and use strongSelf variable name):

self.provider.fetchData { [weak self] (fetchedData) in
    guard let `self` = self else { return }
    let processedData = self.processData(fetchedData)
    self.updateUI(with: processedData)
}

But as of Swift 4.2 you can now do something like this:

self.provider.fetchData { [weak self] (fetchedData) in
    guard let self = self else { return }
    let processedData = self.processData(fetchedData)
    self.updateUI(with: processedData)
}

You can now upgrade reference from weak to strong using optional binding and it is now consistent with other optional variables and properties used in your codebase.

Those are just few examples for using backticks, but I think you get the idea. It is really neat that we have a way to name our identifiers how we want, even if they are same as language-reserved keywords.

We all know that naming variables is one of the hardest things in programming 😉.

M.

It feels good to finally have my own blog. I should have done it long time ago.

This blog is Ghost blogging platform running on Docker, with Nginx web server, Let's Encrypt certificates, all hosted on Digital Ocean.

I look forward to writing some (perhaps) interesting articles about new things I have learned in iOS development and share some (maybe basic) knowledge of Docker. If you have better knowledge than me in topics I write about, don't hesitate to share your insights! We all are here to learn.

See you in next article!

M.