Javier Soto

“Back to the Futures” talk at Swift Summit in London

Wed, 20 May 2015 14:36:01 -0700

This past March I gave a talk at the first Swift Summit in London. The video along with the slides has been posted by Realm, go check it out!

http://realm.io/news/swift-summit-javier-soto-futures/

Featured in an article published on El País

Thu, 07 May 2015 14:55:53 -0700

Today my brother Nacho and I had the pleasure to be featured in an article in one of the biggest newspapers in our home country, Spain.

http://tecnologia.elpais.com/tecnologia/2015/05/07/actualidad/1430960436_222805.html

Functor and Monad in Swift

Thu, 01 Jan 2015 21:39:00 -0800

I have been trying to teach myself Functional Programming since late 2013. Many of the concepts are very daunting because of their somewhat academic nature.

Since I’m obviously not an expert, I intend this to be a very practical post. You will find many posts trying to explain what a Monad is, some of them trying a bit too hard to come up with similes, but hopefully the sample code here will illustrate some of the concepts better.

It wasn’t until recently that I finally could say that I got what Monad means. Let’s explore why this concept even exists, and how it can help you when writing Swift code.

Map

One of the first things that we got to see at the 2014 WWDC with the introduction of Swift was that we could use the map function with the collection types. Let’s focus on Swift’s Array.

let numbers = [1, 2, 3]

let doubledNumbers = numbers.map { $0 * 2 }
// doubledNumbers: 2, 4, 6

The benefit of this pattern is that we can very clearly express the transformation that we’re trying to apply on the list of elements (in this case, doubling their value). Compare this with the imperative approach:

var doubledImperative: [Int] = []
for number in numbers {
    doubledImperative.append(number * 2)
}
// doubledImperative: 2, 4, 6

It’s not about solving it in a one-liner vs 3 lines, but with the former concise implementation, there’s a significantly higher signal-to-noise ratio. map allows us to express what we want to achieve, rather than how this is implemented. This eases our ability to reason about code when we read it.

But map doesn’t only make sense on Array. map is a higher-order function that can be implemented on just any container type. That is, any type that, one way or another, wraps one or multiple values inside.

Let’s look at another example: Optional. Optional is a container type that wraps a value, or the absence of it.

let number = Optional(815)

let transformedNumber = number.map { $0 * 2 }.map { $0 % 2 == 0 }
// transformedNumber: Optional.Some(true)

The benefit of map in Optional is that it will handle nil values for us. If we’re trying to operate on a value that may be nil, we can use Optional.map to apply those transformations, and end up with nil if the original value was nil, but without having to resort to nested if let to unwrap the optional.

let nilNumber: Int? = .None

let transformedNilNumber = nilNumber.map { $0 * 2 }.map { $0 % 2 == 0 }
// transformedNilNumber: None

From this we can extrapolate that map, when implemented on different container types, can have slightly different behaviors, depending on the semantics of that type. For example, it only makes sense to transform the value inside an Optional when there’s actually a value inside.

This is the general signature of a map method, when implemented on a Container type, that wraps values of type T:

func map<U>(transformFunction: T -> U) -> Container<U>

Let’s analyze that signature by looking at the types. T is the type of elements in the current container, U will be the type of the elements in the container that will be returned. This allows us to, for example, map an array of strings, to an array of Ints that contains the lengths of each of the Strings in the original array.

We provide a function that takes a T value, and returns a value of type U. map will then use this function to create another Container instance, where the original values are replaced by the ones returned by the transformFunction.

Implementing `map` with our own type

Let’s implement our own container type. A Result enum is a pattern that you will see in a lot of open source Swift code today. This brings several benefits to an API when used instead of the old Obj-C NSError-by-reference argument.

We could define it like this:

enum Result<T> {
    case Value(T)
    case Error(NSError)
}

This is an implementation of a type known as Either in some programming languages. Only in this case we’re forcing one of the types to be an NSError instead of being generic, since we’re going to use it to report the result of an operation.

Conceptually, Result is very similar to Optional: it wraps a value of an arbitrary type, that may or may not be present. In this case, however, it may additional tell us why the value is not there.

To see an example, let’s implement a function that reads the contents of a file and returns the result as a Result object:

