In software it is the same. You can measure a software developer by how they use their tools. Experienced software developers master their tools. It is important to learn your current tools deeply, and be aware of alternatives to fill in gaps where your current ones fall short.

With that in mind, I present to you a gigantic list of tools. Some of these I use daily, others I see potential in. If you have more tools you’d like to see here, just make sure to add a comment.

I tried to categorize these the best I can. Some of the entries are websites, some are back-end services, but most are apps that you install. Not all of the apps are free, so I’ll make a note with a $ to denote that an app costs money.

And without further ado, we’ll start from the beginning of any project, and that

Inspiration

• pttrns - A great library of iOS screen designs categories by task. If you want to see how other apps handle activity feeds, for instance, this is a great place to go see a bunch of examples.
• TappGala - Another great collection of nice app designs. It’s not categorized by task, but is just a list of great apps to get inspiration from.
• Cocoa Controls - A great list of components (code) that you can use in your iOS apps. Sometimes you’ll find great pieces of code that can save you time, other times you can just learn how other developers accomplish certain features. Subscribe to their weekly newsletter; all signal, little noise.
• IICNS - A collection of really great icons. Get inspired, but don’t copy.
• Dribbble - Some of the best digital designers post up their work for all to see. A treasure-trove of designs to look at.
• Capptivate - a gallery of inspirational designs. Some contain animations. Thanks, @joaopmaia!

Design

• Mocks ($) - An easy to use tool to create a quick mockup of an iOS app. Comes with a bunch of the default controls you can use to assemble something quickly.
• Briefs ($) - A really useful app that allows you to create a mockup of an app and stitch them together so you can see the interaction. Deploy to a device so you can see what it feels like in your hand.
• Acorn ($) - A strong competitor to Photoshop, only way cheaper. I find myself reaching for Photoshop less & less these days. Under active development.
• Sketch ($) - A vector-based drawing tool that is increasingly useful these days, as screen sizes and pixel densities change. It is often helpful to design once and have the freedom to scale up & down as needed. Also sports a really powerful export system. For some example Sketch projects, check out Sketchmine. See my screencast on Sketch for a live demo.
• iOS 7 PSD by Teehan+Lax - A super handy resource if you (or your designer) uses Photoshop. An iOS 6 version is also available.
• Bjango’s Photoshop Actions - A definite time-saver if you use Photoshop to design iOS apps. One click access to resize canvases, scale by 200% (or 50%), set global lighting to 90º, and more. Their blog also has a bunch of useful Photoshop workflow tips.
• xScope ($) - An indespensible swiss-army knife of tools such as guides, pixel loupes, screen rulers, and more. Want to know what color value that pixel is? Want to see how many pixels between a button and the window for a random Mac app? xScope has you covered. Also check out their companion iPhone app for mirroring designs you’re working on and seeing them in pixel-perfect glory on your iDevice.
• Glyphish ($) - A fantastic collection of high quality icons for your iOS apps. Apple doesn’t provide a lot of built-in icons, so it’s handy to have a collection of icons covering all kinds of various concepts. I’m still looking for a use for that baby icon though. Glyphish comes in packs, and the latest pack has iOS 7 “thin line” icons which will be very handy when designing an iOS 7 app.
• Fontastic Icons for iOS - An open source set of classes for utilizing icon fonts, such as Font Awesome in your iOS app. Quickly and easily have an icon in whatever pixel dimensions you require. Since fonts by nature can be scaled up and down with ease, this makes a really nice way to ship & use your icons without having to export multiple versions for the sizes you require.
• PaintCode ($) - A vector-based drawing tool that exports your artwork as the equivalent Core Graphics source code. Awesome for learning how Core Graphics drawing works, but also incredibly handy if you want your drawing to be dynamic. See my screencast on PaintCode for a live demo.
• Edge Insets ($) - A simple tool that helps you define your edge insets for repeatable images. Available on the Mac App Store.
• LiveView - A remote screen viewer for iOS, making it easy to immediately see your designs on a device. Thanks, @_funkyboy!
• Skala Preview ($) - Another excellent tool for quickly showing your designs off on a real device. The guys at Bjango are awesome and this app is deserving of the price. Thanks, jn40!

Source Control

• Git - If you’re not using source control stop what you’re doing and rectify that. I use git for everything I do and love it.
• Kaleidoscope ($) - The best diff/merge tool around. Does 3-way merges and is beautiful to look at. I use it every day.
• p4merge - A free, ugly alternative to Kaleidoscope. Powerful 3-way merge, but good luck finding the download link. It’s hidden deeper in their site every time I look for it.
• Git X - A simple, powerful GUI tool for visualizing git timelines and quickly & easily staging commits. I usually live in the Terminal for git usage, but fall back to this app when I need to stage hunks of changes into logical commits. This is a fork of the original (abandoned) GitX, which I found on this list of forks.
• Source Tree - A free, full-featured Git application. I don’t use this because I favor the command line, but if a GUI tool is your cup-o-tea, check this app out.

Dissecting Apps

• pngcrush - This little utility can crush & uncrush PNG files, which is handy when you want to view images contained in app bundled distributed in the App Store. Just open iTunes, view the local Apps list, and right click on any icon to Show in Finder. Once there, open up the app and you’ll see a bunch of PNG files, but you can’t view them. Using pngcrush you can extract the full version so it can be opened with Preview.
• appcrush.rb - This handy little ruby script will automate the above process for all images. Just point it to a .app file on your disk and it will extract all the images to a folder on your desktop. Handy for seeing how apps on your phone accomplish certain designs. Check out my screencast on dissecting apps for a live demo.
• Charles ($, free limited demo) - I don’t know what’s going on with the ugly UI or icon, but Charles is an essential tool for any developer. Charles acts as a proxy to allow you to inspect your network traffic to & from the iPhone Simulator. You can also inspect traffic from your device by setting your phone’s proxy to your Mac running Charles. With self-signed SSL certificates, request & response breakpoints, and request/response viewers, Charles is really amazingly powerful. A must-have tool. Again, my screencast on dissecting apps covers this well.

Editors

I know what you’re thinking, don’t all iOS developers use Xcode? Well mostly, yes. But with my love/hate relationship with Xcode, I believe there is tremendous value in considering alternatives.

