Archive for the ‘development’ Category

New blog

I decided to move on from WordPress and start a new blog. You can read about my reasons here.

Follow me along and read my new post about Vim: How to Configure Syntastic.

Read Full Post »


I’ve been using spacehi for years. It highlights invisible characters: trailing spaces and tab characters.

Here’s how it looks if you toggle it on and off:

In my dotfiles setup, it’s turned on by default.

In most cases, whitespace characters do not matter. But sometimes they do. For example, Go and Python are picky about spaces. Also, a mix of spaces and tabs will look different for different people and their editors — because nobody can agree how many spaces at tab character is (4 or 8?!). This is something I’ve talked about before.

This week, for the second time in a couple of weeks, I lost a bunch of time on another whitespace: character 160, the non-breaking space. To make a long story short, it was a copy and paste from Skype, and the JSON parser I was using choked on it.

It seems spacehi hasn’t been touched in (almost exactly) 10 years. I found its mirror on github. But it didn’t handle non-breaking spaces, so I forked it.

I’m willing to maintain it, it a very simple Vim plugin. Bug reports and improvements are welcomed.

Read Full Post »

It’s always nice to get something for free. That’s how I feel about JSLint. Running your JavaScript code through JSLint gives you a few advantages:

  • Coding style consistency — always use ; at the end of a line
  • Syntax error detection — did you forget that ) ?
  • Logical error detection — did you forget that var?

There’s a whole bunch of stuff JSLint will pick up for you.

I have talked before about JSLint in the context of SpiderMonkey, but, nowadays, I install node.js for a few things. If I run JSLint through node.js, that means I won’t have to install SpiderMonkey anymore.

Installing Node and NPM

I admit, these pieces of software are moving fast and the instructions (or lack thereof) are limited. But these things will vary with your OS and skill level.

I’m going to focus on the Vim integration, but go ahead and install Node and install NPM.

Installing JSLint

Which one?

I recommend the simply named “jslint”. You can look it up on GitHub as node-jslint.

Make sure you don’t forget that “-g” flag with NPM. NPM changed a lot in version 1.0.

Vim Integration

The end goal is:

You are in a JavaScript file, you press F4, Vim runs JSLint on your file, parses the errors and puts your cursors on the exact location of the first error with the others one waiting in the quickfix list.

The main part of integrating with Vim to “compile” something is to set makeprg and errorformat (aka efm). If you ever need to integrate with something else, be sure to Google for those.

Since we are going to invoke :make all the time, I’m going to bind it to F4. (put it in your .vimrc)

nmap <F4> :w<CR>:make<CR>:cw<CR>

Step by step:

  • :w — save the file, doesn’t hurt if it’s already saved
  • :make — invoke make
  • :cw — open the quickfix window if there are errors. Close it if there are no errors.

Next, create $HOME/.vim/ftplugin/javascript.vim. Put these lines into it:

setlocal makeprg=jslint\ %
setlocal errorformat=%-P%f,
                    \%G/*jslint\ %.%#*/,
                    \%*[\ ]%n%l\\,%c:\ %m,
                    \%G\ \ \ \ %.%#,
                    \%GNo\ errors\ found.,

The variable makeprg is just was it invoked when you do :make. The variable errorformat are instructions on how to parse the error messages of the “compiler”. That variable and how to configure it are a whole world of complexity.

Now, restart Vim and open some JavaScript file you have lying around. Press F4. Be ready for a lesson in humility.


If things don’t work out, try this:

  • try to run “jslint” from the command-line, if it doesn’t work Vim won’t work either
  • if the output of “jslint” changes format, you’ll have to tweak errorformat

Read Full Post »

It all started with CoffeeScript. Like all languages I play with, one of my first step is to look for a Vim syntax file. Thankfully, the CoffeeScript page itself links to kchmck‘s vim-coffee-script on github. So far, so good.

Here’s the first step:

