Why do we use git; what problem are we trying to solve?

• Revert - You want to be able to confidently undo changes that break your code.
• Track changes - You want to be able to figure out what was necessary to implement a feature, or how various code is related to other code. Mostly, you want to know why somebody chose to write a particular piece of code.

There are obviously lots of other great features, but these two will suffice for the purposes of this post.

Formative Moments

I made two very memorable mistakes with git in my first few months as a software developer.

The first related to a feature I had been working on for several days. I was in the habit of making fairly atomic commits along with WIP (Work In Progress) commits at the end of the day. I'm not sure where my pair was when this went down, but at some point, I ended up merging my branch into master and pushing. Within half an hour or so, a chat room blew up with questions about merge commits and WIP commits in master. I was terribly embarrassed, but another developer helped explain what I should have done (squash and rebase).

The second offense was worse. I had pushed code to master that broke something. Upon seeing this, I immediately knew what the problem was and decided to fix it. My solution was to fix the tests and code, amend the commit, and (force) push back to master. This process took maybe five minutes and I figured nobody would be the wiser. Of course the chat quickly blew up again. This time somebody was wondering why they were unable to push to master, having rebased minutes before. Again, I had to identify myself as the culprit.

These were dumb things in retrospect, but you can bet that I learned my lesson. Don't be like me. Follow best practices and your colleagues won't hate you.

Some best-practices

Imagine you're working on a feature branch and are ready to submit a PR or however you prefer to submit your code for review.

• rebase to keep your branch up to date. This is helpful to do frequently while working on a branch to ensure you have the latest commits from master. Make sure you do it before creating a PR or merging into master. I almost always complain when I see a PR for a branch that is "3 commits ahead and 30 commits behind" master*.
• Squash many of your commits. This one is slightly contentious, but need not be. Remember that the whole point of your commits is to tell a coherent story (and be able to easily revert if something goes wrong). That means that commits destined for master should not have WIP in them and should not include stuff like "fixed more typos." Keep track of that stuff however you want when working on a branch, but squash them before the make it to master.** I like to squash through an interactive rebase. On the off chance that you do need to revert a commit, having one commit per feature will ensure that you can revert the whole thing without breaking master or dealing with merge commits.
• 50/72: Message is 50 chars, description wraps at 72 - Here is one of about a thousand blog posts on why the 50/72 rule of git commits makes sense. Lots of tooling is built around commit messages looking a certain way. It's built into my tooling so I don't even have to think about it. One important side note here is that you should really add comments to commits. There is plenty of room to explain why you made certain choices or any other useful context.
• Get your gross merge commits out of my master branch. If you follow the previous points then your PR will be neat and tidy and ahead of master. There is no reason for a merge commit. If you're using Github then you can just "Rebase and Merge" or if you're going cowboy-style then you can just merge your branch into master. Get that: git merge my-branch won't even create a merge commit. It's like git telling you that you're doing it right.

Finally

“Code needs to work today just once, but needs to be easy to change forever.” -Sandi Metz

The audience for your git commit history, like your code itself, is your future self and your future colleagues. Make it easy on them. These suggestions may seem petty and annoying at first, but are really pretty easy to get used to. The benefits far outweigh any cost. Alias git blame to git praise if you have to.

* An unnamed collaborator on a project once merged (his own) PR that was in this 3 ahead, 30 behind state. He ended up merging in some commit from weeks before that broke production and was a nightmare to track down. Don't be "him."

** Sometimes people think that they need to track every single commit, change, and dead end as a way of "telling the truth" or preserving context. I argue that a clean commit history (before changes make it to master) tells a better story. If you are worried about preserving context for decisions, then spend some extra time on the commit message and tell that story explicitly. Now, once a commit is in master then the "telling the truth" argument makes sense.

* This post is how to remote. As for why, maybe I'll cover that in the future.

Why you should listen to me

I started working at an all remote company two years ago. We have since merged with an onsite ("remote-friendly") company and later been enveloped by a huge corporation. Each step along the way saw the workplace become less friendly to our remote team. This post covers some of the things I have learned.

Complaints and Difficulties

These are a few issues that often come up as obstacles to effective remote work

nobody will do any work

This is a people problem. You do not need to see your engineering team sitting at their desks to know they are working. If there is an issue with the work they are producing then deal with that. Solve the problem at its root. (Hint: not being in the office likely isn't the root of the problem.)

face-to-face is the only way to communicate

I can only have a relationship with people I know "irl"

meetings only work in-person

These are all fallacious arguments and the tools I outline below will help mitigate them.

Can you be Agile?!

People > Process - Do not take this as petulance, I truly believe it. Rigid corporate waterfall "Big-A" agile rituals can be shaped to work for remote teams, but maybe this is a good opportunity to investigate how much value they are really adding. :)

Tooling

I have opinions about tooling and enumerate them here.

Remote-First vs. Remote-Friendly

Remote-first refers to an organization that prioritizes remote employees, relationships, and communication. While all-remote companies are remote-first by default, companies split between an office and remote can still work in a remote-first style by following a few guidelines.

Remote-first companies handle meetings and company-wide communication using the tooling that the remote employees use. This can include slack, skype/hangouts, and (gasp!) email. A meeting split between in-office and remote should have each participant calling in from their own computer, even if people in the office are at desks next to each other. This sets the meeting up for success by giving the same communication tools to everyone in the meeting. You wouldn't encourage half the people at an in-person meeting have a private text message chain; think of this as the remote analog.

Your meeting cannot be a conference room with half the team and then a camera "for the remotes" to call in and watch. That makes the remote team effectively an afterthought and thus contradicts the remote-first ethos.

