When your engineers consist largely of twentysomething dudes, you will get situations like this. When you think about your users as data-points rather than thinking, feeling, complex human beings, you will get situations like this.

A widely mocked video released in early November showed Vox leader Santiago Abascal leading a posse on horseback and the party boasting of a “reconquest” of Spain that would begin in Andalucía. One month on, the video, like the party itself, no longer seems quite as absurd as it once did.

https://www.theguardian.com/world/2018/dec/09/far-right-andalucia-seville-vox-party-shockwave-spanish-politics

The world never feels fallen, because we grow accustomed to the fall.

https://www.nytimes.com/2018/11/27/magazine/insect-apocalypse.html

Posted on October 30, 2018October 30, 2018 by sexysoftwareengineer

TIL: protocols and lazy var

TIL this builds:

protocol WizardStep {
    var header: UIViewController { get }
}

final class SiteSegmentsStep: WizardStep {
    lazy var header: UIViewController = {
        return UIViewController()
    }()
}

protocol WizardStep {

var header: UIViewController { get }

}

final class SiteSegmentsStep: WizardStep {

lazy var header: UIViewController = {

return UIViewController()

}()

}

Swift never ceases to amaze me

Posted on October 21, 2018 by sexysoftwareengineer · 3 Comments

WordCamp Taipei 2018

I am still on the long bus ride home from the airport, after an exhausting weekend in Taipei.

Earlier today I spoke at WordCamp Taipei. The experience has been draining, and at the same time extremely rewarding. So rewarding that I might actually consider doing it again 😊

Anyway, I would like to thank the organisers of the first ever WordCamp Taipei for the amazing work they have done. The event run smoothly, so smoothly that you can’t help but thinking “wow, these people have put lots of work and care into this”.

Posted on August 12, 2018August 12, 2018 by sexysoftwareengineer

Stuff I’ve read between August 5th and 12th 2018

As a follow up to the “I’m out of Twitter” post, I am starting a weekly recap of what I’ve read.

Stuff from the internets

There’s a limit to the amount of knowledge a single person can cram into their head in a lifetime

When knowledge is the limiting factor

Sunshine, sensuality, and a dash of danger… the ‘warm south’ has fascinated writers and artists for hundreds of years. But why are the Brits so obsessed?

From EM Forster to Mamma Mia! Why we can’t resist the Mediterranean

… You have created all these classes and complexity to replace only one line of code, which is unlikely to be changed.

Dependency Injection smells

We’re not used to thinking about the tech industry in terms of labor […] But tech, like any industry, is composed of workers and owners. The labor of the former generates profits for the latter

Can Silicon Valley workers rein in big tech from within?

From vaccines to climate change to genocide, a new age of denialism is upon us

Denialism: what drives people to reject the truth

Books

Finished
Greeks Bearing Gifts

Started
The Male Factor

Posted on March 27, 2018 by sexysoftwareengineer

TIL: Swift 4 and protocol composition.

One of the things I like most about Swift is that almost every day I learn something new, more often than not, something new that makes me write more readable and cleaner code.

Today I realised that protocol composition, which I kind of knew could be used to compose a SuperClass and a Protocol, can help remove some downcasts at runtime, and substitute those downcasts by the compiler yelling at you when writing the code.

Let’s take this code. As usual, it is difficult for me to come up with a relevant example that illustrates what I want, but is also simple enough to be understood without too much context.

protocol Presentable {
    func present()
}

class Device {
    func turnOn() {
        print("turn device on")
    }
}

final class Screen: Device, Presentable {
    func present() {
        print("presenting stuff on screen")
    }
}

final class Telegraph: Device {

}

final class Presenter {
    func deliverPresentation(screen: Device) {
        screen.turnOn()
        if let screenPresentable = screen as? Presentable {
            screenPresentable.present()
        }
    }
}

let screen = Screen()
let telegraph = Telegraph()
let presenter = Presenter()
presenter.deliverPresentation(screen: screen)
presenter.deliverPresentation(screen: telegraph)

protocol Presentable {

func present()

}

