Life is Rich All the time.

Blog

One of the first things that intrigued me with the ease of writing code interactively in the Xcode Playground was the feasibility of using Swift as a possible replacement or supplement to traditional shell scripts. When Chris Lattner (one of the founders of the language at Apple) posted the following on Twitter, I knew I was on to something:

Why would you want to do this? Well, first, Swift is quite easy to build fully functional apps very quickly and efficiently, all while maintaining the full power of Foundation. Swift discards the old syntactical chrome of Objective-C (or more accurately C), particularly the whole requiring of a main() method as an entry point to your program. Combined with the ability to actually run an uncompiled Swift file directly from the command line dramatically reduces the friction of using a complete, powerful, system-level language where only simple, barebones scripts would operate before. Swift can bridge the gap between traditional shell scripts and full blown applications.

One of the first things I started tinkering around with when I got home was making this a reality. It's actually not quite as simple as the tweet, but it definitely is quite doable, and opens up a whole new realm of possible opportunities from the command line. So, let's make this happen.

The first step is ensuring that you have the appropriate Xcode selected. From the terminal, you can determine your currently selected Xcode:

xcode-select --print-path

You are likely still pointed to the original Xcode 5 install that does not include Swift. Unless the response looks something like this: /Applications/Xcode6-Beta.app/Contents/Developer, you need to switch over to the new beta:

sudo xcode-select --switch /Applications/Xcode6-Beta.app

The location above presumes you placed the Xcode 6 Beta in your applications folder. If you chose somewhere else or renamed the app, you'll need to modify accordingly.

At this point, you can actually run a Swift file directly from the command line. We'll show that as well, but we really want to run our file without having to actually type out the xcrun command. Let's go ahead and create a simple Swift application. Open up your favorite editor and create a Swift file (e.g. HelloWorld.swift) with the following first line hashbang to instruct the shell on how to handle what follows:

#!/usr/bin/xcrun swift -i
println("Hello World!")

Don't forget to modify the permissions of your newly created shell script. By default, the script will not be marked as executable. A simple call to chmod will fix this:

chmod +rx # adds read and execute for everyone

or my preferred syntax:

chmod 755 # read/write/execute for owner and read and execute for everyone else

While you could now type the following from the command line to run your program:

/usr/bin/xcrun swift -i HelloWorld.swift

...there is a much simpler way. Due to the hashbang line at the top, you should be able to just type HelloWorld.swift (or ./HelloWorld.swift depending on how your path environment variable is setup) and see the traditional welcoming first words of application life.

Without the traditional main method, you don't have apparent access to the command line arguments. These are made available through the C_ARGC and C_ARGV constants. You can iterate over C_ARGV or address specific arguments directly much like a traditional Swift array.

While this is exciting, we still have one small hurdle. If you attempt to import Foundation, allowing access to the file system or environmental variables or a whole slew of other functionality, you'll receive an odd error. We need to let xcrun know where the SDK resides. If you run your Swift file manually, you can use the following:

/usr/bin/xcrun swift -i -sdk $(xcrun --show-sdk-path --sdk macosx)

Unfortunately, it doesn't appear that the substitution works appropriately when used in the hashbang portion of a shell script. I was forced to paste the results from the 2nd xcrun manually. There may be a better way that I'm unware of — until then, replace the first line of your script with the following:

Obviously, this doesn't really do much useful, but it hopefully triggers some ideas and possibility of the many things you could do. With a small framework to simplify some of the traditional functionality often used within command line shell scripts, Swift could quickly become the go-to tool for developing everything from simple scripts to full blown command-line apps. Go forth and code!

After returning home from a mind-blowing week of WWDC goodness, I’m still trying to wrap my mind around the happenings of the last 5 days. Now begins the race to watch the plethora of videos of unattended sessions, plowing through Apple’s Swift book, and tinkering with my personal projects as guinea pigs for all the new toys uncovered.

The legion of new SDKs and updates and additions to existing SDKs are absolutely astounding. That was all before they dropped the bombshell of Swift. If the keynote had ended right before the Swift announcement, I would have been completely satisfied and pleased with the announcements made. The Swift unveiling was flooring - how did they keep this under wraps? No one was expecting this.