• AppCode - A full-fledged IDE from Jetbrains (makers of the excellent ReSharper for .NET). Immensely powerful refactorings & features that help you write code faster. Quickly identify dead code, automatically insert #import statements when you use related code, easily extract variables, methods, and classes. My only wish for this app is that it would instead be a plugin to Xcode.
• Vim - Wait, vim? Really? Yes, there are folks who do all their Objective-C development in vim. I’m not one of these, but I am a fan of vim for Ruby development. As such, I’m a huge fan of…
• Xvim - An Xcode plug-in that gives you vim keybindings. Works well, ‘nuff said.
• OMColorSense - Another plugin for Xcode, this one gives you a small display of color when your cursor is on a line looking like: [UIColor redColor]. Clicking on this little color tab opens a color picker that you can change, and any change in color you make is reflected in the code by changing the line to [UIColor colorWithRed:… green:… blue:… alpha:… ]. When someone is watching me write code with this enabled, they invariably ask me, “Whoa! What was that?!”
• KSImageNamed - Another Xcode plug-in, this one allows you to autocompleted image filenames from your bundle when typing [UIImage imageNamed:…]. Great way to avoid the inevitable typo that causes this method to return nil and you to subsequently waste 10 minutes trying to figure out why your images aren’t displaying.
• CocoaPods Xcode Plugin - This plug-in adds a menu item for interacting with CocoaPods. Useful if you don’t like dropping to the command line.
• Alcatraz Package Manager - An awesome meta plug-in that allows you to easily install other Xcode color schemes and plug-ins with a single click.
• Code Runner ($) - a light-weight code-aware text editor that knows how to compile & run code in most languages. Want to test out a quick snippet of Objective-C code and don’t want to create an entire Xcode project to do it? Code Runner to the rescue.

Documentation

Ahhh, documentation, everyone’s favorite topic. Even still, documentation is really important to have, so pay attention so we can make your life easier.

• appledoc - Want to automatically generate documentation that look’s like Apple’s? Look no further. Automatically inter-links symbols defined in your project as well as extracting discussion to output using specially formatted code-comments. Generates official docsets and HTML web sites.
• Dash ($) - A must-have API documentation viewer and code snippet manager. This tool is really handy as it allows you to download & search API docs for all kinds of languages & frameworks with lightning speed. The fastest way to get access to the docs. I integrate Dash with Alfred to make searches even faster.

Dependency Management

Yes, there’s only one tool listed here. I didn’t want to include actual 3rd party libraries, as that would be a different list entirely. When it comes to dependency management, there’s only one game in town:

• CocoaPods - The essential tool for Objective-C projects. Allows you to quickly & easily integrate 3rd party libraries into your application. It does so by creating a second static library project and automatically links this with your projects. There are thousands of pods available, and it’s easy to add support for libraries that you don’t own (or perhaps are private). I use CocoaPods in every single project I work on.

Diagnostics & Debugging

At some point our app is in the field and we need to understand better what’s going on, maybe to fix bugs or to improve performance.

• Cocoa Lumberjack - a much more powerful NSLog, Cocoa Lumberjack offers advanced logging behaviors such as logging to rotated files, logging to the network, and filtering based on log level (info, debug, warn, error). Covered by NSScreencast Episode 61
• DCIntrospect - crazy powerful tool that you’d link inside your app when running in debug and on the simulator. Once you do, you can press the spacebar to get some really helpful view debugging support. See exact dimensions of elements on the screen, print out view hierarchies, even nudge views horizontally or vertically.
• Pony Debugger - another tool you’d use by embedding a library in your debug builds, Pony Debugger actually utilizes Chrome’s dev tools for seeing network requests coming out of the device, as well as a rudimentary Core Data browser. It’s hard to describe, but check out my screencast on Pony Debugger for more info.
• Runscope ($) - Runscope is a service running online that can capture requests, log details, and give you valuable data about your API. Simple to set up, as it’s an HTTP pass-through API, all you need to change is your host name.
• SimPholders - Quick, easy access to your simulator folders. Browse by iOS version, then app name and jump right to the folder in Finder.
• Spark Inspector - Debug your view hierarchy running on your app in debug mode, in 3D. This app really has to be seen to fully understand the value, but it can really help to understand what views are used to compose your app. Also contains a notification center inspector, so you can easily see what NSNotifications are firing and who is observing them. Another app to look at that is similar is Reveal.

Images

• ImageAlpha - A Mac app that allows you to convert a 24-bit PNG with transparency to an 8-bit PNG with an alpha channel. Typically 8-bit PNGs don’t have an alpha channel, so if your image can be represented in 8-bits (say, a solid color button) you can save a lot on storage by converting the 24-bit PNG to 8-bit using ImageAlpha.
• ImageOptim - Another Mac app that compresses PNGs in order to save space. Most PNG files can shave off a few % of the size, and sometimes you’ll shrink the files by 30% or more. Smaller images mean smaller app sizes and less memory used to load them at runtime.
• Prepo - A little Mac app that can quickly resize artwork in all the various sizes you might need. Just drag a large icon file (say, 1024x1024) onto Prepo and watch it spit out 512x512 iTunesArtwork, 114x114 Icon@2x.png, and all the other sizes & filenames you’d expect.
• Slender ($) - an awesome app that analyzes your app and finds all sorts of problems, such as missing retina artwork, unused images, image that could benefit from compression and more. Shave kilobytes off of your iPhone app by shedding unused images with Slender.

Core Data

• Mogenerator - still a super useful tool for generating smart subclasses of your NSManagedObjects in your Core Data model. Some use Xcode for this, and resort to manually subclassing or creating categories in order to add logic to the models. Mogenerator runs as a quick pre-compile script to generate subclasses for you to use. It does this by creating an underscored version (_User) and a regular one for you to modify (User).
• Base ($) - there will come a time when you need to inspect your actual Core Data sqlite database to see what’s going on. You can use the sqlite3 command line tool, but Base offers a nice looking GUI browser. Just don’t vomit when you see the database schema that Core Data created for you.
• Core Data Editor ($) - for more advanced data anlysis, exploration, and modification you can use Core Data Editor. This app understands Core Data, so you’re working directly with the entities instead of database rows.

Back-end Services

Ultimately your iOS app will likely want to talk to a server to share data, fetch new content, send push notifications or whatever. While this can be accomplished manually, you might want a more drop-in solution.

• Helios - Helios is an open-source framework that provides essential backend services for iOS apps, from data synchronization and push notifications to in-app purchases and passbook integration. Built on top of many open source ruby gems, so you can pick & choose and build your own stack if you so desire. Take a look at the Nomad CLI set of handy related tools as well.
• Windows Azure Mobile Services - you can think of this sort of like a programmable database in the cloud. Create tables, run JavaScript on read, insert, delete to add additional functionality. Really easy support for push notifications as well.
• Urban Airship - I’ve been using Urban Airship to deliver push notifications for a while now. Really easy to integrate with, and small usage is free.
• Parse - This is another data-in-the-cloud service, but offers an impressive API and online data browser. We use Parse for a really small app and works well for that.

Analytics

There are other players here, but none that I’ve seen have been compelling enough to switch from flurry. I’m open to hearing suggestions, so let’s hear about ‘em in the comments.

• Flurry - I’ve used flurry for a long time to provide useful analytics on the usage of my apps. Need to know when to stop supporting iOS 5? Flurry gives you the numbers to have a realistic conversation.

Deployment

