Some of my teammates have become accustomed to some bad git habits. They leave tons of uncommitted and unstashed changes on shared repos and don't clean up old branches. These kinds of behaviors can manifest in any team. We all develop Bad Coding Habits^TM. I know I have several I should do more to break.

Becoming frustrated with my team's growing problem with git etiquette, I decided to create a cron job to send a gentle reminder to my teammates to do some housekeeping. I created a bash script to send a randomized wall message on Tuesdays and Thursdays to anyone logged into our demo server. This may seem like using dynamite to catch a fish, but part of me really just wanted to figure out how to do something like this.

You Get a Message! And You Get a Message! And You Get a Message!

I knew a few things going in to this:
1. I need to send a message to all users logged into our demo server.
2. I wanted the message to not say it was specifically from me because I felt it'd be ignored.
3. I wanted to be able to send a randomized message from a list of messages.

Knowing this, I knew I had to write a cronjob (a scheduled action on a server) that executed a wall message. With this knowledge, all I had left to do was write out my messages and do a little digging into how to get a random integer in bash.

Let's take a look at the script and then go in some greater detail:

#!/bin/bash
# This script displays a message
# about good git etiquette to the user.

array=("Commit your changes early and often and before sending to QA."  
    "Good Housekeeping: Prune old branches. We got the commits!" 
    "A new branch does not mean lost work." 
    "Don't leave uncommitted or untashed changes on a repo.")

n=$((RANDOM%3+0))

echo "${array[n]}" | sudo /usr/bin/wall -n  

The script is fairly simple. It takes an array of four different messages, then determines a random integer between 0 & 3. Then it echoes out whatever message is at the random number index of the array and passes that the wall command.

A few key notes:

• When using a lot of builtin commands in a shell script, it's important to give the full path of the command (i.e., /usr/bin/wall), rather than just the command. In general, it's just better to use full paths in scripts.
• The wall command can only be sent "anonymously" as root. The -n flag indicates "no banner," so only the message itself without any other information is broadcast.

I set up a cronjob that runs as root on Tuesdays and Thursdays and executes gitreminder.sh and voila! Everyone gets a message!

So Many Typos

That being said, I end up entering a lot of commands into my terminal and now I've got a cluttered screen where all my relevant text is at the bottom. I've gotten into the habit of typing clear a lot. But this leaves room for typos...sometimes so many typos. Ugh. SO. MANY. TYPOS.

My deskmate is a 'return key' guy. He just presses return a bunch until he's got some whitespace on the screen and continues running commands. This got me thinking on how to combine these two methods to make one Super Method^TM.

Enter the Return Key Clear Shell Script

So now I looked for a solution that cleared my shell whenever I pressed the return key twice. And behold, return_key_clear.sh:

declare empty_counter=0

precmd_hook() {  
    if [[ $empty_count -gt 1 ]]; then
        /usr/bin/clear
        let empty_count=0
    fi

    let empty_count=$empty_count+1
}

preexec_hook() {  
    let empty_count=0
}

autoload -U add-zsh-hook

add-zsh-hook precmd precmd_hook  
add-zsh-hook preexec preexec_hook  

**This shell script works reliably and predictably for zsh on both macOS and Ubuntu Linux.

Update 2016-11-16 - The original version of this post used MacOS instead macOS. For this, I am eternally regretful of the internet points I lost. As we all know, they can never be regained.

This seems useful at first, but both Paul and I use iTerm2 as our terminal app and iTerm2 already provides tabbed windows and split panes. This weekend provided me with the motivation to learn tmux more fully and try it out in my workflow -- and boy am I enjoying it.

What's amazing about my change of heart is that I'm using tmux only in the most basic implementation right now. I use it to background apps and to afford myself more screen real estate on my cramped Macbook Air screen.

I now have a tmux session that handles my top and rails server screens and I don't have to worry about if my ssh connection breaks or about losing a little bit of screen real estate. I even keep a split in the session for man pages I'm looking at.

So why use it over iTerm2's splits and tabs? iTerm won't keep your session going. If you're pulling a particularly large repo or installing something big, iTerm could lose that connection and your session is over, as is that download. With tmux, you're not just getting a way to manage your multiple windows -- you're gaining a way to manage multiple sessions. And that makes a WORLD of difference once you incorporate it into your workflow.

Finally, I've found out there is no established git command that creates the repo when you attempt to push a local repo up. The repo has to have already been created. This posed a bit of an issue for me because I try to do as much of my work as possible via the command line.

Turns out, curl is perfect for just such a situation.

curl -u 'USERNAME' https://api.github.com/user/repos -d '{"name":"REPO_NAME"}'

This command will create a new repo in your profile using the github API.

1. Create a Ghost Droplet. - This was really simple! I selected my droplet image from Digital Ocean's selection of 1-Click Apps and voila! I now had a working instance of Ghost v. 0.7.9 running on Ubuntu v. 14.04.

2. Implement Site Theme. - While the normal flow of the installation is to set up your domain name, I wasn't ready to switch my current website to Ghost until I had the new one all set up and ready to push live. So I found a great Ghost theme called Stupendous and started tinkering. This was a pretty wild ride for me since I am new to Ember, so I fumbled through changing the theme a bit while I was learning. Here is where I had my first takeaway -- don't forget to restart Ghost after making changes to theme files.

3. Import Wordpress Posts. - I used the Ghost Plugin for Wordpress to export all my posts into a JSON file. Then imported my posts (and pages) into Ghost via the Labs admin section.

4. Set Up Domain Name on the Server. - First, change your nginx config (/etc/nginx/sites-available/ghost) to match your domain. Next, edit your Ghost config file (/var/www/ghost/config.js) so that the settings for production mode match your domain hostname. Don't forget to use http!

   Here's where I found myself in the weeds. Somewhere along the way of changing all the necessary settings in my Ghost and nginx config files, I really messed up. I got myself into a real pickle where no matter what I did, I had a 502 Bad Gateway error message when trying to resolve my website. Which I didn't figure out until I...

5. Set Up Domain Name on Digital Ocean & Your Registrar. - I always wince when I change any of my DNS settings and it was a well earned wince because after I changed my nameservers on my registrar and then connected my droplet to a domain within Digital Ocean's Networking settings, I anxiously awaited the cache to clear and find my worst nightmare. My site was down.

   After about two hours of trying to track down what the error in my log meant, Unable to find node index, I finally decided to scrap the droplet all together and start fresh.

Second chances are plentiful when your willing to let yourself fail. More on my second attempt at setting up Ghost in Part 2 of this series.

I hit quite a few snags along the way, mostly due to being very new to node, ember and nginx. In my experience as a web developer, I've dealt mainly with websites built on Apache servers using PHP. All of the past iterations of my own website were built using Wordpress or Typepad. So switching to Ghost was a real learning experience.

But here I am with new website banner, new CMS and a new sense of accomplishment. Yahoo!