By:
Comments Off

Plans for Swift Books

So WWDC happened, and we were all blown away by Swift. Yay Swift! And one of my reactions afterward was "I want to write a book on this", because that's apparently what I do now. So I created this page where you can register for updates when the book is launched.

Cool, cool. But why, people would ask me, am I writing a book when Apple has two ebooks on Swift already available, for free? Well, I had to think really hard about that. To be honest, I just wanted to write something cool – largely as an excuse to get really good at Swift. So I had to think hard about why I wanted to write about Swift, and after reading the Apple books and getting my hands dirty, it came down to this: Apple's resources are really good at describing the language, but it's not written as a resource for teaching practical knowledge. The book, while excellent, reads like a text book.

I believe this is because Apple – like everyone else in the world – still lacks the kind of practical experience writing production-ready code in Swift. Even the Swift engineers don't know the kinds of new patterns that are going to emerge from the community over the coming months and years.

So that's what I want to write about: practical swift. How do we, as iOS and OS X developers, solve familiar problems with new tools? It would be a shame to ignore this opportunity and just continue to write in Objective-C, but using Swift syntax.

But there's a problem: I don't yet have that practical experience. Hmmm.

About the same time I came to this conclusion, a bunch of people on Twitter (bless you, Twitter people) asked if I was going to updated my existing Your First iOS App book for Swift. Initially I said no, but then I had an idea.

What if I followed my old book's instructions and gained experience building a feature-complete app, in Swift? With Core Data and everything? That'd be really cool, I could write about it, and better yet, I'd get the practical experience I need for my general Swift book. Sweet!

One catch: if I updated my book for Swift, then it won't be available to people who still want to use it to learn Objective-C. My solution is going to be that I create a second book on LeanPub, and the Objective-C one will continue, at least for now. Because the Your First iOS App book was actually the product of a successful crowdsourcing campaign, I feel it would be wrong to make a new book based on the same material without compensating those who already bought the Objective-C version. So that's why, once the Swift version launches, I'll be passing out promo codes good for a free copy of the new book. If you don't want to use it, then pass it along to a friend!

One more thing: I've also gotten questions surrounding my ReactiveCocoa book. I will be updating it for Swift, but only once The Great Swiftening has been completed.

So that's it. My initial thought to create a book in Swift has lead to an updated version of two existing books and writing a whole new one. I'm really, really excited about the next few months, if a little daunted by all the work I have to do.

Oh, and one more thing. My friend over at objc.io are launching a book on functional programming in Swift which you should also consider. It looks super-promising. Also, if you're looking for another Swift resource now, please do check out Daniel Steinberg's A Swift Kickstart on the iBook store.

/Ash Furrow /Comments Off
By:
Comments Off

SwiftCrunch Hackathon

After WWDC, once Swift had been announced, I was contacted by some developers in Poland who wanted to organize the first ever Swift hackathon. Really neat idea – and they wondered if I was interested in giving the keynote.

I accepted and am just finishing up the SwiftCrunch hackathon now. It's been a fantastic experience – I've met a lot of great developers and had a great time.

Here are my slides from the keynote. They don't give a tonne of context, but it was recorded so I'll post the video later once it's up.

There were some really cool projects that developers came up with – not just apps, but tools for developers to use to make their lives easier. One of the most interesting projects is SwiftInFlux, a community-based project for cataloguing the changes that Apple is probably going to make to Swift before 1.0 ships.

My project reproduces Facebook Slingshot's UI for presenting notifications, and it's available on GitHub.

It was a great learning experience – I filed some radars and learned more about writing idiomatic Swift. I'll put together a blog post with some of my findings later.

/Ash Furrow /Comments Off
By:
Comments Off

Lazy Property Setup in Swift

A few weeks ago, I was talking with my friend Robert about Swift. He had a problem. He wanted to create a property of a class that is not an optional, but depends on self for its creation.

The issue revolves around initializers in Swift. If a property is not optional, it must be set before the super's initializer is called. However, in order to refer to self, the super initializer must be called first. It's a chicken-and-the-egg problem. I need to set my properties before calling super.init(), but in order to set my properties, I need to refer to self, which I can't do until I've already called super.init().

Hmmm.

I've come up with a pretty good solution. Consider a UIDynamicAnimator property on a view controller. I need to initialize it with a reference view of self.view, but I'm in the same situation as Robert was. My solution, which came from a talk with Dave Addey at the WWDC labs, was to use a @lazy property that is set to a self-evaluating closure. The closure returns a reference to the initialized dynamic animator, but it since it's lazy, it isn't set until the first time it's referred to.