• Deploymate ($) - Need to support iOS 4 still, but you’re compiling with the iOS 6 SDK? Deploymate will warn you when you’re using symbols that don’t exist in your deployment target.
• Cupertino - Part of the Nomad CLI tools, Cupertino gives you command line access to managing devices & profiles in the Apple Provisioning Portal. For example, just type ios devices:list to see the current list of devices in your account. Useful for automating lots of processes.
• Hockey App ($) - A great service for managing the distribution of your ad-hoc builds. Testers can get a link to install new betas over the air. Also provides robust crash reporting so you can easily respond to crashes in your apps.
• TestFlight - A free service, similar to Hockey App. We’ve used TestFlight with great success for easily distributing apps and collecting feedback from our users. My only wish is that they’d start charging for the service. Also includes analytics and crash reporting, but we don’t use those features.
• iOS Simulator Cropper - A really easy way to snap images of the simulator, with or without status bar, with or without device chrome, etc. Great for taking App Store or just general marketing screenshots.
• Status Magic ($) - Take better app store screenshots. Nothing makes your app look less crappy than an App Store screenshot that includes a low battery, or low signal. Status Magic gives you complete customization over what’s present in your status bar, including removing elements, changing the time to “9:41 AM” like Apple tends to do, and more.
• Crashlytics - Excellent crash reporting for your apps in the field. Automatically uploads dSYMs on release builds so your crashes are automatically symbolicated and organized for you to focus on the most critical ones.

Testing

I don’t think we as a community focus enough on testing. There are great tools available to us, and most are so easy to use we have no real excuse not to write at least some tests for our apps.

• Kiwi - A great Rspec-style testing framework for iOS. Built on top of SenTestingKit, so you just type ⌘U to run your specs. Also includes a completely robust mocking & stubbing library as well as assertions.
• Specta - A light-weight BDD framework very similar to Kiwi, but the expectation syntax has one major benefit over Kiwi: everything is implicitly boxed like this: expect(items.count).to.equal(5). There’s no need to wrap 5 in an NSNumber like Kiwi does. Use in conjunction with Expecta for a bunch of useful matchers.

The following are all various ways of performing end-to-end acceptance tests. These tests will actually interact with your interface, touching buttons, scrolling, etc. By nature these will be slower and more brittle, but testing in broad strokes is certainly helpful to see if all of the pieces fit together properly.

• KIF
• Calabash
• Zucchini
• Frank
• Bwoken

Demos / Marketing

• Reflector ($) - Wirelessly mirror your iOS device on your Mac using Air Play. Great for doing demos of applications on your computer.
• Placeit - A great collection of high res photos of people using devices, but the screens are templates that you can insert your own screenshots into. Very cool, and great for displaying your app in a nice way on your website.

App Sales Reporting

Of course you want to be able to see how much money you’re making on your app, right? There are a few solutions for this, but here are a couple that work well:

• App Viz 2 ($) - a really useful Mac app for tracking sales of your apps. You run it locally and it logs in and downloads your sales reports.
• App Annie - an online sales reporting tool. I’m less comfortable giving my credentials to iTunes to a 3rd party, but it does keep the reports up to date for you so you don’t have to run an app locally. In the comments, Josh Brown suggests creating a different user for analytics in iTunes Connect, which is a really good idea.

Grab Bag

These tools don’t have a defined category above, but deserve a mention nonetheless.

• Quick Radar - Submitting bug reports to Apple is our only way of making their tools better. If you’re frustrated by the lack of a feature, you should be submitting a bug report. If you come across a bug, you should be submitting a bug report. One has no right to complain if they have not yet filed a radar :). With that in mind, submitting bug reports via bugreporter feels like a trip back to 1995. Quick Radar is an awesome little app that makes submitting bug reports super easy. Sports automatic posting to open radar so others can see it, in addition to tweeting, and posting to App.net. I use this app several times per week.

And there you have it. A gigantic wall of tools. Hopefully you learned about a few new ones you can add to your arsenal. If you enjoyed this post, please check out my iOS screencasts over at NSScreencast.

• The iOS Developer’s Toolbelt
• Jenkins - Your personal butler for iOS automation

I hope to see you there!

On my previous MacBook Pro I opted to remove the superdrive and install a 2nd 7200 RPM drive for larger storage. This worked well, but the retina MacBook Pro has no such capability, so I went on the lookout for an external drive to store NSScreencast videos.

Requirement #1: Speed

The first requirement was that the drive had to be fast. Ideally I’d record directly to the drive and then I’d be free to move it over to the iMac and just plug it in.

Requirement #2: Connections

My MacBook Pro has Thuderbolt, which, at 10 Gb/s, is very attractive. However my late-2009 iMac does not have Thunderbolt, this severely limits my options.

My MBP has USB 3.0 ports, and most (if not all) USB 3.0 drives are backward compatible with USB 2.0. For reference, USB 3.0 speed is 5Gb/s, and USB 2.0 is 480 Mb/s.

This means, provided we had a fast enough drive, a Thunderbolt connection could yield up to 1.25 Gigabytes per second data transfer. This is crazy fast, and unfortunately there isn’t a drive on the planet (yet) that reads or writes this fast.

Requirement #3: Size

Most of the time when going for an external drive it is for backup reasons, so size is king. But in my case I was willing to forego size for the right drive.

The Drives

Initially I was eyeing this Buffalo 1TB Thunderbolt USB 3.0/2.0 Drive because it seemed like it would satisfy both connectivity and size requirements. But on further inspection, they seem to have just placed a 5400 RPM drive in here. A few reviewers posted their transfer speeds, and looks to be around 80 MB/s. Considering that a 1TB external USB 3.0 drive is only around $100 these days, this drive (at $200), was clearly not a good choice.

I recently got a USB 3.0 Western Digital 2TB My Passport for time machine backups, which replaced an older 7200 RPM drive in a 3rd party USB enclosure.

The 7200 RPM drive was my baseline. It’s been a handy external drive for a long time, but being USB 2.0, it was going to be the slowest possible choice.

I realized that to saturate USB 3.0 at 5Gb/s, I’d need a drive that can write that fast. SSD’s are the clear choice here, and after a bit of research I picked up a 240GB Mercury Electra 6Gbps SSD from OWC. This drive boasts write speeds of up to 500 MB/s!

Along with the drive I purchased their USB 3.0 / 2.0 enclosure.

So the main question is, is it worth it to buy such an expensive drive for your external drive needs? Time to run some benchmarks.

The Tests

I used the freely available AJA Disk Test tool to perform a benchmark. I used the 1920x1080 10-bit video file test with a size of 16 GB. The file is written to disk and then read back again. All drives were empty when performing the test.

Western Digital Raptor 320GB 7200 RPM drive via USB 2.0

This was obviously the slowest of the bunch, but for comparison, this is my baseline. The drive boasted a write speed of 38 MB/s and a read speed of 41 MB/s.

Western Digital 2TB My Passport (USB 3.0)

