Converting a RAC 3.0 project from Swift 1.2 to Swift 2.0

I've been loving ReactiveCocoa 3.0 (now that I've finally grok'd it), and today I was able to switch to the swift2 branch to start updating Tacks's Swift 1.2 code for iOS9.0.

Aside from converting all usages of '|>' to simply '.' instead ( which is much better! we now have code completion! ๐ŸŽ‰), a few things tripped me up when switching to the Swift 2.0 api.

.Catch()

Firstly, catch is now a reserved word in Swift 2.0, so you should simply replace all usages with flatMapErrors - it's the same.

.Start()

Secondly, the compiler now seems to have problems identifying which default parameter it should use when you pass a closure to start:. The method signature of start: is really:

start(error error: (E -> ())? = nil, completed: (() -> ())? = nil, interrupted: (() -> ())? = nil, next: (T -> ())? = nil) -> Disposable

and previously it was common to use the following shorthand:

producer.start { value in ... }`

Which would really mean (I assume because next was the last parameter?):

producer.start(next: {value in ...})

The Swift 2.0 compiler (Xcode 7 b6, at least) makes a different decision about what we're trying to do. Due to the fact that we're passing a single block parameter, it now assumes that we want to call the start(sink: Event<T, E>.Sink) method instead. This is our clue that something's not right, as we start seeing that our blocks are being passed variables of type Event<YourType, NoError> rather than the expected type.

The solution is easy: either just be clearer about what you're calling by reinstating the next: parameter name:

producer.start(next: {value in ...})`

.. or provide more type information in your closure, to help the poor compiler out:

producer.start { (displayableAnnotations: YourType) in ... }

.Put()

We no longer use .put(x) to set the value on a MutableProperty type - .value is now settable, so we just get and set .value directly. This is probably good, though I liked the separation before - it made it more obvious that MutableProperty also dealt in events. But like I say, it's probably simpler now.

Edit: Extra!

Don't forget to remove the Box dependancy as well, because it's no longer needed with Swift 2.0

Taking a month off

Last week I was contracting on a great project at Philips. I'd been there since December, and before that I was working on something else, and before that something else.

Time was passing by, and part-time projects were piling up, gathering dust. This last year I'd really dug into ReactiveCocoa, but as a consequence I hadn't really learned Swift yet, and I hadn't been making any open-source contributions for god-knows how long. My portfolio site needs updating, my side-project Tacks.io app lies long since forgotten. I've been living in the Netherlands for 18 months, and hadn't started a Dutch class yet - though I'm pretty hot on Duolingo - challenge me ;)

Contracting is really great, but at the end of the day you're tired, and by the end of a long week coding 8 hours at a desk in a skyscrapper, you just want to relax. I've known for a long time that I work better during the afternoon & evening, and if I can do some decent exercise in the morning then even better.

A few months ago I opted not to renew my rolling three-month contract - WWDC was coming up and I wanted to make a huge gesture to myself, to give myself some time to actually attempt the things I 'never had time' to do. Watch the WWDC videos the week they come out! Write some example apps based on the new stuff! Read through my 120+ Pocket'd programming articles. Finish Design For Hackers. Release my long-time-in-the-making-and-still-objc pet project app Tacks.cc. Working towards being an 'indie' developer with recurring income streams.

Keeping myself a strong and skilled developer involves investing in myself. So now I've got a big block of four weeks 'self self-employed' time. Amazing.