Remote-first in a mixed environment is difficult as it requires the on-site people to always keep their remote team members in mind. Some in-office conversations lead to involving a colleague because they are easy to find at their desk. With remote team members, these should be brought online to the correct forum for full-team communication. This helps spread context and include insights from the remote team members.

Remote-friendly describes a company with a mostly in-person culture, but some remote employees. Often, some of those employees will have a desk, but work remotely a few days per week. The key difference is in communication and culture. Many of the considerations of remote-first are ignored. As more communication happens in the office, the remote team members start to lose context. This may work for a company that is mostly colocated.

Considerations:

Be overly clear in all things

Communicating (especially in writing) is difficult! As the primary form of communication on remote teams, we must be careful to explain ourselves clearly. Another way to ensure clear communication is to reach out for clarification via video; a few minutes of conversation can quickly clarify miscommunication. Both sides of any communication are responsible for this final clarity and should be empowered to instigate clarification.

Trust

Working remotely requires trust. Employees need to trust management and management must trust their reports. This applies anywhere, but I've seen trust problems blamed on remote. The key here is opening yourself to the vulnerability of trusting your colleagues and making sure that hire people you trust. If you don't trust somebody to do high-quality work then why is that person working for you?

Trust issues are people problems and not related to process.

Conway's Law

Conway's Law is a thing although it is not limited to remote teams. Take it into account or avoid it at your peril.

Onsites

Bring your remote team together periodically. The advice in this post will help with a healthy and productive remote environment, but meeting in person is still a great way to make the team stronger.

Happy Hour

Remote happy hours work. Schedule some time at the end of the day, grab your favorite beverage, and chat with your colleagues. You'll get over the weirdness of drinking a beer by yourself and laughing at your computer because you're not by yourself!

Finally, a list of Dos and Don'ts

Dos