func dataWithContentsOfFile(file: String, encoding: NSStringEncoding) -> Result<NSData> {
    var error: NSError?

    if let data = NSData(contentsOfFile: file, options: .allZeros, error: &error) {
        return .Value(data)
    }
    else {
        return .Error(error!)
    }
}

Easy enough. This function will return either an NSData object, or an NSError in case the file can’t be read.

Like we did before, we may want to apply some transformation to the read value. However, like in the case before, we would need to check that we have a value every step of the way, which may result in ugly nested if lets or switch statements. Let’s leverage map like we did before. In this case, we will only want to apply such transformation if we have a value. If we don’t, we can simply pass the same error through.

Imagine that we wanted to read a file with string contents. We would get an NSData, that then we need to transform into a String. Then say that we want to turn it into uppercase:

NSData -> String -> String

We can do this with a series of map transformations (we’ll discuss the implementation of map later):

let data: Result<NSData> = dataWithContentsOfFile(path, NSUTF8StringEncoding)

let uppercaseContents: Result<String> = data.map { NSString(data: $0, encoding: NSUTF8StringEncoding)! }.map { $0.uppercaseString }

Similar to the early example with map on Arrays, this code is a lot more expressive. It simply declares what we want to accomplish, with no boilerplate.

In comparison, this is what the above code would look like without the use of map:

let data: Result<NSData> = dataWithContentsOfFile(path, NSUTF8StringEncoding)

var stringContents: String?

switch data {
    case let .Value(value):
        stringContents = NSString(data: value, encoding: NSUTF8StringEncoding)
    case let .Error(error):
        break
}

let uppercaseContents: String? = stringContents?.uppercaseString

How would Result.map be implemented? Let’s take a look:

extension Result {
    func map<U>(f: T -> U) -> Result<U> {
        switch self {
            case let .Value(value):
                return Result<U>.Value(f(value))
            case let .Error(error):
                return Result<U>.Error(error)
        }
    }
}

Again, the transformation function f takes a value of type T (in the above example, NSData) and returns a value of type U (String). After calling map, we’ll get a Result<U>(Result<String>) from an initial Result<T> (Result<NSData>). We only call f whenever we start with a value, and we simply return another Result with the same error otherwise.

Functors

We’ve seen what map can do when implemented on a container type, like Optional, Array or Result. To recap, it allows us to get a new container, where the value(s) wrapped inside are transformed according to a function. So what’s a Functor you may ask? A Functor is any type that implements map. That’s the whole story.

Once you know what a functor is, we can talk about some types like Dictionary or even closures, and by saying that they’re functors, you will immediately know of something you can do with them.

Monads

In the earlier example, we used the transformation function to return another value, but what if we wanted to use it to return a new Result object? Put another way, what if the transformation operation that we’re passing to map can fail with an error as well? Let’s look at what the types would look like.

func map<U>(f: T -> U) -> Result<U>

In our example, T is an NSData that we’re converting into U, a Result<String>. So let’s replace that in the signature:

func map(f: NSData -> Result<String>) -> Result<Result<String>>

Notice the nested Results in the return type. This is probably not what we’ll want. But it’s OK. We can implement a function that takes the nested Result, and flattens it into a simpleResult:

extension Result {
    static func flatten<T>(result: Result<Result<T>>) -> Result<T> {
        switch result {
            case let .Value(innerResult):
                return innerResult
            case let .Error(error):
                return Result<T>.Error(error)
        }
    }
}

This flatten function takes a nested Result with a T inside, and return a single Result<T> simply by extracting the inner object inside the Value, or the Error.

A flatten function can be found in other contexts. For example, one can flatten an array of arrays into a contiguous, one-dimensional array.

With this, we can implement our Result<NSData> -> Result<String> transformation by combining map and flatten:

let stringResult = Result<String>.flatten(data.map { (data: NSData) -> (Result<String>) in
    if let string = NSString(data: data, encoding: NSUTF8StringEncoding) {
        return Result.Value(string)
    }
    else {
        return Result<String>.Error(NSError(domain: "com.javisoto.es.error_domain", code: JSErrorCodeInvalidStringData, userInfo: nil))
    }
})

This is so common, that you will find this defined in many places as flatMap or flattenMap, which we could implement for Result like this:

extension Result {
    func flatMap<U>(f: T -> Result<U>) -> Result<U> {
        return Result.flatten(map(f))
    }
}

