Best practices for building Vim plugins

2016-11-05 VimConf 2016


This is a quick guide to changing the keymap on the GH60 "Satan" or RevCHN. Note that the Satan is NOT a true GH60, and using the GH60 with the normal TMK would not work.

Note that installing dependencies or compiling TMK is not a part of the scope of this document. If you have problems with this part, seek help elsewhere. Note also that these instructions are written for Linux and Mac. If you're using windows, just use the Command Prompt for the git commands, and Windows Explorer to move and delete files. Thirdly, I don't do backlighting or lighting. Whenever I tried to compile this software with support for pwm or any of that stuff, it failed, so I removed those functions. So if you like the lights, you have some debugging to do. Feel free to fork this gist and send me a PR if you can fix it :)

  1. Dependencies.
  2. Download and install GIT:
  3. Download and install the dependencies for compiling TMK: (Point 1 only)
mongoose = require "mongoose"
Busboy = require "busboy"
secrets = require "../config/secrets"
GridStream = require "gridfs-stream"
Files = require "../models/files"
sharp = require "sharp"
async = require "async"
View master.vim
" copy all this into a vim buffer, save it, then...
" source the file by typing :so %
" Now the vim buffer acts like a specialized application for mastering vim
" There are two queues, Study and Known. Depending how confident you feel
" about the item you are currently learning, you can move it down several
" positions, all the way to the end of the Study queue, or to the Known
" queue.
" type ,, (that's comma comma)

Clustering: The basics

The trick? pass the file descriptor from a parent process and have the server.listen reuse that descriptor. So multiprocess in their own memory space (but with ENV shared usually)

It does not balance, it leaves it to the kernel.

In the last nodejs > 0.8 there is a cluster module (functional although marked experimental)

View cpu.rb
require 'rbconfig'
# Based on a script at:
class CpuCounter
def self.count
def count
View output.log
tim@touchsmart:~/Code$ nvm use v0.11.2-generators
Now using node v0.11.2-generators
tim@touchsmart:~/Code$ node --harmony testgen.js
<Buffer 76 61 72 20 66 73 20 3d 20 72 65 71 75 69 72 65 28 27 66 73 27 29 3b 0a 66 75 6e 63 74 69 6f 6e 20 72 65 61 64 46 69 6c 65 28 70 61 74 68 2c 20 65 6e 63 ...>
Sleeping for 2000ms...
View nginx-cors.conf
# A CORS (Cross-Origin Resouce Sharing) config for nginx
# == Purpose
# This nginx configuration enables CORS requests in the following way:
# - enables CORS just for origins on a whitelist specified by a regular expression
# - CORS preflight request (OPTIONS) are responded immediately
# - Access-Control-Allow-Credentials=true for GET and POST requests
View gnuplot commands
set xdata time
set timefmt "%Y%m%d"
set offset graph 0.1, graph 0.1, graph 0.1, graph 0.1
plot "" using 2:1 with lines

My issues with Modules

In researching topics for RailsCasts I often read code in Rails and other gems. This is a great exercise to do. Not only will you pick up some coding tips, but it can help you better understand what makes code readable.

A common practice to organize code in gems is to divide it into modules. When this is done extensively I find it becomes very difficult to read. Before I explain further, a quick detour on instance_eval.

You can find instance_eval used in many DSLs: from routes to state machines. Here's an example from Thinking Sphinx.

class Article < ActiveRecord::Base