Wait … what?! I hate having to install software to … install software. At this point, I was ready to close the tab but it was a tpope project. That’s usually a sign of quality. I was ready to give this pathogen thing another look.

So … pathogen lets you dump “bundle” directories under ~/.vim/bundle/ and will setup the various Vim variables so that the plugin, ftplugin, syntax, ftdetect are all hooked up correctly. That’s nice; it solves a lot of the pain I’ve felt over the years about trying various vim plugins and messing with my setup.

In theory, you would do something like:

cd ~/.vim/bundle
$ git clone https://github.com/kchmck/vim-coffee-script.git

And add at the top of your .vimrc:

" pathogen bundles
filetype off
call pathogen#helptags()
call pathogen#runtime_append_all_bundles()

That’s pretty close to how I have it setup. While I was making my mind about pathogen, I found Tammer Saleh’s post about pathogen. Besides the details I outlined above, he suggests git cloning the repository and removing the .git instead of playing with git submodules. I could not agree more. Of course, I have to deal with that situation only because my ~/.vim is under git. (like all my dotfiles, read more)

I simplified his script for my own purposes: (on github)


refresh() {
  local url="$1"
  local dir="$2"

  rm -rf $dir
  git clone $url $dir –depth=1
  rm -rf $dir/.git

  if [ -f "$dir/.gitignore" ]; then
    rm "$dir/.gitignore"

refresh https://github.com/scrooloose/nerdcommenter.git nerdcommenter
refresh https://github.com/vim-scripts/matchit.zip.git  matchit
refresh https://github.com/tpope/vim-haml.git         &nbsp; vim-haml
refresh https://github.com/timcharper/textile.vim.git &nbsp; textile
refresh https://github.com/kchmck/vim-coffee-script.git vim-coffee-script

I think the --depth=1 on the git clone is a nice touch … especially since I delete the git directory right after the download. The CoffeeScript plugin is working well and it keeps being committed to. The refresh script is quite useful.

I’m planning on packaging a few of the plugins I wrote and “bundle” them too. (vim-slime)

Read Full Post »


This project started out as a list of books in a text file.


When I think about a book, I think about its content, the people who talked about it and how it made me feel. Central to those thoughts is the visual representation of the book itself: its cover. A list in a text file was not the best way to think about books. Over time, I realized that it would be the kind of problem suited for a small web application.


I spent many hours working on this project. It used to be an excuse to play with Ruby on Rails. It used to be an excuse to play the limits of rich-client Javascript applications. It used to be an excuse to play with client and server-side optimizations, not by necessity but by a conscious effort to want to try things on a project I fully understand.

This is an application I designed for myself and that I use, for the lack of a better word, religiously. Hearing about books I want to read, buying a book, starting a new book, or finishing one, these are events that make me want to go to my profile and update it.

This application was initially meant to replace a text file. But the nature of a public display of books created new possibilities. When it comes to people I know, I want to know what they are reading so that we can talk about it the next time we meet.

“How was that book?”

Also, you can look at what people have read and discover what interests them. I have had a lot of interesting discussions after people browsed the books I have read.

Finally, this is also meant to be a portfolio piece. I can send people to the site to have a look at what I can do. The project is open-source and people can read the code and reach their own conclusions.

I’m open to comments and suggestions. Let me know what you think.

Code: http://github.com/jpalardy/bookpiles
Live app: http://bookpiles.ca

Read Full Post »

A few years ago, when I was more into python, I stumbled on python challenge. It was great fun, I learned a bunch of stuff and it forced me to play with libraries I wasn’t familiar with.

In their own words: (about)

Python Challenge is a game in which each level can be solved by a bit of (Python) programming.

The Python Challenge was written by Nadav Samet.

All levels can be solved by straightforward and very short1 scripts.

Python Challenge welcomes programmers of all languages. You will be able to solve most riddles in any programming language, but some of them will require Python.

Sometimes you’ll need extra modules. All can be downloaded for free from the internet.

It is just for fun – nothing waits for you at the end.

Keep the scripts you write – they might become useful.


People who know me know that I read a lot. I am, therefore, painfully aware that books are not the best way to learn things.

What is the best way to learn something?

To be honest … I don’t know. Not books, not screencasts… There are better ways: a one-on-one session, pair programming. On the side of DOING there is always: DOING more. Read more code, program more, release more.


In the spirit of the python challenge, I released today Command-line One-liner Challenges.

The idea is not exactly the same: I do provide solutions and you are allowed to move on based on your interests (or frustration).

I strive to make each challenge look and feel like any other challenge. The directory structure will be something like this:
directory structure
Each challenge is its own directory (numbered). Inside it, you can find a very short instructions.txt file. There are 2 subdirectories: problem and solution. Those subdirectories should be the same except for the content of the compare.sh file.

Look at the input.txt file. Then, look at the expected.txt file. Imagine how, as a one-liner, you could transform input.txt into expected.txt.

You are supposed to run compare.sh. Just open it and fill in the blanks, so to speak.


convert() {
  cat "$@"

convert input.txt > actual.txt

${DIFF:-diff -q} actual.txt expected.txt

The project’s README contains more information.


This is meant to be fun. Clone the repository and give it a go. I’m going to push more challenges over time, you might want to watch the repo.

If you have a better solution than what I provide, please send it to me, I’ll find a way to include it in the project.

Also, if you have an idea for a challenge, let me know.

Read Full Post »

How MANPATH works

Just after I was done writing Managing PATH and MANPATH, I stumbled on “man man” and put to rest the mysteries of MANPATH.

How it works

If MANPATH is defined, it will be used to lookup man pages.

If MANPATH is NOT defined, the manpath config file is going to be used. Depending on the OS your are using, it might be something like /etc/man.conf (Mac OS X) or /etc/manpath.config (Ubuntu).

Here’s an excerpt for “man man” (Mac OS X):

It says there’s a command line flag to override MANPATH (-M), but I don’t think that’s excessively useful.

Here’s something useful: when you aren’t sure what man page you’re going to get, try the -w flag.

Read Full Post »

Bundler Without Rails

Yesterday I reached into a project I had not touched in months. When I wrote that Ruby script, it was supposed to be a one-off effort, but, as it usually goes for things like these, it had ended sticking around for much longer than anticipated.

I have RVM installed and I had installed many Rubies and done all kinds of gem manipulations. In short, the “environment” in which that project had worked was gone.

I had the “require” statements to guide me:

require rubygems
require dm-core
require dm-timestamps

require json

However, that’s not the whole story. In this specific case, DataMapper requires
more gems based on the connection string you give it.

I think we have all tried this:

  1. try to run a script
  2. see what “require” crashed the whole thing
  3. install some gems (hopefully with the version needed)
  4. repeat

Isn’t Bundler supposed to solve that problem?


I have used Bundler with Rails 3. But that’s all configured and just automagically works. In a standalone project, there are a few things you need to do yourself.


> bundle init

All that command did was to create an empty Gemfile.

Open the Gemfile with your favorite editor and add your gem dependencies. Mine looked like this:

# A sample Gemfile
source :gemcutter

gem "dm-core"
gem "dm-timestamps"
gem "dm-sqlite-adapter"

gem "json"

Then, run:

> bundle install

So far, this is all regular Bundler stuff. What about your script?

Bundler knows about all your dependencies, surely it will “require” all I need, right?

Yes and … no.

Bundler Documentation Fail

Here’s a screenshot from Bundler’s documentation

Thank you Bundler, I “require” you and now … huh … I still require all the gems I need?! I doesn’t sound very DRY to me.

What the “bundler/setup” line did was to configure the load path.

And you could do your requires manually…

If I’m writing this it’s because there’s a way. I’m just surprised that the Bundler website doesn’t seem to document this useful feature. If there are good reasons why this is not documented (tradeoffs or something) or, even, the default behavior — we can only guess.

Here’s what your script should do:

require rubygems
require bundler/setup


The “Bundler.require” line will require all your dependencies.

One last note, do lock (bundle lock) your Gemfile so that the dependency resolution phase is skipped. It will make loading your script much faster. (this also applies to Rails projects)

Read Full Post »

I have a bunch of shell/ruby scripts in a directory that I include into my PATH variable. The scripts live there because I don’t have a better location to put them. That’s fine when scripts are general enough to be used anywhere.

Some scripts are not so general and are meant to interact only with a few specific files and directories.

Putting things in perspective: this is a discussion about global variables and local variables when it comes to Bash. You want your variables to be scoped only that was is needed and not more.

Here’s an insight:

Include a .local directory in your PATH.

For example:

forgetful, a project I maintain that implements the Supermemo algorithm, takes CSV files as input. I could use a spreadsheet manipulate these files, but I prefer to use Vim and a bunch of unixy scripts to do what I want. In the directory where I keep my CSV files, I created a subdirectory called .local (could be called anything). When I’m in the directory, Bash will include the .local subdirectory when looking for executables … in essence, I get my “local” executables.

Notice how there’s a Rakefile in that directory? I think that’s a workaround that a lot of people end up using. I’ll probably strip out most of what the Rakefile is doing and shove it to the .local directory.

Read Full Post »

UPDATE: With respect to terminology, check out Drew Neil’s comment below.

In Vim, I’ve been using splits for years. Splits are great:

  • view 2 files at the same time
  • view 2 parts of the same file at the same time
  • dump bits of text into a new split
  • dump command outputs into a new split
  • and so on…

However, I’ve been using the subset of splits that I understood while shying away from advanced use cases. Somewhere down my TODO list, there was an item called “understand Vim splits”. This blog post is an attempt to document what I discovered.

3 Questions

When it comes to splitting, there are, thankfully, only 3 questions:

  • are you splitting the buffer or the window?
  • are you splitting horizontal or vertical?
  • do you want to send the split left, right, up or down?

3 questions

When you type:


You are using the defaults: buffer, horizontal, up.

There are 8 combinations:

window  horizontal  up      -->   :topleft    split
window  horizontal  down    -->   :botright   split
window  vertical    left    -->   :topleft    vsplit
window  vertical    right   -->   :botright   vsplit
buffer  horizontal  up      -->   :leftabove  split
buffer  horizontal  down    -->   :rightbelow split
buffer  vertical    left    -->   :leftabove  vsplit
buffer  vertical    right   -->   :rightbelow vsplit

What were they thinking?! Good time to give up? :-D


Look at the following picture. Starting from a initial state, follow what happens when you invoke these commands. (click to enlarge)

  • for this example, it doesn’t matter whether you’re using split/vsplit or new/vnew
  • the blue buffer is where your cursor is
  • the buffers are numbered to help locate them before and after

Even though I spent a few hours thinking about splits and studying the commands to eventually come up with that summary graph, I can’t say it’s the most intuitive set of commands around. If I stop everything I’m doing, I can mentally come up with the right command but it’s very taxing.

Here’s a list of mappings I just added to my .vimrc

" window
nmap <leader>sw<left>  :topleft  vnew<CR>
nmap <leader>sw<right> :botright vnew<CR>
nmap <leader>sw<up>    :topleft  new<CR>
nmap <leader>sw<down>  :botright new<CR>

" buffer
nmap <leader>s<left>   :leftabove  vnew<CR>
nmap <leader>s<right>  :rightbelow vnew<CR>
nmap <leader>s<up>     :leftabove  new<CR>
nmap <leader>s<down>   :rightbelow new<CR>

Feel free to replace the arrow keys (up, down, left, right) with k, j, h, l if you’re more comfortable with those bindings.

Read Full Post »

Older Posts »