And with that, we turned our Result type into a Monad! A Monad is a type of Functor. A type which, along with map, implements a flatMap function (sometimes also known asbind) with a signature similar to the one we’ve seen here. Container types like the ones we presented here are usually Monads, but you will also see that pattern for example in types that encapsulate deferred computation, like Signal or Future.

The words Functor and Monad come from category theory, with which I’m not familiar at all. However, there’s value in having names to refer to these concepts. Computer scientists love to come up with names for things. But it’s those names that allow us to refer to abstract concepts (some extremely abstract, like Monad), and immediately know what we mean (of course, assuming we have the previous knowledge of their meaning). We get the same benefit out of sharing names for things like design patterns (decorator, factory…).

It took me a very long time to assimilate all the ideas in this blog post, so if you’re not familiar with any of this I don’t expect you to finish reading this and immediately understand it. However, I encourage you to create an Xcode playground and try to come up with the implementation for map, flatten and flatMap for Result or a similar container type (perhaps try with Optional or even Array), and use some sample values to play with them.

And next time you hear the words Functor or Monad, don’t be scared :) They’re simply design patterns to describe common operations that we can perform on different types.

Open source version of the article, where you can create an issue to ask a question or open pull requests: https://github.com/JaviSoto/Blog-Posts/blob/master/Functor%20and%20Monad%20in%20Swift/FunctorAndMonad.md

Most influential Latinos in Tech 2014

Thu, 02 Oct 2014 18:22:00 -0700

Most influential Latinos in Tech 2014:

Somehow I’m among the most influential Latinos in tech by “CNET en Español” along with people like Eddie Cue and Matias Duarte.

Interviewed by "CNET en Español"

Wed, 09 Jul 2014 18:02:50 -0700

I was interviewed by CNET at Pebble HQ. I answer questions about things like my path to Silicon Valley or my opinion on the evolution of wearable devices.

ReactiveCocoa

Wed, 19 Feb 2014 10:26:00 -0800

A lot is being written these days about ReactiveCocoa and the paradigms it introduces. In my opinion, there are only two sides giving their opinion: the ones that know a lot about it and are therefore obviously biased, and the ones that refuse to learn it.

I decided to write something myself because I think I’m right in the middle. A few months ago I knew nothing about it, and now I know enough to want to use it every day. I hope that by not being an expert, I can actual introduce a few really simple ideas in a much easier way to pick up by newcomers, to show why I think ReactiveCocoa is an incredibly powerful tool to help us write better, cleaner, and more maintainable code.

It’s signals all the way down

The base of everything that happens in ReactiveCocoa is signals. I’m going to try to explain what they represent and why they fit in the way we think about what happens on an app. A lot of the things you may read about Functional Reactive Programming end up confusing you when they introduce more advanced FP operators, etc. So let’s avoid that.

What is a signal? Think of it as a pipe that carries values. This flow of values is actually present everywhere in our apps when you think about it: the data downloaded from the network, the Boolean value “is the user logged in”, the value of a setting “font size across the app”, etc. Most values are not constant, they vary over time, and we manage that in a number of ways: callbacks, delegates, KVO, NSNotificationCenter….

Why is something like signals, which clearly represent a real thing and not some crazy mathematical model, not present in our language / frameworks / design patterns? Because the inherent C-way-of-doing-things rules the way we write code. Apart from the Object Orientation abstractions, the imperative code that we write isn’t very far from Assembly: we feed instructions to the machine, and it executes them one by one, sequentially, we have to manage the data that it reads / writes in memory (state)…

When we write imperative code, we tell the machine how to do the work, instead of what work to do. This is what a new paradigm tries to accomplish: to drive us away from this low-level universe into a place closer to the way we reason and express our intentions when writing code.

Now think about something for a second. Say you call a method that returns some data, let’s say a list of tweets. It doesn’t return the present value, by the time the method returns, that’s already the past. Just like the way our eyes don’t observe the present but some not-very-distant past.

But this is not a problem, you may think, whenever the list of tweets changes, we’ll call the method again to feed the new list to our table view. I know! I’ll use a delegate! Right? Right…? But what if we had an entity, a thing that represented exactly that: a flow of values that change over time.

So let me introduce two constructs that I hope will make you want to use ReactiveCocoa even if just for that.

Bindings

Let’s say we want a signal that will carry the values of this list of tweets. Assuming that we have a “Tweet Data Provider” class with a property like this:

@property (nonatomic, readonly, strong) NSArray *tweets;

That is set whenever some other component queries the Twitter API and therefore sends KVO notifications. ReactiveCocoa makes it incredibly easy to get a signal that will send values (in this case, NSArrays) every time the propery changes:

RACObserve(self.tweetDataProvider, tweets);

Note the awesomeness of ReactiveCocoa handling the KVO subscription for us and removing it as soon as either self, let’s say whatever ViewController we’re doing this in, or the observed object is going to be deallocated.

So what we can do with this signal? We can bind its values to something else. Look over the code of the last 5 view controllers you worked on and ping me on Twitter if you don’t think that 90% of the code there is glue-code to change some value whenever other value changes through some callback mechanism. The problem with this code is that it tends to be kind of spaghetti-y: there’s the observations in one place, the values coming in in another, and then the processing of the values somewhere else. We’re used to code like this, but we can’t deny its complexity.

Again: we focus on how the task has to be accomplished and not the what we’re trying to do. And then there’s all the underlying trickiness that is not obvious at first, and is a common source of bugs. Is this happening in the right order? This forces us to use the debugger to analyze the state of the view controller, see what method gets called first, etc. Gross.

So let’s go back to our example. How do we bind our ever-changing list of tweets to something else? With a one liner.

RAC(self.tableDataSource, tweets) = RACObserve(self.tweetDataProvider, tweets);

(When I started using ReactiveCocoa it helped me a lot to read the RAC() macro as “RACBind”. So you could read this line as “Bind the tweets coming from the data provider into the table view.”)

And before you start thinking “ah, magical code that abuses pre-processor macros”, think about what we have achieved. I don’t have to jump back and forth between 3 methods to understand what the flow of data is. This line is so descriptive that one can read it and forget about the implementation details and focus on the what.

You can forget about whether the stringly-typed keypath is correct or has a typo, whether you’re implementing KVO right or your breaking your parent class, you can forget about forgetting to unsubscribe, unsubscribing without having subscribed, and a long etc. And you can simply wonder “did I tell my code to do what I want it to do?”.

Honestly, since I started using ReactiveCocoa I sleep better at night.

And because you may say that this is a dumb example, I’m going to show one last example. And if you think that we don’t need to use KVO for that and we could’ve used a protocol, think about the fact that we get being KVO-complaint for free in almost all cases and creating a protocol requires a lot of boiler-plate code.

So say we want to show or hide a label that says “no tweets” depending on whether there are any tweets or not. I’m sure you’re drawing the graph of method calls in your head to accomplish this. Or maybe you’re imagining the growing -observeValueForKeyPath:ofObject:change:context:. Check out this descriptive code:

RAC(self.noTweetsLabel, hidden) = [RACObserve(self.tweetDataProvider, tweets) map:^NSNumber *(NSArray *tweets) {
    return @(tweets.count > 0);
}];

When you call -map: on a signal, it returns another signal that gets a value every time the original signal gets a value, but “maps” them to another value. In this case we’re converting NSArray values into boolean (isHidden?) values.

If I have convinced you to at least give ReactiveCocoa a try, I would be very satisfied. But maybe you simply have to trust me when I tell you that you need to try it out for yourself to realize how incredibly useful it is.

Comments? Post them on the gist: https://gist.github.com/JaviSoto/9098262

Steve Jobs: Secrets of Life

Thu, 10 Oct 2013 17:19:00 -0700

One year in the U.S.

Tue, 02 Apr 2013 23:05:00 -0700

I felt like I had to write some words about this huge milestone in my life. I could try to summarize this year in one post, but that would be impossible. There’s no doubt these past 12 months have been the most eventful, the most different and the most fun.

On the Christmas of 2011 I thought my new year resolution for 2012 should be something big, I should aim very high. I decided that 2012 should be the year I moved to the US to continue my professional career there. On January 30th, just 30 days in the year, I got an offer from MindSnacks to come work in San Francisco as an iOS Developer. I accepted with no hesitation, and little did I know what was ahead. And just like that I fulfilled an all-time dream.

Of course these things don’t come without effort and hard work. Not only to get here, but being here has been really demanding. The constant feeling of a need to get better at what you do, the pressure to build cool things. All that requires focus and perseverance. But when I look back and see how far I’ve come, I realize how worthwhile it was.