This drive posted better results that the previous drive, but it doesn’t even come close to saturating the USB 3.0 pipe, which could potentially yield around 625 MB/s. Doing the same test above, this drive benchmarked a write speed of 94.2 MB/s and a read speed of 92.9 MB/s.

OWC Mercury Electra 6G SSD - 240GB via USB 3.0

This drive is slightly held back by being on a USB bus rather than direct SATA connection, but still posted impressive speeds. The test resulted in a 284.3 MB/s write speed and a 250.7 MB/s read speed.

Conclusion

Here are the read & write speeds for each drive side by side. The result is clear.

The SSD version is more than twice as fast than any packaged USB 3.0 drive out there. In addition, it doesn’t suffer from seek delay, some random access should be much quicker as well. I did noticed that OWC sells their own external SSD (which I wish I had seen before purchasing mine) but I suspect it will receive similar speeds, and the combo I purchased is actually about $80 cheaper.

SSDs continue to kick major ass, so here’s to hoping they drop in price.

Why use a CDN?

Using a CDN has numerous benefits. First, and foremost, this alleviates a bunch of secondary requests that would normally hit your webserver. Loading the home page of NSScreencast loads more than a dozen images, stylesheets, and javascript files. When deploying to Heroku this can be especially problematic as each asset request will occupy one of your dynos for a short time. In the spirit of maximizing your free dyno on Heroku, not sending these requests to your app is definitely a big win.

In addition, most browsers have a setting that limits the number of connections (usually 2) that it will open in parallel to a given domain. By using a CDN, you can increase the number of parallel requests because these assets are not served up by your application’s domain.

It’s also a common practice to use dns to “alter” the domain so that you can maximize this parallelization.

Using the asset sync gem

Following the instructions on Heroku’s Devcenter article I decided to use the asset_sync gem. This gem will upload your compiled assets to your preferred CDN (any file storage server that fog supports). In my case, I wanted to use S3.

The first step is adding this gem to your Gemfile:

1
2
3
4

group :assets do
  # other asset gems
  gem 'asset_sync'
end

It’s important to put this in your asset group, as your running app doesn’t need to load this into memory.

Then you need to configure the gem. I found Heroku’s instructions to be lacking here, as I had to dig into the asset_sync github page to make this work.

Add a file called config/initializers/asset_sync.rb to your app:

1
2
3
4
5
6
7
8
9
10
11
12
13

# Since this gem is only loaded with the assets group, we have to check to 
# see if it's defined before configuring it.
if defined?(AssetSync)
  AssetSync.configure do |config|
    config.fog_provider = 'AWS'
    config.aws_access_key_id = ENV['AWS_ACCESS_KEY_ID']
    config.aws_secret_access_key = ENV['AWS_SECRET_ACCESS_KEY']
    config.fog_directory = ENV['FOG_DIRECTORY']

    # Fail silently.  Useful for environments such as Heroku
    config.fail_silently = true
  end
end

That last config line is important. When you deploy to Heroku, your app’s assets will get precompiled. But because Heroku doesn’t initialize your app on precompile, none of your settings will be available. Instead we’ll have to run the precompile again, manually, to get AssetSync to kick in.

Setting up the configuration with Heroku San

Since I like to have multiple environments, I use heroku_san to manage them, including the environment variables.

Inside of config/heroku.yml, set up the following for each environment:

1
2
3
4

FOG_PROVIDER: "AWS"
FOG_DIRECTORY: "nsscreencast-assets"
AWS_ACCESS_KEY_ID: "<your access key>"
AWS_SECRET_ACCESS_KEY: "..."

Configuring Your Rails app to use S3 as an Asset Host

In your config/production.rb (and staging.rb if you have one), make sure to add the following line to allow Rails to generate the appropriate links for your assets:

1
2
3
4

  config.action_controller.asset_host = Proc.new do |source, request|
    scheme = request.ssl? ? "https" : "http"
    "#{scheme}://#{ENV['FOG_DIRECTORY']}.s3.amazonaws.com"
  end

This will allow your app to serve up the URLs using SSL if the request is coming via SSL. Doing this can avoid warnings in the browser that your app contains secure and unsecure content.

Testing it all out

If all of this is configured correctly, you can test it out by doing a push…

1

git push heroku master

You’ll see the asset precompile going on in the logs, and likely an error related to AssetSync. This is fine (and in fact, this tripped me up at first). Once the deploy has completed, you’ll have to run this command to upload your assets:

1

heroku run rake assets:precompile --app <yourapp>

Doing this, you should see something like the following output:

1
2
3
4
5
6

Precompiling assets...
Uploading: application.css
Uploading: application.css.gz
Uploading: image1.png
Uploading: image2.png
...

Set up Heroku San to do this on every deploy

I’d likely forget to run this command every once in a while, so I set up Heroku San to run this command after every deploy.

To do this, add a new rake task in your app (lib/tasks/deploy.rake):

1
2
3
4
5
6

task :after_deploy do
  HerokuSan.project.each_app do |stage|
    puts "---> Precompiling asssets & uploading to the CDN"
    system("heroku run rake assets:precompile --app #{stage.app}")
  end
end

Now when you run your deploy via rake production deploy this will happen automatically.

So what’s the net result?

Doing this alleviated nearly 30 secondary requests to my application for each page load. That alone is pretty huge. Also, S3 is much faster at serving these assets than nginx is (at least via a Heroku app on 1 dyno).

I tested this before and after by clearing the cache and doing a fresh page load. Using the Chrome Inspector, I looked at the time to load the page and all assets. Here are my findings:

That’s a huge gain for a minor change in your application & deployment process.

• Objective-C Basics
• Diagnosing Memory Problems

Now that the site has launched, I can share more details with you about it.

A new video each week

Each week, a new video will be posted covering a single, focused topic related to iOS development.

Don’t waste the listener’s time

Each video will be short and to the point. It boils down to this: a 20 minute video is an easy thing to watch. A 60-minute video is a serious time commitment.

Some Free, Some Paid

Eventually, NSScreencast will be a subscription service. I’ll announce details once they are nailed down, but for now, enjoy the videos! If you’d like to be notified when an episode is released, you can subscribe to the RSS feed, or follow @nsscreencast on twitter. (Subscribing in iTunes is coming soon)

If you have any video topic suggestions, feel free to share them at the User Voice Forum. Seriously, I’d love to hear your feedback!

Video training is becoming a very common way to learn these days. With Tekpub, Peepcode, Pluralsight, Code School, and many others, there are usually great productions to teach you any development topic that you’d want to learn about.

All of these services are great, however I’m becoming a fan of the smaller, more focused screencasts. Railscasts, for instance, has been instrumental to my Rails learning development. Destroy all Software teaches me new things every week.

Smaller videos like this are easier to digest, and are more focused on a single topic. Like the boiled frog you eventually realize how far you’ve come on a topic, simply by watching regular videos.

