Babashka is amazing. It’s replaced Bash for 99.999% of my scripting needs. I thought it might be useful to describe my approach to writing Babashka scripts and compare it to how I used to write Bash.

In my terminal, text often flies by. Things like log files, thread dumps, report output, etc. All of these are comprised of text, but not all of that text is equally important. This is the story of how I got my computer to highlight the important bits for me.

The last time I wrote about using Vim to write Clojure, I had just started using it professionally. Now I’m at my second Clojure job and I am still enjoying the its power, combined with the speed of Vim. However, in contrast to the last update, which was incremental to my first post, quite a few things about my setup have changed in the past few years.

When I wrote about developing Clojure in Vim for the first time, I was still early in my journey. For years, I’d only been able to tinker with Clojure in my free time and I was never able to really use it for anything large. Well, now I’m 5 or so months into using it full time and I’m really enjoying the development experience. So I thought I’d update my previous post with what my Vim configuration looks like now.

In my new job, I’ve switched each project being a unique combination of git repositories1 to all projects being in just a few repositories. For instance, my primary codebase consists of two repositories, one for the frontend and one for the backend. As time progresses, I work on multiple (mostly) independent projects in each repo, each one on its own branch. Each project requires a different constellation of files, sometimes organized in radically different ways in my Vim tabs.

When I wrote about tmux for the first time, I was just getting into the idea of nesting sessions. I ran a local tmux session that wrapped remote tmux sessions for more than a year before I switched it up again. I added another level. Background # I originally started nesting tmux sessions so that I wouldn’t have to use tabs in Terminal to keep track of different remote tmux sessions.

I’ve been experimenting with Clojure lately. A few of my coworkers had begun the discovery process as well, so I suggested that we have a weekly show-and-tell, because a little accountability and audience can turn wishes into action. Naturally, I looked around for plug-ins that would be of use in my editor of choice. Here’s what I have installed: vim-clojure-static - Syntax highlighting and indentation vim-fireplace - Slick repl integration and hot code reload rainbow_parentheses.

Since I work on remote systems all the time, I use SCP repeatedly to transfer files around. One of the more cumbersome tasks is specifying the remote file or directory location. So I wrote a helper script to make it easier. It’s called scptarget, and it generates targets for SCP, either the source or the destination. For instance, if I want to copy a file down from a remote server, I run scptarget like this and copy the output:

I’ve been using git_backup to back up the websites I run for quite a while now. It works well and I only need to scan the daily cron emails to see if the backup went well or if there were any odd files changed the day before. One thing that I didn’t expect when I started using it was how it would enable developing those websites in a sandbox without any danger of affecting the production instances.

Update: I refined my configuration. See it here. For the longest time, I was a screen user. Then, a little while ago, I discovered tmux, the next generation terminal multiplexer. Not only is it easier to search for on google, it has a rich and consistent configuration language. I’ve figured out a rather unique tmux configuration and I wanted to share it. Background # Originally, I just used tmux on remote servers to control several windows.

Problem # I copy and paste all the time. Most of the time, I copy short pieces of information that are too long to type (I’m lazy) but too short to setup anything more complex (wget, scp, etc.). For a while, this was fine as most of my copy targets were either local to my system or in a terminal window on a remote server. However, as I increased my use of splits in tmux and windows in vim, highlighting remote text with my mouse became horribly cumbersome.

I have quite a few dotfiles. I have so many that keeping them in sync is impossible with conventional methods. So, I turned to my old friend: version control. For a while, I kept them in subversion at work. This worked well as that was where I spent most of my time. Recently, however, I’ve wanted those same dotfiles to be available at home and other non-work areas. So, I investigated moving them over to a git repository.

I’ve been using git for a while now, and I’m just getting to the point where I can think in it. It’s the same as learning a new spoken language. I took three years of Spanish in high school, so I knew most of the rules and could translate back and forth to English, but I never really learned to think in Spanish (as opposed to thinking in English and then quickly translating).