@lazy var animator: UIDynamicAnimator = {
    let animator = UIDynamicAnimator(referenceView: self.view)
    return animator
}()

The downside, as I can see it, is that @lazy properties must be var and not let, so you lose some Swift-ness there. Still, it's better than having an optional type.

/Ash Furrow /Comments Off
By:
Comments Off

Reflections on Art Basel 2014

My employer, Artsy, sent me to the world's largest art fair last week. It was my first art fair, and let me tell you, I was quite overwhelmed. Three hundred art galleries, each with many different artworks. Two stories of an exhibition centre, plus another floor for art that "transcended the limitations of typical art fairs", plus another warehouse for performance art, plus an entire design show.

Holy. Shit.

I don't have a sophisticated appreciation of art – I'm very new to the art world at large, but have been gaining an eye for good photography over the past few years. I thought I might be prepared.

It started easily enough. I was looking at art I like, turning it over in my head, trying to discern some appreciation from it. Then I started asking questions like, "what even is art?" Then things got trippy. "Can you ever not editorialize art?" Oh boy. Questions I wasn't prepared to answer myself.

The art fair handed out a handy book claiming to have questions and their respective answers. What is art? Well, we don't know. All we know for sure is that art is appreciated. And so on.

It didn't help as much as I had hoped. I was walking around in a haze. Confused by what I saw. Disturbed by some things, aroused by others. It was a confusing and daunting task, to just go and appreciate art. Not just any art, but art that everyone agree is awesome.

And that's when I got it. That's when I realized what the fuck was going on. Here I was, surrounded by the best, coolest art in the entire world, and I had no idea where to even begin.

You know what else used to be unapproachable, accessible only to the upper crust of society? Music. Used to be that the only opportunities to hear and appreciate music were live music.

Technology changed that. We invented the phonograph, and then the 8-track, and the CD and the mp3 player and Spotify and holy shit now everyone loves and appreciates music. Wouldn't it be so cool if we could do that for art?

The art world is hella intimidating. It's unbelievably unapproachable for lay people like me. And that sucks. And that's why the work I'm doing at Artsy matters. I want to make it suck less, because I believe in the importance of art, even if I'm not a sophisticated appreciator yet.

When I set out in my job hunt earlier this year, my most important criterion was that the company had to do good in the world. I feel like I've really found that here. It's why I'm excited to go to work in the mornings, even in the darker days of my depression. I feel like I'm making a positive change in the world, and that's something that neither salary nor anti-depressants can give me. I feel motivated to work because it's intrinsically important.

/Ash Furrow /Comments Off
By:
Comments Off

Me on MacVoices

I was delighted to be interviewed by Chuck Joiner down in San Francisco to discuss Artsy, Swift, and other things. Check it out.

/Ash Furrow /Comments Off
By:
Comments Off

Objective-C is Not Easy to Learn

I read this blog post by Aaron Hillegass this morning and was immediately disappointed.

There are many things that I disagree with about this article, but there is one in particular that I took offence to.

Objective-C is easier to learn than Swift.

Really? Come on now. That's just silly.

Objective-C is a really simple little extension to C.

I'm disappointed by this statement, because it is simply not true. Objective-C is a massive pain in the ass to learn. It's a mix of language (with "weird" syntax), runtime (all that arcane knowledge), and frameworks (massive ones). Swift obviates the difficult with the first two, which is awesome.

Let's consider a simple example.

NSLog(@"Hello, world!");

OK, so let's take a look at this. Why is NS there? Why not just log? And why is there an @ sign in front of the string? That's bizarre! Why doesn't NSLog conform to standard Objective-C syntax?

Pedantic? Maybe. But I'm not the one claiming Objective-C is easier to learn than Swift. Let's take a look at another example. I want an array, called array, of the numbers 1 to 5. Let's contrast.

 NSArray *array = @[@(1), @(2), @(3), @(4), @(5)];

Holy shit. Why is that asterisk there? (Yeah, explain pointers to a newcomer to programming. Have fun.) Again, what's with all these @ signs?! It makes no sense! Why doesn't this look more like the following?

var array = [1...5]

But then, that's Swift.

I'll tolerate people saying that "Swift is complex", either because it's unfamiliar or whatever reason you have. But come on. Objective-C being easier to learn? Give me a break.

As educators, it's our job to put ourselves in the shoes of a beginner and see things through a newcomer's eyes. I don't see that happening in this article.