iOS Development is an ever-changing landscape, with so many topic areas to cover, that a single training class or screencast series just can’t teach you all of it. Instead of trying to cover everything in depth (increasing the length of videos). I find it valuable to have smaller, focused tutorials that teach you one thing, and do it quickly and effectively.

Introducing NSScreencast

NSScreencast will be launching soon and will feature regular bite-sized videos focused on a single topic related to Objective-C and building iOS applications.

NSScreencast will include free videos. Down the road, a nominal paid subsribtion will unlock access to more content.

I still have lots to do before I release the first video, but if you like the idea, please sign up on the site to be notified when it launches. Thanks!

The block based APIs are generally easier to read & follow, and don’t clutter up your class with methods that are out of context with the code that might potentially invoke them.

An Example

One good example is view animations. Here we’re fading out a view and removing it from the hierarchy once the view has been completely faded out. It’s concise, easy to read, and you don’t need to go anywhere else in the class to get a complete picture of how this works.

Also, since you can have multiple animations going on, having a block-based completion handler means you don’t have to distinguish between what the animations were in some generic completion method.

1
2
3
4
5

[UIView animateWithDuration:0.5 animations:^{
  someView.alpha = 0;
} completion:^ (BOOL finished) {
  [someView removeFromSuperView];
}];

Contrast this with the non-block version:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

- (void)fadeOutView {
  [UIView beginAnimations];
  [UIView setAnimationDuration:0.5];
  [UIView setAnimationDelegate:self];
  [UIView setAnimationDidStopSelector:@selector(animationDidStop:finished:context:)];

  someView.alpha = 0;

  [UIView commitAnimations];
}

- (void)animationDidStop:(NSString *)animationID finished:(NSNumber *)finished context:(void *)context {
  [someView removeFromSuperView];
}

Block-Based Notification Handlers

NSNotificationCenter also got some block love when iOS SDK 4.0 came around. The old form looked like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

- (void)setupNotifications {
  [[NSNotificationCenter defaultCenter] addObserver:self
                                           selector:@selector(onWhizBang:)
                                               name:MyWhizBangnotification
                                             object:nil];
}

- (void)onWhizBang:(NSNotification *)notification {
  // reload the table to show the new whiz bangs
  [self.tableView reloadData];
}

- (void)dealloc {
  [[NSNotificationCenter defaultCenter] removeObserver:self];
  [super dealloc];
}

This isn’t a lot of code (and it is easy to remember, unlike the previous UIView animation block code), however the action and the notification handler are separated from each other.

The block-based API looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

- (void)setupNotifications {
  [[NSNotificationCenter defaultCenter]
      addObserverForNotificationName:MyWhizBangNotification
                              object:nil
                               queue:[NSOperationQueue mainQueue]
                               block:^(NSNotification *notification) {
                                 //reload the table to show the new whiz bangs
                                 [self.tableView reloadData];
                               }];
}

- (void)dealloc {
  [[NSNotificationCenter defaultCenter] removeObserver:self];
  [super dealloc];
}

Aside from some funky indentation, this is preferable in some cases, especially when the action to be completed is as simple as reloading the table.

But there’s a bug. Can you spot it?

Blocks Are Closures

There’s a subtle bug here that you might not notice at first. I didn’t realize this until it was littered all over my code base.

Blocks are closures, and they will capture any values declared outside the scope of the block (and retained) so that they can be used when the block executes. This includes variables declared in the enclosing method or any ivars that you reference from inside the block.

Here, we used self.tableView. self gets retained by the block, which is also retained by self. We have a retain-cycle which is generally a bad thing. It’s especially bad here, because we don’t clear out the block until dealloc, but dealloc won’t ever be called because the block is retaining the instance!

Weak Pointers Save the Day

If you’ve read up on blocks, you’ve probably seen the __block keyword. This specifier tells blocks not to retain the pointer. So all we need is a new pointer, like so:

1
2
3

__block MyViewController *weakSelf = self;

// use weakSelf in the blocks, instead of self

This sort of code drives me nuts. It won’t be apparent to the next developer why it’s there, and it’s pretty ugly.

Retain Cycles are Elsewhere, Too

You might also run into this if you have a parent-child view controller relationship, or perhaps a an parent->object->delegate chain, where the parent is the delegate. This is why you typically mark your delegate property signatures with assign instead of retain semantics.

Not all retain-cycles are terrible though. If you have a way of breaking the cycle, then you just need to weigh how long these objects will remain active for to decide if you need to fix it.

Hopefully this will save you a few headaches down the line.

A typical request might look like this:

1
2
3
4
5
6
7
8
9

HTTP 1.1
GET /foo/bars.json

Headers:
    Accept-Encoding = gzip;
    Accept = application/json
    Authorization = "cHOLIOb7bAeqFEmsz3io%2Bxg4sQA%3D";
    Account-Id = 201;
    User-Agent = "...";

The Authorization header is generated by concatenating the HTTP Method, URL, any parameters, and then signed with a key.

Because of this security, it is very difficult to create adhoc requests just to try them out. So instead, we have our iPhone app NSLog the proper curl command for us. Now it’s as simple as copy & paste from the Xcode Console, which gives me a less-than-readable output of the JSON.

Usually for this I just pipe the command into pbcopy to get it on my clipboard, then I visit JSON Lint to make it easy to read.

Doin’ it all from Terminal

I looked at ways of doing this all from the Terminal, and came across this python command:

1

python -mjson.tool

It takes input from stdin and outputs it formatted nicely. Sweet! Now all that’s needed is to make this a bit more easy to remember, so I made a script to do this for me called format_json and put it in my path.

Now, any time I want to see the JSON output of an API, I can simply type:

1
2

$ curl some.server.com/api/devices.json?key=124512312 -H Authorization:"124151231231123123" |
    format_json

And here is the output:

1
2
3
4
5
6
7
8
9
10
11
12

{
  "devices": [
      {
          "device_id": "40f4fc8a5818608dbb9a6c981179222b6f",
          "device_type": "iPhone",
          "id": 24,
          "name": "Ben's iPhone",
          "push_enabled": true,
          "push_token": "a3a36......480c25fdf"
      }
  ]
}

Very handy, indeed.

I gave three talks:

• Rails Intrigue
• Introducing a new feature to a Rails app using Cucumber (with Claudio Lasalla)
• Wrangle your source like a boss with git

You can find the slides & code used in the presentations here on github.

If you attended any of these sessions, I’d really appreciate if you rate them using the links above.

See you next year, Houston Tech Fest!

Instead of competing with another site with the same name for traffic when we could be sharing it, I decided a new name was in order.

I now present to you: AppKickstand.

For an example of what it looks like with real apps, check out Giggle Touch or Tally Things.

If you have an iPhone app, what are you waiting for? It’s FREE!

There are a number of options you can use to share settings between machines, but I’m a fan of using Dropbox (referral link). Any change I make, on either machine, will get automatically synchronized for me.

Since my Vim configurations were already present on my MacBook Pro, the first step was to copy them over to a Dropbox folder:

1
2
3
4
5

mkdir ~/Dropbox/vim
cp -R ~/.vim ~/Dropbox/vim
cp ~/.vimrc ~/Dropbox/vim
cp ~/.vimrc.local ~/Dropbox/vim
cp ~/.gvimrc ~/Dropbox/vim

The next step was to come up with an installer script that would symlink these files on a new machine. I made sure to move existing vim files to a temporary filename so that I wouldn’t lose anything accidentally.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

set -o errexit

function confirm()
{
    echo -n "$@ "
    read -e answer
    for response in y Y yes YES Yes Sure sure SURE OK ok Ok
    do
        if [ "_$answer" == "_$response" ]
        then
            return 0
        fi
    done

    # Any answer other than the list above is considerred a "no" answer
    return 1
}

function link_file() 
{
  echo "symlinking $1"
  ln -s "$PWD/$1" "$HOME/$1"
}

echo "This will remove any existing vim configuration files and simlink them with the files here."
confirm "Are you sure?"
if [ $? -eq 0 ]
then
  for file in ~/.vimrc ~/.vimrc.local ~/.gvimrc
  do
    if [[ -f $file ]]; then
      echo "Moving $file to $file.bak"
      mv $file $file.bak
    fi
  done

  for dir in ~/.vim
  do
    if [[ -d $dir ]]; then
      echo "Moving $dir directory to $dir.bak"
      mv $dir $dir.bak
    fi
  done
fi

echo "symlinking"

for file in .vim .vimrc .vimrc.local .gvimrc
do
  link_file $file
done

echo "Done.  Check that it works.  If so, you can remove the .bak files, if any"

Make sure the script is executable by running:

1

chmod +x setup.sh

Then run this script on any new machine that you want to use Vim on. It will symlink these files from your Dropbox folder to your home folder:

• .vim/
• .vimrc
• .vimrc.local
• .gvimrc

After it’s done, check that it is working. Remove any .bak files that you don’t need anymore.

And that’s it. You have an automatic Vim configuration synching system between machines. It works great for your shell configuration as well!

I wanted to achieve a similar effect for the iPhone app that I’m building, Deli Radio (app store link).

If you’ve ever struggled with the flip transitions before, you probably know how finicky it can be to get it all working. The best way to set it up is to have a parent view contain both views that you want to swap, and set the animation transition type on that view.

For a button (either in the navigation bar or elsewhere) we’d need to introduce a parent view to achieve this effect. This is how I achieved the effect.

First, I had two images I wanted to use for my UIBarButtonItem.

I wanted this to be easily reusable (since I need to do this in more than one place in this application), so I created a category method on UIButton.

It may look strange that a UIButton class method returns a UIView instance, but we need to have a container view to base the animations off of.

Here is the implementation:

I am using a little-known technique of setting associated objects using objc_setAssociatedObject(...). This uses the runtime to attach state to an existing class without needing to subclass.

Now that you understand how it is all setup, the block body will now make sense:

Usage is really easy. I just created a bar button item with a custom view, and was done.

1
2
3
4
5
6
7
8
9
10
11
12
13

UIImage *firstImage  = [UIImage imageNamed:@"btn-info.png"];
UIImage *secondImage = [UIImage imageNamed:@"btn-images.png"];
UIView *container    = [UIButton flipButtonWithFirstImage:firstImage
                                              secondImage:secondImage
                                          firstTransition:UIViewAnimationTransitionFlipFromRight
                                         secondTransition:UIViewAnimationTransitionFlipFromLeft
                                           animationCurve:UIViewAnimationCurveEaseInOut
                                                 duration:0.8
                                                   target:self
                                                 selector:@selector(flipContent)];

self.navigationItem.rightBarButtonItem = [[[UIBarButtonItem alloc]
  initWithCustomView:container] autorelease];

The effect can be seen below.

Note that the flip effect on the main view is achieved separately, but the 2 strategies share identical values for the animation, so the flip transition types match, as well as the duration & animation curve.

The code for this can be seen in the ChaiOneUI project on Github.

This can be accomplished with images, however I needed a series of buttons to have the same glow effect, and it can easily be accomplished with Core Graphics.

The first step is to include the Core Graphics headers:

1

#import <QuartzCore/QuartzCore.h>

Next, the effect is achieved by using a shadow with no offset (meaning the shadow will be directly underneath the text, not shifted down or to the right). The layer is then given a shadow radius & opacity to allow the shadow to bleed outward. Unsetting masksToBounds will allow the glow to be drawn even outside of the label’s frame. Finally the shadow color is set to either the foreground color or something a bit lighter.

1
2
3
4
5
6

UIColor *color = button.currentTitleColor;
button.titleLabel.layer.shadowColor = [color CGColor];
button.titleLabel.layer.shadowRadius = 4.0f;
button.titleLabel.layer.shadowOpacity = .9;
button.titleLabel.layer.shadowOffset = CGSizeZero;
button.titleLabel.layer.masksToBounds = NO;

This effect works on plain UILabel or the titleLabel property of a UIButton. You can see the results of the effect here:

Don’t go overboard with this. It’s a subtle effect, but looks great when used effectively.

The biggest reason was probably that I never set up a proper website for it. Doing a search would only yield a blog post that said it was “coming soon.”

That’s all changed now. I’d like to introduce App Sites.

App Sites

The premise is simple: standup a website for an iPhone app in minutes.

Check it out here: http://appsites.heroku.com.

You can see the site in action by visiting the Giggle Touch page.

It’s free (for now) and gives you the ability to add features, a description, a link back to the app, and a screenshot.

Planned upcoming features include:

• Custom domains
• Multiple screenshots
• Videos
• Coming soon (if the app hasn’t launched yet)
• More analytics

If you have an iPhone app, I encourage you to create a page. Let me know what you think!

And get visual frame debugging information like this:

You can also click & drag your mouse to get pixel information, surrounding frames, print out detailed frame information in the console, and even move frames around all while the app is running.

Using it is incredibly simple:

• Make sure you have DEBUG defined in your Preprocessor Macros:

• Download the code from https://github.com/domesticcatsoftware/DCIntrospect and drag the DCIntrospect/DCIntrospect folder into your project

• In your Application Delegate class, make the following changes:

1

    #import "DCIntrospect.h"

1
2
3
4
5
6
7

// in applicationDidFinishLaunching:

[self.window makeKeyAndVisible];

#ifdef TARGET_IPHONE_SIMULATOR
    [[DCIntrospect sharedIntrospector] start];
#endif

Once that is done, the library will be loaded and you can use it. When the simulator launches, just press Spacebar to activate the tool.

Here are some keyboard shortcuts:

• o - Outline all views
• ? - Prints out a help view
• f - Flash on drawRect: calls
• c - Toggle showing coordinates
• 4 6 8 2 - Nudge the selected view left, right, up, down
• 0 - Recenter view where it was originally
• 9 7 3 1 - Modify Width & Height of selected view