For a while now, I’ve been backing up the few WordPress blogs that I run for various people with a very simple script that followed this algorithm: Copy files to a temporary directory. Dump the MySQL data into a file in that directory. Tarball it up. Scp that file to another server that I run. At the time, I did this because it was the simplest thing that could possibly work.

Being the data and visualization nerd that I am, I’ve been delving into R on occasion. For this purpose, I am using R.app on my Mac. To start it up for a certain working directory (to keep different projects separate), I run “open -a R <working dir>". This worked great until I noticed that my history wasn’t getting saved to the .Rhistory file in each directory. When I use the command line R executable it does, but not in the R.

I’m always looking for ways to improve myself as a programmer. It usually involves something fun, but after reading this post, I think my new area of improvement is to stop increasing my technical debt. From a related post from Steve McConnell: Other debt accumulates from taking hundreds or thousands of small shortcuts--generic variable names, sparse comments, creating one class in a case where you should create two, not following coding conventions, and so on.

Well, I didn’t get much of a chance to blog about the NDWall milestone 2 before it flew past this last Saturday. Dave and I agreed a few weeks ago that milestone 2 would include the following features: Add a configuration/settings area for the application. The keys are: Display Name, Username, Password, URL Move the downloading of new messages into a thread so that it happens in thebackground. We set the deadline for this milestone to be last Saturday, the 17th of January.

Just after 1:30PM today, I finished up my implementation of the first milestone of the NDWall project. The best part was trying to figure out to construct the request to post new messages. Here are a few screen shots of the app: It really doesn’t do much other than the two required features. I haven’t profiled it to make sure there are no memory leaks, but I’ll do that soon. The manual memory management of the iPhone is definitely odd for someone like me who’s done mostly garbage collected languages in his career.

The best way to learn a new programming language/environment is to make something practical with it. To that end, Dave and I started a little side project called (at this point) NDWall. It’s an implementation of a “wall” where new messages can be posted and the 10 most recent can be viewed. The server-side api is very simple. Just two methods (GET and POST) on the api resource. The data transport is JSON, the lingua franca of web APIs.

One of the things that’s been on my mind recently has been optimizing my work life so that I can either spend less time doing the same stuff or accomplish more in the same amount of time. In the back of my head has always been Joel’s test, and in my feed reader the other day, I found a similar list; the humorously titled “Your Doing it Wrong if…” I had to laugh hard at the fourth entry on that list, as I have written my own database abstraction layer (hereafter DAL).

What Ruby on Rails is to web programming, and Capistrano is to deployment, now Castanaut is to screencasts: #!/usr/bin/env castanaut plugin "safari" plugin "mousepose" plugin "ishowu" launch "Mousepose" launch "Safari", at(20, 40, 1024, 768) url "http://gadgets.inventivelabs.com.au" ishowu_set_region at(4, 24, 1056, 800) ishowu_start_recording while_saying " Tabulate is a bookmarklet developed by Inventive Labs. You use it to open links on a web page. It's meant for iPhones, but we'll demonstrate it in Safari 3.

I was handling a customer support request today and it read something like this: I changed a setting and now I get an error. What's wrong? My knee-jerk reaction was to think, "Well, then what was the error?!?" You see, I'm a problem solver. I love to dismantle things and figure out why something isn't working properly. To me, the first step toward the solution is to figure out what the problem is.

With insight into why people don’t read manuals and why features sell products: http://www.codinghorror.com/blog/archives/001048.html Also: http://www.jnd.org/dn.mss/simplicity_is_highly.html http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html From the Norman essay: Logic and reason, I have to keep explaining, are wonderful virtues, but they are irrelevant in describing human behavior. Trying to prove a point through intelligent, reasonable argumentation is what I call the “engineer’s fallacy.” (Also, the “economist’s fallacy.”) We have to design for the way people really behave, not as engineers or economists would prefer them to behave.