I'm often finding myself crafting some of the most complex and ingenious stuff ever known to IEx men, only to find myself having to recreate it minutes later because I'm now in a new IEx session. Annoying? Yes. Solvable? Yes! Here's how.

We're all familiar with using Ctrl+r for searching our shell history of crafty one-liners, right? Great. With that out of the box, let's see how we can achieve the same in iEX. It's quite simple, and it's well explained in the IEx documentation.

Enabling it for single sessions can be done by starting IEx in the following way:

iex --erl "-kernel shell_history enabled"

Enabling it system-wide can be done by setting the following environment variable (Unix-like systems):

export ERL_AFLAGS="-kernel shell_history enabled"

Now, once you've done this you can enjoy having all of your IEx history available using the arrow up and arrow down keys, as well as the Ctrl+r trick mentioned earlier.

Remember iEX history

I’ve written npaste, a simple pastebin for text and images that supports encryption using GPG. After a while of using it via the command line I felt the need for a plugin for Sublime Text 3 and also Visual Studio Code. In this post I will explain how I created the plugin for Sublime Text 3.

The ST3 plugin API is pretty well-documented, and there are also some resources available on the Package Control website that explains how to create a plugin. Despite this I had to do some research on my own, and the point of this post is to document the not so well documented aspects of creating and publishing an ST3 plugin.

The first thing I did was to create a default plugin file. You can easily do this from within Sublime Text 3 by choosing Tools > Developer > New Plugin... from the Main Menu.

The plugin file will look something along the lines of this:

import sublime
import sublime_plugin


class ExampleCommand(sublime_plugin.TextCommand):
    def run(self, edit):
        self.view.insert(edit, 0, "Hello, World!")

ST3 treats these classes as commands without the Command part and in snake case. This ExampleCommand would be executed by telling ST3 to run the command example.

In my case, I named the class NpasteUploadCommand which can be executed by calling npaste_upload. More on that later.

The actual actions that the command will execute should be placed in the run method, but I’m not going to cover that in this post.

I created an empty git repository at ~/dev/npaste-sublime and saved the file as npaste-upload.py inside of this folder.

To be able to test the plugin as I developed it, I created a symbolic link inside of the Packages folder of ST3. Where this folder is located probably differs depending on which OS you’re using, but in my case, as I’m using a Mac, it was located at ~/Library/Application Support/Sublime Text 3/Packages. I basically did this:

ln -s ~/dev/npaste-sublime ~/Library/Application\ Support/Sublime\ Text\ 3/Packages/npaste

Now Sublime Text 3 will load this plugin and automatically reload it whenever I make changes to any files within that folder.

ST3 allows you to easily configure default keybinding for each operating system it supports (Windows, Mac, Linux). To do this, simply create a file for each OS you want to support inside the package folder. The valid file names are:

Inside of each file you can define keybindings by using the following syntax:

[
  {
    "keys": ["ctrl+alt+shift+n"],
    "command": "npaste_upload"
  }
]

As you can see, the command that will be executed when you type ctrl+alt+shift+n is the previously mentioned npaste_upload command.

My plugin depends on the requests package. To make sure that this package will be installed when installing the npaste plugin, I created a file in the root of the package folder called dependencies.json. The format of this file is documented in the Package Control Documentation, but in my case it is the following:

{
  "*": {
    "*": [
      "requests"
    ]
  }
}

I wanted to have a menu entry when right clicking in a buffer, so I added a Context Menu entry. To do this, I created a folder called menus in the root of my package folder. Inside of this folder I placed a file called Context.sublime-menu with the following contents:

To be able to easily edit the settings of the npaste plugin, I wanted to add a menu entry to Sublime Text > Preferences > Package Settings > npaste called Settings. To do so, I created a file inside of the menus folder called Main.sublime-menu. The contents of this file is as following:

As you can see, the Main Menu entry points to a file called settings/npaste.sublime-settings. This file contains the default settings of the plugin. Since npaste relies on a remote server, the user must be able to set the hostname, username and password, along with some other settings. I created a folder in the root of the package folder called settings. Inside of this folder I created a file called npaste.sublime-settings with the following contents:

{
//  Specifies the URL of the npaste server to use
    "npaste.url": "https://localhost:3000/",

//  Specifies the npaste API username
    "npaste.username": "username",

//  Specifies the npaste API password
    "npaste.password": "password",

//  If true, pastes will be archived instead of deleted when they expire.
    "npaste.archive": true,

//  Sets the age of pastes (s,m,h,d,y)
    "npaste.age": "14d",

//  If true, pastes will be encrypted using GPG
    "npaste.encrypt": true,

//  Encryption key length
    "npaste.encryption_key_length": 32
}