You can also click & drag with the mouse to get detailed information about frames & mouse position.

I am amazed at how awesome this library is. I’ll be using it in my default toolbox from now on.

Error detected while processing function 87_JSLint: Line 33: could not invoke JSLint!

It seems many are having this issue. There are 2 things to check:

1. Make sure you have Node in your path. Confirm this by typing which node and make sure it resolves a binary somewhere on your system.
2. Open up your ~/.vimrc.local and add this command:

1
2

" Use Node.js for JavaScript interpretation
let $JS_CMD='node'

Kudos to eventualbuddha for figuring this out.

Roy Osherove, a fairly well-known .NET developer and author of The Art of Unit Testing, ventured into Ruby-land recently and commented on twitter about how Rails’s definition of unit & integration is quite different from his.

I have to agree with Roy. Those in the TDD camp in .NET understood the difference and were (from my experience) fairly cognizent of isolating concerns and not mixing the 2 concepts. Some even go as far as to isolate integration tests into their own assembly, providing a physical separation further guaranteeing that a unit test project won’t touch web services or the database.

It’s easy to assume from the outside that the Rails is just testing nirvana and that everyone does it and it’s so easy. Unfortunately it’s just not the truth. Rails (and Ruby) make testing really easy but that means it’s even easier to do the wrong thing as well.

Legacy Rails Apps

Now that Rails is (gasp) over 7 years old you’re starting to see some real legacy Rails applications out in the wild.

Avdi Grimm has a good post on the topic of how many of the Rails apps he comes to work on are in poor shape, technically.

Here are a few examples, just to give you an idea of what I’m talking about:

“Design Patterns are a Java thing. In Ruby you just write code.”

“The warnings Ruby produces are dumb; just disable them.”

“Sure they aren’t technically Unit Tests, but isolating objects turned out to be kind of hard and besides nobody else is doing it.”

“Stuff like the Law of Demeter isn’t really as important in Ruby code”

“That’s only a problem in large projects” (implying that this project will never become large).

I’ve certainly been guilty of some of this. Rails makes it easy to do things that can turn out to be problematic. As with anything, you have to be disciplined to notice the warning signs and act accordingly.

When testing is painful, you’re likely making mistakes. Some common pain-points that I’ve experienced are:

• No tests - the app is hard to test because the design is poor. Classes are too tightly coupled and don’t have clear delineation of responsibilities.
• Tests break for unrelated reasons - the tests are covering too much behavior, so when a single behavior changes, many tests break.
• Tests break when implementation changes - the tests are probably utilizing too much mocking & stubbing. The tests are coupled heavily to a particular implementation.
• Unclear what the problem is when a test breaks - Tests are probably too coarse-grained and may contain too many assertions per test.

These are just a sampling of what I’ve personally observed.

So why do many Rails developers ignore these concepts?

Pragmatism at work

Many rails tutorials (and the default Rails template) treats model tests as unit tests. Since Rails models are by default based on Active Record, they have data access baked into their core. Doing proper unit testing means you’re testing a logical unit. If your test involves a model operation that requires a database round-trip, that’s technically an integration test. But does it really matter?

Most Rails developers will tell you no. Consider this spec:

1
2
3
4
5

describe Post do
  it "should be initially unpublished" do
    Post.new.published.should == false
  end
end

This is a unit test. It tests a single piece of functionality and will fail for just one reason.

Now, here’s another example:

1
2
3

it "should fetch published articles" do
  # ?
end

1
2
3
4
5
6

# post.rb
class Post < ActiveRecord::Base
  def self.published
    where("published_at <= ?", Time.now)
  end
end

How should you implement this spec?

If you were trying to avoid hitting the database you might intercept the where call and assert the parameters passed to it. But surely this isn’t the only way you could implement this method giving the same behavior. You might use scopes or another where call might actually be added later that doesn’t affect the outcome of this method in any way that this test is concerned about.

1
2
3
4
5
6
7

it "should fetch published articles" do
  3.times { Factory.create :article }
  future_post = Factory.create :article, :published_at => 2.days.from_now
  posts = Post.published
  posts.size.should == 3
  post.should_not include future_post
end

This test hits the database (numerous times, in fact) but it’s testing exactly the behavior we need. We aren’t testing implementation, we’re testing that the behavior works as intended. If we somehow muck with the query, breaking it, this test will fail. If we change the implementation to use some other query means (scopes or whatever) this test will still pass.

Is it so bad that the test hits the database?

There are drawbacks of course:

• The test requires a database, thus you have to migrate
• The database_cleaner gem will have to be present to clean out the database before each run
• These database statements make the test suite a LOT slower, so large test suites will eventually suffer.
• The tests could fail if the database isn’t present (or migrated), or if the query is incorrect. But this isn’t likely to happen since we’re using a tested framework (ActiveRecord).

Ultimately this isn’t really a unit test at all. It’s an integration test. So is spec/models/post_spec.rb the wrong place for this stuff?

The question eventually comes down to this: What is more valuable? A fast, isolated test suite? Or a test suite that breaks for the right reasons?

Don’t throw out good practices just because it’s Ruby

I think it’s important to be cognizant of software paradigms and use them where they make sense. It’s also important to recognize when practices are being ignored because “celebrities” aren’t touting them.

It is still valuable, however, to keep a fresh eye on old assumptions. Don’t always take things as gospel just because that’s the way they have always been. One of the things I love about the Ruby community is how willing people are to rock the boat & try something new.

The problem is, when you have a non-standard view hierarchy (like my current app) these methods don’t get called. The Apple docs have this to say about the problem:

Warning: If the view belonging to a view controller is added to a view hierarchy directly, the view controller will not receive this message. If you insert or add a view to the view hierarchy, and it has a view controller, you should send the associated view controller this message directly. Failing to send the view controller this message will prevent any associated animation from being displayed.

In my application I have a persistent bar at the bottom of the screen, so my UINavigationController only owns a portion of the screen. Thus, my RootViewController (which owns these 2 portions) is always active.

I recently came upon a requirement that needed to leverage viewWillAppear: and viewWillDisappear: in order to decorate the bottom bar with some additional information. Since this is a view controller a few layers deep in the hierarchy, the methods weren’t being called.

Luckly, there is a fix to this. The navigation controller can notify its delegate when it changes view controllers.

Start off in the view controller that is the root of the navigation controller hierarchy. Make it conform to the UINavigationControllerDelegate protocol. We’ll also need an ivar to store the last view controller that appeared so that we can notify when it disappears.

1
2
3
4
5
6
7

@interface MyRootViewController : UIViewController
    <UINavigationControllerDelegate> {
      UIViewController *_lastViewController;
}
// methods

@end

