Quick Time Machine Tip

Tip first, because the backstory ended up being longer to write out than I thought:

I’ve been using Time Machine for a few months now and recently ran into an issue where my backups were filling up too quickly. At first I just disconnected my external HDD and made a mental note to investigate the issue (haha free time), but ultimately only “made time” when it gave me a message like “hey, just wanted to let you know I’m deleting some of your older backups”.

Like hell you are, Time Machine. Like hell you are. We haven’t been in a relationship long enough for you to start telling me that I need to get rid of my things because there’s too much clutter in the house. I mean drive. I meant drive.

Aaaaanyway. It turns out there is a Quick and Easy way to get Time Machine to exclude things it really, really has no business backing up. Like, say, 50 GB worth of virtual machines. Stuff like that.

It’s actually pretty straightforward to do this and I think I can successfully capture it in two screenshots.

And now for some backstory:

As is probably obvious by now I do most of my development on a Mac. I was previously working on a 2012 Macbook Pro from work, but then when it started to have some weird issues it was supposed to be sent off to Apple, repaired, and rehomed while I got to work on a new 2015 Macbook Pro.

As with all things technology this didn’t go as smoothly as anyone would have desired. After going in over the weekend to diagnose the heat issue that wasn’t entirely the fault of the fans, I went to pick up my new 2015 Macbook Pro. While I was there asked if I could bring in the 2012 the next day, instead of dropping it off then, after making sure I could get everything on the new Macbook. Apple Genius bar said it was no problem, so hurray.

Except no hurray, because after I arrived home and turned on the new, shiny, 2015 Macbook Pro it kernel panicked on the first try. Yikes. So I restarted it, was eventually brought through the prompts that all Mac users are familiar with by now to sync all the things. Yay. And things seemed fine, for a time. Until bam. Panic. Shut down.

Ooookaaaay… so then I tried resetting the NVRAM. Rebooted. Seemed fine. Until, again, kernel panic and shut down. This happened a total of four times in the span of … maybe an hour IIRC. After that, I tried just letting the 2015 Mac idle instead of transferring my data onto it, but alas it still panicked just by being on – even when I wasn’t doing anything to it.

So I went back to the Genius Bar with the new 2015 Mac. Explained that it wasn’t the 2012 Mac they thought I’d be dropping off, but that new 2015 Mac had been kernel panicking even without me touching it. So then they tried to boot it and it didn’t boot at all, haha. They ran some hardware tests and everything passed so they tried booting it again and it still didn’t boot. So they handed me a new 2015 Macbook Pro no-(other)-questions asked. In their words “a brand new machine shouldn’t behave this way, we’ll just exchange it”.

Apple Genius bar = lovely people to work with.

Of course when the 2012 Macbook Pro started having heat issues I started to become more attentive with my backups. I didn’t use Time Machine, I just backed up my files to my Synology NAS. I figured that if and when I set up a new machine it would be the perfect time to “declutter” my environment and only install new things and set them up as I need them.

That was before I tried setting up two new environments in a week while also worrying about what would happen if my New New Macbook ended up with similar behavior problems and then I’d have to do it again.

So that’s when I decided something needed to happen and I started using Time Machine. Which brings us full circle to the Quick Tip at the top.

By the way, as for my New New Macbook Pro it is mostly problem free with the exception of some pesky networking issues…

Python Version Management with pyenv

As an aside, today I was hunting around for Python version management à la RVM and I found pyenv.

For version management it’s pretty straightforward. To install on the Mac, I just used Homebrew:

brew install pyenv

Since the version of Python on my Mac (running OS 10.10.4) is 2.7.6, I used pyenv to install 2.7.10 and 3.4.3:

pyenv install 2.7.10
pyenv install 3.4.3

A little backwards, but at this point I realized I needed to update my .bash_profile per the installation instructions:

echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bash_profile
echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bash_profile
echo 'eval "$(pyenv init -)"' >> ~/.bash_profile

Ubuntu users: according to the instructions you should use .bashrc not .bash_profile. Verify your installation instructions on the GitHub README.