I’m very thankful for how much I’ve learned here, both personally and professionally. I’m thankful for all the cool people I’ve met and I get to hang out with and who make me feel at home in San Francisco: my Spanish friends, Vanessa, Ignacio and Juan, my coworkers at MindSnacks, my brother Nacho, some nerds like Jordan (big contributor to my still improving American accent) and Sommer, Kerrie… and other people I’m forgetting. This goes to you all.

Yerba Buena Center (Taken with Instagram at Yerba Buena Center...

Wed, 12 Sep 2012 09:36:07 -0700

Yerba Buena Center (Taken with Instagram at Yerba Buena Center for the Arts)

Goodbye Sunset District (Taken with Instagram at The Inner...

Sun, 09 Sep 2012 12:54:49 -0700

Goodbye Sunset District (Taken with Instagram at The Inner Sunset)

How I manage to get more work done

Thu, 26 Jul 2012 09:56:32 -0700

I got out of the office today with a good feeling about my productivity. I realized how much work I had gotten done today, and thinking back, how much work I’ve been getting done lately, compared to before. I tweeted this:

It was kind of a rhetoric “should”, because talking about this is tricky, since a lot of it has to do with one’s personal habits, but @refulgentis encouraged me to actually write that post, so here it goes.

This all started when I read this post by @pasql talking about how happy he was after turning off push for e-mail, after also having a similar discussion with @deepbane about it. For some reason, ever since I got my first iPhone I’ve become obsessed with getting real time notifications of everything. When I read that post, I realized that e-mail is actually not urgent. If someone sends you an e-mail, they can’t be expecting that you read it inmediately. If they want to reach you quickly, they will call or text you. Not to mention that 90% of e-mails are not even personal e-mails, they’re notifications from some sort of service.

So I not only turned off push, I even turned off automatically pulling e-mails from the server (I set it to “manual”). I was scared at first: “What if I get something important?”. After a few days, I realized I wasn’t missing anything. What did happen, is that my phone wasn’t vibrating in my poket every minute. And this meant fewer interruptions: both at work, and in my free time. This was the first great decision, which has improved my productivity, and my peace of mind significantly. I encourage you to do the same today.

The reason for this is that we, humans, aren’t good at multi-tasking. We can do multiple things at the same time, but we can’t do them right, we can’t focus on all of them with the necessary level of attention: if we want to do something right, we must focus only on that task.

The second improvement came thanks to a small feature added to iOS6, which I installed around a month ago, called Do Not Disturb. I estimate I receive around 2 to 3 push notifications per minute on my phone during peak hours. That’s A LOT of interruptions: Twitter, Facebook, Instagram, Path, Foursquare just to mention some examples. Just like with e-mail: are those notifications urgent? Do you really have to check them out as soon as you receive them? The answer is no, but we live so addicted to our smartphone (some of us anyway) that we forget this. What this feature does basically, is that even though the phone will still receive all those notifications, it just won’t light up the screen or vibrate, unless it’s a phone call (which is normally more urgent, and it’s definitely not as frequent), so it won’t interrupt you. Whenever you want, you can press the home button, and see all you’ve received since the last time you checked. The key is that you choose when you want to look. In the mean time, you’re focused on your task, in my case, programming.

As you can see, it all comes down to one thing: not being interrupted. It’s amazing how easy it becomes to be in the zone after being focused for around 20-30 minutes without a single interruption. It’s in that state that I manage to get the most work done, and with the highest quality.

I could get into the details of what tools I use to check my mail, manage my todo’s and so on, but that would be material for a whole new post.

And you, what do you do to keep up your productivity?

I wanted to share this cool picture that Jarod took of me...

Mon, 09 Jul 2012 23:49:00 -0700

I wanted to share this cool picture that Jarod took of me (right) and my brother Nacho (left) at the office.

So what were we doing? We were working. Writing on a glass. Yep. We were discussing how to implement a piece of functionality for the MindSnacks app, before actually coding it.

Starting from scratch: welcome to my blog (again)

Sat, 16 Jun 2012 14:45:00 -0700

This blog has existed for months, but I never wrote on it, but still I had over one thousand posts. How is that even possible? Well, I was just using iftt hooks to fill this with the same stuff that I was already sharing on Twitter anyway. So along with a new website (http://www.javisoto.es) I decided to actually have a blog here and write from time to time :)