• encourage (or at least don't stifle) some light-hearted banter in meetings
• pair frequently
• take an interest in your colleagues' lives
• consciously leave room in conversations for people who don't feel comfortable interrupting you
• if you're sharing a screen then only share what people need to see (one application window ought to do it)
• use your video camera **
• overcommunicate
• assume the best about your colleagues' intentions

Don'ts

• "ghost" by muting both video and audio
• assume that somebody "got" your humor/sarcasm/ribbing/subtle undertones
• differentiate remote employees with demeaning names like "REMOTE," "TV Land," etc.
• treat remote team members differently at all

** I am shy and can sometimes be quiet in conversations. By keeping the video on, I show others that I am engaged. Also, leaving it vid-muted is just rude.

Wrapup

The above-mentioned observations and recommendations can help create an environment where a team can come together comfortably and on even footing. Prescriptions from a blog post will not necessarily apply to your organization, but following the spirit of this post will foster strong remote company culture. The biggest peril of remote work is employees feeling disconnected from each other or left out of the culture and communication in the office. The computer can be a personal shield while reducing your colleagues to pixels; try to explicitly practice empathy with all of your colleagues.

Learn the rules well so you can break them properly

This post attempts to break down how or when to "properly" break some specific rules.

Sandi Metz has four rules (or five or six) for writing Ruby (and Rails) code

• Classes can be no longer than one hundred lines of code.
• Methods can be no longer than five lines of code.
• Pass no more than four parameters into a method. Hash options are parameters.
• Controllers can instantiate only one object. Therefore, views can only know about one instance variable and views should only send messages to that object (@object.collaborator.value is not allowed).

She mentions in this podcast that people frequently quote her rules while forgetting the most important one:

The [last] rule is that you can break any of [the others], as long as you can get your pair to agree.

She goes on:

Why is it that we're such cargo-culters about things?

That's the rule that people forget!

This is a beautiful reason to break a rule. In writing code, you and your pair are codifying the logic of the domain. The most important thing is to keep that code easy for others to understand and modify as the demands of the domain change. That is why Sandi's rules can be so helpful; they make it harder for you to write complex, difficult-to-understand code. However, these rules do not always apply and there are valid reasons to break them.

Working with a pair or code-reviewer is great because together, the team can write better code.

If you have a strong and empathetic working relationship your pair then you will be able to make good decisions together. These rules are heuristics to prompt discussion about whether a particular choice is "good." As professionals, we must be confident in breaking these rules, but only with good reason: we must convince our pair.

Note:
I mostly write this blog for myself. Writing this post was a lot of fun for me in that I went back and listened to some old podcast episodes, watched the conference talk, and then spent a bunch of time figuring out what I actually wanted to say. I highly recommend checking out the links below. Those people are smarter than me and have great insight. If you come to different or other conclusions then feel free to reach out. I love talking about this stuff!

• Greater than code episode with Sandi Metz and Katrina Owen
• Sandi Metz conference talk re: the rules
• Bikeshed episode with Sandi Metz

This post is aimed at comfortable resort skiers looking to expand their skiing horizons. Most of this applies equally to splitboarding. If you're going to splitboard then my best advice is to practice with your gear a lot. Break the stereotype of everyone waiting on the snowboarder: it can be done!

A Word about Safety

Backcountry skiing is dangerous. It takes some of the risks of resort skiing (e.g. tearing your ACL), and adds in the difficulty of those issues in the wilderness. The backcountry also introduces/increases the exposure to avalanches. The training and safety equipment I'm about to describe is mandatory and non-negotiable.

Avalanche Education

Courses

• If you live on Colorado's Front Range then I can't recommend Friends of Berthoud Pass enough. I volunteer with them so I should recommend them, but I would anyway. You can go to a free three hour Avalanche Awareness classroom session that will give you the basics how to stay safe in the backcountry. They also run on-snow sessions where you can actually play in the snow! Either way, they are a great resource and an excellent way to get more out of your Level I.
• Take a Level I avalanche course. You'll spend time both in the classroom and outside, touring around, digging snow pits, and skiing. Ask lots of questions about snow and avalanches as well as touring in general.

Books

If you really want to get the most out of your Level I then do the FOBP class and read some of these books.

• Staying Alive in Avalanche Terrain, by Bruce Tremper is my favorite book on Avalanches and Snow Science. It could be a little heavy, but if you like to nerd out on this stuff then you'll be into it. Read this before your Level I, and you'll be well-prepared and able to really take advantage.
• Snow Sense, by Jill Fredston and Doug Fesler is less physically intimidating(i.e. long), but still packed with great information. A classic, you can't go wrong with this book.
• Avalanche Essentials, also by Bruce Tremper is newer and aimed more at beginners than Staying Alive. I am slightly less familiar with this one, but wouldn't hesitate to recommend it.

Avalanche Forecast

In Colorado, we use the Colorado Avalanche Information Center(CAIC). I check this site daily from sometime in October until the snow is isothermal in the spring. It's a great way to stay on top of what the snow is doing and how that changes.

Gear

Avalanche Safety Gear

Beacon, Shovel, and Probe are mandatory for travel in avalanche terrain.

• Beacon - Get a modern, three-antenna beacon.
• Shovel - My partners all use metal-bladed shovels
• Probe - Eh, these are pretty straightforward, but one that locks automatically when fully extended is way better than one that requires fiddling
• Airbag Pack - These seem to work well although they are still new enough that we lack a lot of good statistics. Unfortuunately they're also pretty expensive.

Pro tip: Practice things like quickly deploying your shovel and probe. It sounds silly, but practice is important. Think "slow is fast"

Ski Touring Gear

@amention And using dukes as a quiver of one sucks both ways

— Mike Bannister (@MikeBannister6) October 24, 2016

As a rule, gear that works well at the resort doesn't work well in the backcountry and vice-versa. This pretty much means buying a whole new setup of boots, bindings, and skis. The good news is that the used market for this stuff has gotten a lot better in the past few years and even new gear has gotten a lot more affordable. Sadly, where to buy backcountry skiing gear is a topic for another time.

• Skis - This is certainly up to personal preference, btu I'm lazy so I like my skis to be light. A 120 underfoot, full-sidewall ski is sweet at the resort, but I like to keep my backcountry stuff light.
• Bindings - Again, some people tour with heavy things, but it's not worth it. Don't get plate-style bindings (e.g. Marker Dukes). You'll be much happier with a dynafit-style. These have two pins at the toe of the boot that lock into special metal fittings on your boots and let you tour without lifting up the entire binding plate and heel on every step.
• Boots - Focus on walk mode here. some boots have a walk mode that makes them feel like a running shoe while some seem no different than your plug race boots. Go with the former and be happy. Getting ready for the 2016-2017 winter I'll easily recommend the La Sportiva Spectre/Sparkle boots. There is a new version out, but the old ones would be fine too. These are my go-to wintertime boots because they are light, have a great walk mode, and are reasonably stiff on the descent. Best of all, they're cheaper than a lot of the competition.
• Poles - Fixed-length poles are coming back into fashion for touring right now. Use whatever works for you.
• Pack - I already mentioned airbag packs. Go with one of those if you can afford it. Otherwise, I like a pack that has good "A-Frame" carry (bascially lets you strap your skis to the sides of the pack) and a special pouch for your avy gear. The pouch makes it easy to make sure that your gear is always in the pack and that you can get it out quickly.
• Clothes - Your'e going to get hot touring. In Colorado, I almost always wear softshell pants and jackets because the breath well and I run hot. Make sure you have clothing that works for aerobic exercise as well as skiing down. Get good at adding/dropping layers as necessary.

Other Resources

• Wildsnow is a great blog covering everything bacountry skiing. Read it.
• G3 has a bunch of great short videos out. Follow their tips and you'll skip a lot of the heartache of a beginner backcountry skier.

learn to use vim/tmux

Until something better comes along, learn to use vim and tmux if you want to pair remotely. There is defnitely a steep learning curve so remember to use good pairing practice and support people who are new to the tools. The difficulty of learning is worth it; this combination is instantaneous. If you have used screensharing software in the past then imagine sharing your screen, but not having it be terrible. Instead of trying to send a video of your 27" monitor, you only need to know which characters to put where on the screen. It's blazing-fast and looks good for everybody. Anybody connected to the tmux session can watch or drive the action as if it was on your own computer. Screenhero might be ok in a pinch, but you'll hate life if you try to use it every day.

slack (or whatever chat app you choose)

This is how you are going to do much of your communication. Here are a few hints on how to use it:

• Use the right channels for the right tasks (and create new ones if you need to) keep the cat gifs where they belong and the firefighting channel clear for fighting fires.
• Don't @everyone unless you're telling folks to go home for the week. If you have something that has to go to everyone (as opposed to, say, people currently in the channel) use email.

video chat

It doesn't matter what tool you use, but you should be video chatting frequently. I've had good luck with keeping both google hangouts and Skype on deck in case somebody on the team is having trouble with one source. When remote pairing, I like to have my tmux/vim session on a big monitor and a video chat going somewhere else. It'll often be covered up with a browser or documentation or something, but it is nice to be able to look at your pair when you are talking to them.

email

With all these awesome communication tools, you shouldn't need to email very much! Email can be a great async way to share information that people need to hear. Don't abuse it or emails will just get ignored.

calendar

Keep a calendar of when people are going to be available. You should be able to see this from slack, but it is good to know if somebody is out for lunch for an hour or sipping cocktails on a beach and not checking slack this week.

Git

Figure out procedures for source control, socialize them, and follow them.

• Does every commit need a PR?
• Does pairing count as code review?
• How do you ensure that PRs don't get stale (who is responsible for merging)?
• How do you deal with conflicts?

project management software

Agree throughout your company how you're going to use this software. Figure out how stories are created, pulled, discussed, and finished. If acceptance criteria belongs with the story (and it does) then make sure each story has it.

Look forward to more coming soon about pairing remotely and working remotely!

go slow

Pairing is awesome. See, e.g., this blog post. It really only works if you both people are truly involved. Oftentimes, this means slowing down on a concept that may be mindless for you, but requires a little bit of time for your pair to grok. Commit to spending that time.

make sure to switch off drivers

This ought to go without saying, but make sure you remember to do it.

make sure both people know wtf is going on (don't steamroll)

This is the responsibility of the pair, not one individual. If you're not stopping your partner to ask what they are talking about then start. Likewise, make sure to check in frequently with questions like "does this make sense to you" or "do you think this approach is the most effective?"

give each other a chance to try something out

In the "fail early and often" vein, give your pair time to try something out fully. Oftentimes, an idea can be a little difficult to verbally articulate. If one member of the pair needs to write some code to help get an idea out, support them in that. Even if you think/know that this idea will not work, trying an idea that eventually fails gives a better understanding of the overall problem to both members of the pair. Also, if one member doesn't get the chance to try an idea then that person is going to be pissed!

Also, here's a helpful video for more a more advanced technique:

Hey software devs - as you move into the world of functional programming, make sure your opinions stay mutable.

— Brian P. Hogan (@bphogan) January 15, 2016

Of course I got excited about a response that involved Elixir's immutable state that can be rebound to variables. Not wanting to look like a hack, I did a bit of quick googling and, an hour later, decided to write a quick post*.

Immutability in Elixir

(in three bullet points)

• state is immutable in Elixir (it cannot be changed)
• variables often need to change their value
• variables can be re-bound without changing the original value (in memory)

Keeping Opinions Mutable

Here's the meat of this little thought experiment. Your opinions should always be open. Maybe even free. This is the "mutability" of your opinions. Be open to changing them with the right new information. At the same time, your old opinions should also still hold some validity. That's why you held them, and held them so strongly.

The consideration of your opinions should be nuanced enough to account for the situation. Perhaps a given situation will merit taking your old opinion, while a new one will require a new one.

I'm generally a fan of DRY programming, especially in Ruby**. Some code I have write and like in Elixir is not as DRY.

It all comes back around

Maybe the takeaway is that the original tweet had it right: enjoy functional programming, but keep those opinions mutable.

*The twitter had also raised a few questions about the nature of a blog and its scrutiny today, priming the proverbial pump.

** Speaking of dogma, Rubyists need to chill out on the DRYness thing, but that's for another time.

You're going to need a linux environment to follow along. If you're using a Mac I recommend you just follow the directions I wrote about getting set up with Vagrant. That will cover installing Docker and Docker Compose. If you already have a linux environment, you can just install them as follows.

Installing Docker and Docker Compose

• Docker - There is pretty good documentation on the docker site. Here are the commands I used to install:

$ sudo apt-get update && apt-get install wget
$ wget -qO- https://get.docker.com/ | sh
$ sudo usermod -aG docker vagrant
$ sudo docker run hello-world

The last command should show you a bunch of things including: Hello from Docker.

• Docker Compose - This will help us manage multi-container apps. Installation docs are here or just copy and paste:

$ sudo -i
$ curl -L https://github.com/docker/compose/releases/download/1.3.3/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose
$ chmod +x /usr/local/bin/docker-compose
$ exit

Dockerizing your app

Clone your app down first. I'm using a demo rails app called storedom from the good people at Turing.

$ git clone git@github.com:turingschool-examples/storedom.git ~/src/storedom

The problem with that app is that it is using SQLite. We're going to use PostgreSQL so we can have two Docker containers running and talking to each other. To do that, we'll need to change a few files: database.yml, and the Gemfile

#config/database.yml
development: &default  
  adapter: postgresql
  encoding: unicode
  database: storedom_dev
  pool: 5
  username: postgres
  password:
  host: postgres

test:  
  <<: *default
  database: storedom_test

production:  
  <<: *default
  database: storedom

#Gemfile
source 'https://rubygems.org'

gem 'rails', '4.1.4'  
gem 'pg'  
gem 'sass-rails', '~> 4.0.3'  
gem 'uglifier', '>= 1.3.0'  
gem 'coffee-rails', '~> 4.0.0'  
gem 'jquery-rails'  
gem 'turbolinks'  
gem 'jbuilder', '~> 2.0'  
gem 'faker'  
gem 'haml-rails'  
gem 'therubyracer'  
gem 'less-rails-bootstrap'

group :development do  
  gem 'spring'
end

group :development, :test do  
  gem 'capybara'
  gem 'pry', :require => 'pry'
end  

Dockerfile

The Dockerfile is a set of instructions Docker uses to build your container. You start with a base image and then layer on various commands that will install software, organize directories, etc. The commands are carried out in sequence.

Here is an example that will work for storedom:

#Dockerfile
FROM ruby:2.2.0

WORKDIR /usr/src/app/

RUN apt-get update -qq && apt-get install -y build-essential libpq-dev

RUN curl -o /usr/local/bin/gosu -SL "https://github.com/tianon/gosu/releases/download/1.2/gosu-$(dpkg --print-architecture)" && chmod +x /usr/local/bin/gosu

COPY Gemfile /usr/src/app/Gemfile  
COPY Gemfile.lock /usr/src/app/Gemfile.lock

RUN bundle install

COPY . /usr/src/app  
# copy our project into the WORKDIR

CMD ["rails", "s"]  
# this is the default command we will run when starting the container*

Docker has good documentation on building a Dockerfile, but you can see a quick explanation of the commands we are using below:

FROM

Our base image is ruby 2.2.0. This is a basic Docker image with Ruby 2.2.0 installed on top of Ubuntu. It is maintained by Docker. The rest of our commands will build off this starting point.

WORKDIR

The WORKDIR is the working directory for all the other commands.

RUN

The first RUN installs two libraries that we will need. The second installs gosu, a tool we use to avoid permissions hell.

COPY

COPY copies files into the container. We are copying in the Gemfile and Gemfile.lock so that we can install our gems in the container. After they are copied into the container, we RUN bundle install to install all our gems. Then we copy our project into the container.

CMD

The default command for when the container is started. There are a few acceptable form for CMD. This is the preferred form.

Docker Compose

Docker Compose, formerly called fig, is a tool that helps manage building, running, and linking Docker containers. It consists of a YAML file that sits in your project directory, called docker-compose.yml, and a CLI.

Below is a docker-compose.yml that we can use to get for this project.

#docker-compose.yml
rails:  
  build: .
  command: bundle exec rails s -p 3000 -b '0.0.0.0'
  volumes:
    - .:/storedom
  ports:
    - "3000:3000"
  links:
    - postgres:postgres

postgres:  
  image: postgres
  ports:
    - "5432"

So what do those things mean? Luckily, the file is reasonably self-explanitory and well documented, but we can go into a little detail about what each key does.

Container Name

This sample app needs two containers running: rails and postgres. The first will run the rails app and the second will run the postgres database. They are defined at the top level of docker-compose.yml, and we can use these friendly names to refer to the containers in the Docker Compose CLI.

build

build maps to a path to a directory that contains a Dockerfile. We have a Dockerfile in the same directory as the docker-compose.yml, and therefor just use..

command

command overrides the default command as defined in the Dockerfile [ ] check the actual command used in the Dockerfile. Do we even need to use command?

volumes

volumes mounts a path on the host to a path in the new container. Here, we are mapping the current directory to the /storedom directory in the container.

ports

Similar to our Vagrant setup, ports maps ports on the host to ports in the container. We're keeping everything on 3000 just to make it all easy. Using a string here isn't mandatory, but is idiomatic.

links

This is one of the really cool parts of Docker Compose. links links containers together; in this case, we are giving our app container, rails, access to our database container postgres.

image

Every container in Docker Compose needs either build or image. image will pull down the mapped image.

Tying it all together

Now, you should have everything you need to run your app in Docker containers. Run $ docker-compose up and Docker Compose will build your containers and run them. Learn more about the Docker Compose CLI in the docs.

Go out and cargo-cult to your heart's content. Get it? Because Docker? And cargo!

environment setup

These instructions use Vagrant. You can download a .pkg file on vagrant's site. Install that, fire up your terminal, mkdir and cd into a new directory and follow along. First:

$ vagrant init ubuntu/trusty64

When it finishes, you will see that your directory has new Vagrantfile. Open this up and uncomment/modify the line about port forwarding so that it reads something like this:

config.vm.network "forwarded_port", guest: 3000, host: 3000  

That will let you access port 3000 on your vagrant box via port 3000 on the host machine. We're using this port because it is the default for Rails. Fire up your new linux box with vagrant up. This may take a little while because you have to download and set up the linux machine.

Next, we need to get the new environment set up. That entails:

• installing requesite programs
• getting your own damn dotfiles on the machine
• cloning down your project

There are a bunch of great provisioning tools out there, but that's for another post. I'm going to just go through what I think are some of the basics.

Install vbguest on your copmuter with

$ vagrant plugin install vagrant-vbguest

Now you can ssh in with the vagrant ssh command.

Installing Programs

You're going to be doing a lot of apt-geting. Install a necessary Vagrant plugin and update your apt repositories with

$ sudo apt-get update

Then you'll need to install a bunch of other software. I recommend the following:

• Git - You may want to create new ssh keys for your vagrant box and add them to github. If so then I recommend following their excellent help documentation for that purpose.

$ sudo apt-get install git

• ruby - We get 1.9.3 for free, but we're going to use something a little more recent. We're going to use rbenv and ruby-build. You can follow their install instructions. I'll just reproduce the commands here:

$ sudo apt-get install autoconf bison build-essential libssl-dev libyaml-dev libreadline6-dev zlib1g-dev libncurses5-dev libffi-dev libgdbm3 libgdbm-dev libsqlite3-dev
$ git clone https://github.com/sstephenson/rbenv.git ~/.rbenv
$ git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build
$ echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bash_profile
$ echo 'eval "$(rbenv init -)"' >> ~/.bash_profile

At this point you'll need to restart your shell window. One way to do this is to log out of the vagrant box with logout and then log back in with vagrant ssh.

Then back to installing ruby. You can see a list of available ruby versions with the rbenv install -l command. Actually installing ruby takes a little while so you will have a minute to get up and stretch*.

$ rbenv install 2.2.2 # obviously you can use whatever version you would like

Once that's installed, you can set it to be your global version (used everywhere) with

$ rbenv global 2.2.2

Now you have ruby!

• Docker - Again, there is pretty good documentation on the docker site. Here are the commands I used to install:

$ sudo apt-get install wget
$ wget -qO- https://get.docker.com/ | sh
$ sudo usermod -aG docker vagrant
$ sudo docker run hello-world

The last command should show you a bunch of things including: Hello from Docker.

• docker-compose - while we're at it, we will install docker-compose to help manage multi-container apps:

$ sudo -i
$ curl -L https://github.com/docker/compose/releases/download/1.3.1/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose
$ chmod +x /usr/local/bin/docker-compose
$ exit

Dotfiles

I like vim. If you've been using it all along then that's great. Otherwise, this will be an opportunity. One great thing about using vim all the time is that you get it for free with our standard ubuntu version and you only need to clone or copy a few files in order to feel at home wherever you find yourself working. Clone or copy them into your new box.

Clone Your Project

The next thing you need is your project. For this demo, I'm using my most-seen and possibly least-favorite project, storedom.

$ git clone git@github.com:turingschool-examples/storedom.git ~/src/storedom

Profit

Now take a look at what you have: a linux virtual machine running on your computer that you can use to develop on or do whatever you need. If you run your migrations then you should be able to run rails s in your vagrant box and hit the app at localhost:3000 on your host machine. Things are going well!

* If you really want to follow along then you can open a new window, vagrant ssh, cd into /tmp/, figure out what the ruby-build log file is and then tail it. E.g. tail -f ruby-build.20150712002651.320.log

I start on Monday, but my new computer arrived this morning. It's been a while since I set up a dev environment, so here's a quick rundown of the things I did to get it up and running. I'll update more as I make more changes.

Keyboard:

• Fix caps lock/ctrl
• Fix key repeat speed and delay until repeat
• Set up bluetooth keyboard (and caps/ctrl)
• Set up bluetooth mouse
• Let tab move through all the controls (^+F7)

Software:

• Xcode and developer tools - don't worry, you'll be prompted about this
• Git
• hipchat
• iterm
• chrome
• something for window management.

Customization:

• dotmatrix
• bash_profile

Random:

• Put dock on the left
• Get all the bullshit out of the dock (lol windows messenger)

* I don't do resolutions, so I won't resolve to blog more. There are a bunch of drafts I've been working on so maybe I'll do something with those.

General Architecture and Design Considerations

I spent a fair bit of time thinking about the architecture for this app and getting UX input from others. In the end, I think that it lends itself to a one page javascript style, but frankly, I don't know enough javascript to feel comfortable implementing this.

On the other hand, I'm very comfortable building "normal" rails apps so I decided to focus my limited time on integrating all the other new technologies. I look forward to integrating a javascript framework for the front end in the future.

POROs

This app has only a few controllers and only a few pages. In order to separate concerns, I ended up building several POROs (Plain Old Ruby Objects) for various data processing needs such as geospatial operations.

One problem I came across was where to put these POROs. On the one hand, they are somewhat akin to models, and on the other, they are their own sort of thing and do not inherit from ActiveRecord::Base. I ended up keeping them in app/models/, but in the future would consider moving them to lib/. I turned my GPXParser into a gem, despite its measly single class.

Index/Show

I didn't deviate from the vanilla rails actions too much. One place that could have potentially used a bit of a change is the index vs show pages. If the app used more javascript and AJAX then I think that it might make sense to have only one page to view the various ski routes. As it turned out, I ended up sticking with the index/show pages because it made my GeoJSON API calls easier to handle.

API

Speaking of that API, I decided to serve up all my spatial data using a GeoJSON API. The first reason was that I had just learned about them, and with a shiny new hammer, it seemed only right to find some nails. Aside from that, I like the idea of separating out various parts of my app. If, in the future, I were interested in building out more javascript to make things more modern and slidey, then it will be easy to stick with the current API to fetch the ski routes. This also allowed me to keep my views dumber.

There were a few chalanges around serializing the ski routes into GeoJSON. My solution doesn't seem terribly elegant, but it does work well. Basically the serializer does a lot of string manipulation, iterating through each point of the polyline. It works, but I would like to figure out a cleaner method, even if that just means adding a layer of abstraction.

There are some tutorials out there to help you get started with pairing the excellent Ember front end javascript framework with a Rails back end API. It can be a little harder to find a condensed source to help you go beyond simple GET requests.

This tutorial is based off of a project called Snowcial, and will cover implementing CRUD actions for an existing groups model. You can substitute this with whatever model makes sense for your project. Requirements include a working app* with index and show actions. We will go over adding create, update, and destroy. I'll also assume that you are comfortable with Ruby and Rails already though you'll only need passing understanding of javascript and Ember.

*App, in this case, means a Rails app providing a JSON API and an Ember front end consuming it. This set of tutorials from Dockyard will get you up to speed.

A note about testing

Testing should be first and foremost on your mind when thinking about implementing new functionality for your apps. Unfortunately it is outside the scope of this tutorial. Test your apps. Ask for help or advice if you need it.

Ember

Step 1: Routes

Routes in Ember are not the same as routes in Rails, but they are also not entirely different. We'll start here. create a new app/routes/groups/create.js file and add the following. We are adding a create function for the group model and the action to go along with it.

//app/routes/groups/create.js
import Ember from 'ember';

export default Ember.Route.extend({  
  model: function() {
    return this.store.createRecord('group', {
      name: ''
    });
  },

  actions: {
    create: function() {
    var my_model = this.controller.get('model');
    my_model.save();
    this.transitionTo('groups.show', my_model);
    }
  }
});

Follow suit for the edit, index, and show.

//app/routes/groups/edit.js
import Ember from 'ember';

export default Ember.Route.extend({

  actions: {
   submit:  function() {
    var my_model = this.controller.get('model');
    my_model.save();
    this.transitionTo('groups.show', my_model);
    }
  }
});

//app/routes/groups/index.js
import Ember from 'ember';

export default Ember.Route.extend({  
  model: function() {
    return this.store.find('group');
  }
});

//app/routes/groups/show.js
import Ember from 'ember';

export default Ember.Route.extend({

  actions:{
    delete: function() {
    this.controller.get('model').destroyRecord();
    this.transitionTo('groups.index');
    }
  }
});

Step 2: Templates

You will need your templates to have forms for your create and edit actions. Ember's magic will help you out. Unfortunately, my editor doesn't have handlebars highlighting. That's a thing that you'll want unless you're a total masochist or Swiss, in which case you will prefer Emblem.

//app/templates/groups/create.hbs
<h4 class="create-new-group">Create New Group</h4>

<p>Name:&nbsp;{{input value=name class='group-name'}}</p>

<p>Description:&nbsp;{{input value=description class='group-description'}}</p>

<p><button type='submit' {{action 'create'}} class='commit-group-creation'>Submit</button></p>  

//app/templates/groups/edit.hbs
<h4>Edit</h4>

<p>Name:&nbsp;{{input value=name class='group-name'}}</p>

<p>Description:&nbsp;{{input value=description class='group-description'}}</p>

<p><button type='submit' {{action 'submit'}} class='commit-group-change'>Submit</button></p>  

//app/templates/groups/index.hbs
<h3>Groups</h3>

<table>  
  <thead>
    <th>Name</th><th>Trips Taken</th>
  </thead>

  <tbody>
    <p>{{#link-to 'groups.create' class="create-group"}}Create{{/link-to}}</p>

    {{#each}}
      <tr>
        <td>
          {{~#link-to 'groups.show' this}}
          {{name}}{{~/link-to}}</td><td>{{trips.length}}</td>
      </tr>
    {{/each}}
  </tbody>
</table>  

//app/templates/groups/show.hbs
<h4>{{name}}</h4>&nbsp;  
{{link-to 'Edit' 'groups.edit' model class='edit-group'}}
<button {{action 'delete'}} class="delete-group">Delete</button>

<h5>Group Description:</h5>  
<p>{{description}}</p>

<h5>Trips</h5>  
<ul>  
  {{#each trips}}
    <li>{{name}}</li>
  {{/each}}
</ul>  

At this point, you may feel the urge to delete app/templates/groups.hbs. Go for it. Or don't. It's basically just another partial that can hold your various groups templates.

Step 3: router.js

Lastly, you'll need to add these new routes to your router.js

//app/router.js
import Ember from 'ember';  
import config from './config/environment';

var Router = Ember.Router.extend({  
  location: config.locationType
});

Router.map(function() {  
  this.route('demo');
  this.resource('groups', function() {
    this.route('show', {path: ':group_id'});
    this.route('edit', {path: ':group_id/edit'});
    this.route('create', {path: 'create'});
  });
});

export default Router;  

Rails

Step 1: Serializers

If you don't already have a serializer for your model then you'll need to add gem 'active_model_serializers' to your Gemfile and generate a new serializer.

$ rails generate serializer group

The most important part of your serializer is adding the correct attributes. I have added a bit more to mine because I want some of the associations to come along as part of the JSON.

#app/serializers/group_serializer.rb
class GroupSerializer < ActiveModel::Serializer  
  embed :ids, include: true

  attributes :id, :name, :description
  has_many :trips
end  

*Note that embed is deprecated.

Step 2: CSRF Considerations

Rails has a default protection against Cross-Site Request Forgery (CSRF) attacks. While an in-depth analysis of site security is beyond the scope of this tutorial, you can avoid the problem by changing your ApplicationController.

#app/controllers/application_controller.rb
class ApplicationController < ActionController::Base  
  protect_from_forgery with: :null_session
end  

That should get you up and running. If you have questions or comments then sound off below or feel free to reach out on twitter or GitHub.

If you're going to the trouble of blogging then you're probably interested in tracking your readers. Google Analytics is a pretty easy way to do that so I'll show you how to get it set up. I'm assuming you already have your blog set up. If you don't then go to www.digitalocean.com/ and set up a droplet with Ubuntu and Ghost preinstalled.

Step 1

Get an account. Go to google.com/analytics and set yourself up with an account. Go to admin > tracking info > tracking code. That code will send your tracking information to Google.

Step 2

ssh into your droplet by typing

$ ssh root@162.243.131.156

Change my blog's IP address with your own and use another username if you have one.

Step 3

Next, you'll need to edit one of the ghost files using the text editor of your choice. I recommend vim, and that's what I'll use in this example. You could also use nano. At any rate, open your ghost default.hbs. The directory for this file will depend on your theme. The default is casper, so that's the path I've given.

$ vim /var/www/ghost/content/themes/casper/default.hbs

Now you can paste the tracking code from Step 1 into default.hbs I chose to do so right above the </head> tag. This will render the script on every page.

...
   {{ghost_head}}
  <script>
    (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
    (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
    m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
    })(window,document,'script','//www.google-analytics.com/analytics.js','ga');

    ga('create', 'YOUR TRACKING ID', 'auto');
    ga('send', 'pageview');
  </script>
</head>  

Save and close the file (:wq in vim).

Step 4

You'll need to restart Ghost for the change to take effect.

$ service ghost restart

Step 5

You should now have your Google Analytics set up, but there's another pro-move you can make. Right now, you do all your blog editing by visiting yourblog.com/ghost. Unless you're wildly popular, all your editing will skew your analytics. We can fix this problem by setting up a filter in Google Analytics to exclude traffic to the admin side of your site.

• Go back to your Google Analytics dashboard and click on Admin.
• Click All Filters in the Account column.
• Click + New Filter
• Give your new filter a name (e.g. 'exclude blog editing')
• Choose Filter Type: Predefined, Exclude, traffic to the subdirectories, that begin with
• Fill in the Subdirectory field with /ghost
• Add your site to the Selected Views
• Click Save

Now you're really done!

Also, I'm interested in checking out Piwik, a self-hosted open source analytics platform. That one may be phase two.

As I previously mentioned, I'm in the process of getting into Vim. Here's how:

These devs, they come at you all "Hey. Hey kid… use my dotfiles"

— Josh Cheek (@josh_cheek) January 23, 2014

I talked to a friend who helped me out by sharing a bunch of recommendations for getting started with Vim. While there are a load of vim plugins out there, I think it is worth adding them one or a few at a time. There is utility in understanding vanilla vim. For example, it's already there on every computer, and better than nano. When you've ssh'd into your VPS and need to make changes, the ability to get around in vim will come in handy. (:E, for example, is a passable replacement for NERDTree) Also, it is overwhelming and unproductive to have too many plugins for software you are trying to learn.

My setup consists of pathogen along with the following plugins .vimrc.

https://github.com/kien/ctrlp.vim
https://github.com/terryma/vim-multiple-cursors
https://github.com/scrooloose/syntastic

execute pathogen#infect()

set rtp+=/usr/local/go/misc/vim  
colorscheme railscasts

"" ==========  These come from Mislav (http://mislav.uniqpath.com/2011/12/vim-revisited/)  ==========  
set nocompatible                " choose no compatibility with legacy vi  
syntax enable  
set encoding=utf-8  
set showcmd                     " display incomplete commands  
filetype plugin indent on       " load file type plugins + indentation

"" Whitespace  
set nowrap                      " don't wrap lines  
set tabstop=2 shiftwidth=2      " a tab is two spaces (or set this to 4)  
set expandtab                   " use spaces, not tabs (optional)  
set backspace=indent,eol,start  " backspace through everything in insert mode

"" Searching  
set hlsearch                    " highlight matches  
set incsearch                   " incremental searching

"" ========== NERDTree  ==========  
autocmd bufenter * if (winnr("$") == 1 && exists("b:NERDTreeType") && b:NERDTreeType == "primary") | q | endif " close vim if NERDTree is the only open buffer


"" ==========  Josh's shit  ==========  
set nobackup                                        " no backup files  
set nowritebackup                                   " only in case you don't want a backup file while editing  
set noswapfile                                      " no swap files  
set scrolloff=4                                     " adds top/bottom buffer between cursor and window  
set cursorline                                      " colours the line the cursor is on  
set number                                          " line numbers  
nmap <Leader>p orequire "pry"<CR>binding.pry<ESC>;  " pry insertion  
vnoremap . :norm.<CR>                               " in visual mode, "." will for each line, go into normal mode and execute the "."

"" ========== My shit ==========  
imap kj <Esc>

" easier navigation between split windows  
nnoremap <c-j> <c-w>j  
nnoremap <c-k> <c-w>k  
nnoremap <c-h> <c-w>h  
nnoremap <c-l> <c-w>l

" Emacs/Readline keybindings for commandline mode  
" http://tiswww.case.edu/php/chet/readline/readline.html#SEC4  
" many of these taken from vimacs http://www.vim.org/scripts/script.php?script_id=300  
"  
" navigation  
cnoremap <C-a> <Home>  
cnoremap <C-e> <End>  
cnoremap <C-f> <Right>  
cnoremap <C-b> <Left>  
cnoremap <Esc>b <S-Left> " commenting out b/c makes it pause  
cnoremap <Esc>f <S-Right>  
cnoremap <M-b> <S-Left>  
cnoremap <M-f> <S-Right>  
" editing  
cnoremap <M-p> <Up>  
cnoremap <M-n> <Down>  
cnoremap <C-k> <C-f>d$<C-c><End>  
cnoremap <C-y> <C-r><C-o>"  
cnoremap <C-d> <Right><C-h>

I've played with a number of text editors in my brief programming experience. First it was Gedit, which I actually like quite a bit. Then I played around with SublimeText for a while. My time at Turing started out with me using Atom, at the time barely out of beta. I even downloaded Textmate. Now I'm trying to move over to Vim.

Let's back up just a little. Text editors are pretty straight-forward, and I feel like they should mostly just get out of the way. That's what Gedit did: it was already there on my Ubuntu box and it was pretty easu to just type gedit [file]. That worked well at the time.

Then I started doing a little more serious programming. SublimeText is fast. I liked installing a plugin that let me run ruby right in the editor. The black background looked so legit.

For most of my time at Turing I have used Atom. It breaks sometimes. I'm upset that I can't use seeing is believing because it keeps breaking for me. But I'm getting better at programming and demanding more from my editor. I can now move around the editor in ways that are meaningful to my productivity. It's little more than a glimpse right now, but that's what made me decide to jump to Vim.

I tried vim-mode in Atom for a while, but it mostly served to mess up my undo commands and annoy people pairing with me. Then I started spending a decent amount of time ssh-ing around the VPS that is hosting my current project, and working in Vim was, surprisingly, not that bad. That was a turning point.

I've seen the way an accomplished Vim user flies around the environment. I'm jealous and I want in. So I've taken the plunge. From here on out, I'm making a conscious effort to use Vim close-to-exclusively. I'll let you know how it goes.

For the meat of how I switched, head over to that post.