If you’re new(ish) to BASH, before sourcing .bash_profile take a look at the new lines that you just added. Then, source:

source ~/.bash_profile

If you take a look where python is run, you'll see that it has changed from:

$ which python
/usr/bin/python

To:

$ which python
/Users/quinn/.pyenv/shims/python

Now a cool thing that you can do with pyenv is use .python_version file to specify what version of Python you want used with your script.

To play with this, create a .python_version file with the version number:

2.7.10

Now create a quick little Python script, myscript.py:

username = input('What is your Reddit username? ')
name = input('What is your name IRL? ')
age = input('How old are you? ')

print("Your name is ", name, ", you are ", age, " years old, and your Reddit username is ", username, ".")

When you run your script (python myscript.py) it should fail because the script is not compatible with Python 2.x. Update the .python_version file to 3.4.3 instead of 2.7.10 and re-run. This time you should be successful.

Protip: If you need to run against a version of Python that you haven’t yet installed, you can run pyenv install without any arguments from the directory with your .python_version file. This will install whatever versions of Python are specified in the file.

CLI Tricks: Navigating Around the Prompt

It’s not uncommon to need to make changes to a command after entering it in the command prompt. For example, perhaps you need to reuse a command from the history but with a small change or perhaps you need to fix a typo.

Luckily, Unix command prompts support both Emacs (default) and Vi(m) key bindings for quickly arriving at the section you need to make small edits.

Let’s take an example where you want to download a light AWS stemcell (~6 KB):

curl -L -J -O https://bosh.io/d/stemcell/bosh-aws-xen-ubuntu-trusty-go_agent

There is a typo in the above line: the path should include d/stemcells not d/stemcell. Of course this text is awkwardly placed, so what’s the best way to fix it?

Method E: Emacs Bindings

The key bindings of interest here are ^a, ^e, esc+f, and esc+b where ^ represents the ctrl key. Try the following:

1. Copy the curl statement as-is, typo and all, into your command prompt
2. Enter ^a to go to the beginning of the line
3. Enter esc+f until you reach the end of the world stemcell (should be 9 times).
4. Type in the s so stemcell becomes stemcells

At this point you can either enter ^e to go to the end of the line or Enter/Return to execute the command. Although we didn’t use it in this example, just like esc+f goes forward a word at a time, esc+b goes backward.

Caveat: make sure you don’t just hold down the esc key and keep hitting b or f. If you do, you’ll just typing b’s and f’s. You must hit esc+b or esc+b each time you want to move backward/forward a word.

Method V: Vi(m) Bindings

Since Emacs is default, in order to switch into Vi mode first run:

set -o vi

As with the previous exercise, copy the curl command into terminal with the typo. The key bindings of interest here are: ^, $, b, e, and w.

1. Copy the curl statement as-is, typo and all, into your command prompt
2. Hit esc to go into command mode
3. Enter ^ to go to the beginning of the line
4. Enter 16e, which will place the cursor at the end of the world stemcell.
5. Hit a to enter insert mode next to the last l in stemcell
6. Type in the s so stemcell becomes stemcells

At this point you can either use esc (to go back into command mode) and enter $ to go to the end of the line or Enter/Return to execute the command. Note that the command can be run in either command or insert mode.

If you wish to return to Emacs mode at any time, enter:

set -o emacs

On S&W blog

Git-fu: How to avoid pulling a muscle while making pull requests

Even if you’re still new to coding, you’ve probably heard people talk about making pull requests. Maybe it was just a passing conversion:

You: That link is broken.
Someone: Just make a pull request.

Depending on your level of Git-Fu, you might be left wondering: “what the heck is a pull request?”

What is a pull request

Simply put, a pull request is what you do when you want to edit code in a repository that you do not have access to. For example, there are many open source projects where you can view the code, but since you are not a collaborator you cannot directly commit any code changes. So if you notice a problem, e.g. a broken path or an obscure error message, you cannot change it.

To make the changes, you submit what is called a pull request. The TL;DR version is that you are effectively checking out the code, editing it, and then submitting it for review rather than committing it directly to the project’s repository. The project collaborators can then review the suggested edits and choose whether or not to merge the code.