In the implementation, in do the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

    @implementation MyRootViewController

    // other stuff

    - (void)viewDidLoad {
        [super viewDidLoad];

        self.navigationController.delegate = self;
        // ...
    }

    - (void)navigationController:(UINavigationController *)navigationController
          willShowViewController:(UIViewController *)viewController animated:(BOOL)animated {
        if (_lastViewController) {
            [_lastViewController viewWillDisappear:animated];
        }

        [viewController viewWillAppear:animated];
        _lastViewController = viewController;
    }

If you need support for viewDidAppear and viewDidDisappear then you’d have to implement this method as well:

1
2
3

- (void)navigationController:(UINavigationController *)navigationController
       didShowViewController:(UIViewController *)viewController
                    animated:(BOOL)animated;

After doing this, your view controllers should start receiving the viewWillAppear: and viewWillDisappear: methods successfully.

The reasons? Mostly because I’m questioning more & more the need to have a dynamic blog that I need to maintain. Static HTML blog generators are very interesting and I thought I’d give one a try.

I’ll leave this one around for historical reasons. It gets a decent amount of traffic and has content going back to 2004.

So without further ado I present my new blog, Fickle Bits.

(Note to RSS readers, your feeds will not auto-update. Subscribe to the new blog here: Subscribe )

I still use TextMate frequently, but I’ve been ramping up on my Vim skills and I’ve recently come to a point where I think I’m pretty productive in it.

My initial frustrations with Vim were that it was too configurable. Talk to any Vim power-user and you’ll find a completely different set of plugins & keyboard shortcuts. If you snag a friend’s set of Vim configuration files (like I did) you might find yourself frustrated that there’s too much to learn and it’s difficult to know where various behaviors are coming from.

In this post, I’ll attempt to demonstrate a very sane Vim setup that newcomers can use to get started and not be too overwhelmed.

Why Vim?

Before I get started with the basics of Vim, why would you use it in the first place?

For me it boils down to this: I love staying on the keyboard. Vim may not make you faster (in fact initially you’ll be a lot slower) but it can fit your workflow better.

Another big differentiator of Vim is Command Mode. The notion here is that you spend more time wrangling text rather than creating it from scratch. That’s certainly true of my code.

It is important, however, that in the larger software ecosystem, typing is not the bottleneck. Don’t expect Vim to make you build the right software faster.

Vim enables a keyboard-optimized workflow that may make you faster. YMMV. If you’re fast with TextMate or Emacs or don’t want to spend the time to learn something new, then Vim may very well not be for you.

Lastly, Vim is ubiquitous. It’s on every platform and you can carry your configuration (or a very large set of it) everywhere. People frequently put their vim configurations on Github for themselves and others to utilize.

Getting MacVim

Almost all Unix-based systems (like Mac) include a terminal version of Vim. The version included on OS X isn’t compiled with Ruby support, so some plugins won’t work. In addition, it doesn’t have OS-level integration like Copy & Paste in the same buffer.

Most Vim users I know use MacVim, which comes pre-compiled with Ruby support, has tabs, and more.

If you have homebrew installed, just type:

1

brew install  macvim

If you’d rather grab a pre-built binary, then head on over here.

You’ll also want to make sure that the mvim binary is in your path.

Basic Vim Navigation

I won’t cover everything you can do in Vim here, but here’s just enough to get you started:

In Command Mode:

• Press h, j, k, l to move the cursor around. It will feel weird, but you start to appreciate not lifting your hand off of the home row to reach for the arrow keys.
• Press G to go to the end of a document, gg to go to the top of the document.
• Press i to go to insert mode at the current position
• Press I to insert at the beginning of the line
• Press a to “append” content after the cursor
• Press A to “append” content at the end of a line
• Type cw (“change word”) to replace the current word and go into insert mode
• Type dta to (“delete ‘til the letter a”) in a line

In Insert Mode:

• Press esc to go back to command mode.

Commands:

• In Command Mode, you can type commands by prefixing them with :.
• To write the changes to the current buffer (save) type :w and hit enter. Often times you’ll write & quit in one command, with :wq.

Feel free to use the mouse & arrow-keys while you’re getting used to everything. It will feel weird.

For more Vim-fu, definitely check out this PeepCode screencast.

Installing a Base Set of Plugins with Janus

The real power of Vim is in the plugins, and fortunately Yehuda Katz & Carl Lerche have put together an opinionated and useful set of plugins that are pre-configured and work well together. Take a look at the plugins it includes here.

Getting Janus installed is easy. If you are super trust-worthy and don’t mind running a script blindly (I don’t recommend it) you can simply run:

1

curl https://raw.github.com/carlhuda/janus/master/bootstrap.sh -o - | sh

More explicit instructions for the paranoid can be found on the github page.

Once you have Janus installed, your Vim will be on steroids. Don’t worry though, I’ll try to cover the most important things you’ll be using.

Getting a Decent Theme installed

MacVim installs a hundred nasty looking themes, but a few of them are worth taking a look at. Here are some that I like:

• molokai
• railscasts
• vividchalk
• vibrantink

If you want to install other themes (like this nice github one) then you simply download it & copy the theme.vim (or whatever the theme is called) to ~/.vim/colors.

To switch between the themes that are installed, you can use the menu, or you can type :colorscheme <scheme>.

To set defaults for your installation, you’d normally add commands to ~/.vimrc however Janus has taken that file over. It instead reads your settings from ~/.vimrc.local. In order to provide settings for graphical Vim installations (like MacVim) there’s also a ~/.gvimrc file.

Open up that file (:edit ~/.gvimrc) and add the following commands:

1
2

colorscheme github
set guifont=Menlo:h14

Feel free to tweak this to contain your favorite color scheme & font. In order to see these changes you have to “source” the file:

1

:source %

(% here means “current file”)

You should see the changes take effect immediately.

Opening MacVim with a “Project”

One common thing in TextMate is to cd into a project and then type mate . which will open TextMate’s project drawer with all of the files in that directory loaded up.

In MacVim, you can do the same. Navigate to a folder with some content (like a Rails app) and type: mvim .

You should see something resembling a file navigator. You can navigate these with the same movement commands from above.

Once you’ve chosen a file, press enter to open it in the buffer.

Janus comes with NERDTree, which has similar behavior to TextMate’s Project Drawer. Open up the NERDTree pane by typing <leader>-n or \n. By default the leader key is set to backslash. The leader key is a special, configurable key used to create quick shortcut combinations.

The NERDTree window can be collapsed by typing <leader>-n again.

You might want to instead find the file by searching for it by name. For that, the aptly-named Command-T plugin can be hepful.

Command-T can be activated (by default) with <leader>-t. Start typing and it will auto complete the results.

Scared Yet?

Writing this reminds me of how hard it was to get started. I can only offer some encouragement that with practice, Vim does start to feel like you can leverage your fast typing skills to really.

Practice only a couple of commands at a time. Really learn what they are doing and then move one to the next command. Print out a cheet sheet. Pair with someone else who uses Vim.

I hope you found this intro useful. I’ll cover some more Vim tricks as time goes on.