So, I've just backed up about 500Gb of stuff on Laptop, formatted the HD, and installed Mountain Lion from the Recovery partition, all fairly simple, a bit time consuming , but I like to have a completely fresh system for new OS installs, and overtime I've been streamlining my approach.

First off, Xcode

Make sure you've got the latest Xcode, currently 4.4, then after that installs, you'll need to enable command line tools, Xcode -> Preferences -> Downloads

That should be all of Xcode setup and working for development, however, if you plan on using ruby 1.9.2 or earlier, you'll also need to install gcc-4.2 separately (via HomeBrew)

Homebrew

[HomeBrew][http://mxcl.github.com/homebrew] has become my standard package manager on OS X, It's pretty simple to setup, and works well out of the box

GCC

As Xcode no longer installs gcc, you'll have to install it manually before any ruby before 1.9.3. First you need to enable the homebrew-dupes repository, which gives you access to builds of Apples Open Source tools.

Databases

For now, we'll just setup MySql and Postgres as SQLite is included in OS X.

MySql is easy:

Postgres is a bit more troublesome, and there appears to be a bug at the moment with Mountain Lion, which the current 'workaround' is to install without ossp-uuid. This works for me at the moment, but I'll be checking to see when this gets fixed.

Both databases will still require a bit more setting up, the commands to run will be output to the screen after you install them.

There will probably be plenty of other tools you'll need to install, but for me, the last big one is ImageMagick.

This will prompt you to install Java (a necessary evil unfortunately).

RVM

All my rubies for development our managed by RVM, Very useful tool, and very simple to install.

So, that should be enough to get a decent working development environment for Ruby/Rails projects, obviously you'll need to install rails and other project dependencies with bundler, but hopefully you be pretty used to those commands.

XQuarts

[XQuarts][http://xquartz.macosforge.org/landing] is needed if you plan on doing anything X11 related, just down and run the installer

Installing old Rubies with RVM

So, they setup earlier works fine for installing new rubies (i.e., 1.9.3), but it doesn't work so good for 1.8.7 and its bretheren. Now, I know these are old, and and you really shouldn't be using them anymore, but I still work on some old projects that require them. A simple change to your login environment should do the trick:

https://github.com/mathiasbynens/dotfiles/blob/master/.osx

Having a quick development environment means, obviuosly means being able develop ideas quicker. It should be in every programmers interest to understand the impact of project dependencies on speed and effiecentcy. Database servers are things we all need running when we're working, but rarely do we turn thme off when we're not. They just sit in the background. Now, it wouldn't be such an issue if it was only one, say Postgres, but recently i've also been using MySQL, Redis, Solr … to name a few, but still way too many!

One big issue is that most Database servers assume they're the only one you have installed, and asume you want them running all the time. Case in point, installing Postgres via HomeBrew, give you instructions to setup Launch Control to automatically start Postgres on boot, or it porovides you the command to run Postgres as a Daemon. Personally, non of these makes much sense from a development point of view. I want to run Database in much the same way as I run developemnt webservers, spin them up for coding, then kill them when i'm done.

Enter Foreman

Foreman is a Process Manager, when started, it reads from a Procfile and fire up the processes defined. This means I can run Foreman, which will then run all my project dependencies, including database server.

web: unicorn
database: Postgres -D /usr/local/var/postgres
delayed_job: ...

For me, including all my project runtime dependencies, including databases, into a process manager means I know that what I'm running in development is as close as possible to production (without using virtual machines). As a bonus, it also means i can turn off all the background daemons like Postgres or MySQL when I'm not doing any coding, which means my aging MacBook runs a bit smoother.

One reason for choosing Vim as my new code editor is Vims excellent support for scripting. Vim-script pretty much allows you to customize the entire experience, as well as allowing many custom functions to make you more productive.

Learning the basics of vim-script is fairly easy (assuming you have some knowlegde of programming), and most of it is based around calling functions that operate on the current document. Therea are plently of vim-scripts available to download from http://www.vim.org or from online repos like http://github.com.

As an excuse to learn the language a but more, I've started to write my own scripts to better handle my workflow.

RunSpec()

RunSepc() is a simple vim-script to run Ruby RSpecs. It's pretty simple and demostrates a few of the basic ideas of calling functions and passing variables.

  " Checks to see if the passed in file exists, then runs the rspec command line program
  function! RunSpecFile(file)
    if filereadable(a:file)
      " Executes:
      " Clear the Screen
      " Print the Spec filename
      " Run rspec (in the context of bundle)
      exec '!clear && echo ' . a:file  ' && bundle exec rspec --color ' . a:file
    else
      echo "File " . a:file . " does not exist"
    endif
  endfunction

" The command to run, this figures out if the current file is a spec file. " Then it calls the RunSpecFile() passing in the current file, or the related spec file. function! RunSpec() " expands the special vim variable % to the full path of the current file let currentFile = expand('%') if IsSpecFile(currentFile) call RunSpecFile(currentFile) elseif IsCodeFile(currentFile) let specFile = CodeToSpecFile(currentFile) call RunSpecFile(specFile) end endfunction

" Maps the keybinding 's' (which for me is ',s') to call the function RunSpec() map s :call RunSpec()

" very simple regex on the current filename to see if starts with 'spec/...' function! IsSpecFile(file) return match(a:file, '^spec/') != -1 endfunction

" very simple regex on the current filename to see if its not a spec file and is a ruby file function! IsCodeFile(file) return !IsSpecFile(a:file) && (match(a:file, ".rb") != -1) endfunction

" Used to see if the current file is in a special Rails directory function! IsRailsAppFile(file) return match(a:file, '<controllers>|<models>|<views>') != -1 endfunction

" rewrites the file name from a code filename to a spec filename function! CodeToSpecFile(file) let specFile = a:file if IsRailsAppFile(a:file) let specFile = substitute(specFile, '^app/', '', '') endif let specFile = 'spec/' . substitute(specFile, '.rb$', '_spec.rb', '') return specFile endfunction

" rewrites the filename from a spec filename to a code filename function! SpecToCodeFile(file) let codeFile = substitute(a:file, '_spec.rb$', '.rb', '') let codeFile = substitute(codeFile, '^spec/', '', '') if IsRailsAppFile(a:file) let codeFile = 'app/' . codeFile endif return codeFile endfunction

The process here is very simple, each part of logic is split into function calls for reuse. It's also very specific to how I work, I know there are other vim-scripts that do a lot more then mine, however, half the fun of using vim is about customizing it to how I work and my needs. I don't use TestUnit (well, I dont at the moment), so why have the ability to run test unit files? I've found that taking this approach means I only install what I need, and I'm more eager to learn the built in way first.

Things I've learned writing this

Variables are assigned by using let, and need to use let when updating their value.

Variables can be scoped by appending a: to the name, e.g., 'a:myvar' refers to a function arguemnt called myvar. 'g:myvar' world refer to a global variable 'myvar'. There are a few others, e.g., 't:' will make the variable available within the current Vim Tab

Switching From Bash to Zsh

As part of my new new workflow, I'm also swithcing my shell, from Bash, to Zsh.

Bash has served me very well over the years, but its time a for a change. Having heard many good things about Zsh, I decided to take the plunge. The easiest and simplest way to get a working zsh shell is downloading oh-my-zsh by Robby Russell. It's very featured and has lots of plugins and themes. However, I've deceided to roll my own configuration using the already installing z-shell that comes with Mac OS X/Darwin. So, to start with:

        chsh -s /bin/zsh

It's that simple, your previous bash profile is still available should you choose to switch back. I'll let you figure out how to that!

Switching form Textmate to VIM

Or how i learned to stop worrying and love the command line

For many, many years, I have been happily coding in Textmate. A program that hasn't seen any upgrades for a long time. That is, untill the version 2 alpha was released just before christmas. However, this post isn't about really about Textmate, it's about how I turned to the dark side, installed VIM, and for the first time in in atleast 5 years, learned how to use a new text editor.

Now, let me just get one thing straight, I still love Textmte. It's an amazing tool that has served me very well for many years. It's excellent bundle support has made always to the rescue when i've need them. I've used Textmate everyday for most of my career, and I'm sure i'll continue to use it everyday.

So why switch to now? and why switch to VIM? why not SublimeText2? well, I have actually been using SublimeText2 over the past 2 months, and have been very impressed with it. It's quick, supports Textmate bundles and looks beautiful. It also has a command mode, called vintage, which behaves a lot like VIM. With SublimeText2, i thought I'd found the perfect middle ground, Textmates style, and VIMs commands, a very active development cycle and community. But, whilst using SublimeText2, I noticed that I was using the command mode more and more, and quite liking it, but not liking the limitations or a half baked emulation of VIM. So, one day, last week, i just thought, why not switch to VIM, full time, personal and professional … and cold turkey!

First things first … Installing VIM

I should also point out that I'm using Mac OS 10.7, so these command will all be very mac based, and will probably make assumptions like you already have things homebrew installed.

The easiest and safest option is to download the latest version from https://github.com/alexlovelltroy/macvim/downloads, this will have all required bits compiled, as well as using its own UI, it also has familier keyboard shortcuts.

The next step that everyone will tell you to do is to install Janus (https://github.com/carlhuda/janus). Janus is suite of VIM plugins that gives VIM loads of Textmate style functionality. So, I installed Janus, and basked in the glory of using familiar commands in my new VIM editor.

But I quickly realised that VIM is not textmate. My coding habits and Textmate familiarity just dont make sense with VIMs command based input. Janus is good if you want everything done for you, but it also does a lot of other stuff you probably dont want or need. This adds a lot of bulk to what is supposed to be a really light text editor. For me, Janus just doesn't make sense. I want to learn and use VIM the way VIM is supposed to used, not try and get VIM to work like Textmate. If i wanted Textmate, then I might as well have stayed working with Textmate! Janus showed me a lot cool things, but ultimatly it had to go. I want to make VIM fit me perfectly, not make me fit someone elses idea of what I should use.

Right now, I'm using a bare bones basic install of MacVim. the only plugin I have installed is Pathogen, which is a plugin management tool. As I code, I'm sure I'll be installing more plugins, but until I feel I realy need them, I'm quite happy to learn the core tools of VIM, that way, I'll be better actually using VIM, keep VIM lean and quic and only install things that i'll actually use.