td: Todo list the geek way

Today I was looking for a todo list that was simple. I did find todoist but since I don’t use apple store at work and my home computer runs Ubuntu I kept searching.

I ended up finding td.

td is a simple command line todo list with the some interesting functionalities.

You can either have a .todos file in a directory or have a global database configured.

Installation

For Mac, you can find td on brew, so simply do:

$ brew install td

For linux, you can either install it from source with go get github.com/Swatto/td or download the executable and put in your system (/usr/local/bin, for example).

Configuration

The thing I found interesting in td was the ability to have a “per project” to-do list.

Simply create a .todos file in a folder and a to-do list is created and accessible whenever you’re in this folder or any sub-folders (Yes, it is recursive).

On top of it, you can define a global database using the TODO_DB_PATH environment variable.

Just add something like this to your .bashrc or .zshrc:

export TODO_DB_PATH=$HOME/.config/todo.json

If td finds a .todos local file it will start that list, otherwise it will use the global database.

For a multi-computer solution, you can point this global database to a Dropbox folder so you can have it synchronized:

export TODO_DB_PATH=$HOME/myDropboxFolder/todo.json

Usage

td usage is very simple. Just take a look at its help:

COMMANDS:
   init, i  Initialize a collection of todos
   add, a   Add a new todo
   modify, m   Modify the text of an existing todo
   toggle, t   Toggle the status of a todo by giving his id
   clean Remove finished todos from the list
   reorder, r  Reset ids of todo or swap the position of two todo
   search, s   Search a string in all todos
   help, h  Shows a list of commands or help for one command

GLOBAL OPTIONS:
   --done, -d     print done todos
   --all, -a      print all todos
   --help, -h     show help
   --version, -v  print the version

Using db:structure dump and load instead of db:schema

Today I faced the following problem: I had a migration creating a index in SQL, like this:

CREATE UNIQUE INDEX some_table_single_row ON some_table((1))

which will make this table unique in the database.

Problem is, Rails won’t import this INDEX to db/schema.rb and, because of it, my test database didn’t created it and I had a failing test.

rake:structure

Rails comes with a rake task called db:structure which will do pretty much what db:schema does but using the specific database tool for it, in this case pg_dump.

So, I created structure dump from dev database:

[$] rake db:structure:dump

which creates a db/structure.sql file, dropped my test database and re-created it from this new dump:

[$] RAILS_ENV=test rake:structure:load

Et voilà, tests were passing.

Deploying jekyll with capistrano

Assumptions:

  • Server uses RVM
  • Jekyll uses bundle

Install Capistrano

Add capistrano and dependencies to Gemfile:

group :deployment do
  gem 'capistrano'
  gem 'capistrano-rvm'
  gem 'capistrano-bundler'
end

And bundle install:

$ blog cap install .

mkdir -p config/deploy
create config/deploy.rb
create config/deploy/staging.rb
create config/deploy/production.rb
mkdir -p lib/capistrano/tasks
create Capfile
Capified

Configuring capistrano

deploy.rb:

# config valid only for current version of Capistrano
lock "3.8.1"

set :application, "my_app"
set :repo_url, "git@<git-url>.git"

# Default deploy_to directory is /var/www/my_app_name
set :deploy_to, '/home/deploy/mysite.com'

set :rvm_type, :user
set :rvm_ruby_version, '2.4.0@mysite'

namespace :deploy do

  task :jekyll_build do
    on roles(:app), in: :groups, limit: 3, wait: 10 do
      within current_path do
        execute :bundle, 'exec jekyll build'
      end
    end
  end

  # Run the jekyll build command after the release folder is created
  after "symlink:release", :jekyll_build
end

And production.rb:

server "mysite.com", user: "deploy", roles: %w{app web}

That’s it! Now just cap production deploy to update the site.