(I've started my Dutch class, too)

Airserver for WWDC

For some strange reason, Apple has so far only released the videos of their Tech Talks in the WWDC app (and on the Apple TV - which I don't have). What if you want to watch them from the comfort of your sofa? Your hands are occupied already right๐Ÿ•๐Ÿบ?

Presumably they'll be on the website sooner rather than later, but in the meantime you can easily stream the content to your Mac using the excellent third-party AirServer (conveniently free for seven days). Once it's running, play the WWDC app video on your phone and, via the magic of AirPlay, they'll show on your laptop screen. If you can plug that into the TV, all the better.

Pro-tip: if you use the Share Sheet in AirServer, you even get the direct URL of the talk and can use it directly, dispensing with AirPlay completely.

Introducing Tacks

There's an app that I've been working on in my spare time, which I've actually been using personally for several months, but which I've not managed to pat together into an App store release.

It's a simple app based on something I needed each time I found myself in a new city when I was travelling: when you arrive, you constantly see lots of places you'd like to return to, and it would be super handy if you could just drop a pin there, add a short title and thus remember it for later. After a while, you'll see a map studded with interesting places that you yourself have added, and it's simple to find your way back later on. When you go to the next city, you start a new map, etc.

Inspired by Sam Soffes talking passionately about developing Cheddar on the Founders Talk podcast, I'm going to open-source this app and blog about its development too.

Looking Back for Inspiration Part 1: Gigsniffr

Perhaps my fondest memory in all my time spent coding was the all-out dash to build a complex PHP web-app for my undergrad dissertation. It was the biggest project I'd ever attempted, and was the starting-gun I'd been waiting for, the opportunity to really dig into something.

Prototype Homepage

Man, I was so psyched about my idea - it was a web-scraper named Gigsniffr which aggregated a set of concert ticket websites. The killer feature was that when it saw a ticket come onsale for a user's favourite band, it alerted them via a tweet (back when Twitter was still conceived of as a computer-human API platform). At the time, nothing much like this yet existed (2007 was also when Songkick launched), and I knew for sure that it could be big if I could just get it launched.

This was before any of these music sites had a published API for me to use, so I had to really research how to put together a reliable web-scraping algorithm that could repeatedly spider the ticket sites.

The project was incredibly fun: I was developing into (for me) the complete unknown - I wasn't amazing at PHP, I had no experience of managing a long-running web-scraper service, I had no permission to scrape these sites, I had a hard deadline to hit, and nothing to distract me.

There were many problems to solve: how can you work out the names of a user's nearest cities, without Google's Map API; how do you build an engine to accurately scrape many different websites, abstracting away from the quirks of each (answer: invent own XPath tricks); how do you diff the data collected with that taken an hour previously?

I soon found that the first pass of data gathering was easy - but updating and correcting this dataset was actually much harder: I was attempting to keep track of gig cancellations, date changes, and variances in band names (Red Hot Chili Peppers vs RHCP etc), and it was a rathole without end. Much fun to solve!

I did manage to get a prototype working in time for the deadline - an achievement which to this day I'm proud of. At the presentation were two local entrepreneurs who took an interest in my idea and took me out for lunch to discuss it.

Alas - I ground to a halt somewhere between finishing the proof-of-concept and launching a user-ready product. After I'd delivered the proof-of-concept and completed the course, the pressure was off and it was time to relax - I'd hit the deadline and could now continue developing Gigsniffr at my leisure, right after I've been to these music festivals and learned Ruby and started a job and...

.. and it was gradually forgotten. The would-be investors were interested only in funding marketing, and only once the app was finished - they were not interested in financing even the peanuts I'd need to sit down and complete it. I was also messed up after a nasty breakup. I found myself in a job that absorbed 10 hours of coding stamina per day, which I then quit to take a Masters - without any real gap after the undergrad. If I'm honest, I'd got what I wanted from the project, and was moving on - so Gigsniffr was shelved.

I've a profound admiration for those running startups which actually launch, especially those who succeed longterm - it's an amazing feat. People say that ideas are cheap, and that building them is the hard bit. What they don't mention is that building the interesting parts of a project is pretty easy, but FINISHING it is nearly impossible in comparison. Finishing a product really is hard. But the burst of real energy and creativity I summoned for Gigsniffr is something I've been chasing ever since.

Prototype Admin panel

Prototype scraping control panel