The first Release Candidate for the ReactiveCocoa 3 (aka The Swift Edition) has just been announced, so I thought this was a good time to share how I have been doing MVVM bindings with the new version of the framework.

Unfortunately (or fortunately, depending on the point of view), Swift does not play well with KVO, which is a very Objective-C way of doing things. KVO is great, but it was also the main source of RAC's "magic".
For this reason MutableProperty, a more formal and explicit way to do bindings, was introduced in the Swift version of RAC.

The most common scenario in iOS is having a bunch of UITableViewCells or UICollectionViewCells and keep their content up to date with the latest ViewModel.
What I like to do is having a MutableProperty wrapping the ViewModel and describe the bindings once during the initialization of the cell, letting the framework stream the new values whenever the ViewModel changes.

Note that to accomplish this I used the UIKit extension rac_text. Unfortunately those extensions are not present in the framework yet, so you'd have to create them yourself for now. Colin Eberhardt's post is a good starting point.

Since I don't really know what I'm doing, I'm open to suggestion. Please reach me out on Twitter if you have some!

I love keeping most of my configurations in dotfiles and I rely on them for pretty much everything I can.
When I first discovered EditorConfig I was excited to finally have a way to set my indentation settings once in a dotfile and having the editor, whatever that is, apply those settings.
Unfortunately though, it was lacking a Xcode plugin, so I built it myself.

When opening a file, the plugin looks for a file named .editorconfig in the directory of the opened file and in every parent directory.
Once the file is found, the coding styles for the file extension will be read and the plugin will dynamically change the Xcode settings to match the style.

This is particularly useful in different scenarios:

When contributing to a project which has a different style guide from what you normally use, you can just use a different .editorconfig to override the default settings.

If you like having different indentation settings for different languages (e.g. Objective-C and Swift).

You prefer your indentation settings to be editor-agnostic.

For now the plugin supports indent_style, indent_size and tab_width, but I’m planning on adding support for some more settings soon.

A couple of weeks ago I was in San Francisco to attend the Yammer Hack Day.
For my hack, I wanted to explore new ways of sharing some code across our different mobile apps. So I set myself up for the challenge of writing a C++ image cache and to have it working on both iOS and Android by the end of the day.

Even with my rather poor C++ foo, in a couple of hours I had the C++ implementation fully working. But I had no idea how to integrate it in the actual apps.

Luckily for me, Dropbox has released an open source tool, Djinni, to do just that: it takes a C++ implementation and creates the Objective-C and Java interfaces, so that is possible to reuse the same C++ code without worrying about the inter-language communication, which is taken care of by the tool itself.
If you’re interested and want to know more about it (you should!), check out the slides of my Hack Day presentation and Dropbox’s announcement of Djinni at CppCon.

Although I didn’t win, I was pretty happy with my hack.
Not because of what I achieved, but for how simple eventually it turned out to be.

So a few days ago I went a step further: I just wanted to write a simple iOS app using as many programming languages as possible, just for fun and to see how much overhead is caused by the unavoidable inter-language communication.

So I chose a different languages for every different component in the app:

Swift for the front-end, views and controllers

JavaScript to serialize and unserialize the JSON store. Why? Why not!

C++ because I already had the in-memory and on-disk image cache

Machine-generated Objective-C++ to work with the C++ image cache (thanks to Djinni I didn’t have to write it myself)

And of course Objective-C to make all this possible

I tried to minimize the overhead and complexity of using different languages by separating the components as much as possible and declaring simple and clear interfaces.

There are very few articles that every now and then keep coming up on Hacker News. One of them is Peter Norvig's How to Write a Spelling Corrector.
For those of you who don't know Peter Norvig, he's a really smart guy who also happens to be Director of Research at Google.

Having recently started learning Haskell, I decided to take over the challenge of re-implementing his spelling corrector.
One imporant thing to say is that, since there seems to be a leaderboard on Peter Norvig's website for the shortest implementations, I wrote this code trying to come up with the possible shortest version, putting brevity over readability, which is something I usually never do. But hey, sometimes we don't want to be too serious and it's just FUN!
Now, let me say that Python is a very nice language and a lot of people love it because it looks like pseudo-code and it's really easy to prototype in it. That's probably the main reason I still believe his version is better than mine, more readable yet even shorter.

I am not going to explain the algorithm, since you can read it up in Norvig's article. I am just going to explain what I like and I don't like in my Haskell version, adding type annotations previously omitted.

Let's start off with reading the file and training the probability model. Nothing special here. Just some mapping and filtering to create the Map of known words, our probability model.

Things start getting interesting creating all the possible edits at distance 1.
Haskell's list comprehensions are just amazing. Look for example at the inserts function: instead of 2 horrible for loops you can just read "combine all the splits for each letter of the alphabet". This is where Haskell really shines.

Creating all the edits at distance 2 is trivial applying edits1 twice with map and then reducing the sets using foldr. Classic map-reduce right here.
Creating the sets of known edits at distance 2 and the set of known words is just set interesection.

Now the ugliest part.
I couldn't find nothing as neat as Python's or operator so I had to create a little function to do that for me. That's not too bad.
What I don't really like is the function chooseBest. Having to jump between sets and maps passing from lists is horrible. Probably even more terrible is having to manually sort the map based on the values.
I am sure there is a better way since Haskell is so powerful, I just couldn't come up with it.

I am sure I have done something completely wrong and there's something that could have been done in a better way. Feedback is really appreciated. The code is on GitHub.

UPDATE

A lot of people pointed out that this code is not readable and it goes against a lot of Haskell best practices. I know that, in fact writing the most elegant Haskell code wasn't my objective for this article. I just wanted to come up with the shortest implementation.

Some verykind people helped me out on GitHub by making the code cleaner and neater (gotta open source) and now the final implementation looks something like this:

What's Nimble? Nimble is the Core Data wrapper I have been working on for one of my never-completed personal project.
If I had to describe Nimble with a very short description I would probably say: Core Data (and iCloud) made nimble and fast.

Why

The answer is quite easy. I needed a Core Data wrapper with these features:

Easy setup and finders (anyone said MagicalRecord?)

Simple architecture with a main and a background context. A lot has been written about how much faster are 2 context rather than parent+children. Read here and here if you're interested

iOS 7 and iCloud ready (but still compatible)

Features

It has all the features I (and probably you) need from a Core Data wrapper.

What's next

Well, there's a lot of stuff still to be done and it needs to be used in a real app with real world problems to spot big issues (performances and sync conflicts).
A todo list and the source code can be found on GitHub. Please feel free to have a look and post any issue you could find.