Making your edits

Since the whole point of a pull request is to touch code that isn’t yours, you have to fork the repository. Forking the repository puts a copy of the code in your repository

1. Fork the repository by clicking the fork button:
   
2. Clone your forked repository: git clone <forked project path>
3. Checkout a new branch: git checkout -b newBranch
4. Do an initial commit before making your changes: git push origin newBranch
5. Make your edits
6. Run git diff to make sure there were additional edits you did not intend
7. Add, commit, and push your edits to your branch. If you do not want to add all the files, you can add individual files with git add <file name>. Remember, to push the updates to your branch use git push origin newBranch.

As a side note for git diff, occasionally you may find that more code edits occurred than you intended to make. As an easy example, you may have a linting/formatting plugin installed for your text editor. If the plugin “cleans up” the code in a way you did not expect, the only way you would easily see these edits is by running git diff. Depending on the circumstances of your pull request, or how familiar you are with the project in general, you may or may not want to keep these edits.

Creating the pull request

Go back to the main project page – not your forked repository/branch. When you go to create your pull request on GitHub, the software should actually detect that you forked the project and prompt you to “Compare & pull request”:

Here you can see that it pulled the correct branch from my forked repository. If you don’t see this dialog box, do the following:

1. Click “Pull Requests” on the left nav bar:
   
2. Click big, green “New pull request” button:
   
3. Select the correct branch(es) from the drop down menus:
   

Regardless of which method you choose, once you have reached this step you can see your last commit message and an option to add additional details:

Then you can just click “Create pull request” to submit your changes.

Git-fu: Branch (-es, -ing)

When you’re new to the programming world, you may hear a word like branches and think of something like this:

Contextually, though, you know something is awry. Why would that have anything to do with your work?

Hint: It doesn’t.

Except for that whole “save the planet” thing.

…Seriously, though, we should take care of our environment. We live here after all.

Quick “How To” for branching with Git

As a new programmer, a lot of what I’ve done so far has been in my own GitHub repo with no one touching it but me. (Question: Who wants to touch the newbie’s code? Answer: No one. Duh.) As this is the case, it is really easy to get into the bad habit of pushing to the master branch. All the time. Well, most of the time. Perhaps a little unreliably, but that’s no big deal, right? I mean, you’ll just push it later. Maybe. When you remember and get around to it.

So yes. Really bad habits.

In an effort to break this habit, I decided to start making branches.

What is a branch?

If you want to read a bit about it and look at pretty diagrams, I recommend hopping over to git-scm’s “Git Branching – What a Branch Is” page. For now, I’ll just provide a TL;DR version:

• By default in git you have a master branch, which is where you I have been pushing your my code this entire time.
• When you create a branch, you can think of it as a copy of the code. Initially, both the master and newBranch are identical.
• When you push edits to newBranch, master is unaffected.
• When you want to include the newBranch edits in master, you merge the two branches.

Sounds like extra work…

…and it is, especially when your development team has only one member and that member is you, newbie :)

When used properly the main benefits, as I understand them, are:

• Branches are only merged to master when their code is working. Therefore master is always working. Don’t we all wish that were a thing?
• To get ready for the leap to a development team of 2+ developers, you’re going to want to branch so that your edits don’t mess up developer N’s edits (for N < numberOf(otherDevelopers)). (Likewise you don't want anyone else working on what you're trying to work on, right?)

So what do I do?

If you want to take this next step, then it's as easy as 1, 2, 3 (…4, 5, 6…):