Prepending all the keys with npaste. shouldn’t be necessary and it’s something I will improve in a later update.

You’ve probably seen that some packages displays a text file after you’ve installed it or after an upgrade. I wanted this for my npaste plugin, so I created a new folder called messages. Inside of this folder I created two files: install.txt and 0.0.5.txt. The contents of install.txt will be displayed when a user installs the package, and the contents of 0.0.5.txt will be displayed when a user upgrades the package to version 0.0.5. You can read more about this in the Package Control documentation.

Finally I created a file in the root of the package folder called messages.json. The contents of this file is the following:

{
  "install": "messages/install.txt",
  "0.0.5": "messages/0.0.5.txt"
}

You should add a LICENSE file to the root folder of your package. The Package Control bot will give you a warning if you don’t have this file in your repository. It’s also advisable to add a README file of some kind.

This is the structure of my package folder after doing all of the above steps:

.
├── Default (Linux).sublime-keymap
├── Default (OSX).sublime-keymap
├── Default (Windows).sublime-keymap
├── LICENSE
├── README.md
├── dependencies.json
├── menus
│   ├── Context.sublime-menu
│   └── Main.sublime-menu
├── messages
│   ├── 0.0.5.txt
│   └── install.txt
├── messages.json
├── npaste-upload.py
└── settings
    └── npaste.sublime-settings

This is well-documented in the Package Control Documentation, so I’m not going to cover it here. The only thing that puzzled me was that there was no description below the package name when searching for the package within Package Control, so I had to do some research on this. It turns out that the description is fetched from the description of your repository, so be sure to add a short description to your repository.

Sublime Text 3 – creating a plugin

This short guide is basically just a reminder to myself, where most of the content is based on Digital Ocean’s Initial Server Setup with Ubuntu 16.04 and my own memory.

Disclaimer: This short guide is basically just a reminder to myself, where most of the content is based on Digital Ocean’s Initial Server Setup with Ubuntu 16.04 and my own memory. There are some important steps that aren’t included in this guide. If you’re new to Linux or Ubuntu, I suggest that you read Digital Ocean’s guide instead.

All commands in this guide (unless otherwise stated) assume you are currently logged in as root.

We don’t want to use the root user when logging in to our server, so we need to create a new user.

If you’re only using keys to log in to your server (which you should), you can choose to not create a password for the new user using the --disabled-password option. Please note that you’ll be unable to use sudo with this user unless you also perform the steps in this post.

Our newly created user will typically need root privileges:

Now, if you want this user to be able to use sudo without the need for a password, here’s how to accomplish this.

At this point we’re ready to copy the public keys to the newly created user’s .ssh folder. I won’t cover all the details of this process in this guide. Please refer to the previously mentioned Digital Ocean guide if you’re uncertain of how to do this.

We will need to set the correct permissions:

Note: These commands assume you are logged in as your newly created user.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Also make sure that these files are owned by the user we just created.

On new Digital Ocean droplets, this step is usually already done when creating the droplet. Just to make sure, we’ll check to see if the file /etc/ssh/sshd_config contains the following lines and that none of them are commented out:

PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no

If you did any changes, reload the SSH daemon:

Note: Try connecting to your server in a separate tab/window before disconnecting.

We need to make sure that our server doesn’t expose unnecessary ports and protocols, so lets configure UFW in the most basic way possible:

Note: At this point you should once more verify that you’re able to log in to your server.

This concludes this short guide on how to perform the initial steps when creating a new Ubuntu (16.04) server.

Basic server setup (Ubuntu)

Disabling the password needed for sudo for a specific user is very easy in Ubuntu. This method applies to Ubuntu 16.04, but probably also other versions of Ubuntu and maybe even other distros.

Note: If this is the first time you’re running this command, you’ll most likely be presented with a list of editors to choose from. Choose the one you’re most comfortable with.

Then enter the following line at the end of the file:

Make sure to replace user with the username of the user you want to allow using sudo without entering a password.

Disabling password for sudo in Ubuntu

This is something I don’t do that often, and I always forget the correct syntax. Thus this post.

Let’s say you have a table images and a table users. Now you want to delete all rows in table images that are associated with rows in the table users that are marked as deleted.

First, I usually do a visual inspection of the rows that will be deleted:

SELECT i.* FROM images i LEFT JOIN users u ON i.user_id = u.id WHERE u.deleted = 1;

The rows returned by this query are the rows that will be deleted when you run the following query:

DELETE i FROM images i LEFT JOIN users u ON i.user_id = u.id WHERE u.deleted = 1;

They key part here is to specify which table you want to delete from. In this case it’s the table i, which is the images table.

Deleting rows with a LEFT JOIN in MySQL

Occasionally I write something. It'll end up here.