Some gnashing of teeth could be heard for the first couple days after the announcement, but by the end of the conference, the general vibe seemed to be very positive. The more I came to know about the new language, the more impressed I became. It truly is the future of Mac and iOS development (and not only because Apple has all but mandated it to be so).

Authoring a technical book has been on my my bucket list for many years. During my days as a Java developer, I taught a number of casual classes and study groups and became a bit obsessed with reading every Java book available to understand what worked and what didn't. A consultant acquaintance who I discovered was also an author introduced me to Pearson / Addison-Wesley (a book publisher). While I continued to read the same books, now I provided technical reviews and was paid for it! I figured this was a good first step towards becoming an author myself.

After more reviews than I can count, life became busy — both at the office while working on the technology behind the Shazam app and at home with the introduction of my two children to the world. I ran out of time and stopped doing technical reviews. After a nearly 10 year hiatus, I started reviewing books again, but this time in the field of mobile development, and more specifically, iOS and Objective-C. After quite a few reviews of books by the renowned author, Erica Sadun, an opportunity to make my bucket list item a reality presented itself — to co-author a new edition of one of the best-selling iOS books with Erica.

This month, the results of many months of long days and nights comes to fruition. On March 19, The Core iOS Developer’s Cookbook (5th ed) will be available at stores (the electronic variant is already available). While I never could have imagined how much blood, sweat and tears was required (earning an even higher level of eternal respect for all authors), I'm very honored to have the opportunity, and can't wait to have my hands on the physical product of my (and many other's) labor. I hope that many will find benefit from this work.

One of the wonderful elements of my job at Black Pixel is participating in the blog there. The following is a snippet from my recent article on capturing self within blocks.

Occasionally in my software development career, some code or comment will trigger a bolt of fear through my psyche. Were my assumptions incorrect? Have I been doing this wrong all along? Did I ever really understand why I was doing this in the first place? Usually, the response includes stepping back, reassessing with a scientific analysis of the situation, writing some test code, and then reconfirmation (or readjustment) of my assumptions.

Recently, while reviewing some technical reviews of a chapter in a book I’m coauthoring, that familiar pang of fear echoed once again through my consciousness. The target of this loss of faith and understanding revolved around my assumptions and understanding of retain cycles, blocks, and capturing of `self`. As in the past, it was time to solidify and reaffirm the foundation of understanding.

It's been a few years since I've actively blogged. One of the final posts in my long abandoned Wordpress blog was a note detailing a reenvisioning of the site coded from scratch. I guess this incarnation is about as close as I'm going to get to that.

While I didn't build my own blogging platform, I've definitely abandoned the ways of the past by jumping into the world of static site generation and Jekyll. I've also used this as an opportunity to refresh my ancient web skills that were mostly anchored in the early-mid 2000's. This includes playing with fancy tools and frameworks such as SASS (what CSS should be), Compass (helps SASS be what it should be), Foundation (an incredible set of CSS and JS for accelerating site development), and a few workflow / build tools (NPM, Grunt, Bower). Web development has certainly come a long way. That said, I can't wait to get back to native mobile app development! This is a foreign land — while it's fun to visit, it's even better to be home.

My hope is that this site will become a resource for both myself (I tend to be forgetful) and others in a couple ways. First, I intend to create a knowledge base on different Mac / iOS / Development topics — nuggets of information that I'm often trying to recall myself. While I'm recording this stuff here as my own external, latent memory, I might as well make it available to everyone else. Maybe someone will find it useful. Second, I hope to post semi-regular indepth articles on technical topics (mostly Mac or iOS development related, but it may stray to the web or system maintenance on occassion).

Often, these will be written as part of the process of learning something myself. To really be able to explain something to others requires full-committment in understanding. If I don't make that committment, I tend to get lazy and just take things for granted. When I start doing that, I know I've started down a dark path. These articles, whether anyone ever reads them or not, will save me from that dark path.

Please feel free to contact me if you have any suggestions, comments, or concerns!

Blog Categories

About

I am a faithful believer that the highest form of software creation is an art — a worthy craft that must be nurtured and pursued. I’m also obsessed with the creation and form of code that exudes its intent without encouragement.

When not knee-deep in iOS or Mac code or playing with my kids, I enjoy a bit of "tractor therapy” working my little 30 acre farm in rural Georgia, competitive shooting, and making noise on the keys or guitar.