1. Create the new branch. If you're a GitHub user, you can do this in the web UI. Or you can do this in the command line with git checkout -b newBranch
2. Edit some code.
3. Push some code.
4. Rinse, lather, repeat until the code is where you want it.
5. Switch back to the master branch: git checkout master
6. Optional (only as long as you're going solo): git pull origin master
7. Merge the new branch into master locally: git merge newBranch
8. Push the changes: git push origin master
9. Delete the branch: git branch -d newBranch
10. Push the changes (deleted branch) via git: git push origin --delete newBranch

That's it – you have now taken the next step into glory. Pretty awesome, right?

Yeah it is! I’m Super Programmer!

Easy, easy. Just be careful not to make it into the next episode of “Branching Gone Wrong”, ok? Remember:

• Don’t have long running branches. From one of my mentors:

“The longer you have the branch – usually – the further it diverges from master. So, the greater chance of merge conflicts, and of other changes making their way to master that are incompatible with your long-running one, but that’s not noticed until The Great Merging, which by now is An Event because of the sheer amount of things that will change when it happens.”

• Make sure to clean up after yourself and delete branches after they have been merged!

Reference: Git Branching Commands

• git status : Outputs your current branch as well as if you have any uncommitted changes.
• git checkout -b newBranch : Creates a new branch named newBranch and switches your current working branch to newBranch
• git checkout branchName : Switches your current working branch to the branch named branchName
• git branch : Lists all branches, current branch indicated with an *
  • git branch -v : Lists all branches with the last commit ID and message, current branch indicated with an * (-vv includes upstream branch)
  • git branch --merged : Lists all branches merged with your current branch, current branch indicated with an *
  • git branch --no-merged : Lists all branches not merged with your current branch, current branch indicated with an *
  • git branch -d branchName : Deletes the branch branchName locally if it has been successfully merged. If not, returns an error.
  • git branch -m currentName newName : Moves/Renames branch currentName to newName. If unspecified, currentName defaults to your current branch.
• git push origin --delete branchName: Deletes branch branchName from GitHub (as opposed to git branch -d, which only deletes the branch locally).
  • git push origin :branchName : Same as above – the : prefix means “delete”. I personally don’t use this method because I don’t want to get myself in a situation where I have trained my fingers to quickly, accidentally, delete things I don’t actually intend to delete.

Update (1/8): Interactive site to learn Git Branching

Markdown for quasi-Beginners

Recently, we wrote all of our slides in Markdown and used mdpress at my new job (see post here), which was my official dive into Markdown. Prior to that, my exposure had been pretty limited. Since Markdown is commonly used, I’m going to do a quick run through.

The What and Why

Markdown is both a syntax and a tool. A Markdown file, which has the extension .md, is written in Markdown syntax so the Markdown tool can convert it to HTML. The idea behind Markdown is that it’s easier and faster than writing HTML and the source file (*.md) is more human-readable than an HTML file. Personally, I tend to only run into Markdown when looking through code on GitHub – specifically the Readme and related documentation files that programmers include with their applications.

Originally written in 2004, Markdown has been gaining a smattering of followers who use it for more than just writing plain text documents. As mentioned, I recently also encountered it as a tool for writing presentation slides, but a quick search on the net will yield other applictions as well, including various blog platforms, simple to-do lists, full fledged websites, or even resumés. (Note: I haven’t used most/all of these tools, I am simply using them as examples after a quick Google search.)

Why should I care?

You may be looking at all that and thinking “HTML isn’t that hard to read… I don’t know if I really care about all this”. As with many “on the job” tools, your initial exposure (and, in fact, perhaps the only reason you’re reading this post) may only be because you found yourself in need of a quick understanding and how-to for a project at work or school. Don’t feel left out! That’s how I got here :)

The “Meat and Potatoes”

Markdown syntax is very, very easy. In fact so easy that you might not even feel comfortable thinking of it as “syntax”. To help myself out, I only needed to remind myself of three rules:

• All roads lead to Rome
• There are multiple flavors of Markdown
• If all else fails, use HTML

All roads lead to Rome

There is always more than one way to do something and the same is true of Markdown. To get you used to this idea, let’s take a look at how to make a header in Markdown (HTML tag <h1>). You can use either of the following:

#H1 Heading

H1 Heading
==========

There are also multiple ways to make bold, italic, and bold+italic text:

*Italics*
_Also Italics_

**Bold**
__Still Bold__

***Bold and Italics***
**_You get the idea..._**

Since there are a plethora of tutorials available on the web, rather than rehash everything here I’m providing some links at the bottom of the post. You may notice that not all tutorials cover all variations of the syntax. Don’t be confused! Part of this is brevity, but another part brings me to my second point:

There are multiple flavors of Markdown

Although “the basics” of Markdown are standard, there are some variations that provide additional functionality. One example I make frequent use of is syntax highlighting. In Markdown, you can indicate code using either of the following:

`This` word is code formatted in line.

```
This would be a block of code,
two lines.
```

Now let’s say you want to document a bit of Javascript, Ruby, or even bash in your Markdown file. You can use the above, but for added readability you can also make use of the syntax highlighting feature if your flavor of Markdown supports it. When available, you would specify the language of interest after the first set of backticks:

```bash
$ mkdir -p workspace/apps
$ cd workspace/apps
$ git clone https://github.com/cloudfoundry-community/cf-env.git
Cloning into 'cf-env'...
remote: Reusing existing pack: 71, done.
remote: Total 71 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (71/71), done.
```

This feature is especially helpful when posting long output. Again for brevity, I’m not going to rehash all the possible specialized syntax here, but the Wikipedia article does list the most common flavors. If you are using a specific flavor of Markdown, make sure to check what additional features they offer (if any). If syntax highlighting is available, make sure you also check which languages the flavor supports.

If all else fails, use HTML

I was so relieved/happy when I discovered this. You may have something that you aren’t quickly finding the syntax for or that isn’t explicitly available in Markdown. Never fear! Since Markdown converts to HTML, HTML code is left as-is. As a quick example, let me show you how to make a section of blockquoted text. Now, there is valid Markdown syntax for that:

>This is a blockquote.

But let’s say you can’t find the syntax for some reason and would just like to put in the text and move on. You can still use:

<blockquote>This is a blockquote.</blockquote>

You can also mix HTML tags and Markdown syntax. For example, if you wanted to force where the line break occurred in your blockquote, rather than let it wrap around, you could do this:

>This is a blockquote, <br />
with a second line.

One final note

Although I usually prefer command line text editors, when I am working on Markdown files I usually use Atom (available for Mac and Windows). The main reason is because it has a built-in preview pane that allows you to see how your file will render while you edit it. As an added bonus, there are also many Markdown packages that can be added to Atom to make the job even easier.

Resources you may find helpful

What and why of Markdown:

• Why Markdown?
• What is Markdown?
• Markdown Wikipedia Article

Some Markdown Tutorials

• GitHub Markdown
• Markdown Cheatsheet
• Markdown Tutorial
• Markdown Project @ Daring Fireball
• Markdown Primer @ The Unofficial Apple Weblog

This article has also been posted on my work blog, which uses one of the blog platforms that utilizes Markdown. ツ

I want someone at GitHub to marry me

Currently, my “development areas” consist of two places: my Macbook Air for 90%+ of what I do and a Windows laptop that I use to play with C++ (it should be noted the latter has a primary purpose as a gaming laptop, though). I’m ok with this, because honestly due to the jobs I’ve held in the past, I’ve worked almost exclusively in Unix/Unix based operating systems.

I also have a confession: I love terminal, but I hate Windows cmd. I do. I think part of my hatred stems from the fact that I am so used to Unix commands that I don’t like flipping back and forth between the just ever so slightly different but different enough (and occasionally majorly different) commands. The other part is I don’t really like that kind of “nostalgia” when I’m trying to work – I feel like I’m working on the family computer from when I was in grade school (my family had one of these bad boys until 1999). I’ve gone so far as to look into C++ development on Mac, just so I can keep terminal and avoid cmd.

But no longer.

Over the weekend I came across this.

Holy. Space balls.

From Stark and Wayne’s post:

These “optional UNIX tools” is a modest assortment of, say, 144 of the tools you wish Windows had in its own command prompt, without requiring you to install CYGWIN or maintain a separate VM.

Warning – as the dialog box states: “Only use this option if you understand the implications.” Fair enough.

Oh I understand the implications. This is amazing. Thank you, GitHub, from the bottom of my cmd tortured soul.

You know how to reach me about that marriage proposal thing. I’m only half kidding (but don’t tell my fiancée that)!