Aaron Hillegass is an amazing developer and business person. I have admired and looked up to him, and the Big nerd Ranch, for a long time now. However, this post feels like it was written out of fear. I think that it is a disservice to iOS newcomers.

/Ash Furrow /Comments Off
By:
Comments Off

Whelp.

Last week, I attended WWDC in San Francisco. I was in the Bay Area for two weeks in all and spent a lot of time meeting people I know from the Internet.

Since the last time I was at WWDC, I've pulished twobooks, a second edition to a book, started contributing to a number of open source projects, wrote a tonne of iOS 7 tutorials, started another podcast, and doubled my number of twitter followers. Basically, it was a busy year.

In hindsight, it shouldn't have come as such a surprise when I ran into a lot of people who knew who I was. The common refrain from the week was something like:

Hi, nice to meet you. I'm Ash.

Ash... Furrow?

(sheepishly) yeah?

(My friend and colleague Orta says I have a branding problem, but I just can't see myself introducing myself as "Ash Furrow".)

One person who recognized me asked for a photo, since she didn't think her friends back in Melbourne would believe that she had met me.

So yeah. Last week was a big adjustment. I'm not used to attention in the real world, and it's a little uncomfortable to be honest. From a personal perspective, it's something that I think I'm going to have to get used to. And not all attention is desirable – I pissed off a lot of people last week with some strong opinions on Apple's new programming language.

I think what I'm most concerned about is remaining authentic. I answer a lot of questions people have about collection views, ReactiveCocoa, and other topics I've written about. Usually over email or twitter. I always try and answer each question as best I can, but that obviously doesn't scale, and lately, I've been falling behind. It's going to be an interesting problem going forward, and I'm not quite sure what I'm going to do.

/Ash Furrow /Comments Off
By:
Comments Off

In-House with Artsy

A few months ago, I started a new job at Artsy. Artsy is based in New York and I've been working remotely from Amsterdam.

We took advantage of me being in America for WWDC to have me come to New York for a week and work in-house. It's only Tuesday but it's already been a great experience.

The Artsy team is incredible – everyone is very good at what they do. I've been making connections with coworkers that I didn't even know I had (the team is actually pretty large).

After quitting my old job in Amsterdam, I had had some self-doubt about whether or not I made the right decision. Not working for a Dutch company, I'd only get to stay a year in Amsterdam. After meeting the Artsy team in-person, I'm now 100% confident that I made the right decision.

/Ash Furrow /Comments Off
By:
Comments Off

Removing Ads

For the past few years, I've been running this blog with small advertisements on the side (or above if you're on mobile). I've decided to remove them.

I've been blogging a lot more recently with my personal issues with depression, and I've gotten a lot of feedback from readers. People who are supportive of me (thanks for writing – I really appreciate it!) and people who are themselves struggling. I don't feel comfortable selling ad space against this kind of personal content. They'll be gone by the end of June.

I wish Fusion Ads all the best. They've been very kind to me, and if I ever want to sell ads against one of my web properties again, I'll likely return to them.

/Ash Furrow /Comments Off
By:
Comments Off

Expression Interpretation Problem with Swift Closures

I was working with someone on an open-source testing framework for Swift and we came across the following problem. If the last statement in a closure can be interpreted as an expression, then the Swift compiler will try and interpret that as the return value for that closure, which can conflict with an expected type.

Let's take a look at an example.

Cosider a function a that does some operation, then returns true or false depending on the success of that operation.

func a() -> Bool {
    /* do some work */
    return true
}

Cool, so far so good. Let's now take a look at a function b that takes a closure that takes no parameters and doesn't return a value.

func b(closure: () -> ()) {
    closure()
}

Still OK. Now let's invoke b with a closure that invokes a.

b{
    a()
}

Boom, compiler error.

Cannot convert the expression's type '()' to type 'Bool'

Interesting. It took us a few minutes to understand what was going on. The invocation of a returned a Bool, so the compiler was inferring that the closure should return a Bool, too, leading to a type-mismatch. Remember that the last expression in a closure is interpreted as an implicit return statement. So the compiler was interpreting this as follows.

b{
    return a()
}

The workaround is the convert the expression a() into a statement that the compiler will ignore.

b{
    var _ = a()
}

Kyle pointed out this would fix the issue, too.

b{
    var _ = a()
    return
}

Interesting. I've filed a radar about it and I expect it'll be fixed soon.

/Ash Furrow /Comments Off