class Device {

func turnOn() {

print("turn device on")

}

final class Screen: Device, Presentable {

func present() {

print("presenting stuff on screen")

}

final class Telegraph: Device {

}

final class Presenter {

func deliverPresentation(screen: Device) {

screen.turnOn()

if let screenPresentable = screen as? Presentable {

screenPresentable.present()

}

let screen = Screen()

let telegraph = Telegraph()

let presenter = Presenter()

presenter.deliverPresentation(screen: screen)

presenter.deliverPresentation(screen: telegraph)

Notice how I have to check, at runtime, that the parameter I pass to deliverPresentation implements the Presentable protocol.

If we rewrite the Presenter to be like this, we can make the compiler enforce that whatever we pass to deliverPresentation as a parameter also implements Presentable, so we can avoid the downcast.

final class Presenter {
    func deliverPresentation(screen: Device & Presentable) {
        screen.turnOn()
        screen.present()
    }
}

let screen = Screen()
let telegraph = Telegraph()
let presenter = Presenter()

presenter.deliverPresentation(screen: screen)

// The following line will trigger a compiler error
presenter.deliverPresentation(screen: telegraph)

final class Presenter {

func deliverPresentation(screen: Device & Presentable) {

screen.turnOn()

screen.present()

}

let screen = Screen()

let telegraph = Telegraph()

let presenter = Presenter()

presenter.deliverPresentation(screen: screen)

// The following line will trigger a compiler error

presenter.deliverPresentation(screen: telegraph)

A real life example? From this:

private func showDocumentPicker(origin: UIViewController) {
        let docTypes = [String(kUTTypeImage), String(kUTTypeMovie)]
        let docPicker = UIDocumentPickerViewController(documentTypes: docTypes, in: .import)
        if let delegate = origin as? UIDocumentPickerDelegate {
            docPicker.delegate = delegate
        }
        origin.present(docPicker, animated: true, completion: nil)
}

private func showDocumentPicker(origin: UIViewController) {

let docTypes = [String(kUTTypeImage), String(kUTTypeMovie)]

let docPicker = UIDocumentPickerViewController(documentTypes: docTypes, in: .import)

if let delegate = origin as? UIDocumentPickerDelegate {

docPicker.delegate = delegate

}

origin.present(docPicker, animated: true, completion: nil)

}

To this:

private func showDocumentPicker(origin: UIViewController & UIDocumentPickerDelegate) {
        let docTypes = [String(kUTTypeImage), String(kUTTypeMovie)]
        let docPicker = UIDocumentPickerViewController(documentTypes: docTypes, in: .import)
        docPicker.delegate = origin
        origin.present(docPicker, animated: true, completion: nil)
}

private func showDocumentPicker(origin: UIViewController & UIDocumentPickerDelegate) {

let docTypes = [String(kUTTypeImage), String(kUTTypeMovie)]

let docPicker = UIDocumentPickerViewController(documentTypes: docTypes, in: .import)

docPicker.delegate = origin

origin.present(docPicker, animated: true, completion: nil)

}

Posted on November 18, 2017 by sexysoftwareengineer

Why code comments and documentation are better than being an arrogant jerk who keeps other developers out

For months, I have been playing around, in my head, with the idea of a post about documentation, and how it just should be one of the things that every software engineer does regularly.

I have written a few drafts, I have listed arguments both for and against writing documentation, I have debated and tried to debunk some of the usual arguments against it, and in the end, it all comes to the following:

Writing some documentation is better than being an arrogant jerk who keeps others out.

Period.

Posted on November 8, 2017 by sexysoftwareengineer

Building boundaries with third party libraries

The joys of jet lag. Here I am, at 2:43 am, trying to finalize a post that I started writing a couple days ago, while flying over the Pacific Ocean.

This is about dependencies, those third party libraries that often provide out of the box solutions to complex problems we need to solve.

Importing a third party library will save time and effort. Just add a line to a pod or Carthage file, and boom! We have saved days, weeks or months of development.

There are multiple benefits in relying on a third party library. Popular libraries are often well tested, and contain the knowledge of many developers about a given problem. Third party libraries save development time. Third party libraries avoid reinventing the wheel.

But third party libraries are code that you have not written, code that you don’t actually own, but that you somehow have to start maintaining as soon as you import it into your codebase.

Let’s take an example. Loading images, asynchronously, without blocking the main thread, in a table or collection view cell is a complex problem. We need to cancel image downloads when cells are not visible anymore, we might need to handle cell reusability, and ideally we should cache images. None of those problems are trivial to solve, and might require time and finesse to get right.

On he other hand, we could just import a third party library, like, for example, Kingfisher.

All we’d need to do would be adding a line to a pod / carthage file.

But…

We have created a subtle problem here: our cell’s code depends on Kingfisher. We need to call a specific method in that library, passing a set of specific parameters, in the way that library expects.

That be not be a problem if we only have one cell. But things start getting dangerous as soon as we have more than one cell.

Let’s say there are 10 different cells that present images in our codebase. Kingfisher is so convenient that we will repeat the same code in the 10 of them.

What would happen if, for some reason, Kingfisher stops being maintained? Or a new version of Swift breaks source compatibility again, and this library does no get updated? Or a new library comes by, that is twice as efficient as Kingfisher.

Then we would have a bit of a problem. Our code is strongly coupled with the specific api of a very specific library, and updating our code to use a different library might require getting into shotgun surgery mode.

Shotgun surgery.

How do we switch? Well, we could just do a search and replace, or search all the calls to Kingfisher and update them to use the new, hottest library.

But that is not very efficient, obviously.

So how do we avoid the problem?

Building boundaries

The same way that we have tools and mechanism to decouple some parts of our code from some other parts of our code, we have tools and mechanisms to decouple or code from third party libraries.

And the best tool for decoupling things is, as usual, a layer of indirection.

In this case, we could add a layer of indirection by encapsulating the call to the third party library in an extension to UIImageView. This extension would be code under our control, and will contain a single point of dependency with the third party library.

import UIKit
import Kingfisher

extension UIImageView {
    func presentImage(_ imageURL: URL?) {
        guard imageURL == imageURL else {
            return
        }
        
        self.kf.setImage(with: imageURL)
    }
}

import UIKit

import Kingfisher

extension UIImageView {

func presentImage(_ imageURL: URL?) {

guard imageURL == imageURL else {

return

}

self.kf.setImage(with: imageURL)

}

Our cells will load images by calling a method that belongs in our side of the codebase, not in the library’s side of it.

Now if we want, for whatever reason, to switch to a third party library, all we have to do is modify the implementation of our extension. Import a different library, update the presentImage method to that third party library’s API, and we are good to go.

Final words

Introducing seams between our code and third party libraries decouples our code from external dependencies. That way, we are free to modify those dependencies without having a big impact in our codebase.

PS

Kingfisher is a great library that solves a complex problem in an elegant way. I strongly recommend considering it.

Posted on September 23, 2017September 24, 2017 by sexysoftwareengineer

Things I like about Java: Anonymous classes

Everybody that knows me in real life knows that my favourite jokes are always those about Java being slow and bloated. But still, in all fairness, Java has some good things.

One of them, rendered obsolete by Java 8’s Lambda Expressions, that I always liked and that I really wish was possible in Swift, is Anonymous classes.

The way I see it, an anonymous class is just a syntax shortcut to declare and instantiate, inline, an instance of a specific interface. It is a quick way to create lightweight objects at the moment they are going to be used, or passed to another object.

interface Command {
    public void execute();
}

class AThing {
    public void doAThing(Command command) {
        command.execute();
    }
}

class Untitled {
    public static void main(String[] args) {
        AThing thing = new AThing();
        thing.doAThing(new Command() {
            public void execute() {
                System.out.print("Hello");
            }   
        });
    }
}

interface Command {

public void execute();

}

class AThing {

public void doAThing(Command command) {

command.execute();

}

class Untitled {

public static void main(String[] args) {

AThing thing = new AThing();

thing.doAThing(new Command() {

public void execute() {

System.out.print("Hello");

}

});

}

Anonymous classes have access to the members of its enclosing class, and local variables in its enclosing class marked as final, which makes them great candidates to be used, in particular, to declare callbacks in particular.

To me, their greatest advantage is that anonymous classes allow you to encapsulate behaviour in a way that you only declare implicit types when you expect to actually reuse them.

Still, Lambda Expressions, similar if not equal to what in Swift we know as closures, might make code more concise in some situations. So, as usual, it comes down to knowing your tools, and careful considering which tool is the best for the job.

Updated on Sept 24th.

Joe Fabisevich points out that something similar to what the sample code does could be achieved in Swift by typealias-ing a closure, and typing AThing’s doAThing parameter as said typealias.

typealias Command = () -> Void

class AThing {
    func doAThing(_ command: Command) {
        command()
    }
}

let thing = AThing()
thing.doAThing {
    print("hello")
}

typealias Command = () -> Void

class AThing {

func doAThing(_ command: Command) {

command()

}

let thing = AThing()

thing.doAThing {

print("hello")

}

Which is quite similar to a solution based on Java lambdas.

If we need to declare more than one method in the Command interface, though, this approach would fall sort.

Joe also suggests another option in Swift:

protocol Command {
    func execute()
}

struct AThing {
    func doAThing(command: Command) {
        command.execute()
    }
}

class Main {
    init() {
        struct Commander: Command {
            func execute() {
                print("Hello")
            }
        }

        let thing = AThing()
        thing.doAThing(command: Commander())
    }
}

Main()

protocol Command {

func execute()

}

struct AThing {

func doAThing(command: Command) {

command.execute()

}

class Main {

init() {

struct Commander: Command {

func execute() {

print("Hello")

}