CocoaRadio - Ash Furrow on Swift

Swift has been all the talk of the iOS and OS X community these past few months since Apple’s announcement. It’s finally time that we discuss the new language here on CocoaRadio. I called up my friend (and noted Canadian) Ash Furrow to give us the low-down on the ups and downs of Apple’s new language.

We discuss our thoughts on why Apple may have created the new language, what’s good about it, and what is missing from the potential 1.0.

A Sponsor Note

CocoaRadio is shifting away from sponsors in the coming weeks for a new model. In the interim, if you would like to show your support for the show, please consider tweeting about it, writing a blog post, or mailing a link to this episode to your friends and colleagues. Thanks for your support of the show.

CocoaConf Vegas

CocoaConf is going to Vegas this fall. I’ll be there. Other great developers will be too. What’s not to like?

They aren’t paying for this post or anything. I just like the Kleins (the nicest family in tech) and enjoy speaking at their events. I also love Las Vegas, and would enjoy spending time with some of you there.

Use promo code ‘JUSTIN’ and you’ll save 20% on a ticket.

Register Today

Beta Testing A Book

When I decided to ship Achieving Zen With Auto Layout, I knew I didn’t want to wait until the book was completely done before unveiling it to the public. The old way of publishing involved writing a book in a vacuum, throwing it through a bit of tech editing and then putting it on the shelves at Barnes and Noble.

I have a graveyard of books that are out of date or have a few technical inaccuracies, because they were printed to paper and unable to be updated without checking an Errata page on a publisher’s web site somewhere.

Tech publishers have started doing an “early access” program with their digitally published books as soon as a few chapters are available, which allows early readers to provide feedback to the author along the way of writing.

That seems like a much better way to write a tech book to me, so I shamelessly copied it.

Of course, I don’t have a publisher, so I’m doing all of this on my own. Here’s a few of the tools I’m using and how they all piece together for running.

Gumroad

I am using Gumroad to handle selling and distributing my book. There’s a few different vendors you can work with to do this sort of work, but I found the Gumroad interface to be incredibly easy to work with, and their analytics data is just enough to keep me interested, but not overwhelmed.

It also doesn’t hurt that their fees aren’t too high, especially coming from an Apple world where they want 30% of everything.

Gumroad collects the payments and then distributes a PDF of the current state of the book to people as soon as they purchase. They also support Webhooks, however, which I am taking advantage of. Each time a purchase is made, their WebHook fires an API I’ve set up on Azure.

Azure Mobile Services

Azure Mobile Services is the Backend-as-a-Service offering that Microsoft has for developers to easily integrate a server-side component into their iOS, Android, or Windows app. If you’ve ever messed with something like Parse or Stackmob, it’s similar vein to that complexity. You don’t need to provision servers or deal with a bunch of configuration. It handles most of the heavy lifting for you and provides an API for anything you want to get dirty with.

I’m using Azure Mobile Services to host a small API with a single endpoint. To do this, I have a small Javascript…script…that takes the receipt data I get from Gumroad, validates it, and then fetches the purchaser’s GitHub username.

Once I have the GitHub username, I make a call to their API to add that username to my private repository that contains the Markdown files of the manuscript as well as all the source code for any sample projects.

In all, it’s maybe 15 lines of code tops. It’s likely not the traditional use case for Azure Mobile Services, but it was way easier to do this than provision a complete WebAPI or Node application and deploy it to a cloud service or virtual machine.

GitHub

Now that I have a GitHub repository with all my beta purchasers on board, they are able to do a few different things:

  1. They can see my progress as I write on the book. I try to only submit chapters that are completed first drafts.
  2. They can file Issues with either requests for topics to cover, or any technical issues they may find in the book.
  3. They can fix my typos (I admittedly never expected anyone to do this, but a few have taken the time. Thanks!)

The second one is the most useful to me. I’m now able to run this book like a semi-open source project and get instant, trackable feedback from the people who are invested in the project. There’s no middle man in between. It’s just me and the readers working together to make Achieving Zen With Auto Layout the best book it can be.

Achieving Zen With Auto Layout - The Book

tl;dr I am writing a book on Auto Layout. You can purchase it now.

Over the last year I have been criss-crossing the country giving a talk called Achieving Zen With Auto Layout to any conference or user group that would host me. Speaking is not my primary goal. I am not an ex-developer. I just enjoy doing it a few times a year, especially since I spend so much time sitting in front of a computer in a solitary room typing. Even the most antisocial developers need a bit of human interaction.

The talk has been well received far beyond my expectations. Everywhere I have presented has given it high marks and attributed it with helping them get over the hurdles of learning and using Auto Layout in their jobs.

I have had it in the back of my head that I wanted to turn the talk into a book for a while. Every time I have thought about it, however, I have pushed the thought away. Writing a book is hard. Dealing with publishers is a pain. You don’t make much money doing it. Why bother?

Despite all the reasons to not do the book, I kept coming back to the main reason I wanted to do it: I like helping people. I like when people tell me my talk has helped them learn a new technology. I enjoy having people say they learn new things from CocoaRadio.

So, I started writing. Not full-time. Not even part-time. I just started writing when I had time. Over the last few months, I have amassed enough content to generate what I consider to be the first 1/3 of the book.

Achieving Zen With Auto Layout is the eBook companion to my talk of the same name, but with the goal of being much more expanded than what I am able to do in a 45-60 minute on-stage presentation.

This is a beta book right now. There are no screenshots (iOS 8 does still have a tiny bit of NDA that prevents those), copy editing hasn’t been done, and I still need to hire an illustrator to do a cover and some other things in the book for me. Content-wise though, I’m proud of what is there so far, and I’m excited to finish the rest of the book in time for the iOS 8 launch later this fall.

You can purchase Achieving Zen With Auto Layout today and get access to a PDF of the current state of the book, as well as a private GitHub repository where I am writing and storing all the sample code as I go. So far this has proven to be a wonderful way to write, because buyers of the book are able to provide direct feedback to me about the book so I can iron out any confusion or missing things I may not have thought of during my first draft.

If you’ve struggled with Auto Layout in the past, I truly believe Achieving Zen With Auto Layout can help you get over those hurdles.

Purchase “Achieving Zen With Auto Layout”

Passing An Account Object Around

Here’s a scenario I have both in Glassboard and the current client project I am working on.

Everything you do in the app requires that you have an account to authenticate. You’re hit with a brick wall when you launch the app asking you to sign in. Otherwise, the app is 1 star, useless to me.

In a variety of different view controllers I need to reference the user’s account information to be able to display information. A few scenarios:

  • The compose screen needs to know which account you are posting from and whether you have enabled or disabled location.
  • A profile screen needs your personal information such as the user name, password and avatar.
  • An upsell screen needs to know which account is getting upgraded.

Right now I am storing a strongly held GBAccount object in my app delegate controller. I then have a weakly held GBAccount object on each of my view controllers. that I pass whenever I instantiate a new view controller.

This works, but it feels kind of cheesy having to set an account object for each of my view controllers so that it knows about it. On the other hand, referencing [[UIApplication sharedApplication] delegate] account] feels like a mortal sin.

How would you implement this?

Update: I posted this to Twitter and the responses were great.

General consensus seems to have a currentAccount singleton on GBAccount that I can then reference globally. It won’t help if I ever need to support multiple accounts, but in both scenarios (Glassboard and client gig) that shouldn’t ever be a requirement, so no sense in implementing something more complex for an unlikely scenario.