Forem: David Lains

Even Better Rails Date Formatting

David Lains — Tue, 03 Sep 2019 17:29:34 +0000

I just recently came across Andy Croll's article about using strftime to format date and time values in a Rails View.

He makes a strong argument that you shouldn't use strftime in a Rails View:

<%= @user.last_sign_in_at.strftime('%m-%e-%y %H:%M') %>

Because Rails has built in date and time formats, and you can also define your own. To use one of the built in formats you can just call to_s on a Date or Time class and pass in the format you wish to use:

<%= @user.last_sign_in_at.to_s(:long) %>

See Andy Croll's article for the nitty gritty details.

What About `nil`?

If you've spent much time writing Ruby or Rails code you probably already see an issue with the to_s call above. What if the last_sign_in_at value is nil?

You might think... "Hmm, no problem. Calling to_s on nil just returns an empty string, so no harm, no foul."

nil.to_s
  => ""

Well, there are two problems with that line of thinking. First, Rails actually creates a to_formatted_s method that takes a single argument which references the format to use. The to_formatted_s method is aliased too to_s for Date and Time objects. If you try to pass an argument to nils version of to_s you get an error.

nil.to_s(:long)
ArgumentError (wrong number of arguments (given 1, expected 0))

Second, you might actually want to have some visual representation that the date or time is missing or unset. I like to show a couple of dash characters when a date or time is missing.

Best of Both Worlds

Here is how I handle date and time formatting in my Rails apps.

In the application_helper module I add a format_date method, so it is available to every view.

def format_date(date, format = :long)
  date.blank? ? '--' : date.to_s(format)
end

In your views you can call it like so:

<%= format_date @user.last_sign_in_at %>

If the user has never signed in you will see the two dashes that signify there is no last_sign_in_at time set. Otherwise the last_sign_in_at will be formatted with the :long format.

If you want to override the default format you can always pass in a different one.

<%= format_date @user.last_sign_in_at, :db %>

Or use your own format (provided you defined one as outlined in Andy Croll's article).

<%= format_date @user.last_sign_in_at, :myformat %>

Conclusion

Be aware of nils in your code. Anytime you see a . in your code think to yourself, "What happens if the thing on the left side of that . is nil?".

Originally posted at davidlains.com.

tmux Window Juggling

David Lains — Tue, 29 Jan 2019 07:41:41 +0000

I keep finding more and more depth to tmux. It really is a remarkable piece of software. In this article I will show you how to turn a tmux Window into a Pane and vice-versa.

Why would you want to move Panes and Windows around in a tmux session? I'll explain my scenario, and maybe that will give you some ideas of your own.

Debugging Sessions

I create tmux scripts for all of my projects. This allows me to simply run the script to have the development environment for the given project up and running in a tmux session.

For a Rails project I generally have a tmux window named server that is running the Rails server. I make it the last window in the list because I don't need to look at it too often.

However, I also use Byebug for debugging Ruby. If you haven't used Byebug or a similar debugger before the way it works is you add a byebug statement in your code where you want a breakpoint. When you run the code the byebug statement will halt the process and transfer control to the debugger.

In a Rails project the server is running the code, so when Byebug hits a breakpoint the debugger stops in the server window. Then you can interact with the debugger as you normally would, inspecting variables, stepping through code, etc.

Now you can perhaps see where this is going. When debugging Rails it would be very handy to have the server window in a split pane next to my editor. That way I can see the relevant code and the debugger in the same tmux window.

Window Becomes Pane

The first tmux command we need is join-pane. The join-pane command gives you the ability to attach a window or pane somewhere else in tmux to your current window. The join-pane command has the following form.

join-pane [-bdhv] [-l size | -p percent] [-s src-pane] [-t dest-pane]

We wont need all of those options thankfully. The -s option is used to specify the source pane or window to join into the current window.

A quick refresher for how to reference things in tmux may be in order.

[session]:[window].[pane]

For example, if your current tmux session is named giggles then a reference to the third pane in the second window would be giggles:2.3. You can omit the session name if you are currently in the session with the window you want to reference. And yes, that means you can use join-pane to move a window or pane from a different tmux session to your current session.

For my case I want to move a whole window, so I can just use -s N, where N is the window number I'm interested in. You can also move a window by its name, so -s server would work just as well.

The -l and -p arguments can be used to size the new pane appropriately. I'm fine with the default 50/50 split so there is no need to use either.

The -t argument can be used to move the source pane to someplace other than the current window. Also not an option I will need. The -b option works with -t to specify that the new pane should be placed to the left or above the target pane.

The joined pane will be active when you complete the join-pane command. If you don't want it to be you can use the -d option.

The -h and -v arguments make new pane a horizontal or vertical pane respectively.

Now I can put together the first command I need. I want to move my server window into my editor window for this debugging session. First I enter command mode with <Prefix>:. Now the join-pane command:

join-pane -h -s server

And there it is, my server window next to my editor window. One weird thing about tmux is how it deals with horizontal and vertical splits. The -h argument specified above produces what I would call a vertical split. There is a pane on the left and a pane on the right. The -v argument does the opposite, putting one pane on top and the other on the bottom.

Pane Becomes Window

To reverse the join-pane operation and make a pane a window use the break-pane command. The break-pane command has the following format.

break-pane [-dP] [-F format] [-n window-name] [-s src-pane] [-t dest-window]

Again, we won't need all of these options. Just like with the join-pane command, if you specify the -d option the window will not become active after the move. The -P argument tells tmux to print information about the new window, and the -F argument provides the ability to format that information.

If you don't specify a source pane with -s then the currently active pane will be broken out to its own window. Otherwise you can specify the pane to move the same way you did for the join-pane.

Panes are not named like windows are, so when you move a pane to its own window tmux will use the default name for the window, which is the current command. If you would like to name the window use the -n argument and the window name.

The other option, if you have an existing window that you would like to move the pane to you can use the -t argument with the reference to the desired window.

For my case when I'm done with the debugging session I just want to move the pane back to its own window named server, and I don't need it to be active. I'd rather the editor window remain active. I can achieve this with the following command (remembering to activate command mode first with <Prefix>:).

break-pane -d -n server

That tells tmux to move the currently active pane to a new window at the end of the window list, do not make it active, and name it server.

Create Key Bindings

The join-pane and break-pane commands aren't too hard to use in an ad-hoc manner to move panes around as necessary. It is a little bit of typing, but if the window to move is not named, or you need to move different windows around you are stuck having to use the commands themselves.

In my case I know the server window will always be available because it is in the tmux script that sets up the environment. Since I know the window name will not change I can create key bindings for those commands. As an added benefit, these key bindings are only available for this session because they are not in the main .tmux.conf file.

tmux bind-key u join-pane -h -s server
tmux bind-key U break-pane -d -n server

Now, whenever I want to see the server window next to my code I can just type <Prefix>u and to return it to its own window I can type <Prefix>U.

Originally posted at davidlains.com.

Create Your Own Vim Commands

David Lains — Tue, 22 Jan 2019 06:13:54 +0000

If you have used Vim for any length of time you have run across Ex commands. Hell, you use an Ex command to exit Vim; :quit, or just :q. There are Ex commands available to do pretty much anything that can be done in Vim.

You can make your own Ex commands as well. Many Vim plugins add their own Ex commands as part of the plugin. You might think it is hard to create a new Vim command, but it isn't. I'll show you the basics here, and where to look for more information.

Open a Reference File

I find it much easier to learn things if there is something I want to build, so this is the command that will be built.

There is a particular code editing situation that I find myself in very often. I'm working on a bit of code, say an HTML page, and I need to add a class name that is defined in one of the project's CSS files. I can't remember the class name though. I want to open the CSS file in a split window so I can see it, but I don't need to edit it.

This is easy enough to do in Vim, simply :vsplit [path_to_css_file] and the CSS file is available in a split window.

Ahh, but there is a problem. Using :vsplit opens the CSS file in a new Vim window, makes it the active window and moves the HTML file I'm editing to the right. What I really want is to open the CSS file in a window on the right and continue editing the HTML file.

I just need the CSS file for reference.

I'll actually create two commands in this post. One to open a reference file in a vertical window to the right and leave the current window active, and a horizontal version of the same command that opens the reference file in the bottom window.

Along the way I will describe the Vim :command command and its options so you can create your own Vim commands if you need to.

The `:command` Command

That's right, the Vim command to create user defined commands is :command. You can use :command on its own in Vim to get a list of user defined commands. It is handy if you ever forget a command name you created or one you loaded from a plugin. When creating a user command :command takes the following form:

:command [args] Name actions

The new command you create has to have a name, of course, otherwise how could you call it. The name must start with a capital letter. This is a requirement of Vim and is used to keep user defined commands separate from internal Vim commands. There is one exception though, it can not be named :Next. Apparently Vim broke its own rule.

Once the command is working you can use it in Vim by entering :Name, but, you know, replacing Name with the actual command name.

I'll name these commands :Ref and :Vref to stick to the Vim convention of :split for a horizontal window and :vsplit for a vertical window. So the commands so far are:

:command Ref
:command Vref

Optional Args

The :command command takes zero or more optional arguments. The most important of these is the -nargs= argument. This lets Vim know if the command takes any arguments. The possible values it can be set to are:

0 : The command takes no arguments. This is the default, so it can be omitted entirely.
[1-9]: The command takes the specified number of arguments.
*: The command takes zero or more arguments.
+: The command takes one or more arguments.
?: The command take zero or one argument.

The commands I want to build will take a single argument, the path to the reference file to open, so I'll be using -nargs=1.

You can access the arguments in a number of ways. First, just using <args> somewhere in the actions part of the command. Second, if you need to make sure the arguments are properly escaped for use in an expression you can use <q-args. Finally, if you are going to pass the arguments to a Vim function you can use <f-args>.

Another argument that will be used in these commands will be -complete=. This argument lets Vim know what kind of tab completion is available for the command. There are over thirty different values that this can be set to. Far too many to cover here, but some of the values are buffer to complete buffer names, dir to complete directory names, help to complete help topic name and file to complete file and directory names.

The last argument that will be needed is the -bar arguments. This tells :command that the actions can contain a vertical bar | followed by additional Ex commands, or a double quote " followed by comments. I'll need two different Ex commands in these new commands, so they will need to be separated with a vertical bar.

Some of the other arguments you can supply to :command are:

-range allows the command can accept a range of lines in the current buffer to operate on.
-count allows you to supply a repeat count for the command.
-register allows you to specify a register other than the unnamed register.

For more on the available :command arguments look at :h user-commands.

With the arguments defined for the new commands we end up with:

:command -nargs=1 -complete=file -bar Ref
:command -nargs=1 -complete-file -bar Vref

All that is left is to create the actions to take when the commands are executed.

Command Action

The Vim documentation actually calls this the replacement, because it replaces your command name with the command or commands you specify here. I find actions to be a bit more intuitive. In any case, this is what you want to have happen when you enter your command into Vim.

The user command documentation doesn't say anything else about the actions, I suppose because all of the other documentation is applicable. Any Ex command can be used here to achieve the desired effect.

For my case I want to open a new window to the right or bottom with the file specified in the command, but leave the current window active. The built in :split and :vsplit Ex commands don't have the behavior I want.

I looked at the Vim documentation for :split, thinking that perhaps there was an argument that would give me the behavior I wanted. It does take a couple of arguments, but they are related to the file format, and cursor positioning when the file opens. Not really what I was looking for.

A little further down in the documentation for :split I found the splitbelow and splitright settings. If you :set splitbelow then new windows created with :split are created below the active window instead of above. The same goes for :set splitright; new windows will be created to the right.

That looked like exactly what I wanted. I can set those values in my .vimrc right before I define the commands and everything will work like I want.

While that would work I wasn't in love with the solution. That will change the default for every split window. I don't like changing the default settings if I don't have to. A little more digging the the Vim documentation near the :split docs and I found the exact right thing.

There are command modifiers for the split window commands called :rightbelow, :leftabove, :topleft and :botright. These are Ex commands, but are called modifiers because they only take another Ex command as an argument and override the splitbelow and splitright settings.

The :rightbelow modifier just executes whatever command you supply as an argument. If the supplied argument opens a split window it will open it to the right, or below, depending on the argument. So, now the commands are:

:command -nargs=1 -complete=file -bar Ref :rightbelow :split <args>
:command -nargs=1 -complete=file -bar Vref :rightbelow :vsplit <args>

The commands are almost complete. The only issue left to deal with is that the new window that is created is still made active. That is simple enough to fix, I can just add a window movement command to make the previous window active again.

My initial thought was to use the Vim window movement commands; <C-w>k to move to the upper window and <C-w>h to move to the left window. Vim didn't parse that correctly though. Apparently all of the commands have to be Ex commands.

I had to dig through Vim help topics for a bit but I found what I needed. All of the Vim window commands can be activated through the :wincmd Ex command. So, whenever you type <C-w>x you could also use :wincmd x.

The final commands, then, are as follows.

:command -nargs=1 -complete=file -bar Ref :rightbelow :split <args> | :wincmd k
:command -nargs=1 -complete=file -bar Vref :rightbelow :vsplit <args> | :wincmd l

There you have it; two brand new Vim commands. They take one argument, the path to a file, which can be <Tab> completed. They open the file in a new split window, either to the right or below the currently active window and then move to the previously active window.

I hope you enjoyed this little trip through Vim commands. There is so much flexibility available in Vim. With a little bit of effort and digging through the help files you can build your own Vim Commands to do pretty much anything you need.

Quick tmux Sessions

David Lains — Tue, 15 Jan 2019 06:32:40 +0000

I've been using tmux for a few years now. For every project I work on I create a tmux script that will start up a development environment for that project.

For a long time the tmux scripts I created just opened windows to run the various servers that the project required and nothing else. For a Rails project it would typically be a window for the Rails Server, another window for Redis, one for Sidekiq and sometimes one for Mailcatcher.

It was very handy to just run a script to have the whole environment for a project up and running, but I typically didn't interact much with the tmux session after that. Just checking server output from time to time. The rest of the time I was in Atom or the browser.

When I started using Neovim I began to spend more time in tmux. I updated my project specific tmux scripts to include an editor window along with the existing server windows.

I got so used to this way of working that I would find myself creating mini tmux sessions with just an editor window and a console window whenever I needed to do any kind of quick editing work outside of a full project. It is easy to setup a simple two window session, but why repeat the same process over and over?

Here is a short shell script that will create a simple two window tmux session given a directory path.

NAME=`basename $1`
cd $1
tmux new -s $NAME -n editor -d
tmux send-keys -t $NAME $EDITOR C-m
tmux new-window -n console -t $NAME
tmux select-window -t $NAME:1
tmux attach -t $NAME

This is just the main part of the script, the full script is commented and checks the input parameters. You can see the actual script here.

The script expects a single argument, a path to a directory. It extracts the final directory name in the path into the NAME variable. It uses this name as the tmux session name throughout the script.

After extracting the name the script changes directory to the provided path. After that it creates a new tmux session, and names the first window editor. Once the session is created the script sends a command to the tmux session to start the editor associated with the EDITOR environment variable. On my system that is set to nvim, but it could be any editor that can be started from the command line. Be aware, though, if you start a GUI based editor it will open outside of the Terminal and there won't be much use for this tmux editor window.

Now that the first window is created, named and the editor is running the script creates the second window. It simply names it console. I find it helpful to have a dedicated console window for working with Git or examining files or other tasks. Some of these tasks can be done in Neovim, but I like having a dedicated console window for some tasks.

Once the console window is created the script tells tmux to select the editor window and then attaches to the session.

And there it is. One simple script and you can have a mini tmux session running in a matter of seconds. I named the script qs, for quick session, and put it in my path. Now whenever I need to do a little bit of work, for instance in my dotfiles project, I can simply run:

qs ~/dotfiles

If you would like to use the script yourself just copy the code to a file, make sure the file is executable with chmod +x [file] and make sure your EDITOR environment variable is set to something appropriate, or change the $EDITOR reference